GC-паузы, вызывающие проблемы с производительностью

Question

Я только начал работать над проектом (я новый, а не проект), который в качестве оптимизации производительности загружает 32 ГБ данных графа (узлы, ребра и т. Д.) В память и сохраняет их там. Это длинная служба, поэтому данные должны оставаться в памяти на протяжении всей службы службы. Когда коллекция Gen 2 запускается CLR, есть большие паузы (конечно), которые ухудшают производительность, в то время как GC сканирует Gen 2, отмечая все как достижимые объекты.

Что я хотел бы знать, существуют ли стратегии для управляемых приложений, которые должны хранить большие объемы данных в памяти? Каковы наилучшие способы предотвратить запуск коллекций Gen 2?

Answer 1

Есть несколько общих вещей, которые вы можете сделать в своей реализации, чтобы сделать его более дружественным к GC: относительно просто - уменьшить количество ссылок на объекты в графе объектов. Например, заменить:

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

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

С косвенными ссылками через идентификаторы узлов:

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

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

или что-то подобное, что соответствует вашему дизайну. Это уменьшает количество указателей в графе объектов, которые собиратель должен ходить.

Перенос данных на нативную кучу - это еще одна возможность, написав небольшую библиотеку JNI, чтобы предоставить вам интерфейс для выполнения необходимых операций. Это может окупиться другими способами: в прошлый раз, когда у меня была схожая проблема, мы решили сделать экономию пространства с помощью этого подхода, потому что у нас были в основном западные текстовые данные в наборе данных, которые занимали гораздо меньше пространства, закодированного как UTF8. Пока стоимость поиска по графику нетривиальна, накладные расходы на собственный вызов вряд ли будут проблемой.