меньше максимальный размер буфера?

Question

Я возился с моей системой и нашел новый способ использования памяти, но кажется, что команда less содержит только ограниченный объем данных до остановки / уничтожения команды.

Чтобы проверить, бегите (осторожно! очень быстро использует много системной памяти!)

$ cat /dev/zero | less

Из моего тестирования похоже, что команда уничтожается после того, как less достигает 2,5 гигабайта памяти, но я не могу найти ничего на странице руководства, которая предполагает, что это ограничит ее таким образом.

Кроме того, я не смог найти какую-либо документацию через Google по этому вопросу.

Любой свет к этому довольно удивительному открытию был бы великолепен!

Информация о системе: четырехъядерный Intel I7, 8 ГБ оперативной памяти.

$ uname -a
Linux Tyler-Work 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ less --version
less 458 (GNU regular expressions)
Copyright (C) 1984-2012 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04 LTS 
Release:    14.04
Codename:   trusty

Обновить:

Меньшее количество процессов застревает после достижения 2,5 ГБ памяти, но перестает собирать входные данные из потока процесса, переданного по конвейеру. Проверка возвращаемых значений показывает, что процесс cat прерывается сигналом от less.

$ cat /dev/zero | less; echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"
141 0

Выходной статус 141 предполагает, что меньше убивает процесс cat через SIGPIPE (https://stackoverflow.com/questions/19120263/why-exit-code-141-with-grep-q#answer-19120674)

Собирая информацию из самого исполняемого файла, мы получаем, что двоичный файл содержит 64 бита, поэтому он не должен ограничиваться количеством оперативной памяти, которую он может использовать:

$ file /bin/less
/bin/less: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=539cf624699477e3e069b6c4e4b33842f22be2d2, stripped

Что не объясняет, почему less отправляет сигнал уничтожения процессу cat в виде этого определенного количества данных.

Answer 1

Там может быть несколько вещей, исходный код меньше даст вам больше понимания того, что происходит.

Это менее 32-битное приложение? Если это так, то, в зависимости от конфигурации вашего ядра, у вас может быть 3 ГБ, 3,5 ГБ или (чуть меньше) 4 ГБ пространства пользователя.

менее вероятно, что это делает malloc() из кусков памяти на то, что называется кучей. Каковы пределы кучи? Это зависит от конфигурации ядра и других факторов. В какой-то момент меньше, вероятно, запрашивает память, и система говорит, что не может получить ее. Он думает: «Я не могу получить память, я не могу идти вперед, я действительно должен уйти, потому что я не могу идти в ногу с линиями».

Почему на 2.5G? Не знаю, иногда ваш распределитель кучи не полностью эффективен. Вы можете сказать, что 3Gb свободен, но, поскольку вам нужно собрать воедино куски, вы фактически получите меньшие суммы выделения с некоторым отображением свободного места. Я помню одну программу, которая использовала 2 ГБ кучи размером 3,5 ГБ. Небольшие ассигнования настолько фрагментировали кучу, что мы едва получили половину того, что хотели. Помните, что malloc должен быть быстрым и хорошим, иногда быстрый выигрывает у хорошего. Это не Тетрис, где он знает, как идеально вписаться, он торгует эффективностью упаковки на время. Было бы интересным экспериментом использовать другой распределитель (Google tcmalloc кажется особенно старым, если вы знаете, как использовать его с LD_PRELOAD).

Кроме того, это убито? Или оно умирает? Есть эхо $? после того, как это закончится, и вы должны увидеть число <127, если оно делает выход сам, или что-то> 128, если сигнал убил его. Если он убит, возможно, ваш системный жнец убил его, хотя с 8 ГБ ОЗУ, я был бы удивлен, если бы ваша система чувствовала необходимость.

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