큰 XML 파일을 읽는 확장 응용 프로그램

Question

10 분 간격으로 한 번씩과 같이 주기적으로 많은 XML 파일 집합 (20-30 자 정도)을 주기적으로 읽는 응용 프로그램이 있습니다. 이제 각 XML 파일은 최소 40-100MB 크기로 근사 될 수 있습니다. 각 XML이 읽히고 나면 파일에서 맵을 만든 다음 프로세서 체인 (10-15), 각 프로세서에서 데이터를 사용하여 일부 필터를 수행하거나 데이터베이스에 쓰는 등의 방법으로 맵을 전달합니다.

이제 응용 프로그램이 32 비트 JVM에서 실행됩니다. 지금 64 비트 JVM으로 이동할 생각은 없습니다. 예상대로 메모리 풋 프린트가 매우 높습니다 ... 32 비트 JVM의 임계 값에 근접합니다. 현재 우리는 대용량 파일을받을 때 생성 된 맵을 디스크에 직렬화하고 동시에 모든 맵을 처리하려고하는 것처럼 최대 3-4 개까지의 프로세서 체인을 동시에 실행하면 쉽게 OutOfMemory가됩니다. 또한 쓰레기 수거는 꽤 높습니다.

나는 몇 가지 아이디어가 있지만 사람들이 이미 시도/평가 한 몇 가지 옵션이 있는지보고 싶었습니다. 이런 종류의 응용 프로그램을 확장하기위한 옵션은 무엇입니까?

Answer 1

큰 XML 파일 (약 400Mb)을 처리하는 데 비슷한 문제가있었습니다. 우리는 크게이 사용하여 응용 프로그램의 메모리 풋 프린트를 감소 :

http://dom4j.sourceforge.net/dom4j-1.6.1/faq.html#large-doc

Answer 2

네는, @aaray 앵무새하고 @MeBigFatGuy, 당신은이에 대한 몇 가지 이벤트 기반 파서 언급 DOM4J, 또는 SAX 또는 StAX를 사용하려는 .

단순한 예로 100MB XML은 문자를 즉시로드하면 최소 200MB의 RAM을 소비합니다. 각 문자는 즉시 16 비트 문자로 확장됩니다.

다음으로 사용하지 않는 요소의 태그는 추가 메모리 (노드의 다른 수하물과 부기)를 모두 소비하므로 모두 낭비됩니다. 숫자를 다루는 경우 원시 문자열을 long으로 변환하면 숫자가 2 자리보다 크면 순이익이 발생합니다.

합리적으로 작은 문자열 집합을 많이 사용하는 IF (이것은 BIG IF입니다) String.intern()을 사용하여 일부 메모리를 절약 할 수 있습니다. 이것은 문자열이 jvm에 이미 있는지, 공유되어 있는지 확인하는 표준화 프로세스입니다. 이것의 단점은 퍼그 겐 (한때 억류 된, 항상 인턴 된)을 오염 시킨다는 것입니다. PermGen은 꽤 유한하지만 다른 한편으로는 GC에 거의 영향을받지 않습니다.

외부 XSLT를 통해 XML을 실행하여 JVM에 들어가기 전에 처리하고 싶지 않은 모든 cruft를 제거 할 수 있다고 생각하십니까? 몇 가지 독립 실행 형 명령 줄 XSL 프로세서가 파일을 사전 처리하여 더 정상적으로 처리 할 수 ​​있습니다. 실제로 얼마나 많은 양의 데이터가 실제로 사용되는지에 달려 있습니다.

이벤트 기반 XML 처리 모델을 사용하면 XSLT 단계가 거의 중복됩니다. 그러나 이벤트 기반 모델은 모두 기본적으로 사용하기에 너무 끔찍하기 때문에 아마도 XSLT 단계를 사용하면 기존 DOM 논리를 다시 사용할 수 있습니다 (가정 할 때).

내부 구조가 평평해질수록 메모리가 더 저렴 해집니다. 인스턴스 포인터 크기가 절반이기 때문에 사실 32b VM을 실행하는 장점이 있습니다. 하지만 여전히 1000 또는 수백만 개의 노드에 대해 이야기 할 때 모든 것이 합쳐지고 빠르게 달라집니다.

Answer 3

각 XML 파일의 내용을 임시 DB 테이블에 삽입 할 수 있으며 각 체인 링크는 필요한 데이터를 가져올 수 있습니다. 성능은 떨어지지 만 확장 성은 확보하게됩니다.