Сообщений в теме: 36

[Dmitry_NJ]

Подскажите пожалуйста, какие инструменты позволяют обнаружить утечки памяти web приложений. Насколько я понимаю, нужно получать статистику с веб-сервера, в нашем случае это Apache.

Статистику, специфичную для Apache (ReqPerSec, BytesPerSec, BytesPerReq, BusyWorkers, IdleWorkers, Requests currently being processed etc.) можно получить, например, с помощью вот такого инструмента SiteScope. Только скорее всего эта информация не даст вам то, что вы хотите получить. Если я правильно понимаю, то вам надо отслеживать сколько памяти потребляет java.exe процесс, который запускает ваш Apache сервер. SiteScope позволит получить и такую информацию тоже.

[Elena12]

Подскажите пожалуйста, какие инструменты позволяют обнаружить утечки памяти web приложений. Насколько я понимаю, нужно получать статистику с веб-сервера, в нашем случае это Apache.

Само web-приложение на каком языке реализовано?

Приложение на Java.

[Elena12]

Подскажите пожалуйста, какие инструменты позволяют обнаружить утечки памяти web приложений. Насколько я понимаю, нужно получать статистику с веб-сервера, в нашем случае это Apache.

Статистику, специфичную для Apache (ReqPerSec, BytesPerSec, BytesPerReq, BusyWorkers, IdleWorkers, Requests currently being processed etc.) можно получить, например, с помощью вот такого инструмента SiteScope. Только скорее всего эта информация не даст вам то, что вы хотите получить. Если я правильно понимаю, то вам надо отслеживать сколько памяти потребляет java.exe процесс, который запускает ваш Apache сервер. SiteScope позволит получить и такую информацию тоже.

Спасибо, я посмосмотрю SiteScope. А средствами нагрузочного тестирования таких данных нельзя получить?

[Dmitry_NJ]

Спасибо, я посмосмотрю SiteScope. А средствами нагрузочного тестирования таких данных нельзя получить?

Конечно же можно. Принцип будет тот же (ставите мониторы на Apache, на memory и на все, что вам нужно знать), только будете отслеживать не реальных пользователей, а виртуальных, что в вашем случае роли не играет. Только трудоемкость будет больше - придется этих виртуальных пользователей (скрипты) еще создать и отладить. Кстати, если у вас есть LoadRunner, то в нем можно использовать как его родные мониторы, так и мониторы из SiteScope, поскольку SiteScope интегрируется в LoadRunner без проблем.

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

[Green]

To Elena12

Елена, методика выявления утечек памяти веб приложений может строиться по следующему алгоритму.

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

На время тестирования на сервере должны быть прекращены все другие активности. Это необходимо для того, что бы быть уверенным, что ни какие другие (не учтенные действия) не оказали влияние на результат.

Затем снимаются показания счетчиков системы. В первую очередь, показатели использования виртуальной памяти. Затем начинается процесс тестирования приложения - выполняются тест кейсы.

Объем используемой виртуальной памяти может и чаще всего постоянно изменяется. Это зависит как от самого приложения, так и от того какой механизм используется вашим веб сервером. Если это Апач до 2 версии, то он использует модель с управлением по процессам с главным процессом, который назначает процесс каждому новому соединению. Если 2 и выше, то в нем реализована многопоточная архитектура с размещением ресурсов в динамических областях (пулах), которые автоматически высвобождаются после завершения процесса.

Повторно метрики снимаются после выполнения всех тест кейсов. При возвращении сервера и приложения в ждущий режим в идеальном случае объем используемой виртуальной памяти должен вернуться к размеру, который был до начала тестов. Это очевидно. Все открытые при тестировании процессы, после их завершения, должны высвободить занимаемую ими виртуальную память. Но в действительности это не совсем так. Как правило еще некоторое время виртуальная память имеет "повышенный уровень". Это связано с тем, что начало и завершение процесса очень ресурсоемкая и долгая (с точки зрения производительности сервера) операция. Поэтому сервер подстраивается под существующую нагрузку и держит среднее число процессов или пулов, достаточным, что бы удовлетворить все возможные запросы. Но, со временем, при падении уровня нагрузки количество ждущих процессов должно вернуться к предтестовому уровню. И отклонение показателей использования виртуальной памяти не должно быть очень большим. Речь идет о процентах.

Если же после окончания тестирования и по прошествии долгого времени (например час), не происходит существенного снижения объема используемой виртуальной памяти, то это является верным признаком наличия ее утечки. В этом случае имеет смысл провести более длительную серию тестов (например на 8 часов) и повторно произвести замеры. Для выявления процесса, который имеет утечку необходимо провести анализ всех процессов, используемых в работе приложения и сервера. На снятых показаниях такой процесс будет хорошо заметен на фоне других, так как используемый им объем виртуальной памяти останеться большим, в то время как у остальных этот показатель вернется к нормальному размеру.

Далее следует обратиться к разработчикам и документации сервера, что бы определить, какие именно действия приложения вызвали появление утечки.

Успехов.
B)

[Elena12]

Спасибо за подробное объяснение.

Затем снимаются показания счетчиков системы. В первую очередь, показатели использования виртуальной памяти. 

