Делимся последними новостями о СУБД SoQoL

Немного про кеш, исследования и тесты

Немного про кеш, исследования и тесты

В начале лета в «Открытых системах» была опубликована статья — «Реляционная СУБД для современного оборудования», в которой, в том числе, были приведены некоторые измерения бенчмарка для 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. Но мы не останавливаемся, поскольку есть еще идеи для улучшений.