Назад | Перейти на главную страницу

мониторинг / устранение неисправностей aws rds при высоком использовании процессора

У меня запущен экземпляр RDS, и он использует в среднем 20-30% загрузки процессора. Прошлой ночью он подскочил до 80% за несколько минут, и я пытаюсь понять, почему. Журналы ошибок ничего не показывают, и у меня нет настроек для любого другого журнала для групп параметров (только по умолчанию). Я пробовал бежать

show full processlist;

но я не знаю, запустился ли какой-то конкретный процесс во время всплеска.

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

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

Испытываете ли вы всплеск DBConnections во время инцидента? Если да, то имеет ли смысл, если такой всплеск соединений происходит из-за неожиданного трафика (предположим, что ваша БД является источником данных открытого веб-приложения)? Если это так, скорее всего, ваша проблема связана с безопасностью на уровне внешнего интерфейса, а не в самой БД.

Увеличивается ли количество операций чтения или записи во время инцидента? Если это так, это может означать, что ресурсов памяти недостаточно для обработки нагрузки вашего приложения в определенных условиях. Кроме того, это может означать, что у вас отсутствуют индексы или неэффективные запросы, которые излишне загружают ваш экземпляр. Здесь может помочь команда MySQL EXPLAIN.

Я бы порекомендовал вам убедиться, что performance_schema включена, и развернуть схему sys, чтобы включить инструменты производительности MySQL Workbench, это очень помогает обнаруживать узкие места в схеме и запросах.

Кроме того, журнал аудита, доступный через RDS OptionGroups, и его ретрансляция в журналы Cloudwatch (с надлежащим периодом хранения) может очень помочь в будущем для исследования того, что, черт возьми, ваши приложения (или пользователи) делают с базой данных. «Показать список процессов» полезен только при использовании в момент инцидента, поскольку это инструмент времени выполнения.