web-dev-qa-db-ja.com

長いログフラッシュ待機時間とトランザクションログの書き込み

Log Flush Wait Timeに問題があります-現在のところ、平均は30000ms（最小0最大35000）です。データベース自体のパフォーマンスは低く、トランザクションログも合理的な説明を超えて成長しています。ログファイルは、ディスクドライブ全体をログファイルでいっぱいにするのではなく、サイズを適切に保つために縮小する必要があります。私はDB待機を確認しましたが、それらは一般的にLCK_M_S、またOLEDB。データベース自体はSQL 2016 Always-on上にあります。

設定にSQLサーバーの問題がある可能性があると私はまだ信じています-SQLメモリの負荷が非常に高いこともわかります（30000のフリーストール、〜900000000ページの読み取り、30000ページの寿命）。サーバーには32GB RAM、ホスティングがあります。 〜80データベース。

アプリケーションがこれのおそらく主な理由であることは知っていますが、それでも、手続きに関する提案はありますか？

sql-serveravailability-groupstransaction-logwait-types
4
dm12

通常の場合、この場合：IOサブシステムは低速です。 SSDを使用していますか？

DMVは友達です。

アイデンティティと問題の切り分け

ログフラッシュ待機時間

  • これは根本的なIOボトルネックの兆候です
  • 書き込みレイテンシとは何ですか？
  • sys.dm_io_virtual_file_statsとsys.dm_io_pending_io_requestsを使用して調べる

ログファイルのサイズを適切に設定する

  • あなたのアプリケーションは非常に高いトランザクション負荷タイプのようです。
  • ログファイルが特定のサイズ制限に頻繁にアクセスする場合は、そのようなサイズが必要であることを意味します。
  • ログファイルがピーク時に頻繁にそのサイズに達している場合、ログファイルのサイズを750 MBにします。

トランザクションログのバックアップ

  • たぶん、より頻繁なログバックアップが必要なだけかもしれません。
  • テストして決定。

メモリに関して言えば、32 GBの30000 PLEが私には良さそうですRAMサーバー。これはサーバーのメモリではなく、SQLのメモリであると仮定します。

リソース：

2
user3154761