В целом понятно, если не секрет, чем вы пользуетесь для снятия показателей использования виртуальной памяти?

[barancev]

Эх, есть мне что сказать, да времени не хватает, длинный пост получится. На всякий случай спрошу сначала вот какой вопрос: Елена, Вам нужно просто узнать, есть утечки памяти или нет их, или Вы знаете (или хотя бы подозреваете), что они есть и хотите обнаружить причину?

[Elena12]

Эх, есть мне что сказать, да времени не хватает, длинный пост получится. На всякий случай спрошу сначала вот какой вопрос: Елена, Вам нужно просто узнать, есть утечки памяти или нет их, или Вы знаете (или хотя бы подозреваете), что они есть и хотите обнаружить причину?

Я подозреваю что они есть и надо подтвердить мои подозрения :rolleyes:
Допустим что причины мне не интересны.

[barancev]

Эх, есть мне что сказать, да времени не хватает, длинный пост получится. На всякий случай спрошу сначала вот какой вопрос: Елена, Вам нужно просто узнать, есть утечки памяти или нет их, или Вы знаете (или хотя бы подозреваете), что они есть и хотите обнаружить причину?

Я подозреваю что они есть и надо подтвердить мои подозрения :rolleyes:
Допустим что причины мне не интересны.

Тогда пост будет достаточно короткий :)

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

Итак, веб-приложения на Java обычно изготавливаются в виде компонентов, которые выполняются в так называемом контейнере, который управляет жизненным циклом этих компонентов. Контейнер выполняется как отдельный процесс. Он может либо сам выступать в роли веб-сервера, в этом случае никакого апача вообще не будет, либо обслуживать только динамические запросы, а статические запросы выполняет веб-сервер (например, apache), который находится перед ним. То есть в этом втором случае веб-сервер принимает запрос, если может - обслуживает сам, если не может - передаёт его контейнеру, он генерирует ответ, отдаёт его обратно веб-серверу, а последний переправляет его клиенту. Конец лирического отступления.

Переходим к делу.

1. Для того, чтобы обнаружить утечки в веб-приложении, мониторить веб-сервер бессмысленно, нужно мониторить контейнер (Tomcat или JBoss или JRun или WebSphere или что-там у Вас).

2. Для того, чтобы исключить наведённые эффекты, следует веб-сервер и контейнер запускать в тестовом режиме. При этом они выполняются в однопроцессном/однопоточном режиме, не кешируют ответы и т.д. Кроме того, в таком режиме проще измерять.

3. Можно пользоваться всей указанной в вышеприведённых советах техникой измерений, но вот какой есть момент - Java-машина захватывает память кусками, а расходует понемногу, поэтому при небольшой утечке придётся долго ждать, пока она соберётся захватывать следующий кусок. Для упрощения дела можно использовать какой-нибудь Java-специфичный монитор памяти, который покажет реально используемую память и динамику работы сборщика мусора. Например, jvmstat от Sun (универсальный) или JMeter от Apache (заточенный специально для мониторинга контейнера Tomcat).

Не используйте для мониторинга полноценные профилировщики, даже коммерческие, если Вы лично не проверяли их в деле - они могут врать или даже сами провоцировать утечки памяти, используйте лёгкие инструменты.

4. Не пренебрегайте также обычными средствами мониторинга памяти, занимаемой приложениями - top на Unit-системах или perfmon на Windows-системах, даже делая более точное изменение Java-специфичным монитором.

5. Когда убедитесь, что утечки памяти есть - приходите, продолжим рассмотрение дела.

[Mr.First]

опыт тестирования WEB-прилоежений, написанных на VBS, JAVA.
С применением Framework.net

[barancev]

опыт тестирования WEB-прилоежений, написанных на VBS, JAVA.
С применением Framework.net

Это что, резюме? B)

[Mr.First]

нет...
просто если у кого возникнут вопросы по тестированию web-приложений с использованием этих технологий, я смогу посоветовать или просто обменяться опытом

[Dmitry_NJ]

опыт тестирования WEB-прилоежений, написанных на VBS, JAVA.
С применением Framework.net

Это вообще к чему? Рекламная пауза что ли?

[Mr.First]

для особо одаренных повторяю:
если у кого возникнут вопросы по тестированию web-приложений с использованием этих технологий, я смогу посоветовать или просто обменяться опытом

[mdmax]

опыт тестирования WEB-прилоежений, написанных на VBS, JAVA.
С применением Framework.net

Хочу уточнить, вы тестируете Java приложения с применением Framework.net ??? )

[Mr.First]

опыт тестирования WEB-прилоежений, написанных на VBS, JAVA.
С применением Framework.net

Хочу уточнить, вы тестируете Java приложения с применением Framework.net ??? )

нет, приложения написаны на VBS или C#

[Case]

для особо одаренных повторяю:
если у кого возникнут вопросы по тестированию web-приложений с использованием этих технологий, я смогу посоветовать или просто обменяться опытом

А я крестиком вышиваю, очень неплохо :)

Прошу прощения, просто не смог удержаться.
Если вас не поняло больше одного человека - наверное дело в консерватории ;)