MySQL грузит все ядра проца. Глюк?

poige, Спасибо за совет!

MySQL грузит все ядра проца. Глюк?

poige, опробовано.
похоже что включение thread pool помогло.
Я правда еще пару вещей из доки от Перконы там сделал.
Но похоже что проблемы нет.

Но на самом деле если она и есть - она перестала отражаться на общей работе сайта :) Поэхтому от меня отстали с этим проектом. А т.к. их тут дохрена а я один - я все время забываю вечером глянуть как там дела.

MySQL грузит все ядра проца. Глюк?

Да htop я юзаю чисто для наглядности. top показывает ту же петрушку в целом.
Как там с тредами я хз. Скорее всего аггрегируются все.

thread_cache_size пробовал ставить и 200 и даже чуток выше (судя по наблюдениям он в реале у меня не прыгает более 180). Ничего не менялось по характеру проблемы.

MySQL грузит все ядра проца. Глюк?

Спасибо, конечно, за развёрнутый ответ.
Я писал выше, что движок у нас самописный на Laravel. C огромным количеством legacy-кода. Все запросы генерируются через ORM фреймворка.
Видимо до EXPLAIN дело не дойдёт. Т.к. сейчас все силы брошены на переписывание движка на Yii2. Необходимость давно назревала, но всё как-то откладывали.

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

Более того, от myISAM как раз отказались по причине блокировок. Там блокируется вся запись, а то и вся таблица. А в InnoDB только строка/столбец, задействованный в обновлении.

MySQL грузит все ядра проца. Глюк?

Спасибо, гляну.
Возможно это оно и было.

Прошедшей ночью сервак не лагал, после применения всех советов по конфигу, озвученных здесь :)
Правда я нарушил главное правило радиолюбителя "не крути две ручки сразу", и заодно вырубил демона chronyd. Который оказался заменой ntpd. А я его не сразу заприметил.
Попробую сегодня врубить и понаблюдать за серваком.
Если не будет лагать значит дело всё же было в конфигах.

MySQL грузит все ядра проца. Глюк?

evnuh: Да нет там таких запросов. Я же говорю, я сидел смотрел на mytop и на Dashboard в mysql workbench.
Если б какой-то запрос регулярно повторялся и работал десяток-другой секунд - я бы его заметил.

Но так уж и быть. Включу slowlog вечером, посмотрю чего туда попадает.

MySQL грузит все ядра проца. Глюк?

Arris: Нет. Даже не знаю что это такое.
Я сегодня вечером думаю попробовать подключиться через strace и глянуть top10 системных вызовов.
Но что-то мне кажется что всё дело таки в leap second bug.

Насчёт доступа: к сожалению пока никак. Если не разберусь с вашей помощью, буду пробивать возможность заказать консультацию у спеца. Если есть желание - пишите :) Учтём при поисках.

MySQL грузит все ядра проца. Глюк?

Arris: а что это даёт?

MySQL грузит все ядра проца. Глюк?

Arris: Кстати странно что директивы этой нет. По факту база уже разбита по файлам. Может случайно вынес ее из конфига.

Тем не менее в Mysql Workbench во вкладке Perfomance Reports видно что база активно работает именно с отдельными файлами.

MySQL грузит все ядра проца. Глюк?

Arris: Эти утилиты не смотрел. Посмотрю. Скорее всего нет ничего интересного.
Я через dstat смотрю. Там наглядно видно со временем всю активность по процу/диску/сети.
Так вот, как я уже писал, ничего экстраординарного там нет.

ТТ.е. это не связано с валом запросов которые резко обрушиваются на мускул. Нет. Их столько же. Это не связано с активностью диска. Она подрастает в момент затупа. Но не значительно. И уж тем более не может исчерпать бюджет SSD дисков по IOPSам.

MySQL грузит все ядра проца. Глюк?

x67: Это абсолютно новый сервак. SSD тоже новый. ПО на сервере никакого не стоит, кроме Percona. Даже лишние демоны повырубал.

Да и кроме того, я писал в вопросе что такую картинку вижу не в первый раз. Видел ее и раньше на других серверах. С другим ПО. Еще лет 5 назад видел такое.

MySQL грузит все ядра проца. Глюк?

Нет. Это обычная нагрузка на сервер.
Там 6 серваков Xeon E5-2630 о 32 ядрах каждый крутят аппликуху. Так что недостатка в запросах к базе нет.
К сожалению, как я говорил, приложение было разработано без рассчета того что серверов БД может быть несколько. Огромное легаси, переписывать которое никто не будет. Никто не думал что оно так вырастет.

