2011-01-22 7 views
5

많은 하위 요소가 포함 된 큰 xml 파일이 있습니다. 일부 xpath 쿼리를 실행할 수 있어야합니다. 자바에서 vtd-xml을 사용해 보았습니다. 그러나 메모리가 너무 커서 메모리에 맞지 않기 때문에 때때로 outofmemory 오류가 발생합니다. 그런 큰 xml을 처리 할 수있는 또 다른 방법이 있을까요? 당신이 지금 할 려 대용량 파일큰 xml 파일 처리

+0

왜이 질문에 파이썬 태그가 있습니까? 사람들이 파이썬 솔루션을 제공하기를 희망하십니까? – Spaceghost

+0

문서를 구문 분석 할 때 또는 xpath 쿼리를 시도 할 때 메모리 오류가 발생합니까? 두 번째 경우 아마도 xpath 쿼리에 문제가있는 것입니다. 어느 쪽이든, JVM의 힙에 대해 -Xmx 값을 늘리려고 했습니까? – Spaceghost

+0

확장 된 vtd-xml을 시도하고 메모리 매핑 옵션을 사용하십시오 –

답변

2

SAXParser 매우 효율적입니다? 이 소리로 DOM 기반 파서를 사용하려고합니다. 파서는 본질적으로 XML 파일 전체를 DOM 표현으로 메모리에로드합니다. 큰 파일을 다루는 경우 스트리밍 방식으로 XML 문서를 처리하는 SAX 파서를 사용하는 것이 좋습니다.

개인적으로 이것을 위해 StAX을 권장합니다.

+1

직접적인 SAX 스트림 (각 쿼리에 대해 전체 파일을 다시 파싱하지 않아야 함)에 XPath를 사용할 수 없습니다. –

+0

@Glenn Maynard - 물론 OP *는 각 쿼리 (또는 쿼리 일괄 처리)마다 파일을 다시 써야합니다. DOM이 너무 커서 메모리에 맞지 않습니다. –

0

표준 vtd 또는 확장 VTD-xml을 사용하셨습니까? 확장 된 XML을 사용한다면 메모리 매핑을 사용할 수있는 옵션이 있습니다.

0

XPath를 사용하면 수명이 긴 응용 프로그램에서 동적으로 많은 식을 컴파일 할 계획이 아닙니다.

XPath의 자바 버전이 어떻게 작동하는지 완전히 모르겠지만 .NET XPath에서는 동적 어셈블리를 컴파일하여 앱 도메인에 추가합니다. 이후 표현식을 사용하면 이제 어셈블리가 메모리로로드됩니다.
XPath를 사용하여 XPath로 생각한 상황으로이 동일한 유형의 메커니즘이 메모리 누수와 유사한 메모리를 채우는 속도를 줄였습니다.

내 이론은 각 표현식이 사용자의 값을 사용하여 컴파일 될 때마다 각 컴파일 된 표현식이 고유 할 가능성이 높기 때문에 새로운 표현식이 컴파일되어 app 도메인에 추가된다는 것입니다.
전체 앱 도메인을 다시 시작하지 않고 앱 도메인에서 어셈블리를 제거 할 수 있으므로 표현식을 평가할 때마다 메모리를 사용하고 복구 할 수 없었습니다. 결과적으로 코드는 메모리의 어셈블리 형태로 메모리를 누출하고 있었고 잠시 후 결과를 알았습니다.