best practices

Время от времени  мне пересылают запросы от заказчиков,  которые жалуются на производительность  Oracle на AIX.  При этом, жалобы конечно не абстрактные, а вполне конкретные, например  - не работает ввод-вывод как надо и все тут, мол чините.  Так же чисто статистически, обнаружилось, что если выполнить набор некоторых магических пассов, которые в простонародье называются best practices, то большинство проблем рассасываются сами собой (прямо как у кашпировского) , а те что остаются - являются весьма достойными, чтобы ими заниматься.

Конкретные примеры - мы обнаружили,  что в установка AXI по умолчанию queue_depth (длина очереди на диски) для Oracle слишком маленькая и почти всегда ее нужно увеличивать для OLTP приложений. Или, другой пример,  заказчик не использует large pages и жалуется на производительность.   Ну и чтобы как раз и навсегда записать ответ, публикую ссылки ниже:


И вдогонку, те кто только начинают свои проекты, часто интересуются как сделать сайзинг
(http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1887)

А может быть у Вас OEBS и интересно как же он живет на IBM ? тогда читайте - IBM Supported Platforms for Oracle Applications (all acquisitions) (http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS2815)

Так как заказчики массово переходят сейчас со старых Sun и HP на IBM, то есть еще проблема - пытаются принести все свои наработки по настройкам  на новую платформу.  При этом аргументация железная - "ведь раньше работало, а вы нам песни поете что новая платформа лучше старой, так и здесь должно работать также"  -).  Могу сказать - на практике гораздо быстрее и лучше пройтись по ссылкам выше и сделать как написано там. Это тем кому "ехать", с теми кому "шашечки" мы долго, вдумчиво, параметр за параметром на протяжении (иногда) месяцев все равно приходим к тому же самому. 


Читать дальше...

Отправил Dmitry Volkov дата: 8.2.12 27 комментариев

Метки: ,

is big buffer cache is so good ?

Столкнулся тут с интересной задачкой. На машине 512 Gb памяти, но под Oracle DB выделили только около 200 Gb. Больше никаких задачек на сервере нет. Казалось бы очевидно, что нужно использовать больше памяти, Advisors в AWR рекомендуют куда и сколько добавить, но есть проблемка - CPU загружены временами под 90%.  Но пользователей в скором времени должно стать больше, такое  требование бизнеса.  Внимание, опрос  - а стоит ли, или даже так, возможно использовать больше памяти в этой ситуации ?  Противники увеличения памяти под Oracle рассуждают так -   если увеличить память, то логические чтения, которых станет больше  "прикончат" систему, а если база данных будет больше читать с диска, она будет расходовать CPU более бережливо (потому что при чтении с диска не тратится CPU). 

PS. Добавить CPU в данный момент не представляется возможным

Update 1. 

Подбирая факты исключительно в свою пользу,  могу сказать, что увеличение buffer cache позволило выдержать 5100 транзакций в секунду вместо 4300 (или +18%), при этом, что ожидаемо, полезли cache buffer chains:
Для очень въедливых, слева AWR за 15 минут, справа за 1 час, сорри, так получилось.

Что лично мне осталось непонятным, так вроде же физические чтения (кроме direct reads конечно) все равно порождают логические, так что при возрастании нагрузки нам все равно придется сделать и так и так тучу логических чтений, там почему бы не сделать только их, увеличив кэш, и не тратить ресурсы еще на физические чтения ? 


Читать дальше...

Отправил Dmitry Volkov дата: 6.2.12 32 комментариев

Метки:

Server design

Коллега показал прекрасную иллюстрацию к современному положению вещей с многоядерными и многонитевыми (thread) процессорами. Попытка сделать прорыв (надавить) по одному из направлений немедленно приводит к тому, что остальные поршни в картинке начинают "отъезжать". Чтобы как то отвлечь вас от этого несложного факта оперируют термином  performance.

На самом деле когда вы слышите это слово, вы должны всегда уточнить, что имеется в виду

- single thread performance, те ваша однопоточная задача очень быстро посчитает свой pl/sql цикл  (на картинке thread speed)
- total throwout, те много сразу ваших задачек смогу считать свои циклы, но не так быстро как в предыдущем случае (thread count)
- эффективность использования кэша потоком (effective cache/thread)

И исходя из вашего приложения решить,  что является приоритетным.  Но мы же знаем, что все хорошие идеи рубятся на стадии бюджета. Так что нужно считать цену решения. И тут, слава богу все просто - Oracle стоит больше, чем любое железо для него -)

SPARC T4-4 - $194K, SUN Storage 2540 - $262K (данные из TPC-H), Oracle Database  + partitioning на 16 процессоров = (47,500 +11,500)x16 = $944K (Oracle price list)

Сервер можете взять любой -).  Соотношение не сильно изменить.  Так что на первое место сейчас выходит виртуализация, возможность выполнять много задачек с разными приоритетами по процессорному времени в рамках одного физического сервера. Надежность этого сервера, решения по построению  HA и DR. 

Мой совет - постарайтесь рассматривать не один сервер- одна задача, а смотреть немного шире. В конечном этоге это дает большую экономию. Все это требует  разумного и понимающего вас бизнеса -)

Картинка из документа Fit for Purpose: Workload Based Platform Selection (С) IBM


Update 1. Подтверждение, что картинка качественно правильно описывает современное положение дел можно найти в документе Oracle's SPARC T4-1, SPARC T4-2, SPARC T4-4, and SPARC T4-1B Server Architecture. Как вы помните, в T4 по сравнению с T3 существенно (1.65 -> 2.8/3) увеличили частоту и уменьшили кол-во ядре (с 16 до 8 на процессор), что привело, цитаты:

- (T4) Maintain the computational capabilities to meet the growing demand from Web applications by providing equivalent throughput of the SPARC T3 processor.
- (T4) Provide networking performance equivalent to the SPARC T3 CPU to serve network-intensive workloads.

PS Легко увидеть что в TPC-H цена на Oracle не $944K, а  $380K. Там просто рассчитали врменные лицензии на 3 года. Так тоже можно делать в TPC-H. Но в жизни чаще считают по другому.


Читать дальше...

Отправил Dmitry Volkov дата: 4.2.12 4 комментариев

Подписаться на: Сообщения (Atom)