Понимание использования виртуальной памяти> подкачка + физическая в Linux

У меня есть процесс, который сообщает «сверху», что он имеет 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 МБ или около того.

Очевидно, что машина и процесс все еще работают правильно (хотя и медленно), так чего мне здесь не хватает?

Это может быть требование нулевой памяти, которая отсутствует в физической памяти или в файле подкачки.

Некоторые ресурсы, которые вы можете посмотреть:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

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

• http://code.google.com/p/compcache/ ( ЭКСПЕРИМЕНТАЛЬНО )

Это позволяет сжимать и распаковывать страницы памяти в реальном времени. В свою очередь, вы можете хранить все в оперативной памяти, а не на диске ( очень медленно ).

Вот обсуждение вирт против резидентной памяти:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

Обсуждение относится к процессам Java, но применимо ко всему, что работает под Linux. Главное, что касается вирта, это то, что он включает в себя целую кучу вещей, которые никогда не могут быть использованы. Virt - это то, на что нужно обратить внимание в 32-битных ОС (поскольку процессы будут выходить за пределы адресуемого пространства), но в большинстве случаев это бесполезно. Как уже отмечалось, следует обратить внимание на резидентную память, которая будет ограничена доступной физической оперативной памятью и вашей подкачкой.

Вероятно, это связано с тем, что адресное пространство процесса соответствует размеру, который вы указали, но на самом деле оно не выделяется ОС.

От: http://lwn.net/Articles/428100/

В процессе достижения этой цели «достаточно низкие накладные расходы и отсутствие значительных задержек» разработчики Go сделали несколько упрощающих предположений, одним из которых является то, что управление памятью для работающего приложения происходит из единого, практически непрерывного диапазон адресов. Такие предположения могут натолкнуться на ту же проблему, с которой ваш редактор столкнулся с vi - другой код может распределить фрагменты в середине диапазона - поэтому разработчики Go приняли одно и то же решение: они просто выделяют всю память, которая, по их мнению, им может понадобиться (они полагали, разумно, что 16 ГБ должно хватить на 64-битной системе) во время запуска.

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

Ответ, вероятно, MMAP - данные находятся на диске, но они находятся «вне» подкачки и не могут быть видны с помощью команды «free» или «top».

Если процесс Java не слишком сложен, вы можете попробовать поиграть с «lsof», чтобы найти файл MMAP. Однако, если этот Java-процесс сложен, его будет трудно увидеть.

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

К счастью, есть параметр настройки ядра, который можно использовать для переключения режима учета памяти. Этот параметр vm.overcommit_memory, и он указывает, какой алгоритм используется для отслеживания доступной памяти. Значение по умолчанию (0) использует эвристический метод и перегружает систему виртуальной памяти. Если вы хотите, чтобы ваши программы получали соответствующие ошибки нехватки памяти при распределении, а не подвергали ваши процессы случайным убийствам, вам следует установить для этого параметра значение 2.

http://www.linuxjournal.com/article/10678