Ext4の使用法とパフォーマンス

CarbonとGraphiteを実行しているマシンのクラスターを持っているので、ストレージを増やすためにスケールする必要がありますが、スケールアップする必要があるか、スケールアウトする必要があるかはわかりません。

クラスターは現在、次のもので構成されています。

• 1リレーノード：すべてのメトリックを受信し、関連するストレージノードに転送します
• 6ストレージノード：すべてのWhisper DBファイルを収容

問題は、ディスクの使用率が80％近くになると、パフォーマンスが崖から落ちたように見えることです。クラスター書き込みIOPSは、ほぼ一定の13kから約7kのより混aroundとした平均に低下し、IOwait時間の平均は54％です。

構成レポを確認しましたが、4月上旬以降変更はないため、これは構成変更の結果ではありません。

質問：ディスクサイズを増やすとIOパフォーマンスが制御下に戻りますか、それともストレージノードを追加する必要がありますか？

注：ここにはSSDはありません。たくさんのスピンドルがあります。

関連グラフ：

統計ともの：

e2freefrag：

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          4008          4008    0.08%
    8K...   16K-  :          1723          3992    0.08%
   16K...   32K-  :           703          3495    0.07%
   32K...   64K-  :           637          7400    0.15%
   64K...  128K-  :          1590         29273    0.61%
  128K...  256K-  :          4711        236839    4.95%
  256K...  512K-  :          2664        265691    5.56%
  512K... 1024K-  :          2359        434427    9.08%
    1M...    2M-  :           595        213173    4.46%
    2M...    4M-  :            75         49182    1.03%
   64M...  128M-  :             6        118890    2.49%

e4defrag：

[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files>                             now/best       size/ext
1. /opt/graphite/storage/graphite.db            17/1              4 KB
2. /var/log/cron                                13/1              4 KB
3. /var/log/wtmp                                16/1              4 KB
4. /root/.bash_history                           4/1              4 KB
5. /var/lib/rpm/Sha1header                      10/1              4 KB

 Total/best extents                             182256/159981
 Average size per extent                        183 KB
 Fragmentation score                            2
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/vda3) does not need defragmentation.
 Done.

iostat：

[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01)     07/05/2016      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.99    0.00    2.54   29.66    0.35   59.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00   100.34  177.48 1808.94  2715.66  7659.19    10.45     0.26    0.13    0.65    0.08   0.23  46.14

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.17    0.00    7.00   73.21    0.58   13.04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    23.87  672.40  656.47  8729.87  2752.27    17.28     7.36    5.50    2.72    8.35   0.73  96.83

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.06    0.00    7.31   73.03    0.59   12.01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    42.68  677.67  614.88  8634.93  2647.53    17.46     6.66    5.15    2.72    7.83   0.74  96.08

df：

