Nutzung und Leistung von Ext4

Ich habe eine Gruppe von Maschinen mit Carbon und Graphite, die ich für mehr Speicher skalieren muss, aber ich bin mir nicht sicher, ob ich skalieren oder verkleinern muss.

Der Cluster besteht derzeit aus:

• 1 Relaisknoten: Empfängt alle Metriken und leitet sie an den entsprechenden Speicherknoten weiter
• 6 Speicherknoten: Enthält alle Whisper DB-Dateien

Das Problem ist, dass die Leistung anscheinend von einer Klippe abfiel, als die Festplatten in der Nähe von 80% ausgelastet waren. Das Cluster-Schreib-IOPS fiel von nahezu konstanten 13.000 auf einen chaotischeren Durchschnitt von etwa 7.000, und die durchschnittliche IOwait-Zeit betrug 54%.

Ich habe unser Konfigurations-Repo durchgesehen und seit Anfang April gibt es keine Änderungen mehr. Dies ist also nicht das Ergebnis einer Konfigurationsänderung.

Frage: Wird durch Erhöhen der Festplattengröße die E / A-Leistung wieder unter Kontrolle gebracht, oder muss ich weitere Speicherknoten hinzufügen?

Hinweis: Hier gibt es keine SSDs, nur viele, viele Spindeln.

Relevante Grafiken:

Statistiken und Sachen:

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

