default

И снова переезд.

Предыдущая версия хостера самопроизвольно закончилась.
Переезжаем на такое же оборудование, но со сменой IP.
Время на переезд - до 11.02
Новый сервер получу на днях и начну в персональном порядке переносить контент.
Пишите в скайп.
default

Влияние бинарных логов на производительность

Размер БД - 100 WH
Конфигурация MySQL - sync-binlog=0, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-through.

6xSAS = 7896.967 TpmC
6xSATA = 3829.742 TpmC

В скобках даны значения предыдущего теста. Логичного объяснения таким результатам у меня лично нет, вероятно оба теста (sync-binlog=0 и sync-binlog=1) надо будет провести повторно.

Тем не менее продолжим с writeback на контроллере

Конфигурация MySQL - sync-binlog=0, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-back.

6xSAS = 23511.551 TpmC
6xSATA = 17149.617 TpmC

Ну что ж, когда речь о записи - контроллер во многом нивелирует проблему производительности.
А теперь попробуем то же самое, но с большой БД:

В скобках даны значения предыдущего теста. Логичного объяснения таким результатам у меня лично нет, вероятно оба теста (sync-binlog=0 и sync-binlog=1) надо будет провести повторно.

Размер БД - 4000 WH

Конфигурация MySQL - sync-binlog=0, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-through.


6xSAS = 2207.617 TpmC
6xSATA = 371.692 TpmC

Повторим с батарейкой:
Конфигурация MySQL - sync-binlog=0, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-back.


6xSAS = 6091.950 TpmC
6xSATA = 692.458 TpmC

Ну что ж, разрыв только увеличился...
Теперь пожалуй пора их и вовсе отключить.
default

Не только запись. Тест производительности на большой БД.

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-back.

Размер "большой БД" до теста - 340819Mb, это примерно в 28 раз больше пула XtraDB.

Результаты:
6xSAS = 5983.000 TpmC
6xSATA = 652.167 TpmC

Ну вот и всё, SATA-хранилке капут, даже батарейка не спасает.
Посмотрим, что выходит без батарейки:

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-through.

6xSAS = 2082.617 TpmC
6xSATA = 346.583 TpmC

Как видим, кэш на контроллере даёт больший прирост у SAS и почти не влияет на SATA

Теперь попробуем выяснить, помогает ли кэш на SATA-дисках справится с отсутствием кэша на контроллере:


Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 1.5 часа нагрузки.
Кэш на дисках включен. Кэш на контроллере write-through.

6xSAS = 1898.433 TpmC
6xSATA = 619.956 TpmC

SAS ожидаемо дергадировал, SATA - внезапно прибавил. Но тем не менее - writeback на контроллере с батарейкой всё равно быстрее. И надёжнее конечно.

Промежуточный итог: SAS и writeback оказались созданы друг для друга, любые результаты этого теста на SATA-сторадже - почти на порядок хуже, чем на SAS
default

Кэш на дисках и кэш на контроллере - стоит ли платить больше?

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках включен. Кэш на контроллере write-through.

Результаты:
6xSAS = 6184.492 TpmC, ~3.19k DML/sec
6xSATA = 13905.733 TpmC, ~7.46k DML/sec

Несмотря на разогрев - ничего нового, по-прежнему для SAS кэш только ухудшает производительность, а для SATA наоборот.

Ну сейчас сравним с кэшем на контроллере:

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках выключен. Кэш на контроллере write-back

Результаты:
6xSAS = 23849.184 TpmC
6xSATA = 19500.607 TpmC

"Замена" кэша диска кэшем контроллера дала прирост для SAS-стораджа в 3.85 раза, для SATA - 1.4.
А теперь посмотрим, что дадут оба кэша сразу...

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках включен. Кэш на контроллере write-back

Результаты:
6xSAS = 23016.908 TpmC
6xSATA = 21704.350 TpmC

