web-dev-qa-db-ja.com

sarで大待ち

データベースサーバーには、データデバイスに関する次のsar出力があります。

[postgres@dbsrv07 ~]$ LC_ALL=POSIX sar -d  |egrep "await|dev253-2"

00:00:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

00:10:01     dev253-2   2721.27  18357.23  20291.52     14.20    613.68    225.51     0.15     40.60

00:20:01     dev253-2   1345.04    574.92  10685.38      8.37    290.65    215.99      0.06      8.61

00:30:01     dev253-2    801.39    193.53   6364.92      8.18     87.49    109.34      0.07      5.95

00:40:01     dev253-2    832.95    195.70   6617.82      8.18     89.30    107.20      0.07      5.87

00:50:01     dev253-2    835.58    162.90   6644.64      8.15     85.35    102.14      0.06      5.24

01:00:01     dev253-2    847.99    232.36   6722.90      8.20     89.91    106.03      0.07      5.64

01:10:01     dev253-2   2240.78   2295.28  17543.52      8.85    163.37     72.91      0.10     23.06

01:20:01     dev253-2   2706.18   1358.97  21482.68      8.44    175.98     65.00      0.08     20.73

01:30:01     dev253-2   5839.31   3292.69  45960.39      8.43    520.98     89.19      0.07     42.24

01:40:01     dev253-2   5221.88   1945.32  41384.97      8.30    553.92    106.05      0.06     33.85

高待ちは一日中続きます。

これはI/Oのボトルネックを示していると思いますか？

ありがとう

linuxperformanceiosar
2
xpapad

svctmは、コマンドがIOスケジューラーを離れ、IOがカーネルの制御下になくなった後、ストレージが応答するのにかかった時間の測定値です。ここに表示されるのは1ミリ秒未満で、これは優れています。

awaitは、特定のIOがIOスケジューラ全体で費やした時間の測定値です。ここには数百ミリ秒が表示されますが、これはかなり悪いことです。 「良い」とは、人やベンダーによって考え方が異なります。50ミリ秒未満が良いと思います。

物理ストレージが遅い場合は、svctmが大きく、待機時間が長いことがわかります。カーネルのIOが遅い場合、待機時間が長くてもsvctmが小さいことがわかります。

このデバイスでどのIOスケジューラを使用していますか？ IOサイズが小さい（8kb）場合、バルクスループットよりもリクエストのレイテンシを重視します。デフォルトのcfqスケジューラーとは対照的に、おそらくデッドラインスケジューラーを使用するのが最善でしょう。

これを行うには、grub.confのカーネル行にelevator = deadlineを入力して再起動します。

また、キューに数百のIOがバックアップされていて（avgqu-sz）、数千のIOPS（tps ）、私はこれらがdirectioである可能性が高いデータベースIOであることを想定しているため、より大きなリクエストにマージしたり、ページキャッシュを利用したりすることはできません。ストレージサブシステム。

6
suprjami

Superjamiのコメントから、ディスク/アレイの「上」にボトルネックがあるようです。 postgresコミュニティに、彼らがスケジューリングの方法で何を推奨しているか尋ねます。 Solarisの私の時代には、主にデータベースエンジンであるマシンに「クレイ」スケジューラテーブルを使用していました...

-デイブ

1
davecb

ほとんど （：-））

awaitは、サービス時間と待機時間（レイテンシ）の組み合わせであり、待機時間について本当に心配しています。サービス時間が10ミリ秒のオーダーである場合、待機時間がサービス時間と同じ大きさになると、処理が遅くなります。

10ミリ秒は、Sunディスクアレイの適切なサービス時間です。ディスクに最適な時間はわかりませんが、I/Oボトルネックが発生していると思います。

[email protected]

1
davecb