Bearbeiten: Ich habe die Größe eines der Speicherknoten geändert, aber es hat keine Auswirkungen. Ich habe das cachestatDienstprogramm auch in [ https://github.com/brendangregg/perf-tools (eine Sammlung von Perf-Tools) gefunden, das mir einen Einblick in den VFS-Cache gibt. An diesem Punkt habe ich anscheinend die Grenze des E / A-Durchsatzes erreicht, die mein Speicher bereitstellen kann.

An diesem Punkt denke ich, dass ich entweder weiter auf mehr Cluster-Mitglieder skalieren muss oder eine schreibeffizientere Zeitreihen-Speicherlösung finden muss.

Beispielausgabe von 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: Seitdem sind wir auf eine andere Plattform migriert, auf der SSDs verfügbar sind, und obwohl die Dinge einige Zeit gut waren, haben wir schließlich den gleichen starken Leistungsabfall festgestellt, als wir immer mehr Metriken hinzugefügt haben. Obwohl ich keinen endgültigen Beweis habe, glaube ich, dass dies ein Eckfall zwischen der Funktionsweise von Carbon / Whisper-Speicher und der Anzahl der von uns gespeicherten Metriken ist.

Solange das System über genügend RAM verfügt, um die Whisper-Dateien bequem zum Lesen zwischenzuspeichern, ist das E / A im Grunde genommen fast reines Schreiben und alles ist glücklich. Sobald jedoch der FS-Cache-Hunger einsetzt und Whisper-Dateien kontinuierlich von der Festplatte eingelesen werden müssen, die Ihre E / A-Bandbreite beansprucht, beginnt alles zu laufen.

Klingt so, als würden Sie SSDs verwenden, die einige funky Leistungsmerkmale aufweisen können, wenn sie voll werden. Die Tatsache, dass die Leistung nicht wieder normal war, als die Nutzung um 6/1 sank, bestätigt diese Theorie.

Der Grund dafür ist alles ziemlich kompliziert, aber im Grunde liegt es in der Notwendigkeit, geschriebene, aber derzeit nicht verwendete Flash-Blöcke auszublenden, bevor sie wieder geschrieben werden können. Es sieht so aus, als würden Sie ziemlich hart schreiben, sodass der im Laufwerk ausgeführte Austastvorgang keine Chance hat, einen ausreichenden Vorrat an ausgeblendeten Blöcken aufrechtzuerhalten, sobald alle auf einmal geschrieben wurden.

Verschiedene Laufwerksmodelle verfügen über unterschiedliche Controller und unterschiedliche Mengen an "Ersatz" -Blitzblöcken, die verwendet werden müssen, und größere Laufwerke müssen offensichtlich mehr Blöcke schreiben, bevor ihnen die neuen Bits ausgehen. Daher ist es fast sicher, dass ein Upgrade auf größere Laufwerke "gelöst" werden würde. das Problem für Sie, zumindest vorübergehend. Laufwerke der Klasse "Enterprise" schneiden in dieser Hinsicht tendenziell besser ab, aber auch neuere Modelle von Flash-Controllern. Dies ist ein kleiner Fehler, da kein zuverlässiges Testen eines bestimmten Laufwerksmodells durch Dritte in einem ähnlichen Verwendungsmuster vorliegt dein eigenes.

Sie könnten auch in der Lage sein, die Laufwerke, die Sie jetzt haben, für einige Zeit zu verwenden, wenn Sie so etwas fstrimdarüber winken , um dem Laufwerk mitzuteilen , dass Sie "definitiv alle diese Blöcke jetzt löschen können ", obwohl Sie dies auf einem System tun Sie müssen andere Dinge gleichzeitig tun, was möglicherweise nicht so gut ankommt (Sie sollten die Leistungswarnungen auf der fstrimManpage gut beachten ).

Ob Sie mehr Knoten benötigen, kann ich nicht genau sagen, aber ich denke nicht. Die CPU sieht nicht außer Kontrolle und ich bezweifle, dass Sie das E / A-System an anderer Stelle sättigen würden.

Ext3 / 4 leiden bekanntermaßen unter Leistungsgesichtspunkten unter einer Auslastung von über 80-85%. Dies ist auf eine erhöhte Fragmentierung und eine verringerte Rückschreibleistung zurückzuführen.

Können Sie zwei iostat -k -x 60 3Ausgaben bereitstellen , eine bei einer Kapazität von weniger als 80% und eine bei einer Kapazität von über 80%?

EDIT: von Ihrem e2freefragscheint /dev/vda3es viel freien Speicherplatz zu haben. Können Sie die Ausgabe von dfund hinzufügen df -i?

Auf jeden Fall sind Ihre iostatErgebnisse in Kombination mit Ihren Grafiken (insbesondere "Disk IOPS") sehr interessant. Es scheint, dass Ihre Arbeitslast sehr schreibzentriert ist. Wenn> 95% aller ausgegebenen IOPS Schreibvorgänge sind, haben Sie kein Problem. Wenn sich Ihre Leistung jedoch verschlechtert, werden auf Ihren Festplatten konsistente Lese-IOPS bereitgestellt. Diese vermischten Lese- / Schreibvorgänge stören die Fähigkeit der Festplatten, mehrere kleinere Schreibvorgänge in größeren zu kombinieren (Lesevorgänge blockieren normalerweise Vorgänge), was zu einer viel langsameren Leistung führt.

Sehen Sie sich zum Beispiel das Fäustergebnis an, das wie folgt angezeigt wird iostat: Wenn die gesamten Festplatten-IOPS von Schreibvorgängen dominiert werden (wie in diesem Fall), sind Ihre avgqu-szund awaitbeide sehr niedrig.

Aber im zweiten und dritten sehen iostatwir viel mehr Lesevorgänge, die als Blockierungs- / Blockiervorgänge (siehe rrqm/sSpalte: Es wird 0 angezeigt , sodass in Ihrem Fall keine Lesevorgänge zusammengeführt werden können) sowohl die Latenz ( await) als auch den Durchsatz (KB / s) stören. .

Ich habe ein ähnliches Verhalten festgestellt, wenn dem Host der Inode-Cache ausgeht, möglicherweise aufgrund der schieren Anzahl kleiner gespeicherter Dateien. Um Ihr System so einzustellen, dass es den Inode- / Dentry-Cache auf Kosten des Datencaches bevorzugt, versuchen Sie es mit der Ausgabe echo 10 > /proc/sys/vm/vfs_cache_pressureund warten Sie einige Minuten: Ändert sich etwas?