Oracle Data Guard между RAC и standalone. Часть четвертая: заметки к сайзингу

По ходу написания трех частей саги тестировал немного и производительность, причем в весьма забавной конфигурации: все машины стенда (кроме генератора нагрузки) находились на одном физическом хосте. И в тестах у меня все затыкалось на процессоре. С Disk IO, ОЗУ и сетью проблем не было — загрузка была от 20 до 80%. И включая, например, второй узел RAC прироста производительности я получить не мог в принципе, только просадку, равную накладным расходам на функционирование RAC. Считая накладные расходы на сеть пренебрежимо малыми, грубо можно попытаться определить накладные расходы (только CPU) на использование различных технологий Oracle.

Исходя из проведенного тестирования, накладные расходы CPU на использование

  • Flashback составляют ~0, т.е. ими можно принебречь при сайзинге;
  • RAC — от 6 до 12%, т.е. если взять 2 хоста производительностью 100 у.е., то итоговая производительность RAC, собранного из них будет от (2 x 100 x 0,88)= 176 до (2 x 100 x 0,94) = 188 . В суровой реальности, как говорят, из за сетевых задержек (а м.б. и из-за еще чего нибудь, типа блокировок) близкие к реальности результаты дает коэффициент 0,8;
  • Data Guard — от 15 до 20%. Предположив,что эти расходы делятся между primary и standby поровну, можно считать что для включения DG на primary без просадки производительности на нем должен быть запас по мощности CPU не менее 10%, а standby должен иметь мощность (опять же по CPU) не менее 10% от primary;

Оставьте комментарий