Statspack: хто чекає подій log file sync і LGWR wait for redo copy?, Інші СУБД, Бази даних, статті

Ця стаття присвячена аналізу деяких результатів спільної оцінки продуктивності системи. За мотивами цікавою публікації на сайті Тома Кайта від 16 березня 2004 року. Сподіваюся, ви ще пам’ятаєте, і регулярно відвідуєте його сайт …

Statspack: хто чекає подій log file sync і LGWR wait for redo copy?


Прошу вибачення за точ, що не можу коротко сформулювати питання.


Ось витяг зі звіту statspack:

            Snap Id     Snap Time      Sessions Curs/Sess Comment
——- —————— ——– ——— ——————-
Begin Snap: 207 10-Mar-04 08:39:47 36 581,793.7
End Snap: 208 10-Mar-04 08:50:28 36 583,582.8
Elapsed: 10.68 (mins)

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
——————————————– ———— ———– ——–
CPU time 3,747 66.52
enqueue 2,129 1,350 23.97
db file sequential read 37,842 286 5.07
log file sync 9,743 65 1.15
LGWR wait for redo copy 58,067 61 1.08

Я звернув увагу на CPU time – 3,747 секунди в системі з 4 HT-процесорами (в диспетчері завдань Windows відображається 8 процесорів). Це означає, що на одну секунду реального часу доводиться 5.85 секунди процесорного часу, витраченого багатьма одночасно працюють сеансами, завантажувати дані у базу.


Тепер, виникає питання про події очікування log file sync і LGWR wait for redo copy– Я бачу час очікування 65 секунд, і, наскільки я розумію, це час, який провели в очікуванні фонові процеси. Якщо фонові процеси чекали так довго, мені цікаво, наскільки це вплинуло на користувальницькі сеанси (скільки їм довелося чекати в цей же час) … (Або, можливо, саме цей час сеанси кінцевого користувача і чекали, оскільки треба було копіювати журнали повторного виконання). Іншими словами, це час очікування самих фонових процесів або час, протягом якого користувача сеанси очікували завершення фонових процесів?


Ми тільки що перевели кеш-буфер диска в режим тільки записи, як радиться в книзі Джонатана Льюїса “Practical Oracle 8i“(Раніше він використовувався порівну на читання і запис). При схожою завантаженні системи ми побачили зменшення цих статистичних показників (як за кількістю очікувань, так і за часом):

log file sync                                       5,464          21      .44
LGWR wait for redo copy 22,215 18 .38

Можу поставити запитання і по-іншому – якщо процес LGWR прочекав 3 секунди, поки копіюються дані повторного виконання, але жоден користувальницький сеанс через це не чекав (якщо таке взагалі можливо), відіб’ється Чи це на очікуванні подій?


Відповідь Тома Кайта


Розглянемо процесорний час. При наявності тривалих викликів, воно легко може бути як більше, так і менше, Ніж вказано у звіті.

 x —————– x 50 секунд  x ———————- x 50 секунд x ————————————————- —- x 500 секунд x —————- x 30 секунд x —————————————- x 60 секунд
^ ^
/ / / —— Знімок за цей період —- / вікно в 1 хвилину

Нехай ви зробили знімок за період в 1 хвилину. Нехай при цьому відбувалися представлені вище “виконання”. statspack повідомить про використані 80 секундах процесорного часу (50 +30), оскільки статистика по процесорного часу враховується при завершенні виклику. Тому, другий і четвертий рядки внесли свій внесок в cpu time, А решта – ні (вони не завершилися в аналізований період). Враховуйте це.


log file sync – Це клієнтське очікування події. Саме цієї події ваші клієнти чекають, коли говорять “commit”. Це очікування, поки процес LGWR фактично запише їхні дані повторного виконання на диск і фіксація транзакції буде завершена. Можна “налаштувати” цей процес, прискоривши роботу процесу lgwr (Відмовившись від використання raid 5, наприклад) і фіксуючи транзакції рідше, генеруючи менше даних повторного виконання (множинні зміни генерують менше даних повторного виконання, ніж порядковий)


А ось інше очікування – фонове. Процес LGWR чекає, поки пріоритетні процеси закінчать поточне копіювання, що зачіпає дані, які LGWR повинен обробити.


ОДНАК, з урахуванням усього вищесказаного, настройка будь-якого з цих показників, в будь-якому випадку, ніяк істотно не вплине на продуктивність вашої системи! Схоже, основне ваше очікування – “enqueue“, І пов’язане воно з особливостями застосування. Це великовагові блокування, пов’язані з алгоритмом роботи програми. Ви достігшнете кращих результатів, вивчаючи в цей момент додаток, А не “систему” в цілому.


Встановіть для програми подія трасування 10046 рівня 12 і подивіться, чого саме воно чекає. Вся справа – в налаштуванні програми.


Все одно не розумію LGWR wait for redo copy


Спасибі за корисний відповідь! Не могли б ви уточнити, навіщо потрібні ці очікування LGWR – які “пріоритетні процеси закінчать поточне копіювання” і чого саме?


