inhate (inhate) wrote,
inhate
inhate

Про 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) Как деградирует производительность разных шпиндельных хранилищ при росте объёмов данных.
Tags: tpcc
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 3 comments