forum.opennet.ru - "Нужно оптимизировать выделенный MySQL сервер" (20)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

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

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

Оглавление

Нужно оптимизировать выделенный MySQL сервер, DeadLoco, 22:29 , 12-Май-13, (1)

Нужно оптимизировать выделенный MySQL сервер, IVB, 11:33 , 13-Май-13, (5)

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

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

Нужно оптимизировать выделенный MySQL сервер, IVB, 11:35 , 13-Май-13, (6)

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

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

Нужно оптимизировать выделенный MySQL сервер, ALex_hha, 16:40 , 13-Май-13, (7)

Нужно оптимизировать выделенный MySQL сервер, IVB, 17:28 , 13-Май-13, (8)
Нужно оптимизировать выделенный MySQL сервер, Miha, 01:23 , 06-Июл-13, (20)

Нужно оптимизировать выделенный MySQL сервер, pavlinux, 03:18 , 14-Май-13, (10)

Нужно оптимизировать выделенный MySQL сервер, Zzzzz, 14:44 , 04-Июл-13, (11)

Нужно оптимизировать выделенный MySQL сервер, Аноним, 10:26 , 05-Июл-13, (19)

Нужно оптимизировать выделенный MySQL сервер, Zzzzz, 14:47 , 04-Июл-13, (12)

Нужно оптимизировать выделенный MySQL сервер, IVB, 17:51 , 04-Июл-13, (13)

Нужно оптимизировать выделенный MySQL сервер, Andrey Mitrofanov, 17:59 , 04-Июл-13, (14)
Нужно оптимизировать выделенный MySQL сервер, ALex_hha, 18:04 , 04-Июл-13, (15)

Нужно оптимизировать выделенный MySQL сервер, IVB, 19:31 , 04-Июл-13, (16)

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

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

1. "Нужно оптимизировать выделенный MySQL сервер" +/–

Сообщение от DeadLoco (ok) on 12-Май-13, 22:29

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

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

5. "Нужно оптимизировать выделенный MySQL сервер" +/–

Сообщение от IVB (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 (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 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 (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 (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 (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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Нужно оптимизировать выделенный MySQL сервер"	+/–
Сообщение от DeadLoco (ok) on 12-Май-13, 22:29
> вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день. Боттлнек по дисковому и/о. В норме мускль старается закешить индексы и, частично (а если удастся - то и полностью), сами таблицы. Если таблицы существенно больше, чем доступное ОЗУ, то производительность мускля упирается в производительность дисков. Программный пятый рейд - это хреновое решение для мускля. Даже железная пятерка с ББУ/кешью записи - так себе, хотя для массовых инсертов с нечастыми селектами еще куда ни шло. Для начала - поставить mysqltuner и оооочень вдумчиво почитать вывод. И думать примерно втрое осторожнее, поправляя конфиг.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


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