![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Сonnection pooling, JProfiler и clojure
Mar. 7th, 2012 11:15 amУсиленно проверяю различные варианты пула JDBC коннектов с сервисом на кложуре.
c3p0 и серверная jvm - очень быстро растет использование памяти. Решил разобраться, поставил по совету![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
artureg jprofiler, подключился - внутри творится адъ.
Основное место, где выделялась память - оказалось clojure.pprint, который я использовал для отладочных логов - он массово занимался рефлекшеном, и в памяти были 100500 копий java.lang.reflect.Method. Но вроде бы их gc грохал. Ну я ее использование временно убрал, чтобы оно не заслоняло происходящее.
Потом какой-то странный эффект, что по профайлеру используемая jvm память не растет, т.е. все ок, но система показывает постоянный рост. Отключил профайлер - стало нормально, т.е. похоже, что в самом профайлере какие-то спецэффекты.
Артурег убедил меня использовать вместо с3p0 commons-dbcp, с утра сегодня откопал пример использования, завел его с firebird на жабе, затем переписал на кложурь - все работает, причем с серверной jvm, вроде бы тенденция роста есть, но очень слабая, нужно долго тестировать.
Придется видимо, проверять все комбинации: "приложение vs windows-service" "server vs client jvm" "с3p0 vs commons-dbcp vs обычный коннект без пула" и "(str ) vs clojure.pprint" и "c профайлером vs без профайлера".
Т.е. если по хорошему, 48 комбинаций, по сутки-двое тестирования на каждую, т.к. хочется как бы узнать реальную картину происходящего. Хотя для использования это все нафиг не нужно, там памяти минимум на месяц хватит даже если утечка есть (что не факт), кроме того, можно рестарт сервиса делать раз в сутки ночью (что запрещает перфекционизм).
( Read more... )
PS: вариант с BasicDataSource, поддерживающем проверку валидности коннекта перед отдачей его из пула:
( Read more... )
Трасца, примеры для жабьих либ приходится по SO и форумам собирать.
c3p0 и серверная jvm - очень быстро растет использование памяти. Решил разобраться, поставил по совету
artureg jprofiler, подключился - внутри творится адъ.Основное место, где выделялась память - оказалось clojure.pprint, который я использовал для отладочных логов - он массово занимался рефлекшеном, и в памяти были 100500 копий java.lang.reflect.Method. Но вроде бы их gc грохал. Ну я ее использование временно убрал, чтобы оно не заслоняло происходящее.
Потом какой-то странный эффект, что по профайлеру используемая jvm память не растет, т.е. все ок, но система показывает постоянный рост. Отключил профайлер - стало нормально, т.е. похоже, что в самом профайлере какие-то спецэффекты.
Артурег убедил меня использовать вместо с3p0 commons-dbcp, с утра сегодня откопал пример использования, завел его с firebird на жабе, затем переписал на кложурь - все работает, причем с серверной jvm, вроде бы тенденция роста есть, но очень слабая, нужно долго тестировать.
Придется видимо, проверять все комбинации: "приложение vs windows-service" "server vs client jvm" "с3p0 vs commons-dbcp vs обычный коннект без пула" и "(str ) vs clojure.pprint" и "c профайлером vs без профайлера".
Т.е. если по хорошему, 48 комбинаций, по сутки-двое тестирования на каждую, т.к. хочется как бы узнать реальную картину происходящего. Хотя для использования это все нафиг не нужно, там памяти минимум на месяц хватит даже если утечка есть (что не факт), кроме того, можно рестарт сервиса делать раз в сутки ночью (что запрещает перфекционизм).
( Read more... )
PS: вариант с BasicDataSource, поддерживающем проверку валидности коннекта перед отдачей его из пула:
( Read more... )
Трасца, примеры для жабьих либ приходится по SO и форумам собирать.
