Высокая загрузка центрального процессора на AWS RDS - Postgres

Question

Попытка перенести мою производственную среду из среды Native Postgres (размещенная на AWS EC2) в RDS Postgres (9.4.4), но она потерпела неудачу. Использование CPU экземпляров RDS Postgres резко увеличилось по сравнению с экземплярами Native Postgres.

Мои данные среды здесь идет

1. Master: db.m3.2xlarge экземпляр
2. Slave1: db.m3.2xlarge экземпляр
3. Slave2: db.m3.2xlarge экземпляр
4. SLAVE3: db.m3.xlarge экземпляр
5. Slave4: db.m3.xlarge экземпляр

[Примечание: все подчиненные были на репликации уровня 1]

Я сконфигурировал Master для получения только запроса на запись, и этот экземпляр был в порядке. Счет записи составлял от 50 до 80 в секунду, а загрузка процессора составляла от 20 до 30%

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

Предусмотренные IOPS на этих коробках были 1000 И в среднем было от 5 до 7 запросов на чтение каждого подчиненного устройства, а загрузка процессора составляла 60%. Где, как и в «Родных Postgres», мы остаемся с 30% для этого трафика.

Не удалось определить, что происходит неправильно при настройке RDS, и поддержка AWS не может обеспечить хорошие выводы.

Неужели кто-то сталкивается с подобными вещами с помощью RDS Postgres?

Answer 1

Я бы предложил увеличить значение work_mem, так как он может быть слишком низким, и делать обычное исследование оптимизации запросов, чтобы узнать, используете ли вы запросы без соответствующих индексов.

Answer 2

Есть много факторов, которые максимизируют использование центрального процессора на PostgreSQL, как:

• Свободное место на диске
• Использование CPU
• использования I/O и т.д.

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

SELECT max(now() - xact_start) FROM pg_stat_activity 
          WHERE state IN ('idle in transaction', 'active'); 

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