3
하루 종일 업데이트되는 실시간 Lucene 색인이 있습니다. 색인에 대한 여러 연속적인 일괄 처리가 끝나면 가능한 빨리 이러한 업데이트를 검색 할 수 있기를 바랍니다. 따라서 IndexSearcher를 다시 만들어야합니다..Net 가비지 수집이 개체 생성/삭제 속도보다 느리면 어떻게해야합니까?
문제는 IndexSearcher가 약 100MB의 메모리를 사용할 수 있으며 많은 업데이트가 진행될 때 상대적으로 자주 재생성 될 수 있으며 .NET 가비지 수집기가 참조 정리를 느리게하는 것으로 나타났습니다. 이전 IndexSearcher 객체 이렇게하면 콜렉터가 이전 IndexSearchers의 메모리를 다시 만드는 것보다 느리게 메모리를 확보 할 수 있으므로 프로세스의 메모리 사용이 통제에서 벗어나게됩니다.
나는이 문제가 금기 사항을 넘어 금기 지역으로 넘어 가서 GC.Collect()을 호출함으로써 메모리가 즉시 해제된다는 것을 발견했다. 성능에 미치는 영향은 눈에 띄지 않는 것처럼 보입니다.하지만 제가 많은 조언을하고있는 것처럼, 다른 사람들이 객체 생성 경험이 있고 가비지 컬렉터가 그들을 정리하는 것보다 빨리 릴리스하면 궁금합니다. 누군가 Lucene IndexSearcher와 함께이 문제를 겪었다면 특히 관심이 있습니다.
IndexSearcher는 10-20 초마다 한 번 피크 시간에 재생성됩니다.
소리 indexSearcher는 일종의 캐시입니다. 자주 업데이트 할 때 캐시를 사용하는 것은 나쁜 방법이라는 것을 잊지 마십시오. –
아니요, 캐시되지 않습니다. 단일 검색자를 사용하고 있으며 자체 검색 필드에 저장됩니다. 다시 만들 때 필드를 새로 만든 인스턴스로 설정하기 만하면됩니다. 그런 다음 이전 참조가 삭제되고 수집 할 수 있습니다. –
나는 과거에도 비슷한 문제가 있었다. 세션에 데이터 테이블 저장. 새 개체는 수집 된 GC보다 빠르게 커집니다. 긴 개체에서 참조되지 않도록 indexSearcher 컬렉션에있는 개체와 속성이 필요합니다. 다른 오브젝트가 이전 indexSearcher를 참조하고 있지 않은지 확인하십시오. indexSearcher의 객체 중 하나가 다른 객체에서 참조되는 경우 이전 indexSearcher는 긴 실시간 객체로 간주되어 사용자가 필요로하는 gen0이 아닌 두 번째 또는 세 번째 GC 생성에서 수집됩니다. –