Ext4 utilizzo e prestazioni

Ho un gruppo di macchine che eseguono Carbon e Graphite che devo ridimensionare per più spazio di archiviazione, ma non sono sicuro di dover ridimensionare o ridurre.

Il cluster è attualmente composto da:

• 1 nodo di inoltro: riceve tutte le metriche e inoltra al nodo di archiviazione rilevante
• 6 nodi di archiviazione: contiene tutti i file Whisper DB

Il problema è che sembra che quando i dischi hanno raggiunto un livello di utilizzo dell'80%, le prestazioni sono diminuite. Gli IOPS in scrittura a grappolo sono passati da 13k quasi costanti a una media più caotica di circa 7k e il tempo di IOwait è in media del 54%.

Ho dato un'occhiata al nostro repository di configurazione e non ci sono cambiamenti dall'inizio di aprile, quindi questo non è il risultato di una modifica della configurazione.

Domanda: L' aumento della dimensione del disco riporterà sotto controllo le prestazioni di I / O o devo aggiungere altri nodi di archiviazione?

Nota: nessun SSD qui, solo un sacco di mandrini.

Grafici rilevanti:

Statistiche e roba:

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

Modifica: ho ridimensionato uno dei nodi di archiviazione, ma non ha avuto effetto. Ho anche trovato l' cachestatutilità in [ https://github.com/brendangregg/perf-tools lasting(a una raccolta di strumenti perf) che mi ha dato uno sguardo all'interno della cache VFS. A questo punto sembra che abbia raggiunto il limite di throughput IO che la mia memoria può fornire.

A questo punto penso che dovrò continuare a ridimensionare il numero di membri del cluster o vedere come trovare una soluzione di archiviazione di serie temporali più efficiente in scrittura.

Esempio di output da 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: da allora siamo passati a un'altra piattaforma in cui sono disponibili SSD e, sebbene le cose andassero bene per un po 'di tempo, alla fine abbiamo visto lo stesso forte calo delle prestazioni quando abbiamo aggiunto sempre più metriche. Anche se non ho alcuna prova definitiva, credo che questo sia un esempio fondamentale tra il funzionamento dello storage Carbon / Whisper e il semplice numero di metriche archiviate.

Fondamentalmente, fintanto che il sistema ha abbastanza RAM per memorizzare comodamente nella cache i file Whisper per le letture l'IO è quasi pura scrittura e tutto è felice. Tuttavia, una volta che la fame nella cache di FS si avvia e i file di Whisper devono essere letti continuamente dal disco che si consuma nella larghezza di banda IO e tutto inizia a pot.

Sembra che tu stia eseguendo SSD, che possono avere alcune caratteristiche funky delle prestazioni quando si riempiono. Il fatto che quando l'utilizzo è sceso intorno al 6/1, le prestazioni non sono tornate alla normalità, rafforza questa teoria.

Il motivo è tutto piuttosto complicato, ma fondamentalmente si riduce alla necessità di sopprimere blocchi di flash scritti ma attualmente inutilizzati prima che possano essere riscritti. Sembra che tu stia scrivendo abbastanza duramente, quindi il processo di cancellazione in esecuzione nell'unità non ha la possibilità di mantenere una scorta sufficiente di blocchi vuoti una volta che sono tutti scritti una volta.

Diversi modelli di unità hanno controller diversi e diverse quantità di blocchi flash "di riserva" da utilizzare e unità più grandi hanno ovviamente più blocchi da scrivere prima che finiscano i bit nuovi, quindi è quasi certo che l'aggiornamento a unità più grandi "risolva" il problema per te, almeno temporaneamente. Le unità di livello "Enterprise" tendono a fare meglio in questo senso, ma anche i modelli più recenti di controller flash, quindi è un po 'un crapshoot, in assenza di test affidabili di terze parti su un particolare modello di unità in un modello di utilizzo simile a il tuo.

Potresti anche essere in grado di cavartela usando le unità che hai ora per un po 'più di tempo, se agiti qualcosa del genere fstrimsu di loro per dire all'unità "puoi sicuramente cancellare tutti questi blocchi in questo momento ", anche se lo fai su un sistema devi fare altre cose allo stesso tempo potrebbe non andare giù così bene (ti consigliamo di notare bene gli avvertimenti sulle prestazioni nella fstrimmanpage).

Per quanto riguarda se hai bisogno di più nodi, non posso dirlo con certezza ma non la penso così. La CPU non sembra fuori controllo e dubito che dovresti saturare il sistema I / O altrove.

Ext3 / 4 sono noti per soffrire, dal punto di vista delle prestazioni, con un utilizzo superiore all'80-85%. Ciò è dovuto alla maggiore frammentazione e alla riduzione delle prestazioni di writeback.

Potete fornire due iostat -k -x 60 3output, uno con una capacità inferiore all'80% e uno con oltre l'80%?

EDIT: dal tuo e2freefragsembra che /dev/vda3abbia un sacco di spazio libero. Puoi aggiungere l'output di dfe df -i?

Ad ogni modo, i tuoi iostatrisultati, combinati con i tuoi grafici (in particolare "Disk IOPS"), sono piuttosto interessanti. Sembra che il tuo carico di lavoro sia molto incentrato sulla scrittura; quando> 95% del totale degli IOPS emessi sono scritture, non si hanno problemi. Tuttavia, quando le prestazioni peggiorano, i dischi iniziano a servire un IOPS di lettura coerente. Questa combinazione di letture / scritture interrompe la capacità dei dischi di combinare più scritture più piccole in più grandi (le letture in genere sono operazioni di blocco), portando a prestazioni molto più lente.

Ad esempio, supponiamo vedere i pugni risultato mostrato da iostat: quando IOPS disco totale sono dominati da scritture (come in questo caso), il tuo avgqu-sze awaitsono entrambi molto bassi.

Ma nella seconda e terza iostatvediamo molte più letture che, essendo operazioni di blocco / stallo (vedi la rrqm/scolonna: mostra 0, quindi nessuna lettura può essere unita nel tuo caso), interrompendo sia la latenza ( await) che la velocità effettiva (KB / s) .

Ho visto un comportamento simile quando l'host esaurisce la cache degli inode, forse a causa del numero puro di piccoli file memorizzati. Per ottimizzare il sistema in modo da preferire la cache inode / dentry a spese della cache dei dati, provare a emettere echo 10 > /proc/sys/vm/vfs_cache_pressuree attendere qualche minuto: cambia qualcosa?