Oracle mechanics

24.03.2013

Использование SSD дисков для redo logs

Периодически в блогах специалистов появляются странные рекомендации (и даже удивительные результаты тестов) на тему использования SSD дисков для размещения redolog файлов. Аналогично-интересные рекомендации можно найти и в местами устаревших документах техподдержки, например How to Minimise Waits for ‘Log File Sync’ [ID 857576.1]:

  • Do not put redo logs on Solid State Disk (SSD)

Although generally, Solid State Disks write performance is good on average, they may endure write peaks which will highly increase waits on ‘log file sync’

Ниже приведены практические результаты миграции redo на SSD диски с целью уменьшения ожиданий log file sync на OLTP системе с невысокой нагрузкой, полученные совместно с моим коллегой Дмитрием Якубеней

Итак, начальная конфигурация: 11.2.0.3, 2-node RAC, redolog on asm-iscsi-sas (normal redundancy, 2 FailGroup, 2 JBOD x 14 disks)

Типичный AWR:

   Elapsed:               59.78 (mins)
   DB Time:              489.82 (mins)
...
Load Profile              Per Second    Per Transaction   Per Exec   Per Call
~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
      DB Time(s):                8.2                0.0       0.00       0.01
       DB CPU(s):                2.4                0.0       0.00       0.00
       Redo size:        1,521,848.7            8,111.8
   Logical reads:          601,575.9            3,206.5
   Block changes:           10,336.3               55.1
  Physical reads:           16,661.2               88.8
 Physical writes:              457.0                2.4
      User calls:            1,384.8                7.4
          Parses:               83.0                0.4
     Hard parses:                0.3                0.0
W/A MB processed:               37.4                0.2
          Logons:                2.7                0.0
        Executes:            3,585.7               19.1
       Rollbacks:              116.6                0.6
    Transactions:              187.6
...
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
-------------------------- ------------ ----- ---------- ------- -------- ------

log file sync                    43,605     0      2,963      68      0.1   10.1
...
log file parallel write         193,830     0      2,067      11      0.3   31.2
...
gcs log flush sync              258,054    15        758       3      0.4   11.4
...
                                                    % of Waits
                                 -----------------------------------------------
                           Total
Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
-------------------------- ----- ----- ----- ----- ----- ----- ----- ----- -----
...
log file parallel write    193.8    .0   1.2  44.1  25.2  15.1   7.7   6.7    .0 -- "длинный хвост"
...
log file sync              43.7K               1.8  13.9  23.2  20.5  40.2    .4

— хорошо заметно, что значительное влияние на продолжительность log file sync (LFS) оказывает небыстрый процесс записи log file parallel write со средним временем записи ~ 10 мс и длинным статистическим хвостом распределения, о влиянии которого на среднюю длительность LFS можно прочитать в заметке James Morle. Log File Sync and AWR – Not Good Bedfellows

После перемещения логов на отдельную normal redundancy дисковую ASM группу из 4-х INTEL SSD 320 серии (также подключённых по iscsi) при сравнимой нагрузке:

	   Elapsed:               60.04 (mins)
	   DB Time:              352.14 (mins)
...
  Load Profile              Per Second    Per Transaction   Per Exec   Per Call
  ~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
        DB Time(s):                5.9                0.0       0.00       0.00
         DB CPU(s):                3.2                0.0       0.00       0.00
         Redo size:        1,187,371.7            5,288.3
     Logical reads:          605,180.7            2,695.4
     Block changes:            7,806.2               34.8
    Physical reads:           12,660.2               56.4
   Physical writes:              564.5                2.5
        User calls:            1,707.2                7.6
            Parses:              113.6                0.5
       Hard parses:                0.3                0.0
  W/A MB processed:               48.9                0.2
            Logons:                3.7                0.0
          Executes:            4,620.4               20.6
         Rollbacks:              140.9                0.6
      Transactions:              224.5
...
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
-------------------------- ------------ ----- ---------- ------- -------- ------
...
log file sync                    55,095     0        574      10      0.1    2.7
...
log file parallel write         302,177     0        622       2      0.4   21.5
...
gcs log flush sync               92,743     9        165       2      0.1    5.7
...
                                                    % of Waits
                                 -----------------------------------------------
                           Total
Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
-------------------------- ----- ----- ----- ----- ----- ----- ----- ----- -----
...
log file parallel write    302.2  81.0   8.6   3.0   2.6   2.3   1.4   1.1    .0
...
log file sync              55.1K  65.1  13.1   4.3   3.5   3.5   2.9   7.5    .0

— можно заметить заметить кратное уменьшение времени ожиданий, связанных с записью логов, что подтверждается наблюдениями за скоростью отклика  OLTP приложений

