Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Ситуация такая: 2 сервера SQL2012 (физических), на одном БД Axapta 2009. Для нее настроена реплика AlwaysOn на втором сервере. Режим Asynchronous Commit. Нагрузка - типичная OLTP, с соотношением чтение/запись 90% к 10%. Средняя скорость генерации тран. лога на принципале невелика, и составляетс порядка 5-10 мб/сек (естесственно есть и пики, но они обычно длятся недолго, не более нескольких часов). Соответственно на реплику данные передаются с такой же средней скоростью. Никаких проблем с сетью и скоростью передачи нет. (очередь передачи не растет).

С течением времени скорость накатывания лога на "зеркале" снижается и в итоге становиться равна ~1,2 Мб/сек. Соответсвенно начинается отставание реплики, redo_queue_size постоянно растет. Вслед за очередью растет и процент используемого лога на принципале, что и является проблемой, ибо лог 2Тб и увеличить его размер в принципе невозможно. Нагрузки на сервер с репликой нет в принципе. Проц < 5%, дисковых очередей нет, суммарная скорость записи и чтения на все диски (Perfmon Logical Disk: Total) не превышает 5-10 мб/сек. То есть "типичных проблем", описанных в AlwaysOn Troubleshooting нет в принципе.

Может кто знает, в чем может быть проблема? (Если входящих данных недостаточно - пишите, я выложу)
12 авг 14, 17:48    [16432906]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37059
Я бы помониторил еще ожидания (sys.dm_os_wait_stats).

Редакция сервера какая?

Сообщение было отредактировано: 12 авг 14, 18:07
12 авг 14, 18:06    [16433009]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Гавриленко Сергей Алексеевич,

Microsoft SQL Server 2012 - 11.0.5522.0 (X64) 
Jun 17 2014 17:01:31
Copyright (c) Microsoft Corporation
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

select top 15 * from sys.dm_os_wait_stats
order by wait_time_ms desc

Результат под спойлером: честно говоря я ничего особенного не вижу...
+
wait_typewaiting_tasks_countwait_time_msmax_wait_time_mssignal_wait_time_ms
LAZYWRITER_SLEEP3596339484462581236264186824133490
HADR_WORK_QUEUE2655658953206558271100433000678
BROKER_TASK_STOP1184013992827497775100241346964
BROKER_TRANSMITTER382546622403607512304747520
CLR_AUTO_EVENT3072512149046498650142463974
HADR_NOTIFICATION_DEQUEUE9521420483713849036703
SLEEP_TASK190887881174734876224271370207
CLR_SEMAPHORE916441678610303200152132
HADR_CLUSAPI_CALL5125356112056261823960
XE_TIMER_EVENT498167112024390850071120243272
HADR_FILESTREAM_IOMGR_IOCOMPLETION21778271120241205286331472
HADR_TIMER_TASK224016411202038392001231920
DIRTY_PAGE_POLL102588811120198690238053392
SQLTRACE_INCREMENTAL_FLUSH_SLEEP279402112015266459373421
XE_DISPATCHER_WAIT971911201207941200080
13 авг 14, 09:16    [16434701]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Кривая маршрутизация иногда приводит к низкой скорости передачи данных.
Т.е. сетевые проблемы.
13 авг 14, 17:15    [16437866]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Владислав Колосов,

Именно поэтому и написал "Никаких проблем с сетью и скоростью передачи нет. (очередь передачи не растет)". Все данные передаются мигом. Когда есть проблемы с сетью, растет счетчик Database Replica: Log Send Queue. В норме он должен быть равен 60. У нас так и есть. Растет именно Database Replica: Redo Bytes Remaining. То есть все уже передалось и вопрос в накатывании транзакций на реплике.

Вообще, когда все нормально, счетчики Database Replica: Log Bytes received и Redone bytes/sec "шагают в ногу". Это можно хорошо видеть, запустив Data collector по этим счетчикам на пару суток, и посмотрев потом на графики - обычно они почти совпадают. Бывает, когда логируемая активность на принципале возрастает, Log Bytes received становится на это время больше, но если потом активность нормализуется Redone bytes/sec вырастает и реплика быстро догоняет принципал.

В нашем случае Redone bytes/sec тупо устаканивается на скорости примерно 1 мб/сек. И все. Неважно сколько там данных получается, какая очередь, просто вот так медленно накатывется и все тут.
14 авг 14, 11:48    [16440486]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10729
Блог
Увы, это фича :( Как и при RESTORE, фаза REDO выполняется в один поток. Если изменений в журнале очень много, это становится проблемой и для зеркального отображения и для AO. Мне пришлось из-за этого отказаться от подобных технологий на нагруженных VLDB...
15 авг 14, 12:24    [16445640]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Александр Гладченко
Увы, это фича :(


Коллеги из самого МС отвечают мне даже более лаконично, цитирую дословно: "...а х... его знает..." :)
В принципе понятно, почему сам процесс неторопливый (как и заметил коллега выше, из-за однопоточности). Непонятно все-таки остается одно: почему когда включаешь AlwaysOn (ну например при файловере), поначалу все идет довольно резво, и лог накатывается со средней скоростью 30-40Мб/сек и никаких проблем, а с течением времени становится все хуже и хуже...
Такое ощущение, что AlwaysOn как бы "устает" (забивается некий буффер, чтоли, не знаю...) Хотелось бы какой-то ясности в этом вопросе, а не того, что специалисты МС отвечают...

А пока, всем кто столкнется с такой же проблемой, могу посоветовать временное решение-костыль:
Если у вас похожая ситуация, и зеркало остает и все плохо с ним :) мне помогают следующие действия:
1. Пару-тройку раз сделать pause-resume для передачи данных.
2. На реплике:
dbcc freesystemcache('all')
DBCC FREESESSIONCACHE
dbcc freeproccache
checkpoint
DBCC DROPCLEANBUFFERS

