У вас нет прав на изменение скрипта-нарушителя, поэтому исправление требует работы администратора базы данных, а не программирования. Ваша задача называется настройка базы данных MySQL.
(Полагаю, вы уже обращались к вашему поставщику за помощью, и они сказали нет.)
Ron top или htop во время выполнения скрипта. ЦП закреплен на 100%? ОЗУ исчерпано?
1) Просто живите с этим и запускайте скрипт обновления в то время суток, когда на вашем веб-сайте мало посетителей. Довольно простое, но не реальное решение.
2) В качестве эксперимента добавьте RAM к вашему экземпляру VPS. Это может позволить MySQL выполнять все операции в оперативной памяти, которые в настоящее время он помещает на жесткий диск во временных таблицах. Если это поможет, это может быть способом решения вашей проблемы с небольшим объемом работы и более высокой арендной платой за сервер.
3) Добавьте несколько индексов для ускорения запросов в вашем скрипте, чтобы каждый запрос выполнялся быстрее. Вопрос в том, какие показатели помогут? (Обычно случайное добавление индексов не очень помогает.)
Сначала выясните, какие запросы выполняются медленно. Дайте команду SHOW FULL PROCESSLIST repeatluy, пока ваш скрипт выполняется. В столбце «Информация» в этом результате отображаются все запущенные запросы. Скопируйте их в текстовый файл, чтобы сохранить их. (Или вы можете использовать медленный журнал запросов MySQL, о котором вы можете читать онлайн.)
Во-вторых, проанализируйте наихудшие запросы, чтобы увидеть, есть ли очевидный индекс для добавления. Говорить вам, как это сделать, обычно выходит за рамки ответа о переполнении стека. Вы можете задать другой вопрос о конкретном запросе. Прежде чем сделать, пожалуйста
перечитайте это замечание о том, как задавать хорошие вопросы по SQL , и обратите внимание на раздел о производительности запросов.
3) Возможно, ваш скрипт выбирает много строк или использует SELECT для суммирования многих строк из таблиц, которые также необходимо обновить, когда пользователи посещают ваш веб-сайт. В этом случае ваши посетители могут ждать окончания этих SELECT. Если бы вы могли изменить сценарий, вы могли бы поместить этот оператор прямо перед продолжительным SELECTS.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Это позволяет оператору SELECT после него выполнять «грязное чтение», при котором он может получить более раннюю версию обновленной строки. Смотрите здесь .
Или, если вы можете понять, как вставить один оператор в скрытый скрипт, поместите его сразу после открытия сеанса базы данных.
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Однако, без доступа к исходному коду, у вас есть только один способ узнать, в этом ли проблема. То есть получите доступ к серверу MySQL из привилегированной учетной записи прямо перед запуском скрипта и введите эти команды SQL.
SHOW VARIABLES LIKE 'tx_isolation';
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITED;
, затем посмотрите, улучшена ли проблема с производительностью. Установите его обратно после завершения работы вашего скрипта, возможно, так (в зависимости от значения tx_isolation, полученного выше)
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITED;
Предупреждение постоянное глобальное изменение уровня изоляции может испортить ваше приложение, если оно зависит от согласованности транзакций. Это всего лишь эксперимент.
4) Заставьте автора скрипта решить эту проблему.