Приветстую.

Есть 2 MySQL сервера с настроенной master-slave репликацией.

На мастере необходимо было удалить кучу мелких файлов на разделе с
базой. Все SELECT'ы (которых более 80%) перенесли на слэйв.

Начал удалять файлы - на мастере LA подскочило, что вполне ожидаемо, но
буквально через несколько минут LA подскочило и на слэйве + на слэйве
также выросла дисковая активность! Причем это явно не связано с
увеличившимся числом запросов.

mysql-5.1
Linux 2.6.36-gentoo-r5 x86_64

Что это может быть?

P.S. При последнем апдейте я включил 'community patches' - патчи от
percona которые якобы должны положительно пофлият на производительность.
Может в них причина?

Спасибо.

Файлы это куча таблиц? Или просто файлы?

2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru>

> Приветстую.
>
> Есть 2 MySQL сервера с настроенной master-slave репликацией.
>
> На мастере необходимо было удалить кучу мелких файлов на разделе с базой.
> Все SELECT'ы (которых более 80%) перенесли на слэйв.
>
> Начал удалять файлы - на мастере LA подскочило, что вполне ожидаемо, но
> буквально через несколько минут LA подскочило и на слэйве + на слэйве также
> выросла дисковая активность! Причем это явно не связано с увеличившимся
> числом запросов.
>
> mysql-5.1
> Linux 2.6.36-gentoo-r5 x86_64
>
> Что это может быть?
>
> P.S. При последнем апдейте я включил 'community patches' - патчи от percona
> которые якобы должны положительно пофлият на производительность. Может в них
> причина?
>
> Спасибо.
>
>

iops. в диск уперлись, скорее всего.

16 июня 2011 г. 17:01 пользователь Really Big Bug <bigbug@mafia.lv> написал:

> Файлы это куча таблиц? Или просто файлы?
>
>
> 2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru>
>
>> Приветстую.
>>
>> Есть 2 MySQL сервера с настроенной master-slave репликацией.
>>
>> На мастере необходимо было удалить кучу мелких файлов на разделе с базой.
>> Все SELECT'ы (которых более 80%) перенесли на слэйв.
>>
>> Начал удалять файлы - на мастере LA подскочило, что вполне ожидаемо, но
>> буквально через несколько минут LA подскочило и на слэйве + на слэйве также
>> выросла дисковая активность! Причем это явно не связано с увеличившимся
>> числом запросов.
>>
>> mysql-5.1
>> Linux 2.6.36-gentoo-r5 x86_64
>>
>> Что это может быть?
>>
>> P.S. При последнем апдейте я включил 'community patches' - патчи от
>> percona которые якобы должны положительно пофлият на производительность.
>> Может в них причина?
>>
>> Спасибо.
>>
>>
>

Да, но при чем тут слэйв?

- если я просто перевожу SELECT'ы на слэйв - все ОК. LA на слэйве не
превышает 4.
- если я перевожу SELECT'ы на slave, а на мастере удаляю файлы - LA на
слэйве взлетает до 8-9.

Не могу найти логического объяснения...
Ну не может слэйв достучаться до мастера или мастер медленно отвечает,
но это же не повод чтобы ЛА вместе с дисковой активностью взлетали...


On 06/16/11 16:05, Sergey Bochkov wrote:
> iops. в диск уперлись, скорее всего.
>
> 16 июня 2011 г. 17:01 пользователь Really Big Bug <bigbug@mafia.lv
> <mailto:bigbug@mafia.lv>> написал:
>
> Файлы это куча таблиц? Или просто файлы?
>
>
> 2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>>
>
> Приветстую.
>
> Есть 2 MySQL сервера с настроенной master-slave репликацией.
>
> На мастере необходимо было удалить кучу мелких файлов на разделе
> с базой. Все SELECT'ы (которых более 80%) перенесли на слэйв.
>
> Начал удалять файлы - на мастере LA подскочило, что вполне
> ожидаемо, но буквально через несколько минут LA подскочило и на
> слэйве + на слэйве также выросла дисковая активность! Причем это
> явно не связано с увеличившимся числом запросов.
>
> mysql-5.1
> Linux 2.6.36-gentoo-r5 x86_64
>
> Что это может быть?
>
> P.S. При последнем апдейте я включил 'community patches' - патчи
> от percona которые якобы должны положительно пофлият на
> производительность. Может в них причина?
>
> Спасибо.
>
>
>