Сейчас его потихонечку переписывают на другом движке с другим подходом. Но это уже совсем другая история.

MySQL грузит все ядра проца. Глюк?

отключён. да собственно с медленными никто разбираться не будет. все запросы строятся ORM из Laravel.
Откровенное медленные мы видим через Newrelic. И если они тормозят бизнес-ядро ребята переписывают.

А всякие медленные типа статистики в админке и проч никто не трогает. Впрочем их число незначительно и им можно пренебречь. Они медленные в основном из-за объема данных.
Там есть таблицы со статистикой в которых например 200млн записей.

MySQL грузит все ядра проца. Глюк?

Что с IO? Какова нагрузка на диск? Посмотрите через iotop например.

Смотрел. Прекрасно всё. Мизер. 5-25мб запись. Чтение так же от 5 до 150Мбайт (в пике). Но для этих ССД это семечки.

По параметрам. Кроме мускула на сервере что-то крутится? Если нет, смело выкручивайте
innodb_buffer_pool_size до примерно 70% объема RAM.

Ничего вообще. Писал выше. Штатные демоны, которые при установке ОС поставились только. Да и то часть повырубал. Потому что Centos 7 для меня относительно новая. Я еще не понял что все эти tuned и прочие странные штуки делают ))) Привык что у меня на серваке 3-4 демона висит.

Пробовал ставить ну не 70%, но 50%. Побоялся что таки из-за памяти проблемы. Типа я не рассчитал какой-то из параметров, и он помноженный на число коннектов или запросов сжирает память.
Поэтому на всякий случай уменьшил все показатели сейчас.
Но как я уже писал глюк наблюдается в любом случае. При любых параметрах. От дефолтных, до очень высоких значений.

innodb_log_file_size - это размера лога транзакций innodb. Чем он больше - тем реже пересоздается этот файл, и тем меньше нагрузка на диск. Но тем дольше восстановление в случае сбоя. 512mb должно хватить.

Спасибо за разъяснение. Лучше наверное вообще его закомментить. Я почему-то думал что это область памяти такая, где транзакции хранятся.

innodb_flush_log_at_trx_commit = 0 Вы уверены? Поставьте хотя бы 2 - по производительности тож на тож, но безопаснее. А лучше и вовсе 1. Медленно, зато надежно.

Не-не. Ну его нафиг. Это реально переключатель коробки в спорт-режим. С любыми другими значениями всё очень медленно.
Проблем пока не было. Бэкапы всех таблиц через xtrabackup делаются каждый час. Для нас это вполне приемлимо.

query_cache_size = 4096M Куда столько? Помните, что при каждом INSERT\UPDATE этот кеш переписывается. Поставьте 100mb для начала.

А вот это я забыл. Точно.... читал же. Может быть это и есть причина бед. Постоянное выделение памяти...
Спасибо. Поставлю мелкий кэш.

MySQL грузит все ядра проца. Глюк?

vlarkanov: swappiness поставил в 1, как написано в мануале то ли по тюнингу производительности, то ли в доке от Percona. Не помню уже. Разницы особой нет.
Да и судя по мониторингу (Newrelic) своп вообще не юзается.

На самом деле по описанию очень похоже на leap second bug.
Но у меня не установлен ntpd.
Буду копать далее.

MySQL грузит все ядра проца. Глюк?

А, да. Про leap second спасибо что напомнили. Щас погуглю.
Помню что-то такое раньше я уже читал.

MySQL грузит все ядра проца. Глюк?

Про NUMA INTERLEAVE я читал как раз в документации по Percona.
И я его включил в настройках мускула. Согласно доке в Перконе 5.7 она сама умеет при запуске устанавливать нужный интерлив.
Вон в конфиге же

[mysqld_safe]

numa_interleave = yes

На старом сервере забил на это и не включал. Тем не менее все работало нормально. Хотя своппинг действительно был чуток.

Как заставить nginx отдавать по domain.com/sub отдельную папку?

Даниил Муйдинов: Ах вот оно что. А я то только один блок ~ php спрятал. А второй висел снаружи. И я всё не мог понять, почему его выбирает nginx.

Спасибо! Попробую.

Как заставить nginx отдавать по domain.com/sub отдельную папку?

Забавно. Возник этот же вопрос снова. Полез задавать вопрос, а тут оказывается уже все есть. Уже более года как. Причем ситуация один в один. Только в другом месте с другими людьми и другим проектом.

Не пойму причем тут proxy_pass? У меня же все на той же самой машине.

Убрать слэш / в конце URL

Уже не помню. Наверное как-то обошёл.