Автор — Pinal Dave
Сначала я не думал писать о данном виде ожиданий, так как видел LOGUFFER в топе ожиданий всего 1 раз и я не уверен, что данное ожидание является распространённым.
Из Book On-Line:
LOGBUFFER
Возникает, когда задача (task) ожидает место в log buffer для записи строки журнала транзакций. Высокие значения могут означать что диск, под файлом журнала транзакций, не успевает за количеством генерируемой информации сервером.
Объяснение LOGBUFFER:
Описание LOGBUFFER в book on-line выглядит очень точным. На системе, где я встретил данный тип ожиданий, файл лога (LDF) лежал на локальном диске, а файлы данных (MDF,NDF) на системе хранения данных. Как только мы переместили LDF на более быстрое хранилища, данный вид ожиданий исчез.
Уменьшение LOGBUFFER:
Вот несколько способов, чтобы избавиться от данного вида ожиданий:
- Разместите файл транзакций отдельно от файлов баз данных и других файлов (такой диск должен быть достаточно быстрый)
- Избегайте курсоров и частых фиксаций транзакций
- Найдите наиболее нагруженные файлы баз данных по дисковым операциям с помощью скрипта
- Проверьте счётчики производительности Windows (performance monitor), которые могут сигнализировать о проблемах дисковой подсистемы (PhysicalDisk:Avg.Disk Queue Length, PhysicalDisk:Disk Read Bytes/sec and PhysicalDisk :Disk Write Bytes/sec)
Как вы могли заметить, LOGBUFFER сильно похож на WRITELOG. Не смотря на то, что способы уменьшения данных ожиданий похожи, я не уверен, что LOGBUFFER и WRITELOG это один и тот же вид ожиданий. По их описанию, можно понять что они имеют отличия хотя оба зависят от качества дисковой подсистемы под файлом журнала транзакций и оба могут существенно снизить производительность системы.
Заметка: Представленная тут информация является исключительно моим опытом. Я настаиваю на том, чтобы вы читали Books On-Line. Все мои рассуждения о ожиданиях носят исключительно общий характер и варьируются от системы к системе. Прежде чем использовать это на рабочем сервере, рекомендую провести тестирование на сервере разработки.