mysql 5.1.55, freebsd 8.2, gmirror. Высокая загрузка диска

13 Responses to mysql 5.1.55, freebsd 8.2, gmirror. Высокая загрузка диска

1. Alisuper:

   19.02.2013 в 14:52

   Временные таблицы создаются в памяти, винты конечно гавно, но хочется локализовать проблему. Что это? Перестроения индексов, или апдейты, или бинлоги?
   Как это выяснить на продакшн сервере?
   Нагрузка только из-за mysql, так как только на его разделе gstat показывает busy до 100%, ops/s 300-350, и это в основном w/s.

   Ответить
2. XxxSwet:

   19.02.2013 в 15:02

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

   Ответить
3. Alisuper:

   19.02.2013 в 15:14

   если основная нагрузка, это бинлоги, то как временное решение — перенос их на другой диск, если апдейты, то заоптимизировать, если индексы, то переезжать на другие железки. SSD как вариант.
   Мне просто нужно какой-то временный костыль на 2 недели, так как уезжаю и новым железом заняться не смогу.

   Ответить
4. XxxSwet:

   19.02.2013 в 15:27

   блин, сам спрашиваешь — сам отвечаешь.
   перенеси конечно! они и должны изначально, по идее, на других дисках быть

   Ответить
5. Alisuper:

   19.02.2013 в 15:29

   правильно поставленный вопрос — почти ответ. Просто смог в кучу более или менее собрать мысли. Правда у меня и загрузка не такая большая, всего лишь 12-15 kqps к базе.

   Ответить
6. Alisuper:

   19.02.2013 в 16:21

   dT: 1.003s w: 1.000s
   L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
   0 215 0 0 0.0 215 3445 2.5 48.3| ada0
   1 213 1 16 13.3 212 3397 2.5 54.5| ada1
   1 215 1 16 13.3 214 3429 4.8 98.8| mirror/gm0
   1 215 1 16 13.3 214 3429 4.8 99.1| mirror/gm0s1
   0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a
   0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b
   0 3 0 0 0.0 3 48 13.0 1.3| mirror/gm0s1d
   0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1e
   0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1f
   1 212 1 16 13.3 211 3381 4.7 99.7| mirror/gm0s1g
   0 1 0 0 0.0 1 128 0.1 0.0| md1

   вывод gstat в пике.
   Кстати, как вариант, основная масса — быстрые и маленькие UPDATE к базе баннерной системы. Они могут так влиять? Если да, то кроме переноса бинлогов на другой диск, еще может временно помочь перенос баннерки на другой сервак?

   Ответить
7. XxxSwet:

   19.02.2013 в 17:39

   поверь, перенос бинлогов поможет сильно

   Ответить
8. XxxSwet:

   19.02.2013 в 17:39

   поверь, перенос бинлогов поможет сильно

   Ответить
9. Alisuper:

   19.02.2013 в 18:23

   ок, займусь на днях.

   Ответить
10. 0tsMega:

    20.02.2013 в 10:35

    А тебе бинлоги то нужны?

    Ответить
11. Alisuper:

    20.02.2013 в 10:37

    для реплики на два слейва? Да нужны, по идее.

    Ответить
12. TcuUnix:

    20.02.2013 в 15:36

    перенеси часть нагрузке на слэйвы по возможности, лей бинлоги на нфс

    а что шов процеслист говорит?

    Ответить
13. Alisuper:

    20.02.2013 в 16:48

    пока выставил
    innodb_flush_log_at_trx_commit = 0
    innodb_log_buffer_size = 32M

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

    Процесслист все как всегда, в пиковые нагрузки начинают копиться тяжелые запросы из-за нехватки IO, так как в память и проц пока не упираюсь. Ну нагрузку на слейвы перекину, да.

    Ответить