2015-12-08 2 views
0

На моем Linux-сервере я столкнулся с проблемой сегодня утром. Я понял, что после того, как я убил все фоновые задачи, которые составляли записи за 200 бит базы данных (размером 1 ГБ) всю ночь, мое использование процессора по-прежнему составляло 80%, только благодаря MySQL. Ни перезагрузка, ни перезапуск MySQL или nginx не работали.как избежать высокой загрузки процессора, когда нет активных запросов

«InnoDB сохранил данные в строках, которые он изменял, и запросы к этим изменениям, которые все еще откатываются, должны прозрачно отвечать на данные, которые все еще находятся в журнале отмены».

Я не слишком знаком с этой темой, но похоже, что это ответ на вопрос, почему существует высокая загрузка процессора, даже если нет запросов. Когда я SHOW PROCESSLIST, он показывает три соединения, и он говорит в «состоянии» -колонке «Копирование в таблицу tmp».

Я думаю, что сейчас мне просто нужно подождать, пока все эти процессы отката не закончатся, но почему они возникают в первую очередь и как я могу избежать этого снова?

+0

Не убивайте процессы mysql. Избегайте прерывания транзакций. – jcaron

ответ

1
  • Записи и обновления индексов «задерживаются». Это может привести к активности ввода-вывода и процессора даже после завершения всех запросов.

  • «копирование в таблицу tmp» в PROCESSLIST означает, что что-то is все еще работает. Исследуйте этот запрос. Его можно улучшить с помощью лучшего индекса или перезаписи. Убийство mysqld приведет к дорогостоящему откату сейчас и/или при перезапуске mysqld.

  • Убив процесс в середине транзакции, вы сразу же получите ROLLBACK. Измените приложение, чтобы перехватить «kill» и изящно ждать, пока все будет в хорошем положении для закрытия.

  • UPDATEing миллион строк в одном заявлении занимает время ожидания. Возможно, вы убили это (или что-то в этом роде)? Рассмотрите возможность разбивки на куски с использованием рядов 1000 рядов на PRIMARY KEY.

Смежные вопросы