Розуміння використання віртуальної пам'яті> своп + фізична в 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/ ( ЕКСПЕРИМЕНТАЛЬНА )

Це дозволяє стискати та розпаковувати сторінки пам'яті в режимі реального часу. У свою чергу, ви здатні зберігати все в оперативній пам’яті, а не замінювати на диск ( дуже повільно ).

Ось обговорення пам'яті virt vs.

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

Обговорення стосується процесів Java, але застосовне до всього, що працює під Linux. Основний момент, що стосується virt, полягає в тому, що загальна кількість включає цілу купу речей, які ніколи не будуть використані. Virt - це те, на що слід звернути увагу на 32-бітні ОС (оскільки процеси матимуть обмеження на адресному просторі), але в значній мірі це не корисно. Як зазначалося, на що слід звернути увагу, це пам'ять резидента, яка буде обмежена доступною фізичною оперативною пам’яттю та вашим свопом.

Це, ймовірно, тому, що адресний простір процесу є розміром, як ви заявили, але він насправді не виділяється ОС.

Від: http://lwn.net/Articles/428100/

У процесі спроби досягти цієї мети "досить низькі накладні витрати та відсутність значної затримки", розробники Go зробили кілька спрощуючих припущень, одне з яких полягає в тому, що пам'ять, якою керує запущена програма, походить з єдиного, практично суміжного. діапазон адрес. Такі припущення можуть зіткнутися з тією ж проблемою, з якою стикається редактор vi - інший код може виділяти фрагменти в середині діапазону - тому розробники Go прийняли те саме рішення: вони просто виділяють всю пам'ять, яку вони думають, що може знадобитися (вони вважали, Зрозуміло, що 16GB має вистачити на 64-бітну систему) під час запуску.

Тож це неелегантний спосіб управління пам’яттю інколи - наявність безперервного адресного простору спрощує звільнення невикористаної пам’яті.

Відповідь, ймовірно, MMAP - дані є на диску, але вони знаходяться "поза" свопом і їх не можна побачити за допомогою команди "free" або "top".

Якщо процес Java не надто складний, ви можете спробувати пограти з "lsof", щоб знайти, де знаходиться файл MMAP. Однак якщо цей процес Java буде складним, це буде важко помітити.

Мене також здивувало, що Linux дозволяє виділити більше віртуальної пам’яті, ніж є фізична пам’ять + простір для обміну, але, очевидно, це допомагає виконувати продуктивність у типових ситуаціях.

На щастя, є параметр настройки ядра, який можна використовувати для перемикання режиму обліку пам'яті. Цей параметр vm.overcommit_memory, і він вказує, який алгоритм використовується для відстеження наявної пам'яті. За замовчуванням (0) використовується евристичний метод і перевершує систему віртуальної пам'яті. Якщо ви хочете, щоб ваші програми отримували відповідні помилки поза пам'яттю при розподілі, а не піддавали вашим процесам випадкові вбивства, слід встановити цей параметр на 2.

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