Дмитрий Еманов — Под капотом серверного ПО

Под Под капотом серверного ПО:капотом серверного ПО:нюансы разработкинюансы разработки

Дмитрий Еманов[email protected]

FirebirdSQL Projecthttp://www.firebirdsql.org/

http://www.firebirdsql.org/

2

Что прячется за определением «серверное»

Сложность Количественная или качественная? Цена неудачного решения

Производительность Баланс между скоростью выполнения и красотой кода Важность каждой мелочи Оглядка на железо

Кроссплатформенность Борьба против стандартов или все своими руками QA, QA и еще раз QA

3

Программная архитектура

OSRI/DSRI Единый API для всех компонентов Объекты и обмен сообщениями Диспетчер и провайдеры (подсистемы) Каждый компонент архитектуры понимает ее механику,

но не семантику

Диспетчер (Y-valve) Шлюз между клиентом и провайдером Опрос подсистем Поддержка абстрактных дескрипторов Двухфазная фиксация транзакций (2PC)

4


ENGINE

DB

Y-valveREMOTESERVER

REMOTECLIENT

Y-valveCLIENT

APP Клиент

Сервер

5


ENGINE

DB

Y-valveREMOTESERVER

REMOTECLIENT

Y-valveCLIENT

APP

REMOTECLIENT

Клиент

Сервер

6


ENGINE

DB

Y-valveREMOTESERVER

REMOTECLIENT

Y-valveCLIENT

APP

REMOTECLIENT

Клиент

Сервер

7


ENGINE 1DB 1 Y-valveREMOTESERVER

REMOTECLIENT

ENGINE 2DB 2

ENGINE 3DB 3

8


ENGINEDB Y-valveREMOTESERVER

REMOTECLIENT

ORACLEGATEWAY

9


LOGGER

DB

Y-valveREMOTESERVER

REMOTECLIENT

ENGINE

10


REMOTECLIENT

Y-valveCLIENT

APP

11


ENGINEY-valveCLIENT

APP DB

12


ENGINEY-valveCLIENT

APP DB

REMOTECLIENT

13


Эволюция Новый OO API, замена macros hell

на виртуальную диспетчеризацию Переход от статической компоновки провайдеров

к динамической Конфигурирование списка доступных провайдеров Вынос авторизации из ядра на уровень remote server

Proof of concept 30 лет не требовала значительных изменений

и не мешала разработке новых идей на ее основе Пережила несколько ОС и два сетевых протокола

14

Библиотека классов

Изначальные проблемы Boost существовал скорее теоретически STD++ был убог и слабо стандартизирован Невозможность жесткого управления памятью Недружелюбность к пулам памяти Универсальность против производительности

Решения Своя библиотека под существующую архитектуру

работы с памятью Алгоритмы, заточенные под собственные потребности Свои велосипеды — самые лучшие!

15

Синхронизация

Очевидное и не совсем Лучше жить вообще без конкуренции, но не получается Внимательно смотрим на реализацию

и прикладываем ее к своей специфике RW-lock и с чем его едят Честность обслуживания против производительности,

что такое lock starvation Размещение примитивов синхронизации

16


Очевидное и не совсем Лучше жить вообще без конкуренции, но не получается Внимательно смотрим на реализацию

и прикладываем ее к своей специфике RW-lock и с чем его едят Честность обслуживания против производительности,

что такое lock starvation Размещение примитивов синхронизации

THD1 THD2 THD3 THD1 THD2 THD3

SYN

OBJ

SYN1

OBJ

SYN2 SYN3

17


Level Up Кросспроцессная синхронизация и IPC Множественные состояния локов (SR, PR, SW, PR, EX) Гарантированно честное обслуживание Кеширование локов, механизм BAST Обнаружение и решение дедлоков Мониторинг графов ожидания и т. п. Распределенный менеджер блокировок

18

Архитектура работы с памятью

Общие принципы Минимизация обращений к менеджеру памяти Внутренние структуры (по возможности) не должны

требовать динамического расширения Каждый поток (по возможности) должен работать

со своим менеджером памяти

Пулы памяти Предварительная аллокация Изоляция данных различных объектов друг от друга Раздельный учет памяти Возможность «delete by pool»

19


Иерархические пространства памяти Каждый пул порождается родительским пулом Каждый значимый рантайм объект имеет

свой собственный пул Существует иерархия типов рантайм объектов,

