|
|
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
LiveMannetwindпропущено... эффект плацебо кстати тоже научно подтвержден и существует. Чудеса. Я на перкону переходил 2 года назад(с 5.5 на 5.5), точных цифр не помню. Прирост был очень значительный, видимый на глаз по скорости загрузки интерфейса. По цифрам какие то запросы стали работать до 20-30% быстрее. Естественно, что не все стало работать быстрее, основная часть запросов не ускорилась. Быстрее стали работать особенно кривые либо сложные запросы с большим количеством соединений. Если кто то считает что сравнение цифр выполнения запросов это плацебо, то напоминаю, что у нас в стране все еще свобода мыслей. ;) То есть вы в высокопараллельной системе по одному запросы запускали и проверяли? Ясно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 11:24 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrowсделай таки скрин top и iotop Сделаю, как только будет замечена проблема с производительностью. Пока что полет нормальный. LiveMan А ТС почему то упорно не желает делить буфер иннодб, хотя при большом количестве соединений это помогает. А что, несколько инстансов поможет даже при том, что буфера реально используется меньше 1 ГБ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 11:29 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
netwind.... То есть вы в высокопараллельной системе по одному запросы запускали и проверяли? Ясно. Интересно конечно когда человек сам задает вопрос и сам пишет что ему все ясно. Ну хорошо что ясно :) Только мне не понятно зачем вопрос писать. s_vist... LiveMan А ТС почему то упорно не желает делить буфер иннодб, хотя при большом количестве соединений это помогает. А что, несколько инстансов поможет даже при том, что буфера реально используется меньше 1 ГБ ? Разделить буфер надо для того, чтобы не использовать один мютекс буфера. Чеб больше разделено - тем больше параллельности. Но официальные рекомендации делить не менее чем по 1Гб. У меня разделено по 512 и это себя оправдывает, меньше делить точно не стоит(по крайней мере у меня на тестах не получилось выиграть в производительности) Заполняться буфер будет одновременно во всех инстансах. То есть у вас будет 2 не до конца заполненных инстанса буфера. У вас ведь есть тестовый сервер. Вы на нем можете попробовать радикальные способы ? Типа как перейти на перкону, перезалить бекап. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 11:47 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
LiveManА ТС почему то упорно не желает делить буфер иннодб, хотя при большом количестве соединений это помогает. И переход на 5.6 я советовал из похожих соображений - там улучшена работа с кешем запросов. Большое количество соединений они сами создали на пустом месте из-за того что запросы плохие. Соединений там мало должно быть и их мало в отсутствии "лавины". И я что-то никаких улучшений query_cache не обнаружил на соответствующей страничке https://www.percona.com/doc/percona-server/5.6/performance/query_cache_enhance.html Раз ничего не написано, может все-таки плацебо ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 11:47 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
LiveMannetwind.... То есть вы в высокопараллельной системе по одному запросы запускали и проверяли? Ясно. Интересно конечно когда человек сам задает вопрос и сам пишет что ему все ясно. Ну хорошо что ясно :) Только мне не понятно зачем вопрос писать. Суть поста в том, что мне ясно, что у вас методика измерений ненадежная и я это демонстрирую. А вы, возможно, не осознаете этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 11:55 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
авторРаз ничего не написано, может все-таки плацебо ? там паралельность увеличили. а судя по всему это актуально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 13:12 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrow, тогда актуальнее просто выключить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 13:56 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторРаз ничего не написано, может все-таки плацебо ? там паралельность увеличили. а судя по всему это актуально. Где, кстати, ссылка на это? Подтверждение не гуглится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 14:55 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 15:05 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrow, не, где ссылка на то что улучшен query_cache ? я, похоже, не так понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 15:48 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
netwindScareCrow, не, где ссылка на то что улучшен query_cache ? я, похоже, не так понял. ссылку на что и для чего вам надо? в перконе запилили возможность выключить кэш запросов нафик. всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 16:01 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
Короче, сегодня опять ситуация имела повторение В таком ключе: была 2 пика нагрузки на процессор, с интервалом в полчаса пики были очень кратковременные, успел их отфиксировать только по таким собщениям в консоли авторMessage from syslogd@stage at Jun 27 16:05:01 ... kernel:[1477905.036002] BUG: soft lockup - CPU#20 stuck for 23s! [mysqld:31115] Message from syslogd@stage at Jun 27 16:05:01 ... kernel:[1477905.084003] BUG: soft lockup - CPU#21 stuck for 22s! [php5-fpm:7551] Message from syslogd@stage at Jun 27 16:05:01 ... kernel:[1477905.136005] BUG: soft lockup - CPU#22 stuck for 22s! [php5-fpm:7553] Message from syslogd@stage at Jun 27 16:05:04 ... kernel:[1477908.044003] BUG: soft lockup - CPU#0 stuck for 23s! [php5-fpm:31044] Message from syslogd@stage at Jun 27 16:05:04 ... kernel:[1477908.076004] BUG: soft lockup - CPU#1 stuck for 23s! [mysqld:28738] Message from syslogd@stage at Jun 27 16:05:04 ... kernel:[1477908.388003] BUG: soft lockup - CPU#7 stuck for 22s! [php5-fpm:3396] Message from syslogd@stage at Jun 27 16:05:05 ... kernel:[1477908.436003] BUG: soft lockup - CPU#8 stuck for 22s! [php5-fpm:32187] Message from syslogd@stage at Jun 27 16:05:05 ... kernel:[1477908.480006] BUG: soft lockup - CPU#9 stuck for 22s! [php5-fpm:31175] Message from syslogd@stage at Jun 27 16:05:05 ... kernel:[1477908.536016] BUG: soft lockup - CPU#10 stuck for 22s! [php5-fpm:32186] Дальше top уже никакой аномальной нагрузки не показывал и сайт работал нормально, так что скринов, увы, не будет Лог гипервизора показал всплеск до 70% CPU usage А через полчаса - еще один всплеск, такого же порядка А вот теперь из мониторинга значения Threads_created За полчаса до 1го всплеска нагрузки: | Threads_created | 634 | (такое же значение было в течение всего дня, еще со вчерашнего вечера) Сразу же после 1го всплеска: | Threads_created | 714 | Сразу же после 2-го всплеска: | Threads_created | 822 | Напрашивается вывод, что потребление процессорного ресурса существенно увеличивается при создании относительно большого количества новых потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 16:59 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
s_vist| Напрашивается вывод, что потребление процессорного ресурса существенно увеличивается при создании относительно большого количества новых потоков. Должен напрашиваться вывод, что при замедлении работы одних тредов, создаются дополнительные и возникает "лавина". Сколько сейчас обработчиков php-fpm максимально возможно ? Я уже предлагал уменьшить. Довольно странно и сообщение о залипании mysqld на 23 секунды. Что у вас там вместо сервера ? Зачем понадобился proxmox ? Какие еще машины и не могут ли они вносить смуту ? Может быть какой-то админ proxmox ручки крутит и бекапы живые делает. Или диск помирает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2016, 21:07 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
netwindLiveManпропущено... Интересно конечно когда человек сам задает вопрос и сам пишет что ему все ясно. Ну хорошо что ясно :) Только мне не понятно зачем вопрос писать. Суть поста в том, что мне ясно, что у вас методика измерений ненадежная и я это демонстрирую. А вы, возможно, не осознаете этого. Вы у меня не спрашивали методику и поэтому я вам ее не говорил. Поэтому что-то демонстрировать несколько "ненадежно". А меж тем методика измерений достаточно точная. Все тесты были повторены многократно, чтобы убрать ошибки от виртуальной среды. Я гонял тестовый сервер сначала на 5.5 потом на перконе 5.5 и в один поток и в несколько потоков. При том гонял как sysbench так и готовую систему с переходами по интерфейсу. Так что если что есть добавить или предложить по существу - предлагайте, можно даже в ЛС, чтобы в тему не мусорить. Если нет, тогда предлагаю закончить этот флейм. А по теме хорошо бы в нерабочее время запустить нагрузочный тест и посмотреть что будет, когда ресурсы закончатся. Не обязательно, что мускл виновен. Может быть он нормально работает, но Proxmox не дает ресурсов или сам хост перегружен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 06:29 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
опять наблюдали проблему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 14:38 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
Прикладываю скрины top и htop в момент проблемы(iotop, к сожалению, оказалась не установлена) top htop ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 14:46 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
31%sy или диск или мютексы или коннекты к чему то удалённому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 17:10 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrowили коннекты к чему то удалённому. например, как это может происходить в реальности? что к чему может коннектиться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 17:37 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
ScareCrow31%sy или диск или мютексы или коннекты к чему то удалённому. или по моему первоначальном сценарию : безумное количество простых, но тупых запросов, которые вызывают массу накладных расходов на межпроцессные коммуникации. В общем, ничего у вас не получится так. Ставьте плагины какие-нибудь для кеширования целых страниц html в wordpress, как и все беспомощные вебмастеры. Это не стыдно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 18:40 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
Ну и какие-то внешние проблемы вызванные виртуализацией могут быть : помирающий диск, автоматический бекап машины, конкуренция за ресурсы с другими виртуальными машинами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2016, 19:03 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
Доступ к proxmox-у есть ? Можно посмотреть что происходит в эти моменты ? Проц на хосте и задержки дисков. Ошибки в логе очень похожи на проблемы в виртуализации. По мускл вам очень много насоветовали, и практически все совпадает с рекомендациями мусклтюнера. Как все примените так у вас чуть лучше и станет, но мне кажется что не полностью. Ну и может настроить nginx на кеширование всего и подольше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 05:14 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
авторчто к чему может коннектиться? автор[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 10:57 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
netwindScareCrow31%sy или диск или мютексы или коннекты к чему то удалённому. или по моему первоначальном сценарию : безумное количество простых, но тупых запросов, которые вызывают массу накладных расходов на межпроцессные коммуникации. В общем, ничего у вас не получится так. Ставьте плагины какие-нибудь для кеширования целых страниц html в wordpress, как и все беспомощные вебмастеры. Это не стыдно. Похоже, netwind пока что ближе всех к правильному ответу. Для начала - по proxmox. Никаких бэкапов в рабочее время не запускается, на гипервизоре живут еще 3 виртуальных машины, которые чувствуют себя нормально, причем одна из них - еще более нагруженный, чем наш проблемный сайт, веб-сервис, который просто летает на 4-х ядрах и 4 ГБ ОЗУ(правда, на нем только nginx + apache + php, БД вынесена на отдельный физический сервер(там MSSQL)) Теперь по статистике Я с позавчера начал выгружать все переменные состояния каждые 2 минуты и складывать в отдельный лог Так вот, в то время, когда у нас полезла вверх нагрузка на ресурсы машины, у нас увеличилось число max_used_connections со 199 до 354 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 11:05 |
|
||
|
Mysql периодически жрет ресурс CPU
|
|||
|---|---|---|---|
|
#18+
Продолжаю... так же увеличилось число thread_created c 248 до 698(разница в снятии данных - 2 минуты) Ну и последнее, по статистике переменной connections Вообще, средняя разница этого параметра на каждом 2-минутном интервале перед случившейся "лавиной" интервале составила около 2000, кроме последнего. На последнем 2-минутном интервале, на котором по сути уже началось выжирание процессорного ресурса, разница в количестве connections составила 3948 - почти в 2 раза больше среднего. По логу nginx вычислить какую-то аномалию довольно сложно было, т.к. там на каждый запрос есть куча связанных запросов(стилей, картинок и скриптов), поэтому простыми подсчетами кол-ва запросов на интервале времени выявить повышенную нагрузку не удавалось ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2016, 11:23 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=39263071&tid=1831334]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
224ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 596ms |
| 0 / 0 |