Просто файлы - остатки сайтов.

On 06/16/11 16:01, Really Big Bug wrote:
> Файлы это куча таблиц? Или просто файлы?
>
> 2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru
> <mailto:sergey.kobzar@mail.ru>>
>
> Приветстую.
>
> Есть 2 MySQL сервера с настроенной master-slave репликацией.
>
> На мастере необходимо было удалить кучу мелких файлов на разделе с
> базой. Все SELECT'ы (которых более 80%) перенесли на слэйв.
>
> Начал удалять файлы - на мастере LA подскочило, что вполне ожидаемо,
> но буквально через несколько минут LA подскочило и на слэйве + на
> слэйве также выросла дисковая активность! Причем это явно не связано
> с увеличившимся числом запросов.
>
> mysql-5.1
> Linux 2.6.36-gentoo-r5 x86_64
>
> Что это может быть?
>
> P.S. При последнем апдейте я включил 'community patches' - патчи от
> percona которые якобы должны положительно пофлият на
> производительность. Может в них причина?
>
> Спасибо.
>
>

Если на мастере идет активная запись в БД, то, возможно, IO не дает
MySQL достаточно быстро писать бинлоги. А после удаления файлов все
накопившиеся операции туда записываются и уходят на слейв. Нет?


2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru>:
> Просто файлы - остатки сайтов.
>
> On 06/16/11 16:01, Really Big Bug wrote:
>>
>> Файлы это куча таблиц? Или просто файлы?
>>
>> 2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru
>> <mailto:sergey.kobzar@mail.ru>>
>>
>>    Приветстую.
>>
>>    Есть 2 MySQL сервера с настроенной master-slave репликацией.
>>
>>    На мастере необходимо было удалить кучу мелких файлов на разделе с
>>    базой. Все SELECT'ы (которых более 80%) перенесли на слэйв.
>>
>>    Начал удалять файлы - на мастере LA подскочило, что вполне ожидаемо,
>>    но буквально через несколько минут LA подскочило и на слэйве + на
>>    слэйве также выросла дисковая активность! Причем это явно не связано
>>    с увеличившимся числом запросов.
>>
>>    mysql-5.1
>>    Linux 2.6.36-gentoo-r5 x86_64
>>
>>    Что это может быть?
>>
>>    P.S. При последнем апдейте я включил 'community patches' - патчи от
>>    percona которые якобы должны положительно пофлият на
>>    производительность. Может в них причина?
>>
>>    Спасибо.
>>
>>
>
>



--
With best regards,
Dmitri Minaev

Нет. Судя по munin на slave дисковая активность гораздо превышающая
изменения в БД. Можно сказать сравнимая с активностью при удалении данных.

Меня смущают т.н. community patches. Наверно надо попробовать их убрать
и посмотреть на результат...

On 06/16/11 16:23, Dmitri Minaev wrote:

> Если на мастере идет активная запись в БД, то, возможно, IO не дает
> MySQL достаточно быстро писать бинлоги. А после удаления файлов все
> накопившиеся операции туда записываются и уходят на слейв. Нет?

если community patches - это только патчи от Percona и включённые в
Percona-server, то они достаточно стабильны.

Может быть удаление файлов на мастере совпало с ростом нагрузки на
чтение [на слейве] и вы просто воедино связали два или несколько
независымых событий?


Возможно, переключив чтение на слейв вы переключили туда же какую-то
сложную задачу, которая работала вне рамок кэша запросов\диска?