связанных принципами порождения и времени жизни Каждая аллокация «внизу» приводит к рекурсивному

пересчету статистики родительских пулов Существует возможность получать и отображать статистику

всех рантайм объектов

20


Иерархические пространства памяти

База данныхБаза данных

Сессия 1Сессия 1 Сессия 2Сессия 2

Тр-ция 1Тр-ция 1 Тр-ция 2Тр-ция 2 Тр-ция 3Тр-ция 3 Тр-ция 4Тр-ция 4

Запрос 2Запрос 2

Запрос 1Запрос 1 Запрос 3Запрос 3



Запрос 8Запрос 8

21


Чем мы за это платим?

RecordBuffer::RecordBuffer(MemoryPool& pool, const Format* format) : length(format->fmt_length), count(0)

{ space = FB_NEW(pool) TempSpace(pool, SCRATCH);

record = FB_NEW(pool) Record(pool, length); record->rec_length = length;}

template <typename T, typename InternalTypes = BitmapTypes_64>

class SparseBitmap : public AutoStorage{public:

// Default constructor, stack placement SparseBitmap() : tree(&getPool()), defaultAccessor(this)

{}

// Pooled constructor

explicit SparseBitmap(MemoryPool& p) : AutoStorage(p), tree(&getPool()), defaultAccessor(this) {}

22

Сравнение менеджеров памяти

Percona research, © mysqlperformanceblog.com

23

Сравнение менеджеров памяти

Percona research, © mysqlperformanceblog.com

24

Эволюция менеджера памяти

1-е поколение Список свободных блоков + алгоритм «best fit» + mutex Аллокация больших блоков через ОС

25



2-е поколение (200% - 150x) Бинарное дерево свободных блоков + mutex Аллокация больших блоков через ОС + кеш больших блоков

26



2-е поколение (200% - 150x) Бинарное дерево свободных блоков + mutex Аллокация больших блоков через ОС + кеш больших блоков

3-е поколение (50% - 10x) Хеш-таблица малых блоков + CAS Список средних блоков + алгоритм «first fit» + mutex Аллокация больших блоков через ОС + кеш больших блоков

27

Работа с диском

Что мы все знаем Дисковый I/O был и остается узким местом Блочное выделение места в файле и I/O операции Кеширование блоков, FIFO/LIFO Файловый кеш и синхронная запись Фрагментация и raw partitions

Нюансы HDD против SSD Компрессия как способ уменьшения дискового I/O SYNC/FLUSH — доверяй, но проверяй!

28

Работа с диском

Компрессия Баланс между скоростью и степенью сжатия Формат данных в памяти Компактификация, RLE и иже с ними Префиксная компрессия Индексация внутри блоков

Второй уровень кеширования Распакованные данные Структуры поиска Затраты на синхронизацию

29

ACID и архитектура I/O

Журнал транзакций (WAL) Изменения пишутся в журнал синхронно и последовательно Фоновый перенос из журнала в основной файл Чекпойнты Обратное проигрывание журнала при восстановлении

30


Журнал транзакций (WAL) Изменения пишутся в журнал синхронно и последовательно Фоновый перенос из журнала в основной файл Чекпойнты Обратное проигрывание журнала при восстановлении

Принцип careful writes Журнала нет Дисциплина зависимости блоков друг от друга Запись выполняется в соответствии с графом зависимостей Мгновенное восстановление, отложенный reuse

31


Сравнение WAL против CW Синхронная последовательная запись быстрее синхронной

случайной записи (иногда есть возможность асимптотического приведения второй к первой)

Одинарная запись теоретически быстрее двойной, но не надо забывать про SYNC vs ASYNC

Что меняется в случае SSD?

32

Теневая копия

Принцип Физическая копия файла, аналог RAID 1 Читаем из основного файла, пишем в оба Переключение на тень при сбое I/O операции Режим SYNC одинаков для обоих файлов

33



Нестандартные применения Синхронный standby — основной файл локальный,

тень удаленная (через NFS)

34




тень удаленная (через NFS) Кеширование чтения — основной файл на RAM-диске,

тень на физическом диске

35




тень удаленная (через NFS) Кеширование чтения — основной файл на RAM-диске,

тень на физическом диске Оптимизация чтения — основной файл на SSD, тень на HDD

36

Вопросы?Вопросы?

Documents

Дмитрий Еманов — Под капотом серверного ПО