При включенном в режим write-back кэше на контроллере, кэш на дисках не оказывает существенного влияния. Да, производительность SAS-стораджа немного просела, а производительность SATA чуть увеличилась - дальнейшие тесты будут проводится с отключенным кэшем на SAS и SATA-дисках.
Кэш на диске может давать какой угодно результат, но в любом случае - он не надёжен и нет способа сделать его таким же надёжным, как BBU ECC SDRAM. Так что эта фича - на самый-самый крайний случай, если всё остальное уже сделано и повысить производительность нужно немедленно.

Завтра утром будут базовые замеры большой БД - 4000 WH, тут к записи добавляется ещё и производительность чтения.
Тесты на "большой" БД будут пока всё те же: wt, wb с конфигурацией "по умолчанию", а после обеда - попробую из "маленькой" БД выжать ещё производительности путём отключения "чего-нибудь лишнего"
default

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

Конфигурация MySQL - базовая, 128 потоков выполнения, 1 час на разогрев БД, 2 часа нагрузки.
Кэш на дисках отключен. Кэш на контроллере write-through.

Объём данных в БД до тестирования - 8956 Mbyte (данные + индексы)

Результаты:
6xSAS = 7397.942 TpmC, ~3.83k DML/sec
6xSATA = 3203.458 TpmC, ~1.65k DML/sec

Объём данных в БД после тестирования 10024 Mbyte

Для SAS-дисков через час после запуска (т.е. к концу разогрева) производительность стала весьма стабильной, то для SATA-стораджа показатели весьма ощутимо менялись и в среднем падали. Либо я всё ещё недостаточно разогреваю БД, либо SATA без кэша деградируют под нагрузкой.

Конфигурация MySQL - базовая, 128 потоков выполнения, 2 часа на разогрев БД, 2 часа нагрузки.
Кэш на дисках отключен. Кэш на контроллере write-through.

Результаты:
6xSAS = 7288.667 TpmC, ~3.75k DML/sec
6xSATA = 4110.833 TpmC, ~2.12k DML/sec


Объём данных в БД после тестирования 11254 Mbyte

Вывод: для этого объёма данных нужно 2 часа на "разогрев", исходя из этого и буду измерять далее производительного "маленькой" БД.
default

Результаты замеров - мало данных, жесточайший ACID

tps - transfers per second that were issued to the device
TpmC - про эти попугаи можно почитать тут http://www.tpc.org/tpcc/faq.asp
DML - data manipulation language


Конфигурация MySQL - базовая, 128 потоков выплнения, 10 минут на разогрев БД, 1 час нагрузки.
Кэш на дисках отключен. Кэш на контроллере write-through.

Результаты:
6xSAS = 7488.883 TpmC, производительность стораджа на запись - 871tps, средняя скорость записи ~25,6Mbyte/sec, ~3.92k DML/sec
6xSATA = 3993.867 TpmC, производительность стораджа на запись - 480tps, средняя скорость записи ~14Mbyte/sec, ~2.17k DML/sec

Конфигурация MySQL - базовая, 128 потоков выплнения, 10 минут на разогрев БД, 1 час нагрузки.
Кэш на дисках включен. Кэш на контроллере write-through.

Результаты:
6xSAS = 6439.100 TpmC, производительность стораджа на запись - 771tps, средняя скорость записи ~22,39Mbyte/sec, ~3.45k DML/sec
6xSATA = 15298.866 TpmC, производительность стораджа на запись - 1970tps, средняя скорость записи ~54.8Mbyte/sec, ~7.98k DML/sec

Итого: с отключенным кэшем старенькие SAS-диски почти в два раза быстрее SATA (1.87), а вот включение кэша на SAS-дисках только повредило (0.85), в то время как производительность SATA увеличилась почти в 4 раза (3,83)

Возможно, 10 минут - это мало на разогрев БД даже такого относительно небольшого объёма, потому первый тест будет повторён с большей продолжительностью - 2 часа разогрева и 2 часа тестирования. Для проведения длительного теста БД на 100WH будет создана заново, т.к. после двух предыдущих тестов её размер на файловой системе подошел к 15Gb, что весьма близко к количеству RAM.
default