2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru>:
> Нет. Судя по munin на slave дисковая активность гораздо превышающая
> изменения в БД. Можно сказать сравнимая с активностью при удалении данных.
>
> Меня смущают т.н. community patches. Наверно надо попробовать их убрать и
> посмотреть на результат...
>
> On 06/16/11 16:23, Dmitri Minaev wrote:
>
>> Если на мастере идет активная запись в БД, то, возможно, IO не дает
>> MySQL достаточно быстро писать бинлоги. А после удаления файлов все
>> накопившиеся операции туда записываются и уходят на слейв. Нет?
>



--
Ilyas R. Khasyanov
Unix/Linux System Administrator
GPG Key ID: 6EC5EB27 (Changed since 2009-05-12)

Возможно это совпадение (переключение SELECT'ов на slave и увеличение
нагрузки). Но такое совпадение происходит второй раз.

Настораживает то, что увеличивается дисковая активность в несколько раз.
При innodb_buffer_pool_size = 34G и аптайме сервера больше недели,
обращений к диску практически не должно быть, а оно выростает с ~0.2
M/sec (это репликация с мастера) до ~4M/sec.

Непонятно откуда ноги растут...


On 06/16/11 19:21, Ilyas -- wrote:
> если community patches - это только патчи от Percona и включённые в
> Percona-server, то они достаточно стабильны.
>
> Может быть удаление файлов на мастере совпало с ростом нагрузки на
> чтение [на слейве] и вы просто воедино связали два или несколько
> независымых событий?
>
>
> Возможно, переключив чтение на слейв вы переключили туда же какую-то
> сложную задачу, которая работала вне рамок кэша запросов\диска?

Я думаю стоит перестать заниматься уличной магией, а сделать, наконец,
профайлинг. Я бы начал с того что в пик тайм на минуту сделал бы slow
log c 0 секунд (писать все) на час-другой, а потом бы натравил мааткит.
Еще - вариант что у вас временные таблицы создаются на диске, вынесите в
мискле тмп на другой раздел или в тмпфс для простоты мониторинга. Тоже
самое можно сделать с бинлогом если он включен на сервере.

Как-то так....

On 06/16/2011 10:44 PM, Sergey Kobzar wrote:
> Возможно это совпадение (переключение SELECT'ов на slave и увеличение
> нагрузки). Но такое совпадение происходит второй раз.
>
> Настораживает то, что увеличивается дисковая активность в несколько
> раз. При innodb_buffer_pool_size = 34G и аптайме сервера больше
> недели, обращений к диску практически не должно быть, а оно выростает
> с ~0.2 M/sec (это репликация с мастера) до ~4M/sec.
>
> Непонятно откуда ноги растут...



>
>
> On 06/16/11 19:21, Ilyas -- wrote:
>> если community patches - это только патчи от Percona и включённые в
>> Percona-server, то они достаточно стабильны.
>>
>> Может быть удаление файлов на мастере совпало с ростом нагрузки на
>> чтение [на слейве] и вы просто воедино связали два или несколько
>> независымых событий?
>>
>>
>> Возможно, переключив чтение на слейв вы переключили туда же какую-то
>> сложную задачу, которая работала вне рамок кэша запросов\диска?
>

Тогда, наверное, я бы попробовал с помощью iotop найти процесс,
виновный в большом IO. Если это mysql, идем по стандартной процедуре:
processlist и логи (особенно патологически большие).

Да, а слейв полностью идентичен мастеру? Триггеры какие-нибудь не затесались?

Еще один вариант -- проблемы в самом вводе-выводе. Состояние RAID,
состояние fs, работоспособность кэша RAID-контроллера и т.п. В общем,
для начала побенчмаркать его.

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


