31 (21.10.2014 11:31:35 отредактировано valet)

Fat-Zer пишет:

нужны строки не меньше нескольких мегабайт во входном файле, чтобы это дало заметный оверхед по памяти  grep'у...

а, понял.
Но смотрите , ну что значит оверхед - не, ну я понимаю если бы grep вылетел с руганием что ему не хватает памяти и на этом все закончилось - так нет - он еще и приводит к полному дауну сервера, что-то тут в любом случае не так, ну разве нет?
В конце концов непонятно, ну кончилась память, ну сожрал все grep, почему не оборвется сам grep и не освободит память, а сервер бы себе продолжил нормальную работу.

32 (21.10.2014 14:22:41 отредактировано Fat-Zer)

valet пишет:

Но смотрите , ну что значит оверхед - не, ну я понимаю если бы grep вылетел с руганием что ему не хватает памяти и на этом все закончилось - так нет - он еще и приводит к полному дауну сервера, что-то тут в любом случае не так, ну разве нет?

grep, как и абсолютное большинство пользовательских процессов не заботятся о том, сколько памяти они используют... они будут есть сколько захотят и сколько дадут... в большинстве случаев, если им не дают, сколько они хотят они просто умирают...
Но вот при истощении памяти в игру вступает OOM killer... он конечно старается убить виновников торжества в первую очередь, но это не гарантируется... недостаток памяти — критическая ситуация из котиорой надо выйти хоть как-то...  про то как работает OOM неплохо расписано тут: http://catap.ru/blog/2009/05/03/about-m … om-killer/ в современных ядрах всё уже поменялось: http://git.kernel.org/cgit/linux/kernel … eb8435cd10

95% процентов проблем находятся между клавиатурой и стулом.

33

valet пишет:

не приводит на другом сервере.

ну сразу  видно не программиста. Вы уж меня простите, но вы пытаетесь спорить с очевидным. Это было-бы смешно, когда-бы не было так грустно…

valet пишет:

то есть исключить big_file из very_big_file

зачем fgrep???
Я  же вам ман цитировал: УСТАРЕЛО, НЕ НУЖНО, нужно только для  того, что-бы старый код  не сломался. А сейчас  нужно писать grep -F, что ПОКА ЕЩЁ тоже самое.

valet пишет:

Не важно какой это процесс и что он выполняет, я вот пытаюсь понять другое - почему он сжирает всю память и ладно сжирает - уводит сервер в даун и судя по выполнению такой же конструкции на другом сервере такого таки не должно происходить...

потом у что опции -F и -f взаимоисключающие.  Как это я понимаю.

Fat-Zer пишет:

бред же... в мане всё сказано:

ЧТО сказано? Что вы вообще тут сделали? ЯННП.

Fat-Zer пишет:

а ещё grep -F в разы менее прожорлив (а про то что он всё равно прожорлив как раз и тема) и в разы быстрее...

зачем вообще смешивать эти опции? Ведь -f и так берёт образцы из каждой строки. Вместе это  CENSORED какая-то непонятная. И поведение у неё UB.

valet пишет:

В конце концов непонятно, ну кончилась память, ну сожрал все grep, почему не оборвется сам grep

откуда сервер знает, что grep вам не шибко и  нужен? Ну  и браузер жрёт память  не очень быстро. Ну и может  на десктопе браузер увяз в своп,  а на сервере своп "не нужен". Откуда мне знать? Сотни причин могут быть, OOM  Killer это набор эвристик, это магия, а не наука.

Fat-Zer пишет:

в современных ядрах всё уже поменялось

всё, кроме принципа работы.

valet пишет:

если бы grep вылетел с руганием

когда grep смотрит на память, то видит 18  446 744 073 709 551 616  байт.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

34

drBatty пишет:

Ведь -f и так берёт образцы из каждой строки.

drBatty, тяжёлый день? без -F он каждую строку парсит на регулярки...

drBatty пишет:

всё, кроме принципа работы.

нуда... зато лизергин кончился и всю эту эвристику нахер выкинули, а оставили только максимум (rss+swap) и руту 3% форы...

95% процентов проблем находятся между клавиатурой и стулом.

35

drBatty пишет:

ну сразу  видно не программиста. Вы уж меня простите, но вы пытаетесь спорить с очевидным. Это было-бы смешно, когда-бы не было так грустно…

моя твоя не понимать ab что имеется ввиду?
ну я то программист, может просто не такой крутой как вы ab

drBatty пишет:

потом у что опции -F и -f взаимоисключающие.  Как это я понимаю.

мне кажется вы неправильно понимаете
насколько знаю я:
-f - ключ для указания что патерны будут браться с файла
-F - то что патерны будут обрабатываться не как регулярные выражения а как просто строки, что аналогично fgrep

drBatty пишет:

откуда сервер знает, что grep вам не шибко и  нужен? Ну  и браузер жрёт память  не очень быстро. Ну и может  на десктопе браузер увяз в своп,  а на сервере своп "не нужен". Откуда мне знать? Сотни причин могут быть, OOM  Killer это набор эвристик, это магия, а не наука.

тогда поставим вопрос по-другому: хорошо, кончилась память, сожрал кто-то, что делать? - молча лечь, разве система не достаточно умна, чтобы правильно обработать эту ситуацию - например убить виновника...

36

Fat-Zer пишет:

drBatty, тяжёлый день? без -F он каждую строку парсит на регулярки...

именно, ты меня опередил ab

37 (21.10.2014 14:51:10 отредактировано valet)

Fat-Zer пишет:

нуда... зато лизергин кончился и всю эту эвристику нахер выкинули, а оставили только максимум (rss+swap) и руту 3% форы...

я правильно понимаю, это как раз та причина по которой у меня на новом сервере подобное происходит? и кстати там у меня Debian 7, а на том сервере, где все работает Debian 6

38

Fat-Zer пишет:

тяжёлый день? без -F он каждую строку парсит на регулярки...

да?
ну может быть.
может я  и ошибся...  Задача изначально бредовая, и не для  grep.

Fat-Zer пишет:

зато лизергин кончился и всю эту эвристику нахер выкинули

бывает.  Вернут обратно.

valet пишет:

тогда поставим вопрос по-другому: хорошо, кончилась память, сожрал кто-то, что делать? - молча лечь, разве система не достаточно умна, чтобы правильно обработать эту ситуацию - например убить виновника...

проблема в том, что "виновник" проявляется в момент _использования_  памяти. А этот момент случаен. И убивать надо вовсе не того, кто съел последний байт.

Fat-Zer пишет:

руту 3%

чудесно! Это X что-ли? Что-бы туда тёк хромой браузер? Впрочем,  на неделю 4Гб памяти хватает пока.

valet пишет:

я правильно понимаю, это как раз та причина по которой у меня на новом сервере подобное происходит?

нет. Это скорее причуды новой grep, её недавно сильно улучшили, и ускорили в 10 раз или типа того.

А вы похоже первый, кто додумался её протестировать на таких файлах. Мне-бы такое и в голову не пришло-бы.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

39

drBatty пишет:

Задача изначально бредовая, и не для  grep.

задачи «найти строки, которые есть в обоих файлах» или «исключить из файла строки, которые есть в другом»  решаются как раз grep'ом и на вменяемых размерах файлов это прекрасно работает...

drBatty пишет:

нет. Это скорее причуды новой grep, её недавно сильно улучшили, и ускорили в 10 раз или типа того.

не... ускорили его с 2.19-й версии, а ТС божиться, что у него 12-я...
кстати, по тестам видно, что 20-я в полтора раза прожорливей 16-й вышла...

valet пишет:

тогда поставим вопрос по-другому: хорошо, кончилась память, сожрал кто-то, что делать? - молча лечь, разве система не достаточно умна, чтобы правильно обработать эту ситуацию - например убить виновника...

