Какая Java-версия лучше всего подходит для запуска Berkeley DB JE? - PullRequest
0 голосов
/ 30 декабря 2011

У меня есть машина, которая вставляет около 502 000 000 строк в BDB JE.Пример ключа и значения:

juhnegferseS0004-47-19332   39694.290336

Все ключи и значения примерно одинаковой длины.JVM запускается со следующими параметрами:

-Xmx9G -Xms9G -XX:+UseConcMarkSweepGC -XX:NewSize=1024m -server

Но, тем не менее, когда он достигает ~ 50 000 000 строк, JVM «убит» (я просто получаю сообщение «Убит», не знаю как /кем он убивает).Я просто думаю, что он пытается запустить сборщик мусора, а затем он не может освободить достаточно памяти или что-то в этом роде.Но с таким значением -Xmx, я думаю, проблем не должно быть.

Я использую deferredWrites, а размер файлов журнала равен 100 МБ.Переключение на базовый API из DPL не имело никакого значения.

Я использую JDK 6.0 и SUSE x86_64 с 12 ГБ ОЗУ.Существуют и другие процессы, которым требуется остаток ОЗУ, поэтому на самом деле не может выделить более 9 ГБ для этой задачи вставки.

JVM:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Любые советы по устранению этой проблемы:оценили.

Ответы [ 3 ]

0 голосов
/ 10 января 2012

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

0 голосов
/ 12 июля 2017

Хотя это старый вопрос, недавно у меня была такая же проблема.Чтобы решить мою проблему, я использую анализатор журналов gc (который я нашел GCeasy - это круто) и Eclipse Memory Analyzer для глубокого изучения проблемы.

И тогда я обнаружил, что класс com.sleepycat.je.tree.BIN занимает почти память JVM.В моем случае кеш JE не так важен (мое приложение - приложение для миграции).Поэтому я настроил CashMode.EVICT_BIN для своих баз данных.

Я имею в виду, что решение может заключаться не в опциях JVM, а в самом приложении.

0 голосов
/ 30 декабря 2011

Я бы не ожидал, что JVM умрет, и рекомендую вам попробовать более позднюю (или, возможно, даже более раннюю) версию JVM (я говорю о минорной версии, например, JDK1.6.0_21 против JDK1.6.0._22) вЧтобы узнать, сможете ли вы избежать запуска ошибки, которая может быть ошибкой.

Моя другая мысль заключается в том, что, возможно, вы столкнулись с проблемой убийцы OOM в Linux (касающейся перегрузки памяти).См. этот вопрос о неисправности сервера для получения дополнительной информации.

...