MySQL Governor: ограничение ресурсов базы данных отдельных клиентов хостинга

Что ограничивает MySQL Governor

MySQL Governor является компонентом CloudLinux для серверов виртуального хостинга, а не общей функцией MySQL. Он отслеживает нагрузку на базу данных по привязанным пользователям и может ограничивать запросы при превышении пороговых значений с помощью Lightweight Virtual Environments (LVE). Таким образом, нагрузку на отдельные хостинг-аккаунты можно оценивать более дифференцированно, чем просто по общей загрузке сервера базы данных.

В центре внимания находятся Процессор и ввод-вывод жестких дисков: Губернатор учитывает вычислительную нагрузку, а также активность чтения и записи. Высокая нагрузка может быть вызвана, например, импортом данных или часто выполняемым запросом к интернет-магазину. Привязка к учетной записи позволяет увидеть эту нагрузку; а вот является ли она адекватной для данной операции, необходимо оценивать в контексте.

Ограничение на базы данных для этих ресурсов не является квотой на дисковое пространство. Крупная, редко используемая база данных может создавать небольшую текущую нагрузку на ЦП и системы ввода-вывода; и наоборот, небольшая база данных может создавать значительную нагрузку из-за большого количества ресурсоемких обращений. Ограничения на количество подключений также решают иную задачу: они ограничивают количество обращений, но не заменяют автоматическое управление нагрузкой на ЦП и ввод-вывод.

Если запрос ограничивается, это не обязательно означает, что он содержит ошибку. Такое ограничение может защитить другие учетные записи от высокой нагрузки, но в то же время замедлить работу легитимного приложения. Гарантированные времена отклика из этого не вытекают, поскольку служба базы данных, аппаратное обеспечение и другие компоненты приложения остаются общими элементами системы.

Для понимания взаимосвязи между счетами, нагрузкой и LVE предлагается дополнительный обзор по Ограничение нагрузки на базу данных с помощью CloudLinux MySQL Governor еще один вариант доступа. Решающее значение для конкретной настройки имеют фактически установленная среда и действующие в ней настройки.

Проверить версию и совместимость

Прежде чем планировать ограничения базы данных, сначала проверь Издание и лицензия. По заявлению производителя, в CloudLinux OS Admin отсутствует компонент MySQL Governor. Поэтому наличие самой системы CloudLinux не является доказательством того, что данный компонент доступен для выбранной версии, лицензирован и установлен на сервере.

Затем необходимо учитывать сочетание версии CloudLinux, пакета Governor и сервера базы данных. MySQL и MariaDB представляют собой отдельные ветви разработки: поддержка той или иной версии MySQL не означает, что версия MariaDB того же возраста будет работать в тех же условиях. Также необходимо проверить используемую панель управления и её интеграцию.

Минимальные требования показывают, почему общего разрешения недостаточно: для MySQL 8.4 CloudLinux указывает как минимум версию MySQL Governor 1.2-129. MariaDB 11.4 требует как минимум версию 1.2-122 MySQL Governor и, согласно документации производителя, не поддерживается в CloudLinux OS 7. Эти сведения относятся к указанным ветвям и не заменяют проверку остальных комбинаций.

В качестве сред установки производитель указывает, в частности, cPanel, Plesk, DirectAdmin, ISPmanager и InterWorx, а также серверы без панели управления. В случае использования другой панели или самостоятельно интегрированной панели вам следует отдельно уточнить конкретные возможности поддержки и, в частности, вопросы привязки пользователей. Указанная версия базы данных не гарантирует совместимость со всеми комбинациями панелей управления и операционных систем.

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

Присвоение хостинг-аккаунтов пользователям базы данных

Чтобы нагрузку можно было отнести к конкретному клиенту хостинга, необходимо обеспечить правильное сопоставление между пользователями базы данных и учетными записями хостинга. При интеграции с панелью управления для этого обычно используется файл /etc/container/dbuser-map обновляется. Губернатор вносит изменения в это сопоставление в соответствии с документацией по интеграции в течение пяти минут.

Пример: на одном хостинг-аккаунте размещены интернет-магазин и отдельный блог, каждый из которых работает с собственным пользователем базы данных. Если оба пользователя привязаны к одному и тому же аккаунту, нагрузка на базу данных может учитываться в отношении этого аккаунта. Если одна из записей отсутствует или указывает на неправильный аккаунт, отображаемое сопоставление не будет достоверным для оценки по клиенту.

Проверь Присвоение пользователей поэтому это касается не только первоначальной установки. Даже после создания или перемещения баз данных и пользователей панель управления должна корректно обновлять сопоставления. При проверке сразу после внесения изменений следует учитывать указанный в документации срок обновления, прежде чем делать вывод о постоянной ошибке на основании данных, которые ещё не обновлены.