2011/6/16 Sergey Kobzar <sergey.kobzar@mail.ru>:
> Нет. Судя по munin на slave дисковая активность гораздо превышающая
> изменения в БД. Можно сказать сравнимая с активностью при удалении данных.
>
> Меня смущают т.н. community patches. Наверно надо попробовать их убрать и
> посмотреть на результат...
>
> On 06/16/11 16:23, Dmitri Minaev wrote:
>
>> Если на мастере идет активная запись в БД, то, возможно, IO не дает
>> MySQL достаточно быстро писать бинлоги. А после удаления файлов все
>> накопившиеся операции туда записываются и уходят на слейв. Нет?
>



--
With best regards,
Dmitri Minaev

On 06/16/11 19:14, Dmitri Minaev wrote:

> Тогда, наверное, я бы попробовал с помощью iotop найти процесс,
> виновный в большом IO. Если это mysql, идем по стандартной процедуре:
> processlist и логи (особенно патологически большие).

mysql. Дождусь след. раза - буду собирать логи. Нужно посмотреть чем он
там занимается.

> Да, а слейв полностью идентичен мастеру? Триггеры какие-нибудь не затесались?

Идентичен. Такое вообще не используется.


> Еще один вариант -- проблемы в самом вводе-выводе. Состояние RAID,
> состояние fs, работоспособность кэша RAID-контроллера и т.п. В общем,
> для начала побенчмаркать его.

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

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

Пересобирал MySQL реурсивно неск. раз - не помогает.

Да, и в логах появились такие вот записи (на мастере и на слэйве):

110617 14:58:00 InnoDB: error clustered record for sec rec not found
InnoDB: index `countr_id` of table `uiaweb_15`.`towns`
InnoDB: sec index record PHYSICAL RECORD: n_fields 4; compact format;
info bits 0
0: len 4; hex 80000006; asc ;; 1: len 1; hex 53; asc S;; 2: len
28; hex 537472617373686f66c2a0616ec2a0646572c2a06e6f72646261686e; asc
Strasshof an der nordbahn;; 3: len 4; hex 003da258; asc = X;;

InnoDB: clust index record PHYSICAL RECORD: n_fields 11; compact format;
info bits 0
0: len 4; hex 003da257; asc = W;; 1: len 6; hex 000054365a0f; asc
T6Z ;; 2: len 7; hex 80000980023dcc; asc = ;; 3: len 25; hex
537472617373686f662d616e2d6465722d6e6f72646261686e; asc
Strasshof-an-der-nordbahn;; 4: len 28; hex
537472617373686f662c20616e2c206465722c204e6f72646261686e; asc Strasshof,
an, der, Nordbahn;; 5: len 4; hex 80000006; asc ;; 6: len 4; hex
80000060; asc `;; 7: len 17; hex 4e6965646572c3b6737465727265696368;
asc Nieder sterreich;; 8: SQL NULL; 9: SQL NULL; 10: len 1; hex 53; asc S;;

TRANSACTION 1 1112234809, ACTIVE 0 sec, process no 1824, OS thread id
140106850117376 fetching rows, thread declared inside InnoDB 236
mysql tables in use 1, locked 0
MySQL thread id 4193627, query id 53592399 74.208.149.46 tuugo_slave
Sorting result
SELECT `id`,`town_name` FROM `towns` WHERE `countr_id` = '6' ORDER BY
`town_name` ASC LIMIT 15000, 5000

InnoDB: Submit a detailed bug report to http://bugs.mysql.com


Что это такое? Гугл говорит баг?


>
>
> 2011/6/16 Sergey Kobzar<sergey.kobzar@mail.ru>:
>> Нет. Судя по munin на slave дисковая активность гораздо превышающая
>> изменения в БД. Можно сказать сравнимая с активностью при удалении данных.
>>
>> Меня смущают т.н. community patches. Наверно надо попробовать их убрать и
>> посмотреть на результат...
>>
>> On 06/16/11 16:23, Dmitri Minaev wrote:
>>
>>> Если на мастере идет активная запись в БД, то, возможно, IO не дает
>>> MySQL достаточно быстро писать бинлоги. А после удаления файлов все
>>> накопившиеся операции туда записываются и уходят на слейв. Нет?