У меня есть процесс, который сообщает «вверху», что у него выделено 6 ГБ резидентной памяти и 70 ГБ виртуальной памяти. Странно то, что на этом конкретном сервере доступно только 8 ГБ физического и 35 ГБ свободного места для подкачки.
Из «верхнего» руководства:
o: VIRT -- Virtual Image (kb)
The total amount of virtual memory used by the task. It includes
all code, data and shared libraries plus pages that have been
swapped out. (Note: you can define the STATSIZE=1 environment vari-
able and the VIRT will be calculated from the /proc/#/state VmSize
field.)
VIRT = SWAP + RES.
Учитывая это объяснение, я бы ожидал, что выделение виртуальной памяти для процесса будет ограничено моей доступной памятью подкачки + физической памятью.
Согласно pmap, разделы кода, разделяемой библиотеки и разделяемой памяти этого процесса минимальны - не более 300 МБ или около того.
Очевидно, что машина и процесс по-прежнему работают правильно (хотя и медленно), так что же мне здесь не хватает?
Это может быть нулевая память, которой нет в физической оперативной памяти или в файле подкачки.
Некоторые ресурсы, которые вы можете захотеть посмотреть:
Ваше приложение создает много пустых страниц памяти? Если это так, ваше приложение может извлечь большую пользу из:
Он позволяет сжимать и распаковывать страницы памяти в реальном времени. В свою очередь, вы можете хранить все в ОЗУ, а не загружать на диск (очень медленно).
Вот обсуждение вирт и резидентной памяти:
Обсуждение относится к процессам Java, но применимо ко всему, что работает под Linux. Главное в отношении virt заключается в том, что общая сумма включает в себя целую кучу вещей, которые никогда не могут быть использованы. Virt - это то, на что стоит обратить внимание для 32-разрядных ОС (поскольку процессы будут достигать ограничений адресного пространства), но в противном случае он в основном бесполезен. Как уже отмечалось, следует обратить внимание на резидентную память, которая будет ограничена доступной физической RAM и вашим свопом.
Вероятно, это связано с тем, что адресное пространство процесса имеет размер, который вы указали, но на самом деле он не выделяется ОС.
Из: http://lwn.net/Articles/428100/
Пытаясь достичь цели «достаточно низких накладных расходов и отсутствия значительных задержек», разработчики Go сделали несколько упрощающих предположений, одно из которых состоит в том, что память, которой управляют для запущенного приложения, поступает из единого, практически непрерывного диапазон адресов. Такие предположения могут столкнуться с той же проблемой, с которой столкнулся ваш редактор с vi - другой код может выделять части в середине диапазона - поэтому разработчики Go приняли то же решение: они просто выделяют всю память, которая, по их мнению, может им понадобиться (они считали, разумно, что этих 16 ГБ должно хватить в 64-битной системе) во время запуска.
Так что иногда управление памятью осуществляется нелегко - наличие постоянного адресного пространства упрощает освобождение неиспользуемой памяти.
Ответ, вероятно, - MMAP - данные находятся на диске, но находятся «вне» свопа и не могут быть просмотрены с помощью команд «бесплатно» или «вверху».
Если процесс Java не слишком сложен, вы можете попробовать поиграть с «lsof», чтобы найти, где находится файл MMAP. Однако, если этот Java-процесс сложен, его будет трудно увидеть.
Я также был удивлен, что Linux позволяет выделить больше виртуальной памяти, чем есть физической памяти + пространство подкачки, но, видимо, это помогает производительности в типичных ситуациях.
К счастью, есть параметр настройки ядра, который можно использовать для переключения режима учета памяти. Этот параметр - vm.overcommit_memory, и он указывает, какой алгоритм используется для отслеживания доступной памяти. По умолчанию (0) используется эвристический метод и избыточная нагрузка на систему виртуальной памяти. Если вы хотите, чтобы ваши программы получали соответствующие ошибки нехватки памяти при распределении вместо того, чтобы подвергать ваши процессы случайному уничтожению, вам следует установить для этого параметра значение 2.