Знаю, что многие эти комманды не сильно любят и считают их вредными, опасными, и пр. Поэтому сразу, чтобы не разводить холиваров, просьба, прежде, чем "кинуть в меня камень" предложите свое решение.
15 авг 14, 13:55    [16446384]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
GordonF
Member

Откуда:
Сообщений: 39
Александр Гладченко,
Ничего страшного, если не ошибаюсь, в оракле также, по умолчанию.

Странно, но тогда и логшиппинг со временем должен начато тормозить?
Или нет?
17 авг 14, 21:43    [16452984]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
GordonF
Странно, но тогда и логшиппинг со временем должен начато тормозить?
Или нет?

Не знаю. Не пользуем.
18 авг 14, 10:47    [16454469]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10729
Блог
GordonF
Александр Гладченко,
Ничего страшного, если не ошибаюсь, в оракле также, по умолчанию.

Странно, но тогда и логшиппинг со временем должен начато тормозить?
Или нет?


Тормозит и он, правда, справедливости ради, он начинает "отставать" заметно при большей нагрузке. Особенно, если увеличить интервал резервных копий журнала (часов до двух) и отключить компрессию...
18 авг 14, 11:55    [16454893]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4916
Блог
GordonF
Александр Гладченко,
Ничего страшного, если не ошибаюсь, в оракле также, по умолчанию.

Странно, но тогда и логшиппинг со временем должен начато тормозить?
Или нет?
В Oracle конфигурируется параллельное recovery. Так что проблем с этим не случается.
18 авг 14, 14:59    [16456605]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
GordonF
Member

