The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Нужно оптимизировать выделенный MySQL сервер"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Оптимизация и тюнинг / Linux)
Изначальное сообщение [ Отслеживать ]

"Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от IVB email(ok) on 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 - но это чисто субъективное ощущение, т.к. я не вижу, чтобы процессор был загружен даже в те моменты, когда в БД "затор" из запросов.

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от IVB email(ok) on 13-Май-13, 11:33 
>> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день.
> Боттлнек по дисковому и/о.

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

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

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

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

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

17. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от Sabakwaka (ok) on 04-Июл-13, 21:38 
> Т.е. я, к сожалению, не ошибся...

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

2. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от wiseman (ok) on 12-Май-13, 22:41 

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от wiseman (ok) on 13-Май-13, 19:05 

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

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

4. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от Mr. Mistoffelees email on 13-Май-13, 11:06 
Привет,

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

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

WWell,

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от IVB email(ok) on 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 аккаунтинга

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от ALex_hha (ok) on 04-Июл-13, 18:04 
> Да проблема ведь не в том, что Мускуль неоптимально настроен.

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

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

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Нужно оптимизировать выделенный MySQL сервер"  +/
Сообщение от Sabakwaka (ok) on 04-Июл-13, 21:42 

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

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

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

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру