Pull to refresh

Comments 5

Спасибо за статью, наконец-то разобрался в Fill Factor и понял, как оптимально его настроить!

Удалось обнаружить корреляцию между показателями fillfactor и LOGMGR_QUEUE:

это, конечно, интересно, но конечная цель оптимизации — время выполнения, а не статистика по ожиданиям.
интересно было бы посмотреть статистку по времени выполнения insert'а и по результирующему размеру таблицы.

Удалось обнаружить корреляцию между показателями fillfactor и LOGMGR_QUEUE

И как сильно влияет ожидание LOGMGR_QUEUE на производительность вашей системы?

https://www.sqlskills.com/help/waits/logmgr_queue/
This wait type is when the log writer thread (or one of the log writer threads, on 2016+) is waiting for something to do (either log to flush or a write to complete).

https://www.mssqltips.com/sqlservertip/4131/troubleshooting-sql-server-transaction-log-related-wait-types/

LOGMGR_QUEUE wait type

According to Microsoft documentation, this wait type occurs when a task is waiting for any outstanding log I/Os to finish. If you see this wait type you should not be worried because it indicates that the log writer is waiting to be invoked by a session or the checkpoint process. In other words, it is telling you that there is no current log activity. It’s most unlikely to see this wait type on user sessions because the log writer is a background process.

Например, Glenn Berry исключает его при оценке статистики ожиданий в систему
https://www.dropbox.com/s/k1vauzxxhyh1fnb/SQL%20Server%202019%20Diagnostic%20Information%20Queries.sql?dl=0 (строка 1047)

А вот дефрагментация индекса при активной вставке или обновлении не в конец индекса может повлиять.

В целом я с Вами согласен, но корреляция имеет место. Можете проверить. На мой взгляд, ожидания записи возрастают из-за избыточных split page, которые (конечно) связаны с дефрагментацией индекса. Спасибо за конструктивный комментарий.

Ниже перевод фрагмента https://www.sqlshack.com/sql-server-wait-type-logmgr-queue/

[B]Предлагаемые решения[/B]

Безопасно игнорировать, если LOGBUFFER and WRITELOG невелики

  1. Удалите курсор или итеративные процедуры, вносящие множество небольших изменений. Замените их пакетными модификациями

  2. Посмотрите, подходит ли параметр базы данных Delayed Durability для системы баз данных

  3. Отключите все неиспользуемые индексы. Это уменьшит количество записей во время изменения данных

  4. Убедитесь, что коэффициенты заполнения индекса установлены соответствующим образом, чтобы избежать разделения страниц.

  5. Индексы, которые часто меняются, должны иметь более низкий коэффициент заполнения

Это ожидание не проблема, но решение содержит пять пунктов.
Пункты 4,5 совпадают с тем, что я сделал в статье. Это хороший знак.

Sign up to leave a comment.

Articles

Change theme settings