Мы находимся в середине проекта по переносу нашей инфраструктуры из ситуации совместного использования в Amazon EC2, и мы заметили некоторые странные характеристики памяти процессов в нашей настройке. Не вдаваясь в подробности о специфике наших процессов, мы заметили, что на наших инстансах EC2 «вверху» будут показаны процессы, использующие много пространства подкачки - фактически, намного больше, чем объем доступного подкачки или (если вы все это сложите) больше, чем доступный диск.
Вот пример основного вывода:
Mem: 7136868k total, 5272300k used, 1864568k free, 256876k buffers
Swap: 1048572k total, 0k used, 1048572k free, 2526504k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
4121 jboss 20 0 5913m 603m 14m S 0.7 8.7 3:59.90 5.2g java
22730 root 20 0 2394m 4012 1976 S 2.0 0.1 4:20.57 2.3g PassengerHelper
20564 rails 20 0 2539m 220m 9828 S 0.3 3.2 0:23.58 2.3g java
1423 nscd 20 0 877m 1464 972 S 0.0 0.0 0:03.89 876m nscd
Вы можете видеть, например, что jboss, как сообщается, использует 5,2 ГБ пространства подкачки, что определенно невозможно, поскольку выделено только 1 ГБ и ничего не используется (вероятно, потому, что еще 1,8 ГБ ОЗУ).
И вот результаты uname -a:
Linux xxx.yyy.zzz 2.6.35.14-106.53.amzn1.x86_64 #1 SMP Fri Jan 6 16:20:10 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Мы запускаем AMI на основе AMI Amazon Linux по умолчанию (Amazon Linux AMI выпуска 2011.09, поэтому некоторые RHEL5 и RHEL 6) с небольшим количеством настроек и определенно без настроек уровня ядра.
Что-то здесь подсказывает мне, что в этом конкретном ядре / дистрибутиве отчет об использовании подкачки или, возможно, даже об общем использовании памяти - это не то, чем кажется ...
Любая помощь будет оценена по достоинству!
По факту, jboss использует 5,9 ГБ виртуальной памяти и не использует пространство подкачки. В top инструмент использует неверную формулу для вычисления того, что он ошибочно сообщает как пространство подкачки. Фактически это результат вычитания размера резидентного набора из размера адресного пространства. Это глупая вещь, поскольку одна - это мера виртуальной памяти, а другая - мера физической памяти. Так что не совсем понятно, какой результат вообще является мерой. Число так же бессмысленно, как пропавший доллар в старая загадка.
(На самом деле, это не совсем бессмысленно. Это максимальный объем пространства подкачки, который может потребоваться текущим сопоставлениям программы, если они все были загрязнены, а размер резидентного набора программы не изменился. Это действительно, очень близко к бессмысленному, хотя это не занимает во внимание, доступны ли вообще эти сопоставления для записи.)