URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 94651
[ Назад ]

Исходное сообщение
"Нужно оптимизировать выделенный MySQL сервер"

Отправлено IVB , 12-Май-13 20:43 
Доброго времени суток.

Нужен профессиональный совет.

Есть самосборный сервер:
- мать 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 - но это чисто субъективное ощущение, т.к. я не вижу, чтобы процессор был загружен даже в те моменты, когда в БД "затор" из запросов.

Как и чем можно определить, в чем же узкое место вышеописанного сервера?


Содержание

Сообщения в этом обсуждении
"Нужно оптимизировать выделенный MySQL сервер"
Отправлено DeadLoco , 12-Май-13 22:29 
> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.

Боттлнек по дисковому и/о.

В норме мускль старается закешить индексы и, частично (а если удастся - то и полностью), сами таблицы. Если таблицы существенно больше, чем доступное ОЗУ, то производительность мускля упирается в производительность дисков. Программный пятый рейд - это хреновое решение для мускля. Даже железная пятерка с ББУ/кешью записи - так себе, хотя для массовых инсертов с нечастыми селектами еще куда ни шло.

Для начала - поставить mysqltuner и оооочень вдумчиво почитать вывод. И думать примерно втрое осторожнее, поправляя конфиг.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено IVB , 13-Май-13 11:33 
>> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.
> Боттлнек по дисковому и/о.

Чем можно помониторить именно дисковый ввод/вывод?

> В норме мускль старается закешить индексы и, частично (а если удастся -
> то и полностью), сами таблицы. Если таблицы существенно больше, чем доступное
> ОЗУ, то производительность мускля упирается в производительность дисков.

БД биллинга примерно 30 гиг, плюс форум примерно 15 гиг. Т.е. уже явно больше 32 гиг ОЗУ.

> Программный
> пятый рейд - это хреновое решение для мускля. Даже железная пятерка
> с ББУ/кешью записи - так себе, хотя для массовых инсертов с
> нечастыми селектами еще куда ни шло.

Т.е. я, к сожалению, не ошибся...


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Sabakwaka , 04-Июл-13 21:38 
> Т.е. я, к сожалению, не ошибся...

То есть поставь под данные и временные файлы MySQL отдельный SATAIII шпиндель.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено wiseman , 12-Май-13 22:41 

> Диски объединены в программный RAID5 общей емкостью 900Gb
> Назначение сервера - выделенный MySQL сервер.

Эти два пункта несовместимы друг с другом в плане производительности


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено PavelR , 12-Май-13 22:41 
>[оверквотинг удален]
> находится на другом сервере).
> В итоге БД zabbix вынесли на другой сервер, а передо мной встал
> вопрос: чем же вызван тот предел производительности, который мы имеем на
> сегодняшний день.
> Исходя из того, что запуск pgsql на этом же сервере "затормозил" работу
> MySQL - дело не в неоптимальных настройках той или другой БД.
> Я пока "грешу" на программный RAID5 - но это чисто субъективное ощущение,
> т.к. я не вижу, чтобы процессор был загружен даже в те
> моменты, когда в БД "затор" из запросов.
> Как и чем можно определить, в чем же узкое место вышеописанного сервера?

определять головой, посмотрев на графики загрузки различных подсистем....
рейд5 заменить в пользу рейд10, добавив еще один винт.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено IVB , 13-Май-13 11:35 
>>[оверквотинг удален]
> рейд5 заменить в пользу рейд10, добавив еще один винт.

Достаточно ли будет программного RAID10, или нужно искать аппаратный контроллер?


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено wiseman , 13-Май-13 19:05 

> Достаточно ли будет программного RAID10, или нужно искать аппаратный контроллер?

Для начала достаточно софтового. А дальше - по показателям.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Mr. Mistoffelees , 13-Май-13 11:06 
Привет,

> Нужен профессиональный совет.

Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить ситуацию с I/O.

WWell,


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено ALex_hha , 13-Май-13 16:40 
> Привет,
>> Нужен профессиональный совет.
> Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить
> ситуацию с I/O.

с учетом "Диски объединены в программный RAID5" - не поможет

> Как и чем можно определить, в чем же узкое место вышеописанного сервера?

Ну и для начала надо увидеть хоть какие то данные о текущей нагрузке на сервер. iostat/atop/iotop


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено IVB , 13-Май-13 17:28 
>> Как и чем можно определить, в чем же узкое место вышеописанного сервера?
> Ну и для начала надо увидеть хоть какие то данные о текущей
> нагрузке на сервер. iostat/atop/iotop

