Как и во всем остальном, это зависит. Вам нужно будет гораздо более конкретно указать свое приложение, какие службы вы определите, свои рабочие нагрузки, свои цели и т. д. На самом деле вам нужно протестировать его в своей среде, чтобы знать наверняка.
Отдельная служба может позволить вам отделить рабочую нагрузку одного приложения (того, которое пишет контрольный журнал) от рабочей нагрузки других приложений, имея разные наборы узлов в кластере, на которых работает каждая служба (при нормальной работе). Это может помочь гарантировать, что приложение с более высоким приоритетом (предположительно, не записывающее контрольный журнал) имеет установленное количество оборудования для обработки своей рабочей нагрузки, даже если поток с более низким приоритетом работает на полную мощность. Конечно, поскольку все узлы используют один и тот же диск, если узким местом является дисковый ввод-вывод, такое разделение рабочей нагрузки может не дать многого.
Разделение сервисов на разных наборах узлов также может повлиять на то, как часто конкретный сервис получает блоки из буферного кэша локального узла, а не запрашивает их с другого узла и ожидает их доставки по межсоединению. Вполне возможно, что приложение, которое постоянно записывает данные в таблицы журнала, может в конечном итоге потратить довольно много времени на ожидание получения небольшого количества горячих блоков (например, самого правого блока в индексе первичного ключа для таблицы журнала). пересылаются туда и обратно между разными узлами. Если все записи аудита записываются только на один узел (или на меньшее количество узлов), этот горячий блок всегда будет доступен в локальном буферном кеше. С другой стороны, если запись контрольного журнала включает в себя запрос к базе данных для получения информации об изменении, разделение рабочей нагрузки может означать, что блоки, которые были в локальном кэше (поскольку они были только что изменены), теперь передаются через межсоединение, вы может привести к снижению производительности.
Разделение служб, даже если они работают на одном наборе узлов, также может быть полезно, если вы планируете управлять ими по-разному. Например, вы можете настроить правила Oracle Resource Manager, чтобы отдавать приоритет сеансам, использующим одну службу, а не другой. Это может быть более точным способом распределения ресурсов для разных рабочих нагрузок, чем запуск служб на разных узлах. Но это также может добавить дополнительные накладные расходы.
person
Justin Cave
schedule
07.05.2014
