RSS представляет страницы, которые активно используются - для Java это в первую очередь живые объекты в куче и внутренние структуры данных в JVM. Вы можете сделать немного, чтобы уменьшить его размер, за исключением использования меньшего количества объектов или меньшей обработки.
В твоем случае я не думаю, что это проблема. График показывает 3 мегабайта, а не 3 гигабайта, как вы пишете в тексте. Это действительно мало и вряд ли вызовет подкачку.
Так что еще происходит в вашей системе? Это ситуация, когда у вас много серверов Tomcat, каждый из которых использует 3M RSS? Вы добавляете много флагов GC, они указывают, что процесс проводит большую часть своего времени в GC? У вас есть база данных, работающая на той же машине?
Редактировать в ответ на комментарии
Что касается размера RSS в 3M - да, это казалось слишком низким для процесса Tomcat (я установил свой флажок, и у меня на 89M был один, который некоторое время не был активным). Тем не менее, я не обязательно ожидаю, что он будет> размером кучи, и я, конечно же, не ожидаю, что он будет почти в 5 раз больше размера кучи (вы используете -Xmx640) - в худшем случае это должен быть размер кучи + некоторое для каждого приложения постоянная.
Что заставляет меня подозревать ваши номера. Итак, вместо графика с течением времени, выполните следующую команду, чтобы получить снимок (замените 7429 на любой идентификатор процесса, который вы используете):
ps -p 7429 -o pcpu,cutime,cstime,cmin_flt,cmaj_flt,rss,size,vsize
(отредактируйте Stu, чтобы мы могли отформатировать результаты к вышеприведенному запросу для информации ps:)
[stu@server ~]$ ps -p 12720 -o pcpu,cutime,cstime,cmin_flt,cmaj_flt,rss,size,vsize
%CPU - - - - RSS SZ VSZ
28.8 - - - - 3262316 1333832 8725584
Редактировать, чтобы объяснить эти числа для потомков
RSS, как уже отмечалось, это размер резидентного набора: страницы в физической памяти. SZ содержит количество страниц, записываемых процессом (плата за фиксацию); man-страница описывает это значение как «очень грубое». VSZ содержит размер карты виртуальной памяти для процесса: доступные для записи страницы и общие страницы.
Обычно VSZ немного> SZ и очень> RSS. Этот вывод указывает на очень необычную ситуацию.
Уточнение того, почему единственное решение - уменьшить количество объектов
RSS представляет количество страниц, находящихся в оперативной памяти - страниц, к которым осуществляется активный доступ. В Java сборщик мусора будет периодически обходить весь граф объектов. Если этот граф объектов занимает большую часть пространства кучи, то сборщик будет касаться каждой страницы в куче, требуя, чтобы все эти страницы стали резидентными. GC очень хорош в сжатии кучи после каждой основной коллекции, поэтому, если вы работаете с частичной кучей, большинство страниц не должно быть в оперативной памяти.
и некоторые другие опции
Я заметил, что вы упомянули о сотнях и тысячах потоков. Стеки для этих тем также добавят в RSS, хотя это не должно быть много. Предполагая, что потоки имеют малую глубину вызовов (типично для потоков обработчика сервера приложений), каждый из них должен занимать только одну или две страницы физической памяти, даже если для каждого из них взимается комиссия в полмигр.