Если в вышеописанной системе кроме собственно скорости дисковой записи на ожидания записи логов значительно влияют сетевые задержки, то на системе наших коллег с бОльшим количеством SSD дисков, подключённых также через ASM напрямую к хосту и используемых под хранение всех файлов бд,  часовой AWR также показывает:

Event                       Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn % DB time/% bg time
...
log file sync	        4,741,351           0              12,006             3       0.31     12.88
...
log file parallel write	3,367,407           0               1,047             0       0.22               10.74

— отличные времена ожиданий записи логов при высокой скорости генерации redo

При конфигурации SSD для интенсивной записи имеет смысл обратить внимание на важность выделяемого объёма зарезервированного места (%Overprovisioning), как особенность технологии SSD — см., например, тесты Infortend: Enhancing the Write Performance of Intel SSDs through Over-Provisioning:

Over-provisioning is a technique to improve the IOPS of an SSD by increasing the size of its reserved space

Полезно мнение известного Oracle/RAC/Linux специалиста Steve Shaw. Improve Database Performance: Redo and Transaction Logs on Solid State Disks (SSDs)

P.S. Если я правильно понимаю, В ORACLE DATABASE APPLIANCE для размещения redolog уже используются SSD диски. Совсем не удивлюсь, если следующая версия Exadata Database Machine будет ими полностью укомплектована

14 комментариев »

  1. А что на счет надежности? Когда то давно про SSD писали, что flash память имеет фиксированное число изменений состояния и отваливается за 1-2 года интенсивного использования. Помню рекомендации были, использовать SSD под индексные ТБС, либо как 2я failgroup c настроенным предпочтительным чтением…

    комментарий от jimroll — 25.03.2013 @ 09:59 | Ответить

    • Отказоустойчивость обеспечена ASM redundancy, надёжность в смысле долговечности — вечных дисков не бывает, производители активно работают над улучшениями, и т.д.)
      Основная идея описанных примеров — применение технологии SSD для решения конкретных проблем производительности бд

      комментарий от Igor Usoltsev — 25.03.2013 @ 14:14 | Ответить

      • Понятно. Мы пока решили не экспериментировать, тем более что $25K за 1 SSD как то не радует. 5 штук получается $100К.
        Проект запустим, нагрузка пойдет, там посмотрим

        комментарий от jimroll — 25.03.2013 @ 14:43 | Ответить

        • «$25K за 1 SSD» — не совсем понятно
          в описанном первом случае использовались 4 х INTEL SSD 320 серии ~ $1.5K за все, + с учётом 2-х standby и половинного резерва — не более $7.5K

          комментарий от Igor Usoltsev — 25.03.2013 @ 15:04 | Ответить

          • У нас массив Hi-End HP P9500, БД Биллинга. Там лист прайс увы иной

            комментарий от jimroll — 25.03.2013 @ 15:24 | Ответить

      • теория..:)
        http://www.pythian.com/blog/de-confusing-ssd-for-oracle-databases/
        http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/
        http://guyharrison.squarespace.com/blog/tag/ssd
        практика..:)
        когда положил ночью redo(1Гб) на 200GB 2.5-inch SSD (E-MLC) для ibm v7000 были в шоке на след день:)вернул назад на sas и вернул себе менее ~ 10 мс(в зависимости от нагрузки)(aix+ibm)

        комментарий от timscn — 25.03.2013 @ 15:49 | Ответить

        • разумеется easy tier был выключен:)

          комментарий от timscn — 25.03.2013 @ 16:00 | Ответить

        • именно эти загадочные «теории» я и имел в виду

          пока из вашего краткого описания можно только сделать вывод, что технологии IBM, несмотря на космическую стоимость, сильно проигрывают бесплатному линуксу и SSD дискам Intel по $400 за штуку ;)

          интересны детали, например, нагрузка в IOPS на диск, конфигурировался ли Overprovisioning, как прокомментировали ситуацию представители вендора?

          комментарий от Igor Usoltsev — 25.03.2013 @ 16:47 | Ответить

  2. А какой в том и другом случае использовался планировщик?

    комментарий от Max — 25.03.2013 @ 13:23 | Ответить

    • в первом случае — deadline, во втором — noop так же deadline
      специально влияния I/O Scheduler не изучали, насколько я понимаю, для SSD оно незначительное

      комментарий от Igor Usoltsev — 25.03.2013 @ 14:17 | Ответить

  3. Мы как раз таки это исследовали. И пришли к тому что deadline для SSD, уменьшил нам события ожидания log file sync.

    комментарий от mczimm — 25.03.2013 @ 14:21 | Ответить

    • Спасибо, Максим, за уточнение

      комментарий от Igor Usoltsev — 25.03.2013 @ 14:42 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: