grep кушает всю память на большом файле

Этого не может быть. Он построчно файл читает. Скорее всего ты iconv первым выполняешь, а потом grep

Может у него 10 гб файл из одной строки - вот и читает её всю.

«cat file | grep ...» даёт такой же результат?

IMHO когда эти утили видят регулярный файл, то они читают его через mmap(). Так быстрее, но весь файл оказывается в памяти.

А из пайпы/сокета они читают стандартным read().

PS grep с регулярками тоже может жрать память.

Это заговор.

Я по-разному пробовал.

Для iconv нашел даже скрипт iconv-chunks.

с cat ... жрет медленнее, но память всё равно растёт.

Как память мерил?

Для iconv такое поведение норма https://sourceware.org/bugzilla/show_bug.cgi?id=6050 что напрямую, что из пайпа он пытается прочитать весь файл, чтобы проще было. Я так и не понял из обсуждения бага, действительно ли iconv может работать без буферезации всего файла/потока или нет и насколько рабочие патчи предложены.

А с grep непонятно. Что за файл, там нет очень длинных строк? И насколько сложное регулярное выражение?

LC_ALL=C

htop столбец RES

не, всё равно уже 20Г отожрал

Про строки думал, наверное стоит проверить.

Но вобще не должно быть, там дамп базы в формате csv гигабайт на 100.

А условие позволяет использовать fgrep?

Я пробовал grep -F, не помогает.

Попробуй powershell.

Присоединяюсь к части выше отписавшихся. Покажите само условие которое используете в грепе.

условие примерно такое

cat file | grep 12345678

файл около 100Гб, никаких регекспов искать не надо.

В таком варианте через пайп память растёт, но медленно. В варианте

grep 12345678 file

он явно всё пытается всосать наверное через mmap и быстро прибивается earlyoom.

Вот wc -L - хорошая команда, занял 2Мб res и спокойно считает.

файл около 100Гб

Что он из себя представляет?

никаких регекспов искать не надо grep 12345678

man grep

А, уже вижу, что дамп базы. Кто бы сомневался. Надо его загрузить и пользоваться нормальными инструментами СУБД, а не утилитами для небольших файлов.

man grep

-F я пробовал, если ты про это

не утилитами для небольших файлов.

Это всё понятно, непонятно что заставляет разработчиков grep и iconv всасывать всё в память. Я как-то думал, что эти утилиты про потоки, чтоб можно было удобно сделать кучу пайпов и нормально обработать гигабайты данных.

А не, я всё понял, wc -L наконец то посчитал. Там правда есть очень очень длинная строка или файл побился.

Проверил сейчас (даже без LC_ALL и -F) на файле в несколько десятков гигов, память не жрет и целиком в нее файл не засовывает

grep 123456789 file

Ну да, вопросов к грепу нет, у меня это из-за битого файла с очень длинной строкой. К iconv скорее вопросы есть, но да чёрт с ним.)

-F я пробовал, если ты про это

Да, про это. Поленился прочесть все комментарии перед тем, как отвечать :)

Проблему iconv решил uconv, он не сосёт всё в себя.

grep не кушает