В начале лета в «Открытых системах» была опубликована статья — «Реляционная СУБД для современного оборудования», в которой, в том числе, были приведены некоторые измерения бенчмарка для SoQoL в разных степенях вытесняемости.
И вроде бы результаты положительные, но анализируя разные измерения, мы не удовлетворились такими достижениями, а начали исследовать и работать над системой.
Про кеш
Несмотря на распространённость неблокирующих технологий и прочих новшеств, SoQoL для пользователя в своей архитектуре прежде всего является классической дисковой СУБД. Это значит, что без кеша страниц не обойтись и он является критическим компонентом всей системы.
Что же из себя представляет кеш в нашей СУБД?
Алгоритм LRU в SoQoL не может быть использован из-за требований неблокирующей архитектуры (не путать с блокировками в транзакциях).
Есть ещё вариант FIFO и на хабре была статья, достаточно хорошо описывающая суть кеша, построенного на основе FIFO-контейнеров.
В SoQoL реализован вариант кеша, за основу которого взят FIFO (описанный в статье), но с более сложной структурой. И кеш в нашей СУБД интегрирован с его внутренней системой управления памятью.
Память кеша делится на 3 области:
- горячий кеш — ведется статистика доступа к страницам;
- холодный кеш — страницы не требуют записи, не имеют ссылок/статистики, являются источником свободных страниц (если страница запрошена методами исполнения оператора, то она «разогревается»);
- свободные страницы — не имеют ассоциации со страницами хранилища на диске.
Все области памяти организуются на основе циклических буферов (FIFO), а горячий кеш состоит из четырёх FIFO-буферов.
А теперь про результаты
В результате проделанной работы была обнаружена неэффективность в подсистеме управления памятью и кешем, которая сильно снижала оптимальность работы всей системы в режимах с вытеснением. Нам очень повезло — мы провели интересное лето ... :-)
Пришла осень, а с ней и предварительные, но такие долгожданные результаты!
Напомним, что в качестве референтного бенчмарка мы используем TPC-C, 1024 клиента, 250 складов (30Гб в хранилищах). Для ограничения системной памяти используем cgroups.
Рассмотрим конфигурацию, в которой для СУБД выделяется оперативная память, размер которой составляет 10% от размера базы данных (т.е. в данном случае 3Гб).
Какие цифры получили после исправления в подсистеме управления памяти и кэшем (для тех, кто в курсе терминов TPC-C):
- было - 40774 NOPM, 211661 TPM
- стало - 356733 NOPM, 1334717 TPM
В процессе работы мы расширили статистику и замерили итоговый показатель попадания в кеш (cache hit) в указанном тесте. Получили очень позитивный результат: cache hit=97%. Появилась некоторая удовлетворенность по данному вопросу.
P.S. Но мы не останавливаемся, поскольку есть еще идеи для улучшений.