RSS представляет страницы, которые активно используются -- для Java это в первую очередь живые объекты в куче и внутренние структуры данных в JVM. Вы мало что можете сделать, чтобы уменьшить его размер, кроме как использовать меньше объектов или делать меньше обработки.

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

Итак, что еще происходит в твоем организме? Это ситуация, когда у вас есть много серверов Tomcat, каждый из которых потребляет 3M RSS? Вы бросаете много флагов GC, они указывают, что процесс проводит большую часть своего времени в GC? У вас есть база данных, работающая на одном компьютере?

редактировать в ответ на комментарии

Что касается размера 3M RSS - да, это казалось слишком низким для процесса Tomcat (я проверил свою коробку, и у меня есть один на 89M, который не был активен некоторое время). Однако Я не обязательно ожидать, что это будет > размер кучи, и я, конечно, не ожидаю, что он будет почти в 5 раз больше размера кучи (вы используете-Xmx640)-в худшем случае это должен быть размер кучи + некоторая константа для приложения.

что заставляет меня подозревать своего номера. Таким образом, вместо графика с течением времени, пожалуйста, запустите следующее, Чтобы получить снимок (замените 7429 на любой идентификатор процесса, который вы используете):

ps -p 7429 -o pcpu,cutime,cstime,cmin_flt,cmaj_flt,rss,size,vsize

(отредактируйте Stu, чтобы мы могли сформировать результаты по вышеуказанному запросу для ps info:)

[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

Edit, чтобы объяснить эти цифры для потомков

RSS, как уже отмечалось, - это размер резидентного набора: страницы в физической памяти. SZ содержит количество страниц, записываемых процессом (заряд фиксации); manpage описывает это значение как "очень грубое". VSZ содержит размер карты виртуальной памяти для процесса: записываемые страницы плюс общие страницы.

обычно VSZ немного > SZ и очень много > RSS. Этот выход указывает на очень необычную ситуацию.

разработка о том, почему единственным решением является сокращение объектов

RSS представляет количество страниц, находящихся в ОЗУ -- страницы, к которым активно обращаются. С Java сборщик мусора будет периодически ходить по всему графу объектов. Если этот объектный граф занимает большую часть пространства кучи, коллектор будет касаться каждой страницы в куче, требуя, чтобы все эти страницы стали резидентами памяти. GC очень хорошо сжимать кучу после каждой основной коллекции, поэтому, если вы работаете с частичной кучей, большая часть страниц не должна быть в ОЗУ.

и некоторые другие варианты

Я заметил, что вы упомянули о наличии сотен до низких тысяч потоков. Стеки для этих потоков также будут добавлены в RSS, хотя это не должно быть много. Предполагая, что потоки имеют небольшую глубину вызова( типичную для потоков обработчика app-server), каждый должен только потреблять одну-две страницы из физической памяти, хотя там половина-Мэг фиксации заряда для каждого.

почему это происходит? Что происходит "под капотом"?

JVM использует больше памяти, чем просто кучи. Например, методы Java, стеки потоков и собственные дескрипторы выделяются в памяти отдельно от кучи, а также внутренние структуры данных JVM.

в вашем случае возможными причинами проблем могут быть: NIO (уже упоминалось), JNI (уже упоминалось), чрезмерное создание потоков.

о JNI, вы написали, что приложение не использовал JNI но... Какой тип драйвера вы используете? Может быть, это тип 2 и утечка? Это очень маловероятно, хотя, как вы сказали, использование базы данных было низким.

о чрезмерном создании потоков, каждый поток получает свой собственный стек, который может быть довольно большим. Размер стека фактически зависит от виртуальной машины, ОС и архитектуры, например, для виртуальная машина JRockit это 256K на Linux x64, я не нашел ссылку в документации Sun для виртуальной машины Sun. Это влияет непосредственно на память потока (память потоков = размер стека потоков * количество потоков). И если вы создаете и уничтожаете много потоков, память, вероятно, не используется повторно.

что я могу сделать, чтобы контролировать реальное потребление памяти JVM?

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

текущий сборщик мусора в Java хорошо известен тем, что не освобождает выделенную память, хотя память больше не требуется. Однако довольно странно, что размер RSS увеличивается до >3 ГБ, хотя размер кучи ограничен 640 МБ. Вы используете какой-либо собственный код в своем приложении или у вас включен собственный пакет оптимизации производительности для Tomcat? В этом случае у вас может быть утечка собственной памяти в вашем коде или в Tomcat.

С Java 6u14, Sun представила новый сборщик мусора" мусор-первый", который способен освободить память обратно в операционную систему, если это больше не требуется. Он по-прежнему классифицируется как экспериментальный и не включен по умолчанию, но если это осуществимый вариант для вас, я бы попытался перейти на новейший выпуск Java 6 и включить новый сборщик мусора с аргументами командной строки "- XX:+UnlockExperimentalVMOptions-XX:+UseG1GC". Это может решить вашу проблему.