Тестируем SoQoL

Положим, что сервер СУБД имеет N ядер. И пусть производительность сервера — это, например, число транзакций в единицу времени.

Давайте сначала рассмотрим “идеальный” график зависимости производительности СУБД от числа клиентов (соединений).

На графике мы видим, что производительность будет линейно нарастать до момента, пока число ядер не сравняется с числом клиентов. Начиная с этого момента все ядра будут задействованы и производительность будет величиной постоянной даже при росте числа клиентов. Но это идеальный случай, когда каждое ядро работает на полную при обслуживании задач клиентов. 

В реальности же из-за различных ожиданий, связанных с диском, сетью и конкуренцией при доступе к общим данным возникают простои ядер, которые нужно заполнять полезной работой. А эту работу могут предоставить запросы других клиентов. Таким образом “насыщение” ядер происходит при большем числе клиентов (т.е. в итоге достижение максимума производительности). Поэтому график будет выглядеть примерно так:

Так реальная максимальная производительность будет достигаться на числе клиентов, большем, чем число ядер. Вывод: чтобы достичь максимальной производительности, нужно распараллелить выполнение задачи на число соединений, большее чем число ядер.

Системы с несколько сотнями клиентов считаются достаточно серьёзными. Рассмотрим, как выглядят графики до 400 клиентов для SoQoL и PostgreSQL на основе измерений TPC-C бенчмарка (стандартный бенчмарк, который имитирует складскую задачу). В качестве тестовой машины мы использовали 20 ядерный сервер с включенным гипертрейдингом, таким образом получили 40 логических ядер.

На графике видна очевидная аномалия в районе 40 клиентов (количество ядер в системе). Причем падение производительности наблюдается в обеих измеряемых СУБД. В остальном оба графика похожи на идеальный — обе СУБД показывают рост производительности (количества транзакций в минуту), который наступает при числе клиентов, больших чем число ядер в системе. Точка максимума — около 400 клиентов. Разница в пиковых значениях — SoQoL примерно в 6 раз производительнее PostgreSQL.

1К клиентов

Какой вывод можно сделать из этого графика? Мы видим, что произошло насыщение системы задачами. Все ядра заняты работой, не остается свободных процессорных ресурсов. Видна максимальная производительность системы.

Но здесь возникает другой вопрос — как влияет рост числа клиентов на способность системы поддерживать максимальную производительность на одном уровне? Здесь начинают проявляться проблемы высокой конкуренции на внутренних структурах СУБД. Чем качественнее система управляет конкуренцией, тем дольше будет поддерживаться максимальная производительность системы при возрастании числа клиентов, система более предсказуема и надежна. Из графика видно, что PostgreSQL после достижения максимальной производительности начал давать сбой и график устремился вниз. SoQoL держит нагрузку. 

Что же будет с SoQoL дальше, например, с 10К клиентами? Мы любим испытывать наше “детище” на критических нагрузках. Нам тоже было интересно, как себя поведет СУБД. Признаемся, что замеры получилось сделать не сразу — помешали выявившиеся проблемы, которые пришлось по ходу дела решать. Но мы были настойчивы и получили результаты!

C10k

СУБД — это система массового обслуживания. Современный сервер должен решать проблему 10 тысяч соединений (https://ru.wikipedia.org/wiki/C10k).

Для классических СУБД даже C1K выглядит как трудно решаемая задача, если судить по ранее представленным измерениям. SoQoL с точки зрения макро-архитектуры является классической СУБД, тем не менее способен справиться с C10K проблемой.
Достигается это за счет:

1. Повсеместно используются неблокирующие подходы на всех уровнях реализации архитектуры СУБД SoQoL. Другие СУБД могут похвалиться этим только в отдельно взятых подсистемах.
2. СУБД SoQoL реализует собственный планировщик задач, это позволяет сделать “умную” синхронизацию планировщика и исполняющей подсистемы, гарантирующую выполнение коротких транзакций за один квант, что минимизирует вероятность взаимных блокировок.

Бенчмарк TPC-C построен так, что конфликт транзакций неизбежен, только часть транзакций завершается удачно. Уровень конфликтности транзакций поддерживается за счет изменения количества складов — большее количество складов уменьшает вероятность конфликта транзакций. Поэтому для обеспечения примерно того же уровня конфликтности транзакций с большим количеством клиентов в тестах пришлось увеличить число складов до 500 (до этого демонстрировались результаты на 250 складах). Получившийся график:

На графике размещены измерения при количестве клиентов от 512 до 10240. Снижение производительности от пика не превышает 7% на протяжении всего графика. Какой “скучный” график, а какой эффект! Особо любознательные спросят, а что будет дальше с графиком? Когда-нибудь напишем и про это.