eXist 용 JVM 메모리 조정

Question

24G RAM이있는 서버가 있다고 가정 할 때 eXist에 할당 할 메모리 양 (톰캣)은 얼마입니까?

저는 Intel Xeon E5649 (2.53GHz) 프로세서를 사용하여 우분투 12.04 64 비트를 실행하는 새로운 웹 서버를 설치하고 있습니다. eXist는 Tomcat 내부에서 webapp로 실행되며 db는 'stable'컬렉션을 쿼리하는 데만 사용됩니다. 즉, eXist 내부의 리소스에 업데이트가 실행되지 않습니다.

저는 (Tomcat 프로세스를 시작할 때 -Xms 및 -Xmx 설정을 통해) 다른 힙 크기를 실험 해 왔으며 지금까지 eXist에 대한 쿼리의 응답 시간에 많은 차이를 느끼지 못했습니다. 즉, JVM에 4G 또는 16G가 할당되었는지 여부는별로 중요하지 않습니다. 또한 eXist의 WEB-INF/conf.xml 파일에서 @cachesize 및 @collectionCache를 예를 들어 다음과 같이 업로드했습니다. 8192M,하지만 이것은별로 효과가없는 것 같습니다. eXist가 Tomcat에서 실행될 때 이러한 설정/영향/영향을 미쳤다고 생각합니까?

나는 각 상황이 다르다는 것을 알고있다. (그리고 나는 Tomcat 서버가 관련되어 있음을 알고있다.) 그러나 eXist 성능 w.r.t를위한 엄지 손가락 규칙이있다. 할당 된 메모리? 더 많은 양의 RAM을 사용할 수있는 설정을위한 합리적인 메모리 구성을 원합니다.

Answer 1

이 질문에 대한 답변이 on the exist-open mailing list입니다. wolfgang@exist-db.org의 답변은 다음과 같습니다.

메모리를 eXist에 추가하면 반드시 응답 시간이 향상되지는 않습니다. "불량" 쿼리는 많은 양의 RAM을 소비 할 수 있지만 쿼리가 최적화되면 더 많은 RAM이 필요합니다. 즉, RAM이 부족합니다. 대부분의 무거운 프로세싱은 인덱스 룩업을 사용하여 수행되며 최적화 프로그램은 노드 크기를 줄이려고합니다 이 전달됩니다. 따라서 캐싱 메모리는 관련 색인 페이지를 가장 많이 보유 할만큼 커야합니다 ( ). 이 경우 캐시 공간을 늘리면 더 이상 성능이 향상되지 않습니다. 반면에 collectionCache가 너무 작 으면 cacheSize가 이므로 식별 할 수있는 병목 현상이 발생합니다. 예를 들어 @collectionCache가 너무 작 으면 일괄 업로드 파일을 업로드하거나 백업을 만드는 데 몇 시간 (예 : 분 단위로 )이 걸릴 수 있습니다.

대부분의 쿼리가 인덱스를 사용하도록 최적화 된 경우 eXist 용 8GB RAM을 사용하면 보통 은 가끔 높은 부하를 처리 할 수있는 충분한 공간을 제공합니다. 이상적으로 은 최대 메모리 사용이 실제로 무엇인지 알아보기 위해 일부로드 테스트를 실행할 수 있습니다. @cacheSize의 경우 512m 이상으로 갈 필요가 거의 없습니다. @collectionCache 의 설정은 데이터베이스의 컬렉션 및 문서 수에 따라 다릅니다. 수십만 또는 수십만 건의 컬렉션이 인 경우 768m 이상으로 늘려야 할 수 있습니다. 위에서 말했듯이 collectionCache가 너무 작아지면 업로드 또는 백업 중에 성능의 갑작스러운 고장을 알 수 있습니다.

따라서 합리적인 설정은 다음과 같습니다. -Xmx8192m, @cacheSize = "512m", @ collectionCache = "768m". 16G 메인의 메인 메모리를 제공 할 여유가 있다면 확실히 해를 끼치 지 않을 것입니다. 당신이 루씬의 색인 또는 새로운 범위의 인덱스를 사용하는 경우 또한, 당신은뿐만 아니라 conf.xml에서 해당 인덱스의 모듈 구성에 @buffer 설정을 증가 고려해야합니다

<module id="lucene-index" buffer="256" class="org.exist.indexing.lucene.LuceneIndex" /> 
<module id="range-index" buffer="256" class="org.exist.indexing.range.RangeIndex"/>