Базовые условия и исходные данные для тестов.

В обоих случаях используются массивы из 6 HDD в RAID10
Жесткие диски: старенький Seagate Cheetah 15K.7 ST3300657SS 300GB 15000 RPM 16MB и довольно свежій Western Digital WD RE4 WD1003FBYX 1TB 7200 RPM 64MB соответственно.

Файловая система - ext4, создана с опциями "по умолчания", планировщик - для начала deadline.

Collapse )

Судя по всему проблем с выравниванием быть не должно.

Collapse )

Размер пула близок к оптимальному для данного оборудования, после загрузки данных и разогрева количество доступной (free+cached+buffers) памяти - около 1.5Gb, можно было бы увеличить на гигабайт пул, но значение имеет не сам размер пула, а его соотношение с количеством данных в БД.
Соответственно своп выключен вообще.

Базовые наборы данных:
1) "Большой" - 4000 WH, 361G на диcке, 341865Mb по данным MySQL
2) "Маленький" - 100 WH, 11Gb на диске, 9887Mb по данным MySQL (этот набор данных слегка распух после пары тестов, но ещё помещается в концепцию "меньше пула")

Исходная конфигурация СУБД обеспечивает максимальную надёжность хранения - немедленная запись данных и логов транзакций гарантирует, что в случае потери БД можно с помощью своевременного бэкапа и бинлогов восстановить её на любой заданный момент времени.
Размер страйпа массива - 64Kbyte. Этого может оказаться недостаточно, если будет время - переустановлю один из серверов с бОльшим размером страйпа и ещё раз замерю.
default

Про MySQL, жесткие диски, RAID и ACID под OLTP

Давно хотел померять "стоимость" тех или иных опций в плане влияния на производительность.
"Правильным" подходом было бы реплеить нагрузку на копии реальной БД, но такой тест был бы уникальным.
Потому в качестве "мерялки" взят tpcc-mysql, а в качестве БД - Percona-server 56-5.6.14-rel62.0.483.rhel6, в качестве ОС - CentOS 6.5 amd64 с ядром 2.6.32-431.el6
Базовая конфигурация создана посредством https://tools.percona.com/
Сервера - Dell R520, 16 GB RAM, 2x Xeon E5-2430 - 6 ядер с HT @2.2Ghz, контроллер - PERC H710P Mini с 1Gb кэша.

Примерная программа замеров:
1) Производительность "маленькой" БД (заметно меньше буферного пула XtraDB)
2) Производительность "большой" БД (во много раз больше буферного пула)
3) Производительность "средней" БД (тут размер обсуждаем, наверное что-то около x2 от пула)
4) Производительность vs. надёжность хранения - включение и выключение бинлогов, синхронная запись бинлогов, периодичность сброса данных XtraDB на диск - т.е. что мы приобретаем отступаясь от идеалов ACID
5) Многопоточная производительность.
6) Батарейка: мифы и реальность. Позволяют ли мифические опции файловых систем всерьёз повлиять на производительность записи для транзакционного хранилища. Тут я надеюсь пригласить компетентного товарища для комментария.
7) Бонусом - обновление прошивки контроллера и контрольные замеры.

Очевидно измерять все сочетания параметров у меня точно не хватит времени, буду проводить "селекцию" сочетаний, приближая по возможности их к моим задачам.

Основных вопроса два:
a) Как много производительности мы можем получить оставаясь в рамках разумной надёжности хранения.
b) Как деградирует производительность разных шпиндельных хранилищ при росте объёмов данных.
default

Про OLTP

А на чём стоит начинать писать OLTP-систему с целевой производительностью порядка 4k запросов в секунду с перспективами масштабирования в несколько раз?

Предположим, есть только неможко пхпшников, которых в любом случае переучивать. Вопрос - куда.

Пока что кандидаты: scala, erlang, java, clojure