Столкнулся тут с интересной задачкой. На машине 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 конечно) все равно порождают логические, так что при возрастании нагрузки нам все равно придется сделать и так и так тучу логических чтений, там почему бы не сделать только их, увеличив кэш, и не тратить ресурсы еще на физические чтения ?
Сообщения
А какой правильный ответ? :)
ОтветитьУдалитьПо мне так, расход CPU на ожидания
ОтветитьУдалитьsequential или scattered куда больше,
нежели на логические чтения.
Так тут главный вопрос в том на что процессор расходуется. Бэз этого сложно сказать что пришивать а что ампутировать надо :(
ОтветитьУдалитьОт тех, кто радует за зарезание памяти в угоду CPU, хотелось бы в цифрах послушать, сколько процессорного времени они таким образом выгадали.
ОтветитьУдалитьПо моему опыту увеличение SGA либо улучшает производительность (если ботлнек в постоянном чтении больших объектов с диска), либо никак на нее не влияет.
ОтветитьУдалитьЧисто теоретически ухудшение производительности при добавлении памяти в SGA возможно. Помимо очевидных вещей, вроде большего времени шатдауна/стартапа, может быть такое: количество латчей на буферный кэш не увеличивается, а сам буферный кэш растет, это дает увеличение длины buffer chain, что даст увеличение времени ее сканирования -> приложением будет дольше держаться латч на цепь. В условиях недостатка CPU это может сыграть в плохую сторону. Чисто в теории. Все конечно зависит от характера работы приложения и того, как оно нагружает БД.
В данном конкретном случае если узкое место -- CPU, я бы сконцентрировался на том, что его потребляет (неоптимальные запросы с большим количеством LIO? парсинг?) Идеальный вариант -- если есть возможность влиять на код, опять-таки опыт говорит, что половина проблем с производительностью лежит в приложении =)
Если у Вас много ОЗУ используйте его под кэш файловой системы. Кэш ufs например очень даже спасает.
ОтветитьУдалитьСудя по AWR db file sequentinal read = 6ms что не бог весть какой показатель. Диски не пробовали тюнить?
ОтветитьУдалитьAWR это хорошо, но никак не показательно в плане конечных результатов. Вспоминаем Method R и смотрим на то, сколько времени тратилось на выполнение запросов и сколько стало. Очень может быть, что потупив лишние микросекунды на LCBC, мы стали получать конечный ответ на МИЛЛИсекунды отминусованного PIO быстрее.
ОтветитьУдалить2 Ivan G.
ОтветитьУдалитьbigfile от chain-ов спасает.
а что это вдруг "Hard Parses" стало в 2.5 раза больше при неизменном "Parses" ? -)))
ОтветитьУдалитьДима что-то это похоже больше погоду показывает. DB file sequential read стало в 4 раза больше -- это от куда? Ты уверен что транзакции слева такие же что и справа?
ОтветитьУдалитьВидимо не разогрели библиотечный кэш после рестарта инстанса. МК.
ОтветитьУдалитьВо первых хочу всех поблагодарить, скажу по секрету что по качеству ответов тут далеко переплюнули advanced oracle support, который в данной истории.. был не advanced вовсе -)
ОтветитьУдалить>а что это вдруг "Hard Parses" стало в 2.5 раза
Ума не приложу, я этого не замечал -(
>DB file sequential read стало в 4 раза больше -- это от куда
слева AWR за 15 минут, справа за час, так получилось, это написано под картинкой -)
>Вспоминаем Method R и
Это сильно между прочим, спасибо ! Я вот ступил и не посмотрел, хотя и про метод R в курсе
>Если у Вас много ОЗУ используйте его под кэш файловой системы
Да, но тут были сырые устройства
>Так тут главный вопрос в том на что процессор расходуется.
А вот кстати, на что ? Я знаю про logical reads и parsing. Ну и латчи конечно же, но тут их кот наплакал. Или у тебя есть еще идеи ?
>о моему опыту увеличение SGA либо улучшает производительность либо никак на нее не влияет.
Лучше и не скажешь -)
Дима если слева AWR за 15 минут, а справа за час то почему DBTime не сильно отличается. Сдается мне это совершенно два разных по характеру нагрузки периода(если этот термин употребим в контексте данной системы). Все таки хотелось бы сравнивать два одинаковых по продолжительности и желательно одинаковых по характеру нагрузки AWR а то так делать совсем не правильные выводы.
ОтветитьУдалить>то почему DBTime не сильно отличается.
ОтветитьУдалитьDB Time идет per Second, вот и несильно отличается, потому что не зависит от периода. А DB CPU ниже в Top 5 вот как раз сильно, >4 раз, где фактор 4 объясняется разницей по времени, а прочее - разницей в нагрузке.
Или я не туда смотрю ?
>Все таки хотелось бы сравнивать два одинаковых по продолжительности
Это да, согласен
Судя по достаточно большому LIOps, проблема в неэффективном SQL. В данном случае добавление кэша дает общий прирост throughput системы, но на горизонте уже появились cache buffer chains =) А значит дальше особо масштабироваться некуда. Нужно, мне кажется, смотреть на самые жадные до CPU запросы, и если (если) есть возможность, оптимизировать их.
ОтветитьУдалить>>>то лично мне осталось непонятным, так вроде же физические чтения...
Мнение, что можно удачно разменять LIO на PIO, как мне кажется, идет от древней статьи Миллсапа "почему 99% буферкэшхит это некруто", в ней так часто повторяется тезис из заголовка, что волей не волей можно придумать себе такую арифметику:
a. 0.9999=1-PIO/LIO
b. увеличиваем P, уменьшаем L
c. теперь buffer_cache_hit=90% -- Profit!!!
Хотя это, безусловно, давольно извращенное понимание смысла статьи =)
интересным кажется то, что при "увеличении" кол-ва транзакций Redo size практически не изменился, а Block changes даже немного уменьшился - неясно чем занимались эти дополнительные транзакции?
ОтветитьУдалитьну в Cache buffer chains со средней длительностью 8 мс только подтверждают, что системы лимитируется дисками и/или неоптимильными запросами - что уже отмечали выше
>неясно чем занимались эти дополнительные транзакции?
ОтветитьУдалитьОтчеты ?
>Cache buffer chains со средней длительностью 8 мс только подтверждают, что системы лимитируется дисками
Вот это как связаны CBC и диски ?
Про неоптимальные запросы соглашусь
>Нужно, мне кажется, смотреть на самые жадные до CPU запросы, и если (если) есть возможность, оптимизировать их.
Занимаются этим конечно, но хотелось бы чуда -)
Если есть доступная память, ее надо отдавать Ораклу.
ОтветитьУдалить3К откатов в секунду это мегажесть.
> Во первых хочу всех поблагодарить, скажу по секрету что по качеству ответов тут далеко переплюнули advanced oracle support,
ОтветитьУдалить> который в данной истории.. был не advanced вовсе -)
ваще ниасилил, к чему вот это было сказано.
>>а что это вдруг "Hard Parses" стало в 2.5 раза
>Ума не приложу, я этого не замечал -(
напрасно - ибо сравниваются километры с килограммами.
>>DB file sequential read стало в 4 раза больше -- это от куда
>слева AWR за 15 минут, справа за час, так получилось, это написано под картинкой -)
учитывая предыдущий пункт - совершенно необязательно.
>>Если у Вас много ОЗУ используйте его под кэш файловой системы
>Да, но тут были сырые устройства
в качестве добавления: может увеличиться sys, ибо на обслуживание как памяти вообще (на paging/swapping), так и кэша в частности
тоже нужно время. если используются механизмы типа big pages/large pages - тем более. да и вообще - я давно уже не видал баз на
ufs, надо сказать.
>>Так тут главный вопрос в том на что процессор расходуется.
>А вот кстати, на что ? Я знаю про logical reads и parsing. Ну и латчи конечно же, но тут их кот наплакал. Или у тебя есть
>еще идеи ?
DB CPU :)
>>о моему опыту увеличение SGA либо улучшает производительность либо никак на нее не влияет.
>Лучше и не скажешь -)
это некорректное утверждение. так как на обслуживание памяти и структур сериализации требуются ресурсы - то увеличение количества
памяти может дать негативный эффект, что я так же видел у некоторых кастомеров.
общее ощущение: либо "бизнес" некорректно формулирует проблему (которая их беспокоит), либо "оптимизирующий производительность"
ее некорректно понимает.
ranger.
>Если есть доступная память, ее надо отдавать Ораклу.
ОтветитьУдалитьСогласен
>3К откатов в секунду это мегажесть.
Кажется приложение дисконнектиться из за своих проблем что и создает такое кол-во откатов.
>увеличение количества
памяти может дать негативный эффект что я так же видел у некоторых кастомеров.
Покажи AWR до и после
>> Если есть доступная память, ее
ОтветитьУдалить>> надо отдавать Ораклу.
> Согласен
тоже не совсем корректное заявление. во-первых, операционке тоже нужна память (под оракловые процессы - в том числе :), а во-вторых, как уже сообщалось, бОльшее количество памяти требует бОльшего хаускипинга. ну не бывает чудес, не бывает. равно как и rule of thumb не бывает.
>> 3К откатов в секунду это
>> мегажесть.
> Кажется приложение
> дисконнектиться из за своих
> проблем что и создает такое
> кол-во откатов.
что делаТЬ - дисконнектиТЬся. граммар-сами-знаете-кто негодуэ :)
по сути: ничего страшного нету, вобщем-то - это ж не роллбэки массовых апдейтов многотерабайтных таблиц :) для, скажем, системы наподобие ebay, где проводятся короткие транзакции, такое количество откатов не так уж и велико, к примеру, да и нагрузка на буферный кэш от такого количества роллбэков определяется во многом приложением.
>> увеличение количества
>> памяти может дать негативный
>> эффект что я так же видел у
>> некоторых кастомеров.
>
> Покажи AWR до и после
это из прошлой жизни (года три назад) - я на тех кастомеров уже не работаю и все грохнул.
ranger.
>>Cache buffer chains со средней длительностью 8 мс только подтверждают, что системы лимитируется дисками
ОтветитьУдалить>Вот это как связаны CBC и диски ?
В вашем случае длительность ожидания Cache buffer chains с большой вероятностью лимитируется скоростью записи DBWR
>большой вероятностью лимитируется скоростью записи DBWR
ОтветитьУдалитьТеория интересная, я в нее не верю -), но если скажешь как проверить - я посмотрю в AWR и напишу тут ответ.
>> Покажи AWR до и после
>я на тех кастомеров уже не работаю и все грохнул.
Почему то я так и думал -)
>>> Покажи AWR до и после
ОтветитьУдалить>> я на тех кастомеров уже не
>> работаю и все грохнул.
> Почему то я так и думал -)
а какой смысл а) хранить сотни гигов данных кастомеров, с которыми я больше не работаю и работать не буду, да еще и б) если там сменилась версия БД, а в некоторых местах - и платформа?
и не надо говорить про стоимость гигабайта - она ничтожна, но целесообразность еще ничтожнее.
ranger.
Можно разбавить высокоинтеллектуальный спор ламерско-виндусячим вопросом?
ОтветитьУдалитьВсегда думал, что Ораклу можно давать не более половины памяти.
Или это только для windows ?
Сколько тогда максимально можно % дать, например, на Linux?
>Всегда думал, что Ораклу можно давать не более половины памяти. Или это только для windows ?
ОтветитьУдалитьЕсли на машине работает только Oracle DB то ей нужно отдать как можно больше памяти. Что такое как можно больше ? Всю за исключением того что нужно ядру ОС и каким то специальным процессам если они есть. Требования к ОС для Windows я надеюсь можно найти у microsoft. Теперь что такое отдать Oracle -есть SGA и PGA. Вот тут Oracle installer часто и рекомендует сделать распределение 60%/40%, ну а вы можете сделать его лучше если знаете. Так как многие не знают и не хотят знать, то Oracle ввел параметр memory_target, который говорит сколько памяти будут использовать вместе SGA+PGA.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/memory003.htm
Но если у вас большая и нагруженная система, пользоваться memory_target...не очень рекомендуется из-за...особенностей..которые иногда называют багами -)
Пример - AIX kernel занимает порядка 700 Mb, но агент системной консоли жрет собака еще 400 (???!!!) Mb. Для того чтобы быть спокойным я считаю что моей OC нужно 1,5Gb - все остальное - Oracle. Выставил memory_target и пошел спать (но на самом деле так как на AIX AMM несовместим с large pages так я конечно же не делаю никогда)
Чуть не забыл про файловый кэш OC. Я всегда делаю так чтобы БД не работала через файловый кэш -)
> Но если у вас большая и нагруженная система, пользоваться memory_target...не очень рекомендуется из-за...особенностей..которые иногда называют багами -)
ОтветитьУдалитьбаги багами, но - один коммент: моя личная статистика гласит, что с вероятностью около 65% memory_target будет расчитан пользователем НЕПРАВИЛЬНО. лично я при рекомендации НЕ использовать данный механизм обычно исхожу из этого. к сожалению.
ranger.
так и в 10G автоматическое управление SGA (SGA_TARGET) очень глючное...не раз наблюдал на разных платформах (и AIX,и Linux) например такое: раздувание shared_pool, при этом буферный кэш становился размером в 10% SGA ;-)))
ОтветитьУдалитьНу и назад в cache_buffer оракл и не собирался возвращать память.
И вообще динамический резайзинг - это как обухом по голове приложению )
не пробовал memory_target, но подозреваю что он в силу такой-же глючности может также раздуть PGA в ущерб SGA
Если вы хотите чтобы система "сложилась", то можете уменьшить память :)). Тогда возможно чтопользовательский набор не влезет в кэш и диск "схлопнется" а а ним и Оракл.
ОтветитьУдалитьЕсли у вас процессор занят на 100%, то либо вам ничего делать не нужно вобще, либо оптимизировать приложение, Ну уж точно не увеличивать/уменьшать память или диск.
Единственно нужно понять количество прямых соединений, при его росте, памяти нужно точно добавить.
AWR вам говорит о том, что нужно больше шпинделей. У нас как раз такой-же AWR. Помогает SSD.
> увеличение buffer cache позволило выдержать 5100 транзакций в секунду вместо 4300
ОтветитьУдалитьЯ не уверен какой у вас тип транзакций, но в большинстве случаев их количество лимитировано со стороны бизнеса. Если это банковские транзацкии например, то сколько люди их сделали, столько и будет, а не сколько может обработать система.
Если производительности недостаточно, то конечно лучше грузить CPU, т.к. он лучше делится между потребителями. Плюс для CPU одно логическое чтение сильно дешевле физического.
По AWR: 80 hard parses в секунду это алес :) Что показывает раздел Instance Efficiency Percentages ?
Привет!!!
ОтветитьУдалитьЧесно говоря, читая все эти рассуждения (имеется ввиду весь блог) думал что все очень серьёзно. И человек реально эксплуатирует системы с высокой нагрузкой. А оказывается мой "каждые день" для человека - прорыв какой-то. У меня 3 БД для которых 5100 это каждый день ЧНН и как-то не вызывает восторга. Напрягаться начинаю когда количество транзакции переваливает 7000-8000 (в НГ было 11200 на каждой). Такое количество уже заставляет напрячь задницу и включить мозг для правки параметров, что бы облегчить работу. И всё это на "отстойных" T3-4. Значит тесты были правильные и Т3 действительно самые дешевые в пересчете на транс акцию. Я рад!!
Теперь буду читать блог как комикс :)...
Удачи!! И новых прорывов!!!
Сергей.