Менеджер транзакций для базы данных в оперативной памяти

И ещё одно решине для хеш индексов, оно спорное с точки зрения потребления места на диске, я когда то делал небольшой прототип github.com/laa/lsmtrie, вот собственно сам paper www.usenix.org/system/files/conference/atc15/atc15-paper-wu.pdf

Менеджер транзакций для базы данных в оперативной памяти

Интересно. Так как Вы используете зелёные потоки возможно вам будет интеерсна, эта статья www.scylladb.com/2018/06/12/scylla-leverages-control-theory в контексте compaction для LSM Tree. Были еще вопросы, но пока аппровался коммент я их забыл :LoL. Надо будет ещё раз пробежаться по ней :-)

Менеджер транзакций для базы данных в оперативной памяти

Ребята, спасибо. Статья интересная, но я правильно понял, что primary index в vinyl так же сделан ввиде LSM Tree? Так же интересно узнать как Вы боритель паузами во время компашена. Если можно задать такой вопрос.

Опыт использования ZGC и Shenandoah GC в продакшене

maximwirt Мне кажеться Вы всё таки пропустили важный момент в комментарии. ZGC использует мультимаппинг. Там по моему 3 цвета замапленных на RSS если я не ошибаюсь. Т.е. Ваши 6Gb heap система видит как 18Gb heap и начинает использовать SWAP и в конце срабатывает OOM killer. Возможно Вм и правда надо отменить своппироание и убрать OOM killer. Хотя я и сам считаю что как раз мудтимаппинг и есть главная проблема ZGC, но она заложена в его архитектуре.