Откуда:
Сообщений: 39
Александр Гладченко,
Идиотизм...как-то даже не верится :(
18 авг 14, 19:04    [16458514]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
GordonF
Member

Откуда:
Сообщений: 39
Alexander Ryndin,
Знаю.
В своё время, как-то подтупливал этот параметр.
Или это я нарвался неудачно :( на 11ом не пробовал.
18 авг 14, 19:10    [16458544]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Включите запись текущего времени в какую нибудь таблицу БД а потом сравнивайте разницу текущего времени с значением на второй ноде. Получите синтетический счетчик отставания. Можно будет увидеть график зависимости от количества транзакций, объема транзакшин лога, сетевой загрузки. После чего можно будет делать выводы.
19 авг 14, 10:24    [16460543]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
fghjjjgfdd
Guest
Сколько vlf в transaction log'е?
20 авг 14, 20:49    [16470813]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10729
Блог
fghjjjgfdd
Сколько vlf в transaction log'е?


Большая нагрузка подразумевает, что их будет больше, чем хотелось бы. Даже если приращение выставите большое... Но, ИМХО, дело не столько в количестве, а в том, что создаются они многопоточно, а повторяются на вторичном сервере в один поток. Получается "бутылочное горлышко".
Вот сценарий, в который можно запускать на разных стадиях восстановления и видеть, сколько потоков создаётся, а в протоколе восстановления видно, сколько страниц для какого файла было затронуто:

SELECT ost.session_id
	, er.command
	, CAST(er.percent_complete AS money) AS percent_complete
    , dateadd (ms, er.estimated_completion_time, getdate()) AS [Прогноз завершения]
	, ost.pending_io_count
	, osth.os_thread_id
	, ost.scheduler_id
	, owt.exec_context_id
	, owt.wait_duration_ms
	, owt.wait_type
	, s.text	
FROM master.sys.dm_os_tasks AS ost
JOIN master.sys.dm_os_threads AS osth
ON ost.worker_address = osth.worker_address
AND ost.pending_io_count > 0
AND ost.session_id IS NOT NULL
JOIN master.sys.dm_exec_connections AS ec
ON ost.session_id = ec.session_id
CROSS APPLY master.sys.dm_exec_sql_text(ec.most_recent_sql_handle) AS s
JOIN master.sys.dm_os_waiting_tasks AS owt
ON ost.session_id = owt.session_id
AND owt.wait_duration_ms > 0
JOIN master.sys.dm_exec_requests AS er
ON ost.session_id = er.session_id
AND er.percent_complete > 0
ORDER BY ost.session_id
GO


Следить нужно за ожиданиями. Вот их описания с пояснениями:

PREEMPTIVE_OS_WRITEFILEGATHER - Затянувшееся по времени автоматическое увеличение файла журнала транзакций или базы данных может привести к проблемам с производительностью. Это потому, что операции, требующей авторасширение файла будет продолжать ресурсов, таких как блокировки или кратковременные блокировки во время воспроизведения файла развивать операции. Может появиться большое время ожидания кратковременных блокировок выделения страниц. Операции, требующей много Автоувеличение покажет тип ожидания PREEMPTIVE_OS_WRITEFILEGATHER

SLEEP_BPOOL_FLUSH - Имеет место при повторе контрольной точкой выпуска новых операций ввода-вывода во избежание переполнения дисковой подсистемы. Можно наблюдать когда при восстановлении журнала достигнуть 100%, и перестал расти pending_io_count – продолжительность не возможно предсказать.

BACKUPTHREAD – сколько файлов резервных копий

BACKUPIO – сколько файлов резервных копий в квадрате. Когда присутствует ожидание PREEMPTIVE_OS_WRITEFILEGATHER, ожиданий BACKUPIO для каждого файла на одно меньше, похоже, одно отдаётся под PREEMPTIVE_OS_WRITEFILEGATHER. Также, можно наблюдать и меньшее число ожиданий на один os_thread_id. Например, на 8 файлов я видел 6 таких ожиданий на каждый файл. Хотя вначале было 7.

ASYNC_IO_COMPLETION – в начале, до 100%. Occurs when a task is waiting for I/Os to finish
IO_COMPLETION – после 100% - Occurs while waiting for I/O operations to complete. This wait type generally represents non-data page I/Os. Data page I/O completion waits appear as PAGEIOLATCH_* waits.
PAGEIOLATCH_EX – рост значений pending_io_count - Occurs when a task is waiting on a latch for a buffer that is not in an I/O request. The latch request is in Exclusive mode.

В самом начале видно тройку ожиданий: BACKUPIO, PREEMPTIVE_OS_WRITEFILEGATHER и BACKUPTHREAD. На 25% картина та же. PREEMPTIVE_OS_WRITEFILEGATHER равно числу файлов резервных копий. На 80% PREEMPTIVE_OS_WRITEFILEGATHER уже не видно. По достижении 100% картина не изменилась, также висят всё те же BACKUPIO и BACKUPTHREAD. При этом растёт pending_io_count.
PAGEIOLATCH_UP – при восстановлении журнала, сразу после того, как достигнуто 100% и завершились все BACKUPIO и BACKUPTHREAD. Потом сразу наблюдается IO_COMPLETION. Потом PAGEIOLATCH_EX.
21 авг 14, 11:20    [16472674]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
fghjjjgfdd
Сколько vlf в transaction log'е?

153
22 авг 14, 11:24    [16478660]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Александр Гладченко

Вот их описания с пояснениями:

"Можно наблюдать когда при восстановлении журнала достигнуть 100%, и перестал расти pending_io_count – продолжительность не возможно предсказать."
"сколько файлов резервных копий в квадрате"
"операции, требующей авторасширение файла будет продолжать ресурсов"


OMG =О, спасибо, но лучше уж в оригинале текст выкладывать - так вообще ничего не понятно. Овноурсы какие-то...
22 авг 14, 11:31    [16478730]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
МуМу
Включите запись текущего времени в какую нибудь таблицу БД а потом сравнивайте разницу текущего времени с значением на второй ноде. Получите синтетический счетчик отставания. Можно будет увидеть график зависимости от количества транзакций, объема транзакшин лога, сетевой загрузки. После чего можно будет делать выводы.


Не понял, кому адресован этот совет.
22 авг 14, 11:41    [16478821]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
gallam
Member

Откуда:
Сообщений: 178
emperor_bms,
сталкивались с подобной проблемой у клиента,
помогло: добавление памяти на вторую ноду (узкое место кеш) и отключение стандартной трассировки с любыми фильтрами на второй ноде.
22 авг 14, 14:46    [16480300]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
gallam
emperor_bms,
сталкивались с подобной проблемой у клиента,
помогло: добавление памяти на вторую ноду (узкое место кеш) и отключение стандартной трассировки с любыми фильтрами на второй ноде.

Хм.. ну память добавить у нас не получится (бюджета не дадут, т.к. не защитить данную трату перед начальством). Плюс к этому придется добавлять память и на 1-ой ноде, для симметрии, так что с этим вряд ли. А вот насчет "отключение стандартной трассировки" - тут не очень понял. Вы Default trace выключили чтоли? Если да, то что значит "с любыми фильтрами"?
22 авг 14, 16:01    [16480860]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
gallam
Member

Откуда:
Сообщений: 178
emperor_bms,
Лучше попробовать выключить все трассы, в том числе и служебные.
Про фильтры я имел в виду, что если у вас запущены пользовательские трассировки, то они могут влиять - независимо от фильтров.
22 авг 14, 16:05    [16480886]     Ответить | Цитировать Сообщить модератору
 Re: AlwaysOn: очень медленное применение лога на "реплике".  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
gallam,
Ну у нас только Default trace и запущен. Я понял Вас, спасибо!
22 авг 14, 16:20    [16480970]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить