Доброго времени суток.Нужен профессиональный совет.
Есть самосборный сервер:
- мать MSI 990FXA-GD65
- проц AMD FX(tm)-6100 (3.3GHz)
- память DDR3 4x8Gb 667MHz
- диски 3 x WD4500HLHX (SATAIII, 10000rpm, 450Gb)В качестве ОС установлен Gentoo Linux x64 с ядром 3.2.1
Диски объединены в программный RAID5 общей емкостью 900GbНазначение сервера - выделенный MySQL сервер.
На сегодняшний день на сервере расположены следующие базы данных:
- биллинг (самописный)
- биллинг (UserSide)
- форум (VBulletin 3.x)
- 2 самописных системы мониторинга (друг друга не дублируют)
+ несколько "легких" БД, которыми можно пренебречь.Даже при такой нагрузке периодически возникают моменты, когда приложения, обращающиеся в БД, "подтормаживают".
Когда же я поставил на этот же сервер pgsql и попытался развернуть из бэкапа БД zabbix (раньше эта БД располагалась на другом сервере) - практически все запросы к БД MySQL "замерзли".
Решили не заморачиваться с pgsql и запустить zabbix с "чистой" БД MySQL (на этом же выделенном MySQL сервере). Однако запуск zabbix-сервера привел к довольно серьезным тормозам других приложений, работающих с БД (естественно, сам zabbix-сервер находится на другом сервере).
В итоге БД zabbix вынесли на другой сервер, а передо мной встал вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.
Исходя из того, что запуск pgsql на этом же сервере "затормозил" работу MySQL - дело не в неоптимальных настройках той или другой БД.
Я пока "грешу" на программный RAID5 - но это чисто субъективное ощущение, т.к. я не вижу, чтобы процессор был загружен даже в те моменты, когда в БД "затор" из запросов.
Как и чем можно определить, в чем же узкое место вышеописанного сервера?
> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.Боттлнек по дисковому и/о.
В норме мускль старается закешить индексы и, частично (а если удастся - то и полностью), сами таблицы. Если таблицы существенно больше, чем доступное ОЗУ, то производительность мускля упирается в производительность дисков. Программный пятый рейд - это хреновое решение для мускля. Даже железная пятерка с ББУ/кешью записи - так себе, хотя для массовых инсертов с нечастыми селектами еще куда ни шло.
Для начала - поставить mysqltuner и оооочень вдумчиво почитать вывод. И думать примерно втрое осторожнее, поправляя конфиг.
>> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.
> Боттлнек по дисковому и/о.Чем можно помониторить именно дисковый ввод/вывод?
> В норме мускль старается закешить индексы и, частично (а если удастся -
> то и полностью), сами таблицы. Если таблицы существенно больше, чем доступное
> ОЗУ, то производительность мускля упирается в производительность дисков.БД биллинга примерно 30 гиг, плюс форум примерно 15 гиг. Т.е. уже явно больше 32 гиг ОЗУ.
> Программный
> пятый рейд - это хреновое решение для мускля. Даже железная пятерка
> с ББУ/кешью записи - так себе, хотя для массовых инсертов с
> нечастыми селектами еще куда ни шло.Т.е. я, к сожалению, не ошибся...
> Т.е. я, к сожалению, не ошибся...То есть поставь под данные и временные файлы MySQL отдельный SATAIII шпиндель.
> Диски объединены в программный RAID5 общей емкостью 900Gb
> Назначение сервера - выделенный MySQL сервер.Эти два пункта несовместимы друг с другом в плане производительности
>[оверквотинг удален]
> находится на другом сервере).
> В итоге БД zabbix вынесли на другой сервер, а передо мной встал
> вопрос: чем же вызван тот предел производительности, который мы имеем на
> сегодняшний день.
> Исходя из того, что запуск pgsql на этом же сервере "затормозил" работу
> MySQL - дело не в неоптимальных настройках той или другой БД.
> Я пока "грешу" на программный RAID5 - но это чисто субъективное ощущение,
> т.к. я не вижу, чтобы процессор был загружен даже в те
> моменты, когда в БД "затор" из запросов.
> Как и чем можно определить, в чем же узкое место вышеописанного сервера?определять головой, посмотрев на графики загрузки различных подсистем....
рейд5 заменить в пользу рейд10, добавив еще один винт.
>>[оверквотинг удален]
> рейд5 заменить в пользу рейд10, добавив еще один винт.Достаточно ли будет программного RAID10, или нужно искать аппаратный контроллер?
> Достаточно ли будет программного RAID10, или нужно искать аппаратный контроллер?
Для начала достаточно софтового. А дальше - по показателям.
Привет,> Нужен профессиональный совет.
Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить ситуацию с I/O.
WWell,
> Привет,
>> Нужен профессиональный совет.
> Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить
> ситуацию с I/O.с учетом "Диски объединены в программный RAID5" - не поможет
> Как и чем можно определить, в чем же узкое место вышеописанного сервера?
Ну и для начала надо увидеть хоть какие то данные о текущей нагрузке на сервер. iostat/atop/iotop
>> Как и чем можно определить, в чем же узкое место вышеописанного сервера?
> Ну и для начала надо увидеть хоть какие то данные о текущей
> нагрузке на сервер. iostat/atop/iotopmd0 - программный RAID5 из sda+sdb+sdc
sdd - бутовая флешка# iostat
Linux 3.2.1-gentoo-r2-201202221440 (mysqls) 05/13/2013 _x86_64_ (6 CPU)avg-cpu: %user %nice %system %iowait %steal %idle
1.90 0.00 0.98 4.96 0.00 92.15Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 109.24 555.94 358.55 725755456 468072116
sdc 108.81 538.97 376.42 703596100 491405940
sda 108.29 535.66 377.62 699283673 492968888
md0 150.72 136.66 557.46 178397433 727734612
sdd 0.00 0.05 0.00 71037 24atop:
Такие значения для дисков - исключение. Я специально ждал минут 15, пока поймал. Такие значения держатся секунд 10-15, затем падают до 4-5%%.ATOP - mysqls 2013/05/13 16:23:14 --------- 10s elapsed
PRC | sys 0.54s | user 0.92s | #proc 104 | #tslpu 4 | #zombie 0 | #exit 6 |
CPU | sys 5% | user 10% | irq 2% | idle 431% | wait 153% | curscal ?% |
cpu | sys 1% | user 2% | irq 1% | idle 78% | cpu000 w 18% | curscal ?% |
cpu | sys 1% | user 2% | irq 0% | idle 62% | cpu002 w 35% | curscal ?% |
cpu | sys 1% | user 2% | irq 0% | idle 77% | cpu003 w 20% | curscal ?% |
cpu | sys 1% | user 1% | irq 0% | idle 68% | cpu001 w 30% | curscal ?% |
cpu | sys 1% | user 1% | irq 0% | idle 88% | cpu004 w 10% | curscal ?% |
cpu | sys 1% | user 1% | irq 0% | idle 58% | cpu005 w 40% | curscal ?% |
CPL | avg1 0.90 | avg5 0.73 | avg15 0.70 | csw 43060 | intr 44810 | numcpu 6 |
MEM | tot 31.4G | free 274.0M | cache 28.1G | dirty 18.2M | buff 196.0M | slab 608.5M |
SWP | tot 32.0G | free 32.0G | | | vmcom 2.4G | vmlim 47.7G |
MDD | md0 | busy 0% | read 24 | write 5181 | MBw/s 2.02 | avio 0.00 ms |
DSK | sda | busy 82% | read 1435 | write 2954 | MBw/s 1.32 | avio 1.88 ms |
DSK | sdc | busy 81% | read 1408 | write 2914 | MBw/s 1.40 | avio 1.86 ms |
DSK | sdb | busy 80% | read 1787 | write 2485 | MBw/s 1.18 | avio 1.88 ms |
NET | transport | tcpi 2098 | tcpo 1799 | udpi 15 | udpo 13 | tcpao 0 |
NET | network | ipi 2115 | ipo 1814 | ipfrw 0 | deliv 2115 | icmpo 2 |
NET | eth0 0% | pcki 1872 | pcko 1219 | si 714 Kbps | so 99 Kbps | erro 0 |
NET | vlan102 0% | pcki 1674 | pcko 1165 | si 676 Kbps | so 92 Kbps | erro 0 |
NET | eth1 0% | pcki 284 | pcko 502 | si 14 Kbps | so 511 Kbps | erro 0 |
NET | vlan101 0% | pcki 63 | pcko 53 | si 11 Kbps | so 6 Kbps | erro 0 |
NET | lo ---- | pcki 96 | pcko 96 | si 9 Kbps | so 9 Kbps | erro 0 |PID TID SYSCPU USRCPU VGROW RGROW RUID EUID THR ST EXC S CPU CMD 1/2
3282 - 0.35s 0.89s 0K 1364K mysql mysql 172 -- - S 12% mysqld
741 - 0.12s 0.00s 0K 0K root root 1 -- - S 1% md0_raid5
3553 - 0.01s 0.01s 0K 0K root root 1 -- - R 0% atop
753 - 0.02s 0.00s 0K 0K root root 1 -- - D 0% kjournald
3411 - 0.01s 0.00s 0K 0K root root 10 -- - S 0% radiusd
3615 - 0.00s 0.01s 69616K 3116K root root 1 N- - S 0% sshd
3524 - 0.01s 0.00s 0K 0K zabbix zabbix 1 -- - S 0% zabbix_agentd
3537 - 0.01s 0.00s 0K 0K root root 1 -- - S 0% kworker/2:2
20294 - 0.01s 0.00s 0K 0K root root 1 -- - S 0% kworker/1:0
3627 - 0.00s 0.01s 0K 0K sshd - 0 NE 0 E 0% <sshd>
3456 - 0.00s 0.00s 0K 0K root root 1 -- - S 0% snmpd
3192 - 0.00s 0.00s 0K 0K root root 1 -- - S 0% syslog-ng
3475 - 0.00s 0.00s 0K 0K root root 1 -- - S 0% sshdiotop показать не могу - ядро собрано без поддержки I/O аккаунтинга
>> Привет,
>>> Нужен профессиональный совет.
>> Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить
>> ситуацию с I/O.
> с учетом "Диски объединены в программный RAID5" - не поможетКак же, еще как помогает. Я сравнивал на старом Пне4 с софтовым рейдом на ide-дисках. Вот как раз току смог уменьшить нагрузку.
> Диски объединены в программный RAID5 общей емкостью 900GbRAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :D
>> Диски объединены в программный RAID5 общей емкостью 900Gb
> RAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :DА что тебя смущает? ))
>>> Диски объединены в программный RAID5 общей емкостью 900Gb
>> RAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :D
> А что тебя смущает? ))на 3 дисках райд 5 работает медленнее одного одинокостоящего винта, райд 5 собирать нужно не меньше 4 в идеале 5 или 6, при 4-х винтах райд догоняет одинокостоящий винт при 5-6 опережает, это мой сугубо личный опыт работы как с софтовым райдом так и с железным
Добрый день!
Помнится очень давно под дебиан-м использовал mysqloptimizer. Точное название если нужно - поищу. Смысл в том - запускаешь - он у тебя чекает настройки, проводит тесты и выдает то что нужно подкрутить. Например память под процессы мускуля, количество их и прочее-прочее...
Утила очень полезная. Например производит анализ тн медленных запросов.
> Добрый день!
> Помнится очень давно под дебиан-м использовал mysqloptimizer. Точное название если нужно
> - поищу. Смысл в том - запускаешь - он у тебя
> чекает настройки, проводит тесты и выдает то что нужно подкрутить. Например
> память под процессы мускуля, количество их и прочее-прочее...
> Утила очень полезная. Например производит анализ тн медленных запросов.Да проблема ведь не в том, что Мускуль неоптимально настроен.
Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.
> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.Есть решение!! Пиши на диск менее интенсивно.
> Да проблема ведь не в том, что Мускуль неоптимально настроен.вы уверены? А то я видел запросы с join на 150 лямов без индексов, и во всем был виноват админ и слабое железо ;)
> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.
а конкретней, что в вашем понятии - "более-менее интенсивная запись"
>> Да проблема ведь не в том, что Мускуль неоптимально настроен.
> вы уверены? А то я видел запросы с join на 150 лямов
> без индексов, и во всем был виноват админ и слабое железо
> ;)Да я ведь не утверждаю, что у меня Мускуль вылизан. Но если диски тормозят - сколько времени я убью на попытки оптимизации настроек Мускуля, прежде чем убежусь, что результат - нулевой?
>> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.
> а конкретней, что в вашем понятии - "более-менее интенсивная запись"Ну я ведь писал в первом посте - восстановление из бэкапа Постгресовской базы (т.е. настройки Мускуля как бы вообще не причем) все операции записи в БД Мускуля "замерзли". И пока я не прибил процесс восстановления - Мускуль висел.
> восстановления - Мускуль висел.А какой MySQL-то?
5.0? 5.1? 5.5?Производительность может в 100-1000 раз упасть от использования джойнов по непроиндексированным полям и т.п.
Что там у тебя в slow log?