Особенно важно отсутствие сопоставления в режиме «Abusers»: по заявлению производителя, в этом режиме эмулируется режим «Single». Клиенты с ограниченными правами в режиме «Single» совместно используют один общий LVE с ограниченными правами, вместо того чтобы каждый из них был ограничен в собственном клиентском LVE. Поэтому сам по себе активированный режим «Abusers» ещё не доказывает, что предусмотренное ограничение для отдельного аккаунта действительно действует.

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

Сравнение режимов работы

Режим работы определяет, будет ли MySQL Governor лишь отслеживать нагрузку на базу данных или выполнять запросы в ограниченной среде. При выборе режима важны не только пороговые значения: на результат также влияют назначение пользователей базы данных и то, какие клиенты совместно используют один LVE.

Для проведения анализа текущей ситуации можно воспользоваться С сайта Примечание: Анализ использования показывает, какие учетные записи и периоды времени заслуживают более тщательной проверки, при этом Governor не ограничивает количество запросов. Однако однократное высокое значение моментальной нагрузки еще не означает, что учетная запись постоянно генерирует большую нагрузку или же в данный момент выполняет законные работы по техническому обслуживанию.

На сайте Злоумышленники ограниченные запросы к базе данных делят бюджет ресурсов LVE с другими процессами той же учетной записи, например с PHP. Поэтому ограничение может не только увеличить время выполнения запросов: приложение также может реагировать медленнее, если его процессы конкурируют за одни и те же ограниченные ресурсы. И наоборот, уже задействованный бюджет PHP может повлиять на работу базы данных.

Параметр «Single» устарел и актуален, прежде всего, для существующих конфигураций, а также для задокументированного поведения при замене: несколько клиентов с ограничениями совместно используют одну среду и могут конкурировать друг с другом в ней. При отсутствии файла dbuser-map Abusers эмулирует такое поведение; на основании только выбранного параметра невозможно сделать вывод о наличии ограничений, специфичных для конкретного клиента. Параметр «All» также устарел и не рекомендуется для новых установок.

Планирование ограничений базы данных и временных интервалов

MySQL Governor различает загрузку ЦП, а также ввод-вывод при чтении и записи. В документации по командной строке показатели ЦП указываются в процентах, а ввод-вывод — в МБ/с; для чтения и записи можно настроить отдельные значения. Эти показатели отражают разные виды нагрузки: вычислительно-интенсивная операция не обязательно сопровождается значительным объёмом записи на носитель.

Пороги текущий, краткосрочный, среднесрочный и долгосрочный учитывают краткосрочное и длительное использование. Их превышение приводит к введению ограничений в зависимости от режима работы и конфигурации. Они не являются ни гарантированной пропускной способностью, ни четырьмя независимыми друг от друга постоянными жестко соблюдаемыми гарантиями производительности. То, какое ограничение фактически вступает в силу, зависит также от выбранного метода и предельных значений LVE.

Импорт наглядно демонстрирует разницу: если нагрузка на запись кратковременно возрастает, а затем снова снижается, это может быть частью запланированного рабочего процесса. Если же она остается высокой в течение длительного времени, импорт дольше задействует ресурсы. При принятии решения, помимо пикового значения, следует проверить, какой ресурс задействован, как долго длится процесс и повторяется ли он.

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

Планируйте значения регулятора с учетом предельных значений LVE и фактически предлагаемых тарифов. Рекомендации производителей явно учитывают эту взаимосвязь; однако на их основе невозможно вывести универсальные производственные показатели. Наблюдаемая нагрузка запросов, эффективность запросов и характер работ клиентов служат основой для контролируемой корректировки пороговых значений после внедрения системы.

Подготовка к внедрению и установке тарифных ограничений

Перед установкой или обновлением необходимо полная резервная копия базы данных включая системные таблицы. Также запланируйте, как будет осуществляться восстановление в случае необходимости. Производитель обращает внимание на то, что пакеты баз данных можно обновлять из репозиториев CloudLinux; поэтому смена пакета — это не безобидный побочный эффект, который следует проверять только после установки.

Затем проверьте сочетание издания и версии CloudLinux, лицензии, ветви базы данных, пакета Governor и панели управления. Наличие поддерживаемой версии базы данных само по себе не гарантирует, что каждая комбинация этих компонентов поддерживается. Если версии пакетов или интеграция с панелью управления не соответствуют требованиям, перед началом работ необходимо уточнить, поддерживается ли данная комбинация.

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

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

