Bitrix mysql грузит процессор
Устанавливал mysqltuner - правил конфиг, как он просил с ожиданием в 24 часа. Всё без изменений. На сервере около 40-ка сайтов, которые парсят контент. Сервер сильно соответственно сильно нагружается, когда разом парсят. Спасает сейчас только одно рестарт mysql каждые 20 минут.
Может посоветуете что-нибудь? Как-нибудь ограничить кол-во mysql коннектов внутри сервера или поочерёдно что бы делались запросы? Запутался вообщем.
В вашем случае нагрузка по CPU? Индексируйте таблицы, уничтожайте не нужные данные, оптимизируйте запросы. В некоторых случаях имеет смысл в конвертации табличек в InnoDB, но большой результативности можно добиться только реорганизацией самих баз.
lonelywoolf:
В вашем случае нагрузка по CPU? Индексируйте таблицы, уничтожайте не нужные данные, оптимизируйте запросы. В некоторых случаях имеет смысл в конвертации табличек в InnoDB, но большой результативности можно добиться только реорганизацией самих баз.
Да, именно загружен проц. Может возможно как-то сделать ограничение, что бы проц не загружался на 100%, а в щадящем режиме шёл парсинг?
у вас innodb-таблицы ? действительно столько нужно?
категорически уберите. мускуль прогревается после запуска. зачастую ему нужно и несколько часов , что бы прогреться полностью, а вы тормозите этот процесс рестартом.
смотрите /var/log/mysqld-slow-query.log и что там. и напрягайте своего программиста. Возможно при открытии главной у вас выполняется запрос, который запрашивает зачем-то 100млн записей , а они бесполезны.
попробуйте без весты или другую панельку. у меня тоже впска падала и падала она из-за весты ))
веста - это просто панель управления.
forfun, Не в данном случае. Здесь просто не оптимально написаны парсеры.
Смотрите лог медленных запросов, 99% вероятности, что прогер не использует where в выборках базы!
Запросы базы оптимизируйте, все что больше 1й секунды выполняется - это плохо!
Хорошо было бы включить кэшировние в базе.
pupseg:
у вас innodb-таблицы ? действительно столько нужно?
категорически уберите. мускуль прогревается после запуска. зачастую ему нужно и несколько часов , что бы прогреться полностью, а вы тормозите этот процесс рестартом.
смотрите /var/log/mysqld-slow-query.log и что там. и напрягайте своего программиста. Возможно при открытии главной у вас выполняется запрос, который запрашивает зачем-то 100млн записей , а они бесполезны.
baas:
Смотрите лог медленных запросов, 99% вероятности, что прогер не использует where в выборках базы!
Запросы базы оптимизируйте, все что больше 1й секунды выполняется - это плохо!
Хорошо было бы включить кэшировние в базе.
Если не делать перезапуск mysql - сайт просто не будут доступны часа 3 к примеру или через раз будут открываться и ругаться на коннект к mysql.
Slow wuery и подключал ранее, но почему-то он пустой. Вот сейчас разкомментил строчки:
Добрый день. Уже второй месяц мой сайт работает нестабильно, медленно и создает большую нагрузку на сервер. Хостер первый месяц молчал, затем начал слать письма такого содержания:
Ранее Вам направлялись уведомления о необходимости снижения нагрузки, оказываемой аккаунтом. В случае если на текущем этапе развития Ваших проектов снижение оказываемой нагрузки до установленных ограничений невозможно, вероятно, техническое решение виртуального хостинга не подходит для Ваших задач. В этом случае Вам следует рассмотреть возможность перехода на один из следующих вариантов размещения:
Также Вы можете расширить лимит нагрузки на CPU внутри текущего тарифного плана, подключив платную дополнительную услугу "Расширенная нагрузка на сервер". Эта возможность доступна в разделе "Тариф" Вашей панели управления аккаунтом. Если нагрузка не будет превышать новых лимитов, это будет являться решением проблемы.
До 2016-02-02 включительно Вам необходимо снизить нагрузку до ограничений тарифного плана, после чего проконтролировать создаваемую аккаунтом нагрузку; либо принять решение об адекватной смене условий размещения. Если по истечении данного срока будет наблюдаться повышенная нагрузка, в соответствии с регламентом о предоставлении услуг мы будем вынуждены приостановить работу сайтов аккаунта.
Получить консультацию по данному вопросу Вы можете в рамках текущего обращения системы обратной связи.
Я использую тариф Eterno , который по сути рекомендован битриксом.
Логи нагрузки за последние дни.
Помимо битрикса, установлено "решение" от студии Romza - Bitronic 2.0
Есть подозрение, что это связано с каким-то компонентом, который глючит.
В службу тех.поддержки ромзы 13.01, т.е. пошла 3-я неделя, а ничего так и не предприняли.
Что мне делать? Деньги за хостинг оплачены на год вперед, решение ромзка куплено, битрикс управление сайтом куплено, а ничего не работает.
В этой статье мы расскажем, как оптимизировать крупный проект в «Битрикс24» и увеличить его производительность в 3 раза, изменяя настройки MySQL и режим питания CPU.
Корпоративный портал в «Битрикс24», рассчитанный на несколько сотен пользователей, c ~300 Гб файлов и ~80 Гб БД на выделенном сервере с BitrixVM.
До изменения настроек показатели были следующими:
Стандартный тест производительности в панели администратора «Битрикс»
Из всех параметров стоит обратить особое внимание на работу с MySQL и «Конфигурацию PHP». Именно эти показатели особенно важны для нас, так как они косвенно отражают уровень производительности проекта.
Запрос клиента
Наш клиент хотел не только перенести проект на новый выделенный сервер, но и улучшить параметры производительности. Например, среди сложностей можно назвать отсутствие возможности делать дампы базы данных на исходном сервере, а также медленную работа самого портала.
Решение
Настройки MySQL — первое, с чем мы начинаем работать.
Заменим стандартные значения BitrixVM на:
Следующий шаг — изменим режим питания CPU, так как «Битрикс» любит большую частоту процессора.
В зависимости от количества ядер меняем в каждом
файле /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor powersave на performance.
Далее проверим результат:
Мы видим, что больше всего изменилась работа с MySQL: параметры “запись” и “изменение” выросли почти в 3 раза; показатель “чтение” вырос в 5 раз. Это значит, что при обращении сайта к базе данных этот тип операции будет выполняться в несколько раз быстрее. Как следствие, вырастет и общая производительность сайта.
Из-за изменения режима питания CPU (это возможно, так как используется выделенный сервер) увеличилось количество операций на CPU.
Теперь необходимо отредактировать настройки для OPcache.
В файле /etc/php.d/10-opcache.ini заменяем его исходное значение на:
Примечание: Тест «Битрикс» сообщит вам, что параметр opcache.revalidate_freq должен иметь значение 0 а не 1, но с указанным нами он будет работать лучше.
Сам параметр opcache.revalidate_freq отвечает за проверку кеша: при значении 0 она выполняется каждый раз при запуске скрипта, а при значении 1 — раз в секунду.
После изменения настроек проверяем результат:
Из таблицы следует, что показатель работы с MySQL еще немного вырос. В то же время операции на CPU и общая производительность «Битрикс» увеличились значительно за счет изменения настроек PHP и кеширования скриптов.
Вывод
Благодаря таким несложным изменениям в настройках, мы смогли увеличить производительность проекта в 3 раза, а взаимодействие с БД — от 3 до 5 раз (на основании общей оценки теста «Битрикс»). Работой проекта на новом сервере наш клиент полностью доволен. We did it!
В данном способе оптимизации мы сделали акцент на основных моментах, с которыми взаимодействует «Битрикс», а также на сам тест. Клиенты часто обращают внимание именно на него.
Среди других способов повышения производительности «Битрикс» можно назвать установку и настройку кеширующего сервиса (например, Redis). Показатель производительности в CMS может упасть, но общая работа сайта должна быть лучше. Кроме того, можно использовать php-fpm, но в нашем случае переделывать ОС, изначально настроенную под «Битрикс», было бы нерационально.
Также можно еще поиграться с настройками MySQL. Они индивидуальны для каждого проекта и конфигурации, поэтому единого идеального рецепта не существует. Будет интересно узнать ваши лайфхаки по оптимизации проектов в «Битрикс». Делитесь мнением в комментариях.
Лучше всего проблему иллюстритует сия картинка
Если описать это словами, то выходит так. Сервер работает как ни в чём ни бывало. Нагружено около половины ядер. И не на 100%, а на 50-70%. Потом внезапно нагрузка улетает в космос. При этом база встаёт раком, ответы происходят очень долго. Всё это длится 10-50 секунд, и потом опять перерыв на минутку.
И я никак не могу понять в чём причина этой беды. Ибо эту картинку я вижу не в первый раз. На нее я натыкался и ранее, еще лет 5 назад. То есть собственно версия ядра, дистрибутива или даже мускуля скорее всего не причем.
Причем по мониторингу (htop) видно что проц то загружен системным вызовом. Т.е. это или огромное количество некоторых вызовов к ядру, или интенсивное выделение-забирание памяти, или ввод-вывод.
Но как промониторить самые топовые вызовы ядра я не знаю. Память судя опять же по мониторингу массово не выделяется и не забирается (по меньшей мере гигабайтами, чтобы это было заметно).
iotop показывает ввод-вывод не сильно отличающийся от такового в нормальном состоянии.
Запросы во время глюка выполняются самые обычные. Не сказать чтобы как-то менялась пропорция выбор/обновление, или запрашивались особые таблицы. Думал может что-то по крону запускается из переодических заданий. Но я пробовал останавливать их все на время. Проблема остается.
К слову о сервере и системе: 2 x Xeon E5-2680v3 @2.5GHz (24 реальных ядра), 64Гб DDR4. SSD энтерпрайз уровня на 960Гб. Быстрые. Ну то есть сервер очень даже ничего. ОС Centos 7 (ядро 3.10), юзаю Percona 5.7. База на отдельном разделе (впрочем рояли это особо не должно играть). Кроме мускуля на сервере не стоит вообще ничего.
Собственно неделя как переехали со старого сервака, который был ровно в 2 раза слабее и перестал тянуть нагрузку.
Так вот на нём по началу я тоже видел такую же картину переодически. Но потом подобрал такие параметры в конфиге мускула, что всё вроде как улеглось. Но все ж сервак перестал тянуть, и мы переехали на новый. а тут опять эта проблема.
И тут время перейти к тому, чтобы рассказать что я УЖЕ делал:
1) Рестарт мускула - спасает ситуацию на минуту
2) Рестарт сервера ни на что не влияет
3) Тюнинг параметров. Пробовал дефолтные. Пробовал со старого сервака. Пробовал поднимать до разумных значений. Пробовал до неразумных. Пробовал тюнить по советам утилиты mysqltuner. Ничего не помогает.
Важное замечание: проблема наблюдается только в час пик. Так что всё это явно коррелирует с нагрузкой на мускул сервер. В остальное время дня всё окей.
Что еще я хочу сказать. я не настоящий сварщик. В смысле не DBA. Просто рядовой Linux-админ. Я плохо понимаю как внутри устроен mysql, innodb и так далее. Поэтому и прошу помощи. Разобраться сам не смог.
Ниже прикреплю на всякий случай шапку от mytop:
Сейчас конечно не час-пик уже. Но хоть какая-то инфа.
И заодно конфиг мускула
Если интересно, могу опубликовать скрин Mysql Workbench Dashboard во время того когда мускул глючит.
Или Perfomance Statistics. Все равно я в ней ничего особо не понимаю.
Очень хочется разрешить уже этот глюк для себя. И понять почему он возникает.
Пока подозрения на то что у меня мускул сконфигурирован так, что потенциально может запросить больше памяти чем есть. И это как-то сносит крышу ядру.
У меня проблемы с моим LAMP-сервером. В последнее время все стало очень медленно, хотя количество посетителей на моих сайтах сильно не изменилось. Когда я запускаю top команду, она говорит, что процесс MySQL занял 150-200% процессорного времени. Как это возможно, я всегда думал, что 100% это максимум?
Я использую серверную версию Ubuntu 9.04 с 1,5 ГБ оперативной памяти.
Что может быть причиной этой проблемы? Могу ли я внести изменения в мой, my.cnf чтобы предотвратить зависание сервера?
- Увеличьте ключевой буфер (у вас сейчас 64 МБ, но суммарные индексы составляют 116 МБ, поэтому установите не менее 128 МБ). Должно помочь немедленно.
- Запустите mysqloptimize и mysqlrepair на ваших столах
- Увеличьте кеш таблиц / уменьшите общее количество таблиц, чтобы увеличить частоту обращений к кешам таблиц. Возможно, у вас есть неиспользованные или старые таблицы, которые можно удалить.
Другие рекомендуемые варианты конфигурации:
- log_slow_queries = /var/log/mysql/mysql-slow.log
- long_query_time = 4
- лог-запросы, не использующие индексы-
Проверьте файл журнала через некоторое время.
У вас есть процессор с несколькими ядрами или несколько процессоров. Если у вас два ядра и процесс использует 100% обоих ядер, он будет отображаться как 200% сверху.
Аналогично, это, вероятно, работает как задумано - с вашей конфигурацией все в порядке. Если вы испытываете частые зависания, из того, что вы опубликовали, вы можете захотеть добавить правильные индексы в свои таблицы (или оптимизировать свои запросы).
Запустите, top -H чтобы увидеть все запущенные потоки, а не только общий процесс. Кроме того, если вы нажмете 1 клавишу в верхней части, он покажет вам использование процессора для отдельных процессоров / ядер.
Спасибо, это действительно помогло мне - много лет использовал топ и не знал, что у него есть такая способность. Я обнаружил, что существует один «вечный» поток mysql, который все время потребляет 60% ЦП, в то время как потоки запросов приходят и уходят поверх этого. Теперь, чтобы узнать, что на самом деле делает эта тема .
Mysql имеет несколько процессов (потоков), работающих независимо, например, один отвечает за запись данных из памяти на диск. При наличии нескольких ядер в ЦП (и / или нескольких ЦП) работает более одного потока, и поэтому он может работать более чем на 100% одного ядра - на упрощенном уровне, возможно, работает 75% каждого из двух ядер , давая 150%.
Я заметил проблему, не связанную с процессором. Если вы используете apache и MySQL на одном сервере, вы можете достичь плохих условий ( ОЗУ ), когда ваша активность apache возрастет.
MySQLTunner сообщает вам, что, используя 200 доступных подключений (ваш максимальный параметр подключения), вы будете заполнять оперативную память. Допустим, у вас ограничен процесс Apache до 150, и вам наверняка не хватит оперативной памяти, когда MySQL и apache попытаются использовать 150 соединений (поскольку Apache также является хорошим потребителем ОЗУ).
Так что речь идет об оперативной памяти, и вы, возможно, еще не нажали :-) Верхние команды показывают только 15 процессов Apache (но вы загружаетесь в среднем 3/6/16, так что это означает, что шторм был 15 минут назад и сейчас в оставляя).
Что касается проблемы с процессором, чтобы дополнить хороший ответ shakalandy , это может быть из-за одного запроса. Это может быть огромная таблица, выполнение множества заданий по переиндексации, использование большого количества временных файлов, отсутствие индекса (удаление?) И т. Д. Единственный способ обнаружить его - активировать журнал медленных запросов (может быть, с высоким порогом, как 8s). Затем используйте инструмент mysqlsla для анализа этого медленного журнала запросов и выполните некоторые объяснения по идентифицированным запросам.
Читайте также: