Max performance DS4700


Главная Форумы Storage SAN, Disk & Tape Max performance DS4700

В этой теме 13 ответов, 5 участников, последнее обновление  uxTuaHgp 7 года/лет, 7 мес. назад.

  • Автор
    Сообщения
  • #8217

    Theodor
    Участник

    Добрый день!

    В настоящий момент [для меня] открыт вопрос — как лучше в DS4700
    создать LUN c целью достижения максимальной производительности.
    Приложение — Oracle DB. Два табличных пространства: data и index.
    Сейчас работает на одном LUN из 8 дисков RAID10.
    Если посмотреть lvmstat, то количество операций IO
    для data в три раза больше чем у index.
    Планируется перевести эти табличные пространства на 20 дисков RAID10.
    Нагрузка на Oracle DB — многопользовательский realtime.
    Пока что решил создать два LUN, каждый из 8 дисков RAID10.
    После перевода TS на эти LUN посмотреть,
    собрать статистику и [при необходимости] добавить
    в какой-то из LUN оставшиеся диски.

    Хотел бы услышать мнение уважаемого сообщества по этому поводу.

    Интересует так же время простоя DS4700 и Oracle DB
    в случае добавления дисков в LUN.

  • #8218

    uxTuaHgp
    Участник

    Ну так можно приближаться к цели мелкими итерациями.
    Можно ведь и таблицы растащить по разным таблспэйсам, а не просто данные отделить от индексов, раз уж такой «жесткий реалтайм».

    А с самого начала если, то у вас есть проблемы с дисками?
    Из чего это видно?
    wio зашкаливает?
    Пользователи жалуются?

    select * from v$db_cache_advice что показывает?
    Или у вас сплошные изменения в базу?
    REDO надеюсь уже вынесены на другой том?

  • #8220

    Theodor
    Участник

    Александр писал:

    Ну так можно приближаться к цели мелкими итерациями.

    Лучше потратить день! А потом быстро долететь! 🙂

    Можно ведь и таблицы растащить по разным таблспэйсам,
    а не просто данные отделить от индексов, раз уж такой «жесткий реалтайм».

    «средний реалтайм» — поэтому пока есть задумка растащить TS по разным LUN.

    А с самого начала если, то у вас есть проблемы с дисками?

    В часы пик нагрузка на LUN с TS data и index — 100 процентов.

    Из чего это видно?

    nmon показывает.

    wio зашкаливает?
    Пользователи жалуются?

    чтения с диска на 4-ре порядка больше чем записи.
    Пользователи жалуются в час-пик.

    select * from v$db_cache_advice что показывает?

    ID,NAME,BLOCK_SIZE,ADVICE_STATUS,SIZE_FOR_ESTIMATE,SIZE_FACTOR,
    BUFFERS_FOR_ESTIMATE,ESTD_PHYSICAL_READ_FACTOR,ESTD_PHYSICAL_READS,
    ESTD_PHYSICAL_READ_TIME,ESTD_PCT_OF_DB_TIME_FOR_READS,ESTD_CLUSTER_READS,
    ESTD_CLUSTER_READ_TIME
    3,DEFAULT,8192,ON,800,.1984,98950,8.1774,1145771715,5101877,322.7,0,0
    3,DEFAULT,8192,ON,1200,.2976,148425,5.5387,776054050,3417296,216.1,0,0
    3,DEFAULT,8192,ON,1600,.3968,197900,4.0415,566272679,2461447,155.7,0,0
    3,DEFAULT,8192,ON,2000,.496,247375,3.0342,425131401,1818351,115,0,0
    3,DEFAULT,8192,ON,2400,.5952,296850,2.3009,322392001,1350229,85.4,0,0
    3,DEFAULT,8192,ON,400,.0992,49475,14.717,2062070546,9276903,586.7,0,0
    3,DEFAULT,8192,ON,2800,.6944,346325,1.7965,251709957,1028173,65,0,0
    3,DEFAULT,8192,ON,3200,.7937,395800,1.4337,200883005,796585,50.4,0,0
    3,DEFAULT,8192,ON,3600,.8929,445275,1.1895,166665484,640677,40.5,0,0
    3,DEFAULT,8192,ON,4000,.9921,494750,1.0114,141714572,526990,33.3,0,0
    3,DEFAULT,8192,ON,4032,1,498708,1,140114657,519701,32.9,0,0
    3,DEFAULT,8192,ON,4400,1.0913,544225,.8763,122787678,440752,27.9,0,0
    3,DEFAULT,8192,ON,4800,1.1905,593700,.7805,109354843,379547,24,0,0
    3,DEFAULT,8192,ON,5200,1.2897,643175,.7011,98233747,328874,20.8,0,0
    3,DEFAULT,8192,ON,5600,1.3889,692650,.639,89535113,289240,18.3,0,0
    3,DEFAULT,8192,ON,6000,1.4881,742125,.5912,82839563,258732,16.4,0,0
    3,DEFAULT,8192,ON,6400,1.5873,791600,.5497,77025357,232240,14.7,0,0
    3,DEFAULT,8192,ON,6800,1.6865,841075,.5169,72420893,211261,13.4,0,0
    3,DEFAULT,8192,ON,7200,1.7857,890550,.4912,68824128,194872,12.3,0,0
    3,DEFAULT,8192,ON,7600,1.8849,940025,.4707,65957614,181811,11.5,0,0
    3,DEFAULT,8192,ON,8000,1.9841,989500,.439,61510571,161549,10.2,0,0

    Или у вас сплошные изменения в базу?

    Основное — чтение, потом добавление и потом только изменение.

    REDO надеюсь уже вынесены на другой том?

    Да, REDO, на отдельном LUN — 8 дисков RAID10.
    Переключение журнала в 1.5 Гб происходи 3 раза за сутки.
    Есть желание уменьшить REDO до 4-рех дисков RAID10.

  • #8223

    uxTuaHgp
    Участник

    1. Много чтений — это хорошо.
    Судя по адвайсу база будет тратить вдвое меньше времени на обработку запросов к диску при увеличении db_cache_size до 5ГБ и втрое меньше при увеличении до 7GB.

    2. А приложение чужое? Анализировали запросы? Мож индексов где не хватает?
    Я это к чему:
    тюнингом системы и настроек СУБД можно получить 10% прироста,
    а остальное получается путем отладки запросов и индексами
    Есть у вас ораклоид то? Ожидания анализировали?
    Каких чтений больше:
    db file sequential read
    db file sсattered read?

    Расширение и разделение — это хорошо, когда есть куда расти.

    Я бы жил на едином большом RAID10, доверив расправляться с конкуренцией за диски дисковому массиву, но есть и другая религия, которая предлагает все раскладывать по разным коробочкам.

    Вот допустим ты выделишь сейчас DATA на другой том, а индексы оставишь на старом.
    Запросто может так случиться, что том с индексами будет курить, а с данными перенапрягаться.
    Оптимальней было бы, ИМХО, если бы они лежали вместе, но на большем кол-ве шпинделей.

    Добивать массивы можно дисками и на 4800 это прозрачно все проходит.

  • #8224

    Сергей
    Участник

    Раньше был замечательный редбук — DS4000 Best Practices and Performance Tuning Guide, SG24-6363-01. Там даже пример отдельная глава с рекомендациями для оракла есть. на ибмовском сайте я прямо щас его не нашел, но сама книжка нагугливается в других местах.

  • #8225

    Theodor
    Участник

    Александр писал:

    1. Много чтений — это хорошо.
    Судя по адвайсу база будет тратить вдвое меньше времени на обработку запросов к диску при увеличении db_cache_size до 5ГБ и втрое меньше при увеличении до 7GB.

    Увеличение памяти сервера планируется вместе с модернизацией DS4700.

    2. А приложение чужое? Анализировали запросы? Мож индексов где не хватает?

    Приложение чужое. Запросы анализировать пытались первое время. Потом забросили.
    Тормоза вылезают в час-пик, а народ у нас терпеливый.

    Я это к чему:
    тюнингом системы и настроек СУБД можно получить 10% прироста,
    а остальное получается путем отладки запросов и индексами

    Согласен, Том Кайта читал.

    Есть у вас ораклоид то? Ожидания анализировали?

    Думаю, когда деньги на техническую модернизацию кончатся,
    так сразу назначат ораклоида 😉

    Каких чтений больше:
    db file sequential read
    db file sсattered read?

    А как посмотреть?

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

    +1
    Собственно, это для меня главный вопрос — какую религию выбрать!
    Так как выбрав — прийдется исполнять все атрибуты культа 😉
    Жечь огнем отступников …

    Вот допустим ты выделишь сейчас DATA на другой том, а индексы оставишь на старом.
    Запросто может так случиться, что том с индексами будет курить, а с данными перенапрягаться.
    Оптимальней было бы, ИМХО, если бы они лежали вместе, но на большем кол-ве шпинделей.

    Согласен.
    Но, все равно REDO и TEMP мы размещаем на других LUN!
    Истина где-то рядом …

  • #8226

    Theodor
    Участник

    smk писал:

    Раньше был замечательный редбук — DS4000 Best Practices and Performance Tuning Guide, SG24-6363-01. Там даже пример отдельная глава с рекомендациями для оракла есть. на ибмовском сайте я прямо щас его не нашел, но сама книжка нагугливается в других местах.

    Да, смотрел эту книгу. Уже 4 релиз вышел.
    К сожалению, основная рекомендация — REDO и TEMP на разных дисках.
    По поводу размещения TS в одном LUN или на разных, ничего не сказано.

  • #8233

    uxTuaHgp
    Участник

    Batutex писал(а):
    Думаю, когда деньги на техническую модернизацию кончатся,
    так сразу назначат ораклоида 😉

    А как посмотреть?
    [/quote]

    Эт да. То есть нет специального человека по ораклу?

    А посмотреть например так:
    select *
    from v$system_event se
    where se.event in ( ‘buffer busy waits’,
    ‘db file sequential read’,
    ‘db file scattered read’,
    ‘enqueue’,
    ‘free buffer waits’,
    ‘latch free’,
    ‘log file parallel write’,
    ‘log file sync’)
    order by 4 desc

  • #8236

    Theodor
    Участник

    Александр писал:

    Эт да. То есть нет специального человека по ораклу?

    Есть специальный человек. В других форумах он задает вопросы
    как оптимизировать запросы.
    А я в этом форуме задаю вопросы по поводу дисков.
    Мне нравится Ваша точка зрения по поводу одного LUN.
    А вот «ораклоиду» не нравится.
    Ему то как раз хочется сделать партишинал из самой большой таблицы.
    Так в супорте советуют и на форумах так пишут.
    Т.е. взять 20 дисков — сделать data — 4 диска, index — 4 диска,
    и 6 партишинал по 2 диска для одной таблицы!?
    Это потому что для одних — 20 дисков много, для других мало.
    Особенно учитывая, что в Гигабайтах это сумашедшие цифры.

    А посмотреть например так:
    select *

    Я оставил в запросе 5 колонок.
    Вот результат

    EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED WAIT_CLASS
    db file sequential read 114920778 0 51273045 User I/O
    db file scattered read 2425046 0 766145 User I/O
    log file parallel write 5915572 0 372843 System I/O
    log file sync 3428816 30 229222 Commit
    latch free 7146 0 38115 Other
    buffer busy waits 5251 5 741 Concurrency

  • #8240

    uxTuaHgp
    Участник

    Все неплохо.
    Индексы используются в полный рост.

    Это конечно не признак того что все безусловно отлично, но…

    Я бы все же на одном наборе дисков все держал, ну кроме редо, но это моя религия.

  • #8241

    roman
    Участник

    Если приложение серьезное, то в нем может быть «родная» система анализа производительности, которая показывает затраченные ресурсы на выполнение тех или иных операций. Если нет, то можно воспользоваться средствами oracle, вот только результат при этом получить будет намного сложнее. В первую очередь проанализируйте «тяжеловесные» запросы и их execution plan (фактический, а не estimated). Возможно есть неоптимальные планы. Тогда анализируйте причины выбора неоптимальных планов

  • #8242

    Theodor
    Участник

    roman писал:

    ….. Возможно есть неоптимальные планы. Тогда анализируйте причины выбора неоптимальных планов

    Давайте отвлечемся от СУБД.
    Давайте представим себе, что система оптимальна!
    Просто она достигла предела по железу.
    Сейчас все работает на 8 шпинделях.
    Скоро будет 20 шпинделей.
    Александр предложил свое распределение: один LUN.
    Я свое — 2 LUN плюс резерв.

    А Вы лично, как бы Вы распределили 20 шпинделей по LUN?

    Какая у вас «религия» 😉

  • #8247

    Serg
    Участник

    замерить за день, два в оракле physical reads и write, подсчитать iops.
    вычислить вообще даст ли raid 10 из 20 дисков эти iops или хватит меньше(http://www.yonahruss.com/architecture/raid-10-vs-raid-5-performance-cost-space-and-ha.html)
    может есть смысл сделать два рэйда и в них по луну для data и index, c разными сегмент сайз.

  • #8249

    uxTuaHgp
    Участник

    Кстати вот еще.
    Если шкалит из-за TPS большого с маленькими объемами, можно попытаться изменить DB_FILE_MULTIBLOCK_READ_COUNT, чтобы ридэхид увеличить, но это повлияет непременно на планы исполнения запросов в сторону преобладания сканов.

Для ответа в этой теме необходимо авторизоваться.