Berkeley DB JE를 실행하기위한 최고의 Java opts는 무엇입니까?

Question

BDB JE에 약 502,000,000 개의 행을 삽입하는 기계가 있습니다. 키와 값의 예는 다음과 같습니다.

juhnegferseS0004-47-19332 39694.290336 

키와 값은 모두 대략 동일한 길이입니다. 이 방법/누가 모르겠어요 ~의 JVM는, (난 그냥 메시지 "사망"을 얻을 "사망"입니다 50,000,000 행에 도달하면, 여전히

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

을하지만 : JVM은 다음과 같은 매개 변수와 함께 시작됩니다 그것은 죽임을 야기한다). 난 그냥 가비지 수집을 실행하려고 다음 그것은 충분한 메모리 또는 뭔가를 무료로 수없는 것 같아요. 그러나, -Xmx의 양으로, 나는 그것이 어떤 문제도 없어야한다고 생각할 것이다.

나는 deferredWrites를 사용하고 로그 파일의 크기는 100MB로 설정됩니다. DPL에서 기본 API로 전환해도 아무런 차이가 없었습니다.

12GB RAM이 장착 된 JDK 6.0 및 SUSE x86_64를 사용하고 있습니다. RAM의 나머지 부분을 필요로하는 다른 프로세스가 있으므로이 삽입 작업을 위해 실제로 9GB 이상을 할당 할 수 없습니다.

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) 

모든 팁을 알 수있다.

Answer 1

모든 상황에 적합한 단일 솔루션이 없습니다. 주어진 상황에서 어느 것이 가장 효과적인지 알아 보려면 다른 GC 수집기를 사용해 봐야합니다.

Answer 2

나는 JVM이 죽는 것을 기대하지 않으며 나중에 (또는 이전 버전의) JVM 릴리스를 사용하도록 권장합니다 (예 : JDK1.6.0_21 대 JDK1.6.0._22) 버그 일 가능성이 있는지 확인하기 위해

다른 생각은 아마도 메모리 부족과 관련된 Linux OOM 킬러 문제에 부딪 히고 있다는 것입니다. 자세한 내용은 this Serverfault question을 참조하십시오.

Answer 3

낡은 질문이지만, 최근에는 같은 문제가있었습니다. 내 문제를 해결하기 위해 gc 로그 분석기 (나는 GCeasy이 굉장합니다)를 사용하고, Eclipse Memory Analyzer을 사용하여 문제를 자세히 파악합니다.

그리고 나서 com.sleepycat.je.tree.BIN 클래스가 거의 JVM의 메모리를 사용하는 것으로 나타났습니다. 제 경우에는 JE의 캐시가 그렇게 중요하지 않습니다 (내 응용 프로그램은 마이그레이션 응용 프로그램입니다). 그래서 데이터베이스에 CashMode.EVICT_BIN을 설정했습니다.

내 말은 솔루션 자체가 JVM 옵션이 아니라 응용 프로그램 자체 일 수 있다는 것입니다.