Чтение страниц - проблема с памятью или кодированием?

Согласно документации MSDN, количество прочтений страниц в секунду — это хороший способ решить, связана ли проблема с системой с нехваткой памяти или с проблемой кодирования/утечкой памяти.

Я ищу некоторые советы от других и способы пойти по пути, чтобы узнать больше.

Я использую следующее на своей машине (Windows 7. 64-разрядная версия. 4 ГБ оперативной памяти)

1. InteliJ 10 (Tomcat for my Web Services & JSP for the front end)
2. Oracle 11g

Я пытаюсь определить, в чем/где может быть проблема, поэтому я создал скрипт в JMeter, чтобы запустить его, чтобы немного дросселировать систему для создания данных и поиска данных в системе.

Запуск монитора производительности в течение 10 минут, мои данные следующие:

Page Reads/Sec (Average): 26.841
Pages Input/Pages Fault = Hard Fault % = 5%
Pages Fault/sec (Avg) = 2300

MSDN говорит, что устойчивое значение более 5 чтений страниц в секунду часто является сильным индикатором нехватки памяти, но это устойчивое значение, а не среднее значение. Он всплескивает несколько раз, но в долгосрочной перспективе кажется, что он колеблется между 0-3 с несколькими всплесками, которые достигают очень больших значений.

Я думал, что проблема может быть в утечке памяти; однако после проверки кода и проверки того, что потоки были закрыты (файлы/входы/подключения к БД/и т. д.), я не уверен.

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

Редактировать 1: Глядя на кучу

В настоящее время я могу получить доступ только к своей системе разработки, а не к производству. Потребуется координировать свои действия с кем-то еще, чтобы получить доступ к журналам и использовать jvisualVM в системе.

Тем не менее, я сделал несколько дампов системы разработки на прошлой неделе и сегодня. Ничего сумасшедшего в использовании классов, кроме String и char[]. Глядя на монитор, мой размер кучи в разработке составляет 463 863, а максимальный - около 480. Используемый колеблется между 415 и 450.

Использование Eclipse Memory Analyzer и «отчет о предполагаемой утечке» в heapdump показывает 3 подозреваемых проблемы.

 1. One instanceo f "org.apache.jasper.servlet.JspServlet" loaded by "org.apache.catalina.loader.StandardClassLoader"  Occupies 18.70%  The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]

 2. The thread org.apache.tomcat.util.threads.TaskThread @ http-apr-8080-exec-19 keeps local variables with total size 12.30%.  The memory is accumulated in one instance of "org.apache.tomcat.util.threads.TaskThread" loaded by "org.apache.catalina.loader.StandardClassLoader"

 3. The thread org.apache.tomcat.util.threads.TaskThread @http-apr-8080-exec-24 keeps local variables with total size 10.72%.  The m emory is accumulated in one instance of "org.apache.tomcat.util.threads.TaskThread'  loaded by "org.apache.catalina.loader.StandardClassLoader"

У меня сложилось впечатление (может быть, ошибаюсь), что некоторые из них нормальны, поскольку TomCat изначально загружает много материала и сохраняет его.


person ist_lion    schedule 07.01.2013    source источник
comment
В любом случае, каков симптом - то есть что медленно? Общее время отклика? Пропускная способность?   -  person Chris    schedule 08.01.2013
comment
По сути, после того, как система используется какое-то время (хотя нет определенного количества времени/пропускной способности, кажется, нет постоянного), система замедляется как по времени отклика, так и по пропускной способности. В конце концов, TomCat останавливается, и сервис должен быть восстановлен.   -  person ist_lion    schedule 08.01.2013
comment
Если системы снова набирают скорость после отказа от tomcat, это исключает Oracle. Можете ли вы использовать jvisualvm в процессе tomcat, чтобы посмотреть на использование кучи java?   -  person Chris    schedule 08.01.2013


Ответы (2)


Одна вещь, которую вы можете сделать, это заглянуть в диспетчер задач и посмотреть, сколько памяти занимают ваши процессы, связанные с Java.

Суммируйте всю память Private Working Set, скажем, 10 наиболее интенсивно использующих память процессов (независимо от того, связаны они с Java или нет). Если это значение близко или превышает 75 % объема вашей физической памяти, ИЛИ если вы используете 32-разрядную операционную систему с отключенным PAE (вы не указали свою операционную систему), это может быть ограничение физической памяти.

Если ваша частная сумма рабочего набора использует намного меньше, чем ваша общая физическая память, скорее всего, это не проблема, связанная с этим. Это также может быть интенсивный дисковый ввод-вывод, связанный с базой данных Oracle; больше памяти позволит вашей системе кэшировать страницы диска в ОЗУ, что значительно ускорит чтение, потому что ОЗУ воспринимается как своего рода диск (но ОЗУ в 20-50 раз быстрее, чем жесткий диск).

person allquixotic    schedule 07.01.2013
comment
Частный рабочий набор из 10 лучших (это JVM и другие разные вещи) составляет примерно 1250/4080, что составляет примерно 30% емкости. Я начну исследовать, связано ли интенсивное использование дискового ввода-вывода с Oracle с действиями, связанными с CRUD. - person ist_lion; 08.01.2013

Если вы диагностируете базу данных Oracle, MSDN — очень плохой источник информации: архитектура SQL Server слишком отличается, чтобы иметь к ней отношение. Вам следует прочитать руководство по концепциям.

Словарь данных в Oracle имеет vпредставления, которые предоставляют различные сведения о производительность системы. Прямо сейчас для вас актуален V$SGA_TARGET_ADVICE; это покажет вам прогнозируемый эффект увеличения или уменьшения системной памяти. Fузнайте больше.

person APC    schedule 08.01.2013