Loadrunner, Vuser

Помогите решить проблему если кто сталкивался:
При запуске в LoadRunner controller'а проекта с виртуальными пользователями, все работает нормально примерно 16-20 мин , далее один (случайный) виртуальный пользователь начинает есть память до тех пор пока не исчерпывается вся виртуальная память и тест валится. Если в менеджере задач убить процесс(этого виртуального пользователя) то тест продолжается далее еще 20 мин и снова ситуация повторяется. От теста (кода) ничего не зависит, проверялось на разных тестах врят ли они все кривые.
Возможно в код нужно что-то добавить?

Какой протокол?

Сервер SYBASE, протокол TCP/IP, приложение клиент сервер

Я плохо сформулировал вопрос :( - имелось в виду, какой протокол вы записываете вo Vugen? Sybase dblib? Дело в том, что я с подобной проблемой сталкивался только с COM-протоколом - но там всё было более или менее понятно - при такой активной работе с памятью утечки были почти неизбежны... Могу посоветовать только обратиться в Support Mercury - они обычно отвечают быстро и по делу, или поискать у них в Knowledge Base.

Единственная же идея которая приходит мне в голову - попробуйте отрубить логгинг в Controller. Для начала - совсем отрубить. Может помочь, но, судя по тому, что проблема возникает случайным образом, это больше похоже на баг в LoadRunner'e - если имеете возможность - занесите Service Request...

Помогите решить проблему если кто сталкивался:
При запуске в LoadRunner controller'а проекта с виртуальными пользователями, все работает нормально примерно 16-20 мин , далее один (случайный) виртуальный пользователь начинает есть память до тех пор пока не исчерпывается вся виртуальная память и тест валится. Если в менеджере задач убить процесс(этого виртуального пользователя) то тест продолжается далее еще 20 мин и снова ситуация повторяется. От теста (кода) ничего не зависит, проверялось на разных тестах врят ли они все кривые.
Возможно в код нужно что-то добавить?

Вообще-то, конечно, хотелось бы узнать версию LR и тип VUser'a (используемый протокол в VuGen'e).

Судя по тому, что вы пишете, вы запускаете юзеров как процесс, а не как thread. Если вы только не используете Sybase-Ctlib или Sybase-Dblib протоколы, то используйте multithreading. Это гораздо более scalable & robust подход.

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

Спасибо за помощь
Протокол используемый при записи в Vuser DB-Lib, логинг отключен, в контроллре Vuser запущены как процессы другое не возможно.
Если Vuser забывает освобождать память то почему какой то один и случайным образом ?
Есть подозрение что при обработке очереди запросов в какой то момент сервер не успевает обработать запрос, но как с этим бороться непонятно. Это только предположение.

версия LR 7.6

Спасибо за помощь
Протокол используемый при записи в Vuser  DB-Lib, логинг отключен,  в контроллре Vuser запущены как процессы другое не возможно.
Если Vuser забывает освобождать память то почему какой то один и случайным образом ?
Есть подозрение что при обработке очереди запросов в какой то момент сервер не успевает обработать запрос, но как с этим бороться непонятно. Это только предположение.

версия LR 7.6

Судя по тому, что никаких патчей для LR 7.6 в части Sybase DB-Lib протокола не существует, проблема, скорее всего, внутренняя. Можно попытаться локализовать ее, поигравшись с разным числом VUser'ов, разным количеством итераций и т.д. Я бы прежде всего посмотрел что будет, если вы запустите на исполнение сценарий с 1 VU, но indefinitely. Если проблемы не будет, то постепенно увеличивайте количество VUs, чтобы найти предел.

В любом случае в вашей ситуации самое верное будет обратиться в support. Хотя имейте в виду, что LR официально поддерживает только Sybase 10.x и 11.x. При работе с версией 12.x обеспечивается полная backward compatibility, но новые возможности версии 12 не поддерживаются. Это, кстати, тоже может быть источником проблемы.