|
|
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Обращаюсь к страничке 2 раза под профайлером. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. com.mysql.jdbc.Field 2584 byte 19 instance. Запускаю gc. 0 instance. Обращаюсь к страничке. com.mysql.jdbc.Field 2824 byte 4 instance. итд. Память не освобождается. Конфигурация c3p0: Код: plaintext 1. 2. Когда заккоменчу эти строчки, hibernate начинает использовать свой пул по умолчанию, с которым утечки не возникает. К сожалению, он не рекомендован для production use. Общая конфигурация: Tomcat 5.5 jdk1.4.2 Hibernate3.0 c3p0-0.9.1-pre6.jar mysql-connector-java-5.0.0 mysql 5.0 WinXpSp2. JProfiler4 Прокомментируйте пожалуйста. Буду благодарен за любые мысли по этому поводу, так как бъюсь над проблемой не один день. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 09:23 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Лично я из-за этого отказался от hibernate... В примерах все отлично над таблицами по 3 записи, а как доходит до реализации хорошей ДБ, тут все почему-то молчат:( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 16:44 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Сейчас VM отдано 600 метров на серваке. Они выжыраются инстансами класса com.mysql.jdbc.Field за 4-5 суток. Потом приходится перезапускать tomcat. И это примерно при 2000 посетителей в день. Мне что-то кажется что hibernate здесь не причем, точнее не он один в этом замешан:) надо копать всю связку: hibernate + pool + mysqldriver. Как уже постил, родной пул hibernate не приводит к утечке памяти. Хочу сравнить его исходники с исходниками c3p0. Если не поможет - останется использовать не production от hibernate. Кстати говоря, наблюдал через MySQL Администратор: все коннекты визуально создаются и закрываются. Пробовал на коротком таймауте maxIdleTime=5 sec. Это в свою очередь никак не помогает при сборке мусорщиком объектов com.mysql.jdbc.Field Надеюсь, что все же получу ответ, от того, кто юзает в production hibernate+mysql. Может у меня у одного такие проблемы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 20:36 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Дает ли какой-нибудь выигрыш хибернетовский маппинг с тегом set и many to many отношением. Другими словами - почему бы не создавать маппинги по системе одна таблица - один hbm файл. Или эти теги предназначены специально для HSQL и в случае с mySQL не имеют смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 00:42 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Alexey Turn com.mysql.jdbc.Field 2584 byte 19 instance. Запускаю gc. 0 instance. Обращаюсь к страничке. com.mysql.jdbc.Field 2824 byte 4 instance. итд. Память не освобождается. Я что-то не понял, что Вас смущает. Ну сработала страничка, оказалось 19 невычищенных объектов. Запустили GC - они вычистились. Все правильно. Утечка - это когда растет количество НЕУДАЛЯЕМЫХ объектов - то есть объектов, на которые есть ссылки из других объектов; в корне этих цепочек ссылок сидят статические объекты. В итоге растет память, которую никак нельзя освободить. Смотрите в Ваше приложение. Где-нибудь растет какой-нибудь статический Hashtable или что-то в этом роде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 01:16 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
usaЛично я из-за этого отказался от hibernate... В примерах все отлично над таблицами по 3 записи, а как доходит до реализации хорошей ДБ, тут все почему-то молчат:( А что, нужно что-то кричать?... Ну вот у меня работают приложения на полусотне таблиц каждое (есть таблицы под 3M записей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 01:18 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
При каждом вызове gc, по данным профайлера число объектов com.mysql.jdbc.Field обнуляется. Внезависимости от того, был ли вызван gc, память, занятая объектами растет стабильно на N байт, при каждом вызове страницы. Т.е. после K вызовов, профайлер покажет 19 объектов и N*K байт Вот это меня и смущает. Это и есть утечка памяти, если я не ошибаюсь. Упоминание про статический HashTable наводит только на мысль о ThreadLocal переменной session. Хотя опять же, заменой на дефолтный пул hibernate проблема решается. Сегодня попробую погонять этот тест с MSSQL сервером и jtds драйвером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 07:45 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Подобная тема уже поднималась в топике Пул соединений в hibernate Решения(на форуме) я не увидел, хотя автор, возможно решил проблему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 07:52 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
MSSQL2000 + jtdsDriver0.8+c3p0: Весь мусор jtds драйвера нормально собирается. MySQL5.0 + mysql-connector3.1.12(5.0) + hibernate default pool: утечек нет MySQL5.0 + mysql-connector3.1.12(5.0) + c3p0: утечка в com.mysql.jdbc.Field MySQL5.0 + mysql-connector3.1.12(5.0) + dbcp: утечка в com.mysql.jdbc.Field MySQL5.0 + mysql-connector3.0.16-ga.bin + c3p0: утечка в com.mysql.jdbc.Field MySQL5.0 + mysql-connector3.0.16-ga.bin + hibernate default pool: утечек нет. Пул c3p0 и dbcp во всех случаях имел настройки типа: Код: plaintext 1. 2. 3. Тестовый код: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Резюмируя тесты можно сказать, что стандартные opensource пулы реализованы так, что работают с hibernate + MSSQL- сервером корректно, а с mysql на всех драйверах дают утечку в классе com.mysql.jdbc.Field Заявляю это с вероятностью 80% за списанием 20% на кривизну моих рук:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 09:48 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Alexey TurnПодобная тема уже поднималась в топике Пул соединений в hibernate Решения(на форуме) я не увидел, хотя автор, возможно решил проблему. Автор решил проблему. Там автор просто не закрывал итераторы, которые и оставались открытыми : "...Это приводит к тому что когда достигается предел открытых курсоров на сессию, с3р0 начинает ожидать закрытия курсоров..." Решение было простое: закрывать итераторы, как и положено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 11:26 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Alexey TurnРезюмируя тесты можно сказать, что стандартные opensource пулы реализованы так, что работают с hibernate + MSSQL- сервером корректно, а с mysql на всех драйверах дают утечку в классе com.mysql.jdbc.Field Заявляю это с вероятностью 80% за списанием 20% на кривизну моих рук:) Вот этот последний код у Вас попроще и попонятнее. Все сделано правильно. Но я никак не пойму, о каких утечках "в классе com.mysql.jdbc.Field" Вы говорите, когда все объекты этого класса при вызове GC благополучно вычищаются (как Вы пишете выше). Вот если бы они продолжали торчать, это была бы утечка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 11:40 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
В поле "instances" профайлера все обнуляется после вызова gc, точнее объект com.mysql.jdbc.Field не отображается профайлером. При следующем вызове этого же кода профайлер говорит, что com.mysql.jdbc.Field занимает памяти, как при двух вызовах кода итд... Факт в том, что память не освобождается. И если вызов кода будет осуществлен 1024 раз, то будет занято 1024*N памяти, которая не будет освобождена. Нормальная работа: это когда я вызываю код 1000 раз, потом запускаю gc, потом запускаю код и получаю 1900 для объекта, как и при первом обращении, а не 1900*1000. Я не знаю, почему профайлер не отображает эти объекты после сборки мусора. Хорошо, пусть это не утечка памяти. Что тогда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 12:19 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Похожая проблема описана здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 12:32 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
М.Голованов Alexey TurnПодобная тема уже поднималась в топике Пул соединений в hibernate Решения(на форуме) я не увидел, хотя автор, возможно решил проблему. Автор решил проблему. Там автор просто не закрывал итераторы, которые и оставались открытыми : "...Это приводит к тому что когда достигается предел открытых курсоров на сессию, с3р0 начинает ожидать закрытия курсоров..." Решение было простое: закрывать итераторы, как и положено. Если внимательнее прочитать конец топика: автор У меня вот такой код: List list = query.list(); ... Поэтому Hibernate.close(...) как мне кажется для данного случая не актуален. Очевидно - здесь нет итераторов. А проблема с открытыми курсорами осталась. Думаю, у меня нечто похожее. Это происходит с отдельными jdbc-drivers в случае автора oracle, в моем - mysqldriver. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 08:54 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Alexey TurnОчевидно - здесь нет итераторов. А проблема с открытыми курсорами осталась. Думаю, у меня нечто похожее. Это происходит с отдельными jdbc-drivers в случае автора oracle, в моем - mysqldriver. Здесь нет, а где-нибудь есть... не видя всего кода, судить трудно. Короче, я бы на вашем месте пересмотрел весь ваш код. На предмет таких простых вещей, как безусловное (в finally) явное закрытие Statement/PreparedStatement, явное закрытие итераторов (если используются) и так далее. Именно драйверы Oracle (classes12.jar) и MySQL (mysql-connector-java-3.1.12-bin.jar) с c3p0 мне никаких проблем с утечками не доставляют. При соблюдении вышеперечисленных условий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 16:03 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
М.Голованов Alexey TurnОчевидно - здесь нет итераторов. А проблема с открытыми курсорами осталась. Думаю, у меня нечто похожее. Это происходит с отдельными jdbc-drivers в случае автора oracle, в моем - mysqldriver. Здесь нет, а где-нибудь есть... не видя всего кода, судить трудно. Короче, я бы на вашем месте пересмотрел весь ваш код. На предмет таких простых вещей, как безусловное (в finally) явное закрытие Statement/PreparedStatement, явное закрытие итераторов (если используются) и так далее. Именно драйверы Oracle (classes12.jar) и MySQL (mysql-connector-java-3.1.12-bin.jar) с c3p0 мне никаких проблем с утечками не доставляют. При соблюдении вышеперечисленных условий. Спасибо. Это обнадеживает. Если не трудно - закиньте пожалуйста jar-ы c3p0 и mysqldrv3.1.12 на jdev(ШАРИК)ngs.ru Буду очень благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 18:20 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Весь код приложения состоит из двух файлов: 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. Сегодня специально сузил область поиска, чтобы не возникало вопросов об ошибках в коде приложения. Осталось 2 файла. Скачал hibernate3.1.3 и прицепил его библиотеки hibernate.jar и lib/ Прицепил mysql-connector-java3.1.12-bin.jar Результат тот-же, что описан в топике. Подскажите, можно ли это запостить, как баг. Если да, то где? Снимки кучи: снимок 1 снимок 2 снимок 3 Все снимки(второй и третий точно) сделаны непосредственно после того, как мусор был собран. В аттаче приложение из двух файлов, которое "течет" с описанным набором библиотек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 23:29 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Ну, в общем, явно висят и поля, и NewProxyResultSet, и NewProxyStatement, и NewProxyConnection - вся компания. Проблема есть. Наша с Вами разница только в том, что, оказывается, все мои системы тихо и спокойно живут с Hibernate 2.1.8 / c3p0 0.9.1. Это большая разница. Непременно погоняю Ваши тесты у себя и с 2.1.8, и с 3.1.3... в выходные. Только я, извините, JProfiler4 не доверяю и работаю с дампами непосредственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2006, 13:21 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Проблему решил с помощью бубна. Поэксперементировал с профайлером и разными версиями opensource библиотек типа c3p0, dom4j,cglib, hibernate, ehcache. При каждом прогоне теста, после замены какой-нибудь из библиотек память вела себя по разному.(С поправкой на доверие к профайлеру). Иногда она росла линейно, иногда ступенчато. Удовлетворился тем, что нашел много сочетаний, для которых количество Instance ов соответствует размеру отъедаемой ими памяти после сборки мусора. Видимо, у меня просто была неудачная конфигурация, или просто в отпуск пора. В заключение фотки использования кучи: Heap_telemetry_graph_2.html Heap_telemetry_graph_3.html М.Голованов, спасибо за участие в топике. Вы не думали, кстати переходить на более свежие версии hibernate? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2006, 15:04 |
|
||
|
hibernate c3p0 утечка памяти при работе с mysql
|
|||
|---|---|---|---|
|
#18+
Alexey TurnМ.Голованов, спасибо за участие в топике. Вы не думали, кстати переходить на более свежие версии hibernate? А зачем?... работает отлично, все сделано правильно. От добра добра не ищут. Хотя рано или поздно придется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2006, 19:45 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=33749946&tid=2149117]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 470ms |

| 0 / 0 |
