Почему процесс убивается на 4 ГБ?

Question

Я написал программу, которая работает с огромным набором данных. Мой процессор и ОС (Ubuntu) являются 64-битными, и у меня есть 4 ГБ ОЗУ. Используя "top" (поле% Mem), я увидел, что потребление памяти процессом возросло примерно до 87%, то есть 3,4+ ГБ, а затем его убили.

Затем я проверил, сколько памяти может получить доступ к процессу, используя "uname -m", которая выглядит как "неограниченная".

Теперь, поскольку ОС и ЦП являются 64-разрядными, а также существует раздел подкачки, ОС должна была бы использовать виртуальную память, т. Е. Всего [> 3,4 ГБ + yGB из пространства подкачки], и только если процессу требовалось больше память, он должен был быть убит.

Итак, у меня есть следующий квест:

1. Сколько физической памяти теоретически может получить доступ к процессу на 64-битном м / с. Мой ответ 2 ^ 48 байт.
2. Если существует менее 2 ^ 48 байт физической памяти, то ОС должна использовать виртуальную память, правильно?
3. Если ответом на вышеуказанный вопрос является ДА, то ОС должна была также использовать пространство SWAP, почему оно убило процесс без его использования. Я не думаю, что мы должны использовать какие-то конкретные системные вызовы, которые кодируют нашу программу, чтобы это произошло.

Пожалуйста, предложите.

Answer 1

Причиной может быть не только размер данных.Например, выполните ulimit -a и проверьте максимальный размер стека.У тебя есть причина убийства?Установите 'ulimit -c 20000', чтобы получить файл ядра, он показывает причину, когда вы проверяете его с помощью gdb.

Answer 2

Проверьте с помощью file и ldd, что ваш исполняемый файл действительно 64-битный.

Проверьте также ограничения ресурсов.Внутри процесса вы можете использовать системный вызов getrlimit (и setrlimit, чтобы изменить их, когда это возможно).Из оболочки bash попробуйте ulimit -a.Из оболочки zsh попробуйте limit.

Проверьте также, что ваш процесс действительно потребляет память, которую, как вы полагаете, он потребляет.Если его pid 1234, вы можете попробовать pmap 1234.Изнутри процесса вы можете прочитать /proc/self/maps или /proc/1234/maps (которые вы можете прочитать из терминала).В вашем /proc/self/ ...

также есть /proc/self/smaps или /proc/1234/smaps и /proc/self/status или /proc/1234/status и другие файлы. Проверьте с помощью free, что у вас есть память (и своп)космос) ты веришь.Вы можете добавить некоторое временное пространство подкачки с помощью swapon /tmp/someswapfile (и использовать mkswap для его инициализации).

Несколько месяцев (и несколько лет назад) я обычно мог запускать процесс 7Gb(огромная cc1 компиляция), под Gnu / Linux / Debian / Sid / AMD64, на машине с 8 ГБ ОЗУ.

И вы можете попробовать с крошечной тестовой программой, которая, например, выделяется с mallocнесколько блоков памяти, например, 32 МБ каждый.Не забудьте написать несколько байтов внутри (по крайней мере, на каждый мегабайт).

стандартные контейнеры C ++, такие как std::map или std::vector, по слухам, занимают больше памяти, чем мы обычно думаем.

Купите больше оперативной памяти, если это необходимо.Это довольно дешево в наши дни.

Answer 3

То, к чему можно обратиться буквально, ВСЕ должно соответствовать этому, включая ваши графические адаптеры, ядро ​​ОС, BIOS и т. Д., И объем, который можно адресовать, также не может быть увеличен с помощью SWAP.

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