md0 - программный 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.15

Device:            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         24

atop:
Такие значения для дисков - исключение. Я специально ждал минут 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% sshd

iotop показать не могу - ядро собрано без поддержки I/O аккаунтинга


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Miha , 06-Июл-13 01:23 
>> Привет,
>>> Нужен профессиональный совет.
>> Посмотрите в сторону замены backendа MySQL на TokuDB. Это поможет вам улучшить
>> ситуацию с I/O.
> с учетом "Диски объединены в программный RAID5" - не поможет

Как же, еще как помогает. Я сравнивал на старом Пне4 с софтовым рейдом на ide-дисках. Вот как раз току смог уменьшить нагрузку.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено pavlinux , 14-Май-13 03:18 
> Диски объединены в программный RAID5 общей емкостью 900Gb

RAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :D


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Zzzzz , 04-Июл-13 14:44 
>> Диски объединены в программный RAID5 общей емкостью 900Gb
> RAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :D

А что тебя смущает? ))


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Аноним , 05-Июл-13 10:26 
>>> Диски объединены в программный RAID5 общей емкостью 900Gb
>> RAID5 на 3-х дисках да и ещё программный? Ты чо, прикалываешься?! :D
> А что тебя смущает? ))

на 3 дисках райд 5 работает медленнее одного одинокостоящего винта, райд 5 собирать нужно не меньше 4 в идеале 5 или 6, при 4-х винтах райд догоняет одинокостоящий винт при 5-6 опережает, это мой сугубо личный опыт работы как с софтовым райдом так и с железным


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Zzzzz , 04-Июл-13 14:47 
Добрый день!
Помнится очень давно под дебиан-м использовал mysqloptimizer. Точное название если нужно - поищу. Смысл в том - запускаешь - он у тебя чекает настройки, проводит тесты и выдает то что нужно подкрутить. Например память под процессы мускуля, количество их и прочее-прочее...
Утила очень полезная. Например производит анализ тн медленных запросов.

"Нужно оптимизировать выделенный MySQL сервер"
Отправлено IVB , 04-Июл-13 17:51 
> Добрый день!
> Помнится очень давно под дебиан-м использовал mysqloptimizer. Точное название если нужно
> - поищу. Смысл в том - запускаешь - он у тебя
> чекает настройки, проводит тесты и выдает то что нужно подкрутить. Например
> память под процессы мускуля, количество их и прочее-прочее...
> Утила очень полезная. Например производит анализ тн медленных запросов.

Да проблема ведь не в том, что Мускуль неоптимально настроен.

Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Andrey Mitrofanov , 04-Июл-13 17:59 
> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.

Есть решение!! Пиши на диск менее интенсивно.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено ALex_hha , 04-Июл-13 18:04 
> Да проблема ведь не в том, что Мускуль неоптимально настроен.

вы уверены? А то я видел запросы с join на 150 лямов без индексов, и во всем был виноват админ и слабое железо ;)

> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.

а конкретней, что в вашем понятии - "более-менее интенсивная запись"


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено IVB , 04-Июл-13 19:31 
>> Да проблема ведь не в том, что Мускуль неоптимально настроен.
> вы уверены? А то я видел запросы с join на 150 лямов
> без индексов, и во всем был виноват админ и слабое железо
> ;)

Да я ведь не утверждаю, что у меня Мускуль вылизан. Но если диски тормозят - сколько времени я убью на попытки оптимизации настроек Мускуля, прежде чем убежусь, что результат - нулевой?

>> Проблема в том, что более-менее интенсивная запись на диск блокирует всю работу.
> а конкретней, что в вашем понятии - "более-менее интенсивная запись"

Ну я ведь писал в первом посте - восстановление из бэкапа Постгресовской базы (т.е. настройки Мускуля как бы вообще не причем) все операции записи в БД Мускуля "замерзли". И пока я не прибил процесс восстановления - Мускуль висел.


"Нужно оптимизировать выделенный MySQL сервер"
Отправлено Sabakwaka , 04-Июл-13 21:42 

> восстановления - Мускуль висел.

А какой MySQL-то?
5.0? 5.1? 5.5?

Производительность может в 100-1000 раз упасть от использования джойнов по непроиндексированным полям и т.п.

Что там у тебя в slow log?