[root@graphite-storage-01 ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda3       39153856 33689468   3822852  90% /
devtmpfs         1933092        0   1933092   0% /dev
tmpfs            1941380        0   1941380   0% /dev/shm
tmpfs            1941380   188700   1752680  10% /run
tmpfs            1941380        0   1941380   0% /sys/fs/cgroup
/dev/vda2         999320     2584    980352   1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda3      2490368 239389 2250979   10% /
devtmpfs        483273    304  482969    1% /dev
tmpfs           485345      1  485344    1% /dev/shm
tmpfs           485345    322  485023    1% /run
tmpfs           485345     13  485332    1% /sys/fs/cgroup
/dev/vda2        65536     22   65514    1% /tmp

編集：ストレージノードの1つのサイズを変更しましたが、効果はありませんでした。またcachestat、[ https://github.com/brendangregg/perf-tools]（perfツールのコレクション）にユーティリティがあり、VFSキャッシュの内部を確認できます。この時点で、ストレージが提供できるIOスループットの制限に達しているようです。

この時点で、より多くのクラスターメンバーにスケールアウトし続けるか、より書き込み効率の良い時系列ストレージソリューションを見つけることについて検討する必要があると思います。

からの出力例cachestat：

storage-01 [resized disk]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    9691    14566     7821    40.0%          160       2628
   36181    14689     7802    71.1%          160       2631
    8649    13617     7003    38.8%          159       2628
   15567    13399     6857    53.7%          160       2627
    9045    14002     7049    39.2%          160       2627
    7533    12503     6153    37.6%          159       2620

storage-02 [not resized]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    5097    11629     4740    30.5%          143       2365
    5977    11045     4843    35.1%          142       2344
    4356    10479     4199    29.4%          143       2364
    6611    11188     4946    37.1%          143       2348
   33734    14511     5930    69.9%          143       2347
    7885    16353     7090    32.5%          143       2358

Super Late Edit：その後、SSDが利用可能な別のプラットフォームに移行しましたが、しばらくの間は順調でしたが、最終的にはメトリックを追加するにつれてパフォーマンスの急激な低下が見られました。明確な証拠はありませんが、これはカーボン/ウィスパーストレージの仕組みと、格納するメトリックの数の間のコーナーケースだと思います。

基本的に、システムが読み取りのためにウィスパーファイルを快適にキャッシュするのに十分なRAMを持っている限り、IOはほとんど純粋な書き込みであり、すべてが満足です。ただし、FSキャッシュの枯渇が始まり、Whisperファイルをディスクから継続的に読み込む必要があるため、IO帯域幅を消費し、すべてがポットになり始めます。

SSDを実行しているように聞こえますが、SSDはいっぱいになるとファンキーなパフォーマンス特性を持つ場合があります。使用量が6/1前後に低下したとき、パフォーマンスが通常に戻らないという事実は、その理論を補強します。

その背後にある理由はすべてかなり複雑ですが、基本的には、書き込まれたが現在使用されていないフラッシュのチャンクを消去してから再度書き込む必要があります。あなたはかなり一生懸命書いてい​​るように見えるので、ドライブで実行されているブランキングプロセスは、一度書き込まれると、ブランクチャンクの十分な供給を維持する機会がありません。

ドライブのモデルが異なればコントローラーも異なり、使用する「スペア」フラッシュチャンクの量も異なります。また、大きなドライブでは、新しいビットがなくなる前に書き込むチャンクが多いため、大きなドライブにアップグレードすると「解決」することはほぼ確実です少なくとも一時的にあなたのための問題。「エンタープライズ」グレードのドライブはこの点で優れている傾向がありますが、フラッシュコントローラーの新しいモデルも同様です。そのため、特定のドライブモデルのサードパーティによる信頼できるテストが存在しない場合、あなた自身の。

また、システム上で実行している場合でも、「今すぐfstrimこれらのチャンクのすべてを確実に消去できる」とドライブに指示するように振ると、現在のドライブをしばらく使用しなくても済む場合があります。他のことを同時に行う必要がある場合は、それほどうまくいかないかもしれません（マンページのパフォーマンス警告に注意してください）。fstrim

もっとノードが必要かどうかについては、確かに言うことはできませんが、そうは思いません。CPUは制御不能に見えず、I / Oシステムが他の場所で飽和状態になることはないでしょう。

Ext3 / 4は、パフォーマンスの観点から、80〜85％を超える使用率で苦しむことがよく知られています。これは、断片化の増加とライトバックパフォーマンスの低下によるものです。

iostat -k -x 60 380％未満の容量と80％を超える容量の2つの出力を提供できますか？

編集：あなたからe2freefragそれ/dev/vda3は十分な空きスペースがあるようです。dfand の出力を追加できますdf -iか？

とにかく、iostatグラフと組み合わせた結果（特に「ディスクIOPS」）は非常に興味深いものです。ワークロードは書き込み中心です。発行されたIOPSの合計の95％以上が書き込みである場合、問題はありません。ただし、パフォーマンスが低下すると、ディスクは一貫した読み取りIOPSを提供し始めます。この読み取り/書き込みの混在により、ディスクの複数の小さな書き込みを大きな書き込みに結合する能力が損なわれ（読み取りは通常ブロック操作です）、パフォーマンスが大幅に低下します。

たとえば、次のように表示される最初の結果を見てみましょうiostat。合計ディスクIOPSが書き込みに支配されている場合（この場合のように）、あなたavgqu-szとawait両方は非常に低いです。

しかし、2番目と3番目のiostat読み取りでは、ブロック/ストール操作（rrqm/s列を参照してください：0を示しているため、読み取りをマージできません）により、レイテンシ（await）とスループット（KB / s）の両方が中断されます。

ホストがiノードキャッシュを使い果たすと、おそらく保存されている小さなファイルの数が多いために、同様の動作が見られます。データキャッシュを犠牲にしてinode / dentryキャッシュを優先するようにシステムを調整するには、発行してecho 10 > /proc/sys/vm/vfs_cache_pressureから数分待ってください。変更はありますか？