|
|
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Всем добрый день, нужна помощь Имеется 2 сервера - один мощный с ssd, на котором выполняются все запросы, второй слабый - только для репликации БД и хранения статичных файлов. На обоих стоит percona Intel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация Недавно слейв начал сильно отставать (текущее отставание - больше двух дней). Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. Смотрю "show full processlist" на реплике - вижу там DELETE запросы к таблице table1 (там 1.9 млн записей). Вроде бы адекватные запросы, на мастере без проблем выполняются. Пробую делать банальный Код: sql 1. - на мастере мгновенно (0.00 секунд), на слейве - 3-5 секунд. Причем если репликацию перед этим стопнуть - тоже мгновенно выполняется top на слейве показывает что la в районе 1, память есть, wa - не больше 5%, iotop тоже не показывает никаких проблем mysql стабильно занимает около 100% CPU (т.е. полностью одно ядро), место свободное есть В связи с этим 2 вопроса: a) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении) б) таблица эта по большому счету не очень важна (это денормализованные данные, их по идее можно почистить), если стопнуть реплку, сделать TRUNCATE этой таблицы, а потом запустить репликацию снова - будут ли проблемы (последующие запросы ошибок давать не должны, они от данных в этой таблице не зависят) --------------------------------------- С уважением, Каримбаев Тимур ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2015, 18:12:47 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
авторa) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении) explain ну и у перконы офигенная куча счетчиков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2015, 22:10:15 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
авторIntel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация Репликация отстает потому что может. Тем более при такой существенной разнице в железе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2015, 22:21:05 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторa) куда дальше копать, как можно понять почему запросы которые быстро выполняются на бою медленно выполняются при репликации (понятна разница в конфигурации, но слишком сильная разница в выполнении) explain ну и у перконы офигенная куча счетчиков забыл я это написать: explain select разницы не показывает, explain delete-запроса на моей установке mysql не поддерживается netwindРепликация отстает потому что может. Тем более при такой существенной разнице в железе. я видимо плохо описал суть: мне как раз и надо было понять - почему на слейве delete-запросы выполняются медленно (т.е. куда смотреть). мне нужен был способ как понять почему на одном сервере медленно выполняются конкретные delete запросы, на довольно простой и небольшой таблице, с индексами, при неполной загрузке по ресурсам (на 100% занят CPU, причем на довольно простых запросах). я бы понял если бы дело было в диске, но тут ситуация явно не та, дисковой активности почти нет. --- в общем проблема решена по второму варианту. почистил на слейве второстепенную таблицу на которой возникали проблемы, на текущий момент отставание разгреблось с 185к до 20к секунд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:07:28 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Тимур Каримбаевmysql стабильно занимает около 100% CPU (т.е. полностью одно ядро)Насколько я понимаю, именно сюда и упираетесь. Накат репликации работает в один поток и поэтому более одного ядра занять не может. А ядро медленное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:10:26 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
miksoftА ядро медленное.Судя по http://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz ядро не просто медленное, а очень медленное. Иначе 8 ядер и чипсет в TDP 20 W просто не запихнуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:15:22 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
miksoftТимур Каримбаевmysql стабильно занимает около 100% CPU (т.е. полностью одно ядро)Насколько я понимаю, именно сюда и упираетесь. Накат репликации работает в один поток и поэтому более одного ядра занять не может. А ядро медленное. это я понимаю. мне нужно было разобраться "почему этот конкретный delete запрос тормозит на этом сервере" (т.е. почему именно он загоняет в эти 100%. В базе есть и другие таблицы, большие по объему, с ними тоже идет работа, но они вроде как не проскакивают в медленных). запрос несложный, delete. Действительно сначала explain (я так и сделал), правда селекта - с ним все ок, быстро Потом смотрел внешние ключи, убедиться никто не зависит от этой таблицы (т.е. по идее delete от селекта отличаться может тем что по внешним таблицам на предмет целостности проходится и там действительно может быть нагрузка на процессор) - нет, не оно. Потом я попробовал остановить репликацию и оптимайзнуть таблицу - не помогло. Потом стал смотреть диск - активность маленькая На этом месте я решил что моих знаний mysql недостаточно (это не совсем моя область) для нормального анализа и полез на форум посоветоваться :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:17:12 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Тимур Каримбаевexplain select разницы не показываетА сам explain можете показать? Возможно, с ним на обоих серверах проблемы. Но первый вытягивает за счет могучего железа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:17:55 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
miksoftmiksoftА ядро медленное.Судя по http://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz ядро не просто медленное, а очень медленное. Иначе 8 ядер и чипсет в TDP 20 W просто не запихнуть. http://habrahabr.ru/company/selectel/blog/230689/ судя по тому что что говорит селектел - производительность ядер отличается не так уж и сильно, раза в 4. по моим прикидкам при текущей загрузке мастера, и отсутствии другой загрузки реплики - на репликацию должно хватать с запасом (и всегда хватало). господа, у меня нет вопроса в производительности железа (там много других цифр нужно будет смотреть), и нет ощущения что "один из серверов настолько медленнее другого что репликация обязана отставать" (выше описал почему) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:22:56 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Тимур Каримбаев, Т.е. итоговая разница в производительности в 16 раз Вас не смущает? Тимур Каримбаеви всегда хваталоТогда вспоминайте, с чего началось отставание. Возможно, резко вырос объем данных, изменились запросы/нагрузка, еще что-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:29:41 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
miksoftТимур Каримбаевexplain select разницы не показываетА сам explain можете показать? Возможно, с ним на обоих серверах проблемы. Но первый вытягивает за счет могучего железа. Похоже вы правы. Вчера в пылу разборок с железом не туда посмотрел. Начал сейчас смотреть логи mysql-клиента, я вчера это как-то упустил из виду (а сейчас после truncate сложно воспроизвести на слейве) там был запрос вида Код: sql 1. 2. 3. 4. 5. 6. 7. 8. при этом на table1.f1 висит индекс, но с результатами подзапроса он не срабатывает (кстати, пользуясь случаем спрошу - это нормально?). действительно более мощный сервер легко его проглатывал, даже с type=ALL Сейчас переделал на JOIN - все гораздо проще оказалось Код: sql 1. 2. 3. 4. 5. 6. спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 11:33:59 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Тимур Каримбаев Код: sql 1. Не знаю как в Перконе, а в MySQL до версии 5.6 был баг оптимизатора, приводящий к тому, что вложенный селект вычислялся не один раз, а столько раз, сколько раз нужно было его проверить. Т.е. по числу записей в таблице `table1`. Поэтому крайне рекомендуется переписывать такие запросы через JOIN или EXIST, в зависимости от контекста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 12:10:32 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
miksoftТимур Каримбаев Код: sql 1. Не знаю как в Перконе, а в MySQL до версии 5.6 был баг оптимизатора, приводящий к тому, что вложенный селект вычислялся не один раз, а столько раз, сколько раз нужно было его проверить. Т.е. по числу записей в таблице `table1`. Поэтому крайне рекомендуется переписывать такие запросы через JOIN или EXIST, в зависимости от контекста. мне казалось это совсем старый баг mysql (я просто mysql'ем не занимался уже несколько лет, сейчас приходится снова вникать, точно помню что там было раньше). в оптимизаторе вроде как перкона и mysql отличаться не должны если бы на каждую запись из table1 выполнялся - было-бы совсем медленно (т.е. 1.9млн раз должен был выполниться). а тут впечатление такое что подзапрос выполняется 1 раз, но индекс не участвует, при этом проходит по всем 1.9 млн для сравнения с результатами подзапроса в любом случае большое спасибо за помощь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 12:39:49 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
Тимур Каримбаевмне казалось это совсем старый баг mysql (я просто mysql'ем не занимался уже несколько лет, сейчас приходится снова вникать, точно помню что там было раньше). в оптимизаторе вроде как перкона и mysql отличаться не должны если бы на каждую запись из table1 выполнялся - было-бы совсем медленно (т.е. 1.9млн раз должен был выполниться). а тут впечатление такое что подзапрос выполняется 1 раз, но индекс не участвует, при этом проходит по всем 1.9 млн для сравнения с результатами подзапроса в любом случае большое спасибо за помощьСудя по слову DEPENDENT в плане, баг все еще присутствует. Кстати, непонятно, почему был выбран индекс PRIMARY. По идее, индекс f2 должен быть более полезным. Но не видя DDL таблицы нельзя утверждать что-то наверняка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 12:52:38 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
netwindавторIntel Xeon E3-1270 3.5 ГГц, 32 ГБ DDR3, 2 x 240 ГБ SSD - master, здесь вся работа Intel Atom Avoton C2758 2.4 ГГц, 8 ГБ DDR3, 2 x 1000 ГБ SATA - slave, здесь только репликация Репликация отстает потому что может. Тем более при такой существенной разнице в железе. я могу ошибаться, ибо не из опыта а из теории делаю вывод, но нагрузка на слейве процессорная посильнее будет. ибо ему то что...пришла команда на изменение, максимум оповестил все слейвы, и делает себе штатно изменение, притом что старые данные если и потребуют слейвы - хотя зачем они им... а вот слейву тяжелее...ему надо делать выборки, притом учитывать кучу моментом с апдейтами... если провести аналогию с сервером свн, то твоя машина это сервер, где обрабатываються изменения, а сервер свн это слейв, который другим всем на команды апдейт выдаёт новую версию данных. (при условии что другие не меняют ничего...только читают, как клиенты слейва базы данных) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 13:20:02 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
alex564657498765453netwindпропущено... Репликация отстает потому что может. Тем более при такой существенной разнице в железе. я могу ошибаться, ибо не из опыта а из теории делаю вывод, но нагрузка на слейве процессорная посильнее будет. ибо ему то что...пришла команда на изменение, максимум оповестил все слейвы, и делает себе штатно изменение, притом что старые данные если и потребуют слейвы - хотя зачем они им... а вот слейву тяжелее...ему надо делать выборки, притом учитывать кучу моментом с апдейтами... если провести аналогию с сервером свн, то твоя машина это сервер, где обрабатываються изменения, а сервер свн это слейв, который другим всем на команды апдейт выдаёт новую версию данных. (при условии что другие не меняют ничего...только читают, как клиенты слейва базы данных) очень странное предположение (не говорю что неверное) > ибо ему то что...пришла команда на изменение, максимум оповестил все слейвы, и делает себе штатно изменение во-первых мастер, в отличие от слейва, должен учитывать транзакционность. т.е. параллельно открытые транзакции и т.п. на слейв можно отгрузить только закоммиченные изменения во-вторых на мастер нагрузка неравномерная (пришел запрос, обработал, ждешь пока следующий придет), т.е. с пиками и вынужденными простоями, на слейве откручивать лог можно без задержек > а вот слейву тяжелее...ему надо делать выборки это еще почему? в нашей ситуации мастеру как раз нужно делать выборки, слейву - нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 13:29:19 |
|
||
|
Отстает репликация - percona
|
|||
|---|---|---|---|
|
#18+
alex564657498765453netwindпропущено... Репликация отстает потому что может. Тем более при такой существенной разнице в железе. я могу ошибаться, ибо не из опыта а из теории делаю вывод, но нагрузка на слейве процессорная посильнее будет. ибо ему то что...пришла команда на изменение, максимум оповестил все слейвы, и делает себе штатно изменение, притом что старые данные если и потребуют слейвы - хотя зачем они им... Мне не понятно. По-моему это неверно. автора вот слейву тяжелее...ему надо делать выборки Вы, видимо, хотели сказать о ситуации когда при старте репликации до завершения "прогрева" те же запросы работают медленнее. Да, это запросто. Есть специальный скрипт - mk-slave-prefetch. Он призван поднимать данные перед тем как будут запускаться запросы на модификацию. И, причем, параллельно в несколько потоков, что в некотором смысле может выжать из подчиненного больше чем обычно. Но это все надо проверять для конкретной ситуации. Я не использовал, просто знаю об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2015, 13:55:29 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38853097&tid=1833700]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
509ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 794ms |

| 0 / 0 |
