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

Question

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

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

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

問題は、ディスクの使用率が80％近くになったときに、パフォーマンスが崖から落ちたように見えることです。クラスター書き込みIOPSは、ほぼ一定の13,000から約7,000のよりカオスな平均に減少し、IO待機時間は平均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]（a コレクションの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が利用可能な別のプラットフォームに移行しましたが、しばらくの間は良好でしたが、最終的には同じシャープが見られましたメトリックを追加するにつれて、パフォーマンスが低下しました。明確な証拠はありませんが、これはCarbon/Whisperストレージの仕組みと、保存されているメトリックの数との間のコーナーケースであると思います。

基本的に、システムがRAM読み取りのためにWhisperファイルを快適にキャッシュするのに十分である限り、IOはほぼ純粋な書き込みであり、すべてが満足です。ただし、 FSキャッシュスタベーションセットを入力し、Whisperファイルを継続的にディスクから読み込む必要があります。これは、IO帯域幅に食い込み、すべてがポットに達し始めます。

womble · Answer

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

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

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

fstrimのようなものを振ってドライブに伝えると、「これらのすべてのチャンクを正しくワイプできます今 "、システム上で同時に実行する必要があるものの、同時に他のことを実行する必要がある場合、それほどうまくいかない可能性があります（fstrimのマンページにあるパフォーマンスの警告に注意してください））。

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

shodanshok · Answer

Ext3/4は、パフォーマンスの観点から、使用率が80〜85％を超えることがよく知られています。これは、断片化の増加と書き戻しパフォーマンスの低下が原因です。

2つのiostat -k -x 60 3出力を提供できますか。1つは容量が80％未満の場合、もう1つは80％を超える場合です。

編集： e2freefragから/dev/vda3には十分な空き容量があるようです。 dfとdf -iの出力を追加できますか？

とにかく、グラフ（特に「ディスクIOPS」）と組み合わせたiostat結果は非常に興味深いものです。ワークロードは非常に書き込み中心であるようです。発行された合計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を発行して数分待ちます。何か変更されますか？