Куда копать?

Tagged with →  

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

  1. Alisuper:

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

  2. XxxSwet:

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

  3. Alisuper:

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

  4. XxxSwet:

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

  5. Alisuper:

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

  6. Alisuper:

    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:

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

  8. XxxSwet:

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

  9. Alisuper:

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

  10. 0tsMega:

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

  11. Alisuper:

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

  12. TcuUnix:

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

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

  13. Alisuper:

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

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

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

Добавить комментарий