CloudLinux Manager позволяет управлять ограничениями регулятора на уровне отдельных пакетов; для отдельных клиентов могут применяться иные значения. Поэтому при каждом изменении необходимо документировать Источник ограничения: Это значение взято из пакета или задано индивидуально? Так впоследствии можно будет отследить, на каких клиентов повлияет изменение тарифа, а какие исключения необходимо проверить отдельно.

Проверить текущую нагрузку и историю

Для постановки диагноза тебе понадобится как Снимок а также динамику во времени. Приведенные ниже команды выполняются в терминале сервера CloudLinux, а не в консоли MySQL. Они предназначены для ознакомления и не изменяют ограничения; для проведения полноценного анализа необходимо установить соответствующие инструменты и обеспечить доступность необходимых данных.

Одинаковые подозрительные счета с Присвоение пользователей и от выбранного режима работы. Если какой-либо пользователь базы данных отсутствует в файле сопоставления, видимая нагрузка на хостинг-аккаунт может быть неполной. В документации по интеграции указано, что изменения в файле сопоставления вступают в силу в течение пяти минут; поэтому данные, проверенные сразу после этого, могут ещё не отражать новое состояние.

Затем сравните момент возникновения ограничения с наблюдаемым процессом использования. Высокое единичное значение может быть связано с импортом и само по себе не является доказательством постоянного чрезмерного использования. Руководство по чтению отчетов MySQL Governor дополняет интерпретацию отображаемых показателей.

Различать ограничение мощности и его причины

Если сайт начинает работать медленно, сначала проверьте, действовало ли в данный момент какое-либо ограничение и какая причина указана. Соотнесите этот результат с конкретным процессом: замедление оформления заказа и одновременно выполняемый импорт могут быть связаны, но не обязательно. Без совпадения по времени было бы поспешным считать регулятор единственной причиной.

В режиме «Abusers» выполняются ограниченные запросы к базе данных в LVE соответствующей учетной записи. Там они делят Бюджет ресурсов с другими процессами, работающими с учетными записями, например, с PHP. Поэтому при возникновении жалобы следует учитывать обе стороны: задача, интенсивно использующая базу данных, может конкурировать с PHP за ресурсы; и наоборот, уже занятые ресурсы LVE могут влиять на производительность запросов.

Если нагрузка на какую-либо функцию магазина повторяется, проанализируйте соответствующий запрос и его План запросов вместе с соответствующими статистическими данными базы данных. Отсутствие или несоответствующий индекс — одна из возможных причин, но не единственная. Ограничение может уменьшить нагрузку на общие ресурсы; оно не исправляет ни план, ни логику приложения.

В случае с режимами «Single» и «Abusers» CloudLinux указывает, что ограничения снимаются после того, как использование в течение минуты не превышало пороговое значение. Тем не менее, проверьте фактически настроенный механизм ограничения и динамику во времени на своей системе, а не делайте поспешных выводов о постоянном решении на основании кратковременного снижения нагрузки. Задача, запущенная повторно, может позже снова превысить пороговое значение.

Перенастроить ограничения или изменить архитектуру

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

Если этого временного интервала недостаточно, можно провести целенаправленную Исключение из тарифной сетки будет более целесообразным, чем общее повышение лимита для всех клиентов. Зафиксируйте причину, имя ответственного сотрудника и дату повторной проверки. Также укажите, было ли предыдущее значение установлено на уровне пакета или индивидуально: CloudLinux Manager поддерживает лимиты на уровне пакетов и индивидуальные отклонения.

После внесения изменений в течение репрезентативного периода проверьте, улучшилась ли производительность запланированных задач и не возникают ли ограничения или сбои в других местах. При этом соотносите пороговые значения регулятора с ограничениями LVE. Более высокий порог потенциально позволяет обрабатывать большую нагрузку в течение более длительного времени; он не является ни гарантированной пропускной способностью, ни обещанием определённых времён отклика.

Еще одним фактором, влияющим на ситуацию, является Устранение причины: Оптимизация запросов, использование подходящих индексов или кэширование могут сократить объем повторяющихся операций, а не просто ограничить их последствия. В то же время ограничения на количество подключений на стороне базы данных ограничивают одновременные обращения и не заменяют автоматическое управление ЦП и вводом-выводом, осуществляемое регулятором.

Если требования клиента на постоянной основе значительно отличаются от требований, предъявляемых к виртуальному хостингу, целесообразно использовать отдельный экземпляр базы данных или собственный сервер. Однако это переносит акцент с отдельных пороговых значений на планирование мощностей, техническое обслуживание и эксплуатацию. Кроме того, такое разделение не следует безоговорочно представлять как гарантию полной изоляции или фиксированного времени отклика.