Использование ЦП Oracle установленной БД - PullRequest
3 голосов
/ 15 марта 2011

Я использую Oracle 11g, и у меня есть приложение, которое написано в Spring Framework. После того, как я настроил базу данных на Sun Fire 4170, установленной с Linux, загрузка ЦП машины составляет около 80-100%, однако, когда я перенесу ту же базу данных на сервер Sun M3000, установленный с ОС Unix (предположительно, более мощной машиной), производительность приложения снизится и загрузка процессора остается на уровне 90-100%. Я не могу понять, является ли это приложение, которое делает такое использование, или его дизайн базы данных. Добавляется, что база данных не является реляционной; вещи обрабатываются приложением.

Ответы [ 3 ]

7 голосов
/ 15 марта 2011

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

У Oracle нет настоящей серверной архитектуры (у других она есть).

Вместо того, чтобы выполнять классические серверные задачи, такие как многопоточность, кэширование страниц данных, параллельная обработка (разделение запроса по нескольким устройствам) и т. Д. Внутри себя, он использует o / s для всего этого.Это означает, что для каждого пользовательского процесса (соединение PL / SQL) существует один процесс unix;1000 пользователей означают 1000 процессов Unix, все конкурирующие за одни и те же ресурсы.

Вы можете заметить, что Oracle имеет

  • архитектура пула соединений (многопоточный сервер) с тех порверсия 7 (1992).
  • кэш для страниц данных (также называемый буферным кешем), поскольку навсегда
  • параллельный запрос (разделение запроса по многим процессам) начиная с версии 7.1 (1993)
  • разделение запросов по нескольким серверам начиная с OPS (версия 6) или по распределенным базам данных (версия 5)

Примечательно, что даже если все сказанное было правильным, а не неправильным, это нена самом деле не поможет вам в определении первопричины.

Особенно примечательно, поскольку он использует файлы файловой системы (не необработанные разделы), а «кеширование» происходит извне, оно в значительной степени зависит (и очень чувствительно) от имеющегося у вас кеша файловой системы.настроить.Точно так же Oracle требует огромного объема памяти для этих процессов.

Oracle, безусловно, может использовать необработанные разделы снова, начиная с прошлого тысячелетия, более того, если вы хотите кешировать в базе данных - используя буферный кешо котором PerformanceDBA забыл - и в обход кеша файловой системы эта функция доступна во всех текущих файловых системах.Oracle также предоставляет свой собственный комбинированный менеджер файловой системы / тома в ASM, который вы можете использовать, если хотите.

Oracle также достаточно хорошо оснащен (и если у вас есть доступ к dtrace, как и Solaris), и он может точно сказать вам, какие сеансы, процессы и т. Д. Используют ЦП, сколько времени приложение тратит в базе данных.by (вплоть до времени чтения отдельных блоков, если вам это нужно) и поэтому очень подвержен профилированию.Я бы порекомендовал вам ознакомиться с документом «Мысля о производительности», который доступен по адресу http://www.method -r.com / downloads / cat_view / 38-paper-and-article и написан одним из ведущих экспертов по производительности Oracle вмир.Если у вас есть доступ к пакету Oracle Diagnostics, то проверка, прежде всего, отчетов ADDM и, во-вторых, отчетов AWR будет выгодной.

5 голосов
/ 28 марта 2011

Попытка избежать пламенной войны здесь.

Вероятно, мне следовало бы более четко отделить часть своего ответа "как узнать" из моих ответов на комментарии об архитектуре сервера от PerformanceDBA. Я разделяю подозрения Стефани по поводу пружинных рамок, но без должного объема доказательств измерения нет смысла обвинять какой-либо конкретный атрибут окружающей среды, это было бы просто особым смещением. К счастью, инструментарий, встроенный в ядро ​​Oracle, позволяет вам отслеживать, а затем профилировать медленные сессии, чтобы точно определить, в чем заключается проблема. Поэтому я бы сделал следующее:

1) включить трассировку для репрезентативного сеанса (для этого вы можете использовать пакет dbms_monitor). 2) также собрать план выполнения для оператора (ов), связанных с подсказкой collect_plan_statistics. 3) профилировать файл трассировки по времени, используя соответствующий профиль (tkprof, orasrp, method-r profiler)

Изучите формулировки проблемы в зависимости от порядка времени ответа.

Если вы не можете выполнить вышеизложенное, то вы можете использовать ADDM и / или AWR, если лицензия, как я изначально предлагал, или statspack, если нет лицензии для пакета диагностики. Естественно, ADDM концентрируется на потребителях времени. Я полагаю, что если вы вынуждены идти по пути statspack, вы делаете то же самое.

3 голосов
/ 16 марта 2011

M3000, безусловно, является более мощной машиной, но больше подходит для настоящих серверов. X4170 с гиперпотоками больше подходит для файловых серверов.

Я не уверен в этом. У вас есть данные, подтверждающие это утверждение?

M3000 имеет один процессор SPARC64 VII с 4 ядрами ( технические характеристики ), в то время как X4170 имеет 1 или 2 процессора Intel 5500 "Nehalem-EP" каждый с 4 ядрами ( технические характеристики ). Я знаю, что ожидал бы гораздо большего даже от однопроцессорной системы Nehalem-EP, чем от M3000. Очевидно, что данные будут немного отличаться в зависимости от рабочей нагрузки, но я знаю, куда бы я положил свои деньги.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...