тюнинг мусороуборщика

[Strannik]

народ кто нить тюнил мусороуборщик на джаве?

вопрос следующий. есть приложение висящее на 17 серверах в кластере. используется RMI. RMI подло вызывает полную уборку каждую минуту, хотя есть еще гиг свободной памяти, и проводит за этим занятием секунд 10. после запрета ручного вызова мусороуборщика приложение стало летать в несколько раз быстрее.

однако вендор начал махать руками типа так нельзя, и надо вместо этого указать RMI что так часто уборку делать не обязательно.

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

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

[Strannik]

нда...
полон форум топовых айтишников и никто не может на вопрос ответить...

[shkoda]

Если абстрагироваться от первой части поста и ответить только на вторую:

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

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

[Strannik]

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

[palmdev]

Вот здесь читали?

Факторов много: как часто вы создаете новые объекты через RMI, сколько у вас памяти и процессоров. Поскольку в RMI собственный механизм сборки мусора (с помощью lease-ов, которые удаленные клиенты должны периодически продлять), нужна гарантия, что на каждой локальной машине периодически происходит полная сборка. Раз в минуту - это, скорее всего, слишком часто. Если RMI у вас используется для кластеризации серверов или соединений типа сервер-сервер, когда удаленные объекты живут долго, то принудительную сборку можно вообще отключить. Если к вашему серверу цепляется много клиентов, и время жизни удаленных объектов невелико, то нужно найти оптимальный таймаут для принудительной сборки.

[shkoda]

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

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

[Strannik]

palmdev, там не читал у нас 1.5 но я читал аналог и обсуждения на других форумах.

-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

это то что рекомендует вендор (правда сначала они нам сказали только -Dsun.rmi.dgc.client.gcInterval=3600000 установить). в принципе мы только что протестировали и вроде как нормально работает, будем сравнивать

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

[RomZes]

я конечно не по жабе спец, но все равно, что вам мешает GC делать в off-peak время, когда эти 10 сек не критичны? а до этого собрать статистику по тому, как часто необходимо делать чистку?

[Strannik]

я конечно не по жабе спец, но все равно, что вам мешает GC делать в off-peak время, когда эти 10 сек не критичны? а до этого собрать статистику по тому, как часто необходимо делать чистку?

если коротко то вендор.

RMI по умолчанию делает ее каждую минуту что слишком все тормозит
те параметры сверху заставляют его делать GC каждый час, но JVM сама делает его каждые 10 мин в тестовом енвайронменте, что вроде как нормально. если вообще отключить ручную GC то в тестовом енвайронменте она происходит каждые пол часа по моему. в продакшене после отключения по моему раз в несколько часов.

[palmdev]

GC может по-разному работать: есть быстрые циклы, есть медленные, при этом может захватываться/освобождаться дополнительная память или нет. Так что еще неизвестно, что там у вас происходит каждые 10 минут или несколько часов. Правильный совет могут дать только реальные спецы по JVM, а все, что здесь напишут, - это так, на уровне шаманства. Если не хочется обращаться к вендору, можно, к примеру, поэкспериментировать на load-balanced нодах: отключить на одной принудительный GC и погонять недельку-другую. Ну, это, конечно, если есть несколько нод.

[Strannik]

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

у нас уже один недельку висит в продакшн и юзеры довольны работой.

реальных спецов по JVM днем с огнем не сыщещь, я в принципе сам уже спецом стал не хуже вендора за время настройки наших серверов