Прояснюють щодо CPU. Наш знімок – за 10 хвилин, тоді як більшість транзакцій (а, значить, і викликів операторів) завершується не більше? ніж за хвилину => можливість недорахуватися або перерахувати становить +/-10%.


Прояснюють щодо Equeues (я очікував такого коментаря, але не хотів викидати цей рядок зі звіту statspack). Черги, проте, хоч і виглядають підозріло – не викликають проблем у нашій системі, просто тому, що так і було задумано. Наша система спроектована так, що ряд фонових завдань виконує завершальну обробку даних після їх завантаження. І, іноді? фонові процеси чекають завершення пріоритетних процесів (за допомогою SELECT … FOR UPDATE), щоб гарантувати узгодженість. Ідея в тому, що хоча прірітетние завдання із завантаження можуть вимагати до однієї хвилини на транзакцію, ці фонові завдання спрацьовують за пару секунд. Велику частину часу наші процеси черги завдань (6 з них) простоюють, а коли прокидаються (кожну хвилину) для виконання нещодавно переданих завдань по завершальній обробці, можуть виявити, що їм треба почекати завершення інших завантажень. Шкоди від цього немає – навіть якщо деякі процеси черги завдань через це “зависають”, інші процеси вільні і можуть виконувати інші завдання, а в найгіршому випадку завершальна обробка відкладається не більше? ніж на хвилину. Так що, хоча і можна було позбутися від “Enqueues”, змінивши час виконання завдань з завершальній обробці, це, ймовірно, не підвищить загальну продуктивність системи.


Нарешті, ви маєте рацію в тому, що настройка процесу LGWR і log file sync в нашому випадку не сильно підвищить загальну продуктивність системи (очевидно, що мова йде приблизно про 2% загального часу). На самому ділі? мета була не стільки в налаштуванні, скільки у вивченні та доведенні затвердження Джонатана (установка відсотка використання кеша для читання і запису на диску зайняла одну хвилину).


Відповідь Тома Кайта


Копіювання даних повторного виконання – пріоритетні процеси це роблять (наприклад, lgwr намагається скинути буфер журналу за однією з причин, яка таке скидання викликає – 3 секунди, заповнення 1/3, заповнення 1 Мбайта, commit).


Але, серйозно, – ці очікування нічого не значать, І я б порадив їх ігнорувати ПОКИ вони не з’являться в результатах трасування програми!


Ваші коментарі про черги (enqueues) – прекрасне пояснення, чому настройка за допомогою statspack– “Не найкращий спосіб” і чому треба вивчати програму. Будь-хто, хто подивиться на такий звіт statspack, Зверне увагу на enqueues – але ви-то знаєте, що у вашому випадку вони пов’язані з простоєм (“idle-ing waits”) 🙂


Серйозно, які пріоритетні процеси і що копіюють?


Я зрозумів, і про настройку більше не питаю. Поділіться, будь ласка, як завжди, відсутніми нам знаннями. Наведіть приклад “пріорітеного” процесу (це користувальницький сеанс або щось ще) і того, що саме він копіює (дані, буфери журналу або щось ще)?


Ще мене дивує такий результат:

Event                               Waits   Timeouts   Time (s)    (ms)     /txn
—————————- ———— ———- ———- ——- ——–
log file sequential read 849 0 10 12 0.0

Чому Oracle читає файл журналу повторного виконання (окрім як при відновленні, але ми його не виконували в період? Охоплений цим звітом statspack)?


Відповідь Тома Кайта


Процес LGWR збирається записати набір блоків журналу на диск. Він повинен почекати, поки пріоритетний процес (ми, ви і я) не завершить будь-які поточні операції копіювання, що зачіпають буфери, які ми збираємося записувати. Раніше була клямка “redo copy latch“, Але в 8i були зроблені зміни для підвищення продуктивності, щоб це робилося” швидше “.


Так що, це дані, пов’язані з журналом.


Ви ж працюєте в режимі archive log??

ops$tkyte@ORA9IR2> select * from v$system_event where event like “log file sequential%”
2 /

EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
————————- ———– ————– ———– ————
log file sequential read 4 0 0 0

ops$tkyte@ORA9IR2> @connect “/ as sysdba”
ops$tkyte@ORA9IR2> set termout off
sys@ORA9IR2> REM GET afiedt.buf NOLIST
sys@ORA9IR2> set termout on
sys@ORA9IR2> alter system switch logfile;

System altered.

sys@ORA9IR2> archive log all;
1 log archived.
sys@ORA9IR2> @connect /
sys@ORA9IR2> set termout off
ops$tkyte@ORA9IR2> REM GET afiedt.buf NOLIST
ops$tkyte@ORA9IR2> set termout on
ops$tkyte@ORA9IR2> select * from v$system_event where event like “log file sequential%”
2 /

EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
————————- ———– ————– ———– ————
log file sequential read 69 0 26 0


😉

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*