он и должен убивать виновника, но, во-первых, виновника можно неправильно определить, а, во-вторых, это может быть отключено (для проверки см. grep -H . /proc/sys/vm/*{oom,over}*)

valet пишет:

я правильно понимаю, это как раз та причина по которой у меня на новом сервере подобное происходит? и кстати там у меня Debian 7, а на том сервере, где все работает Debian 6

основная причина в том что ты скормил grep'у немерено паттернов и он съел всю память...
а вот почему OOM убил не grep'а, а кого-то важного — вопрос... на новых ядрах всё как раз должно было бы быть в порядке...

95% процентов проблем находятся между клавиатурой и стулом.

40

Fat-Zer пишет:

задачи «найти строки, которые есть в обоих файлах» или «исключить из файла строки, которые есть в другом»  решаются как раз grep'ом и на вменяемых размерах файлов это прекрасно работает...

у каждого инструмента есть границы применимости. За ними  инструмент ведёт себя непредсказуемо.

Fat-Zer пишет:

не... ускорили его с 2.19-й версии, а ТС божиться, что у него 12-я...
кстати, по тестам видно, что 20-я в полтора раза прожорливей 16-й вышла...

ну как я понял ТСа, с 16й проблем как раз нет. Хотя понять ТСа  сложно…  На самом деле, grep просто не для того сделана.  Файл в котором ищут может быть громадным, но:
1. это должен быть текстовый файл. Ну или что-то похожее.
2. Поиск разных вариантов  сразу — дополнительная фича, просто что-бы пару-тройку строк  найти. Но не миллионы жеж!
И никто не говорил, что оно работать не будет.  Будет. Но как —  никто не знает.

PS: дал я маху  с ключами. Но проблема в  том, что я вообще охренел, от такого решения задачи.

PPS: ИМХО  нет никакой "странности".  Классический случай GIGO.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

41

drBatty пишет:

ну как я понял ТСа, с 16й проблем как раз нет.

не знаю... я думаю, что ТС как раз или -F забыл или какая-то CENSORED из-за проблем с бинарными данными... второе воспроизвести без точных данных будет сложно...

drBatty пишет:

Но проблема в  том, что я вообще охренел, от такого решения задачи.

а какие на баше альтернативы? только исходный файл разбить на два десятка, а дальше то же самое...  об этом подумаешь только когда наступишь на грабли (или предвидишь их) и это те же яица только в профиль...

95% процентов проблем находятся между клавиатурой и стулом.

42

Fat-Zer пишет:

а какие на баше альтернативы?

а при чём тут bash? Grep к нему вообще  никак  не относится.

Что до  альтернатив, то сама задача неправильная.  ТС что-то делает не так, и проблема тут совсем не в grep.

ЗЫЖ как альтернативу именно на bash'е могу предложить следующее:

1. считаем CRC32 каждой строки из файла образцов.
2. загоняем их в bash-массив

3. читаем построчно файл, и считаем CRC32 строки
4. проверяем наличие строки в массиве

Тут всё имеет сложность O(N), кроме п4, который имеет сложность O(Nlog(N)), а следовательно, можно строго доказать, что существует некое M, начиная с которого данный алгоритм порвёт способ с grep.

Это M конечно достаточно большое, но у ТСа оно всяко ещё больше.

Очевидно, что использовать для этого именно bash не обязательно, хотя особого профита даже ассемблер тут не принесёт п сравнению с bash.

PS: да, возможны коллизии CRC32, это не страшно. Просто надо сравнить ещё и строки, если совпала CRC32. Это будет случаться раз в 100 лет, т.ч. на производительность  не влияет.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

43

Fat-Zer пишет:

задачи «найти строки, которые есть в обоих файлах» или «исключить из файла строки, которые есть в другом»

полностью согласен, тем более задача разовая...

[root@server ~] $ grep -H . /proc/sys/vm/*{oom,over}*
/proc/sys/vm/oom_dump_tasks:1
/proc/sys/vm/oom_kill_allocating_task:0
/proc/sys/vm/panic_on_oom:0
/proc/sys/vm/memory_failure_recovery:1
/proc/sys/vm/nr_overcommit_hugepages:0
/proc/sys/vm/overcommit_memory:0
/proc/sys/vm/overcommit_ratio:50

Тут что-то надо сменить? как именно? чтобы нормально убивался именно виновник?

drBatty пишет:

Хотя понять ТСа  сложно…

это почему так? Вот мне например иногда сложно понять собеседников из-за недостатка знаний, так как у них их поболее чем у меня в этой тематике, но тут же наоборот ab

drBatty пишет:

1. это должен быть текстовый файл. Ну или что-то похожее.

так и есть

Fat-Zer пишет:

не знаю... я думаю, что ТС как раз или -F забыл или какая-то CENSORED из-за проблем с бинарными данными...

ну насколько я знаю fgrep и grep -F - то же самое, я просто привык использовать fgrep, а на счет данных - в файле с патернами были строки, состоящие из одного или группы всяких спецсимволов типа !";%:?*(),. - может в этом проблема.

drBatty пишет:

Что до  альтернатив, то сама задача неправильная.

и чего это она неправильная - отобрать все строки с файла, которых нету в другом или другими словами вычесть из одного файла содержимое другого - что неправильного в этой задаче, ИМХО вполне распространенная задача и решается именно так (ну по крайней мере я ее решаю всегда именно так)

drBatty пишет:

ТС что-то делает не так

и что же я делаю не так? ab

drBatty пишет:

ЗЫЖ как альтернативу именно на bash'е могу предложить следующее:

да ну - совсем сложно выглядит для такой элементарной задачи, зачем писать велосипед если эти вещи должен делать grep

44

valet пишет:

ну насколько я знаю fgrep и grep -F - то же самое

просто fgrep устарела.

valet пишет:

зачем писать велосипед

что-бы избавится от квадратичной сложности. Если строк в  образце 2 или 3, то это не имеет значения,  но у вас другой случай.

valet пишет:

эти вещи должен делать grep

ну делайте, я  не против. Напомню, что проблема у вас, а  не у меня.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

45 (25.10.2014 14:39:00 отредактировано valet)

drBatty пишет:

ну делайте, я  не против. Напомню, что проблема у вас, а  не у меня.

я понимаю, но проблема в том, что это не катит только на одном сервере, на другом все благополучно проходит, я специально закачал туда эти файлы и показал результаты - все ок.
Еще раз уточняю - это была разовая задача, которая кое когда возникала и благополучно решалась на 3 разных тележках, а вот на новом мощнейшем сервере с 64 ГБ памяти она почему-то не решается стандартными инструментами.
Мне важен был результат, я его получил на другом сервере и забыл ab но все равно конечно интересно, почему не катит на самом мощном...

46

valet пишет:

но проблема в том, что это не катит только на одном сервере

вот видите? В том и проблема, что UB отлично работает на локалхосте, а в продакшене падает. (у вас немного другой случай, но суть та же).

но все равно конечно интересно, почему не катит на самом мощном...

ещё раз: дело не в "мощности", дело в неправильном решении.

Я ещё и не то видел, у меня команда срабатывала, но НЕПРАВИЛЬНО (т.е. в результате были неверные строки), причём никаких сообщений не вывело. Но если вам это нравится -- ваше дело. Я не желаю прыгать по заминированной трясине UB.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

47

drBatty пишет:

вот видите? В том и проблема, что UB отлично работает на локалхосте, а в продакшене падает. (у вас немного другой случай, но суть та же).

ничего не понял

drBatty пишет:

ещё раз: дело не в "мощности", дело в неправильном решении.

это решение правильное, если бы оно было неправильное, оно бы не работало нигде, а оно работает везде кроме одного сервера, и выдает правильный результат, еще раз повторяю - часто использую подобную конструкцию - никогда не испытывал каких либо проблем.

drBatty пишет:

Я не желаю прыгать по заминированной трясине UB.

что такое UB? переведите, не гуглится...

48

valet пишет:

ничего не понял

плохо, когда то работает, то не работает. Намного хуже, чем если не работает вовсе.

valet пишет:

это решение правильное, если бы оно было неправильное, оно бы не работало нигде

погуглите

x++ + ++x;
valet пишет:

что такое UB?

undefined behavior
https://ru.wikipedia.org/wiki/%D0%9D%D0 … 0%B8%D0%B5

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

49

drBatty пишет:

плохо, когда то работает, то не работает

дык не так же ab. На одной тележке всегда работает, на другой всегда нет ab

50

valet, вы таки погуглите про x++ + ++x, оно так всегда и бывает.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)