я использую aws rds Postgres 9.4. Я столкнулся с проблемой очень высокой загрузки ЦП. Тип инстанса - t2.xlarge (оперативная память 16 ГБ).
Все время я вижу очень низкое использование оперативной памяти, т.е. 14 ГБ свободно, 15 ГБ свободно.
Но для сравнения загрузка процессора составляет 100% при 100 активных соединениях.
Я проверил все свои запросы в журналах медленных запросов pg_stat_activity. Ничего не найдено. Хотя это касается 100% загрузки ЦП, и мое приложение перестает работать даже при очень менее активных соединениях.
Какое решение снизить высокую загрузку ЦП при таком большом объеме оперативной памяти?
Когда он достигает 100% ЦП, мои операции ввода-вывода в секунду при записи составили 400 операций ввода-вывода в секунду, а операций ввода-вывода в секунду при чтении - 8,5 операций в секунду.
Мне нужно обрабатывать 300 одновременных подключений несколько раз, когда на моем сайте очень высокий трафик. Какой должна быть неактивная конфигурация экземпляра rds?
Однажды у меня возникла проблема с экземпляром AWS RDS, на котором загрузка ЦП была 100% даже после изменения его на m3.xlarge с t2.medium. Проблема, как выяснилось, заключалась в том, что некоторые запросы зависали и продолжали работать в течение нескольких часов, заставляя процессор загружаться. Тот же запрос при запуске через консоль дает результат через 4-5 секунд, что тоже слишком много. Хотя попытка того же запроса с консоли выполняется успешно, но иногда он зависает и продолжает работать часами.
Ниже приведены методы отладки, которые я пытался найти для устранения основной причины проблемы.
Системные факторы часов:
Полный набор показателей производительности системы, в основном для PostgreSQL:
Дисковое пространство : У вас должно быть 10% дискового пространства, доступного для раздела данных Postgres, поскольку дисковое пространство может колебаться во время очистки Postgres при высокой загрузке записи.
Использование процессора : Высокая загрузка ЦП снижает производительность системы, так как также показывает плохо оптимизированные запросы, которые занимают огромное количество процессорного времени. Связанный CPU - лучшая ситуация для Postgres.
Использование ввода / вывода : Если ваш Postgres работает медленно, сначала измерьте процент ожидания ввода-вывода ЦП, который указывает количество времени, в течение которого машина ожидает диска
**Watch Postgres Factors**
1. Общее количество подключений
max_connections определяет максимальное количество одновременных транзакций с сервером базы данных и предоставляет список клиентов, которые пропускают соединения с базой данных.
Команда:
ВЫБРАТЬ Счетчик (*) ИЗ pg_stat_activity;
2. Количество подключений по штатам
Четыре возможных состояния соединений: (a) активное - соединение, в настоящее время выполняющее запросы транзакции.
(b) idle - Соединение не выполняет транзакцию. (c) бездействие в транзакции - соединение в длительной транзакции, т.е. запрос не выполняется. (d) бездействие в транзакции (прервано) - соединение в ситуации, когда транзакция не была откатана из-за ошибки.
Команда:
Состояние SELECT, count (*) FROM pg_stat_activity GROUP BY состояние;
3. Подключения ждут блокировки
Заблокированные соединения, ожидающие блокировки, указывают на медленное выполнение транзакции с монопольной блокировкой.
Команда:
ВЫБРАТЬ счетчик (отдельный pid) FROM pg_locks, ГДЕ предоставлено = false
4. Максимальный срок транзакции
Транзакции должны быть как можно короче, так как они будут выполнены менее чем за минуту. Длительные транзакции не позволяют Postgres очищать старые данные, он может завершить работу базы данных из-за переноса идентификатора транзакции (xid). Если это выводит более одного часа, то это вызывает беспокойство, поскольку запрос выполняется с тех пор, как это время удерживает ресурсы занятыми. Измените параметр максимального возраста (в коде приложения) соединения на минимально возможные значения, например 2-3 секунды, в соответствии со средним временем ответа на ваш запрос к базе данных.
Команда:
ВЫБРАТЬ max (now () -xact_start) FROM pg_stat_activity WHERE state IN ('idle in transaction', 'active');
5. интервал контрольной точки
Частые контрольные точки снижают производительность, Postgres будет отображать эти контрольные точки в своем журнале. Также вы можете проверить частоту в таблице pg_stat_bgwriter.
6. Время выполнения запроса.
Вы должны измерять это на уровне приложения. Или, задавая и периодически анализируя запросы журнала, log_min_duration_statement = 0 или отслеживая модуль pg_stat_statements.