GC가 일시 중지되어 성능 문제가 발생했습니다.

성능 최적화에서 32GB의 그래프 데이터 (노드, 가장자리 등)가 메모리에로드되어 계속 유지되는 프로젝트를 시작했습니다. 이것은 장기 실행 서비스이므로 데이터는 서비스 수명 동안 메모리에 남아있게됩니다. Gen 2 수집이 CLR에 의해 트리거되면 성능을 해치는 큰 일시 중지가 있으며 GC는 모든 것을 도달 가능한 개체로 표시하는 Gen 2를 검사합니다.GC가 일시 중지되어 성능 문제가 발생했습니다.

내가 알고 싶은 것은 많은 양의 데이터를 메모리에 보관해야하는 관리 응용 프로그램에 사용할 수있는 전략이 있다는 것입니다. Gen 2 컬렉션이 실행되는 것을 방지하는 가장 좋은 방법은 무엇입니까?

출처

2012-01-23 Mark J Miller

Gen 2를 절대 실행하지 않으면 Gen 2로 만들지 만 영원히 살아 있지 않은 개체가 누출됩니다. 응용 프로그램의 기능에 따라 많은 객체가있을 수 있습니다. – delnan

죄송합니다. 그런 긴 멈춤을 막을 수있는 전략이 있습니까? 또는 관리되는 런타임을 사용하여 이러한 종류의 응용 프로그램을 구현하는 것은 좋지 않은 아이디어입니까? –

@itadapter 감사합니다. 저는 더 이상 그 회사에서 일하지 않습니다.하지만 그것은 결국 비 관리 상태에 대한 마샬링을 수행 한 결과입니다. 그리고 당신 말이 맞아서 문제가 해결되었습니다. –

더 많은 GC를 사용하기 위해 구현시 할 수있는 몇 가지 일반적인 작업이 있습니다. 비교적 쉬운 방법은 객체 그래프에서 객체 참조 수를 줄이는 것입니다. 예를 들어, 대체 : 간접 참조로

class Graph { 
    List<Node> roots; 
    // ... 
} 

class Node { 
    Node[] outwardEdges; 
    // ... 
}

를 노드 식별자를 통해 : 당신의 디자인에 맞는 유사한

class Graph { 
    List<Node> roots; 
    Node[] allNodes; 
    // ... 
} 

class Node { 
    int[] outwardEdges; 
    // ... 
}

또는 무언가를. 이것은 콜렉터가 걸어야하는 오브젝트 그래프에서 포인터의 수를 줄입니다.

네이티브 힙으로 데이터를 이동하는 것은 작은 JNI 라이브러리를 작성하여 필요한 작업을 수행 할 수있는 인터페이스를 제공하는 또 다른 방법입니다. 다른 방법으로도 효과를 볼 수 있습니다. 비슷한 문제가 발생한 마지막 시간에 데이터 세트에 서쪽 텍스트 데이터가 많이 있었기 때문에이 방법을 통해 상당한 공간을 절약 할 수있었습니다. UTF8로 인코딩 된 공간이 훨씬 적습니다. 그래프 검색 비용이 중요하지 않은 경우 기본 전화의 오버 헤드가 문제가되지 않을 수 있습니다.

출처

2012-01-23 21:00:05

GC가 일시 중지되어 성능 문제가 발생했습니다.

답변

관련 문제