Utilisation et performances d'Ext4

J'ai un cluster de machines exécutant Carbon et Graphite que je dois faire évoluer pour obtenir plus de stockage, mais je ne sais pas si je dois augmenter ou diminuer l'échelle.

Le cluster est actuellement composé de :

• 1 nœud de relais : Reçoit toutes les métriques et les transmet au nœud de stockage concerné.
• 6 Nœuds de stockage : Héberge tous les fichiers de la base de données Whisper

Le problème est qu'il semble que lorsque les disques sont utilisés à environ 80 %, les performances tombent d'un coup. Les IOPS d'écriture en grappe sont passées d'un niveau quasi-constant de 13k à une moyenne plus chaotique d'environ 7k et le temps d'IOwait est en moyenne de 54%.

J'ai jeté un coup d'œil à notre répertoire de configuration et il n'y a pas eu de changement depuis début avril, donc ce n'est pas le résultat d'un changement de configuration.

Question : L'augmentation de la taille du disque permettra-t-elle de maîtriser les performances d'E/S, ou dois-je ajouter des nœuds de stockage supplémentaires ?

Note : Pas de SSD ici, juste beaucoup, beaucoup de broches.

Graphiques pertinents :

Stats et autres :

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

Edita: J'ai redimensionné l'un des nœuds de stockage, mais cela n'a pas eu d'effet. J'ai également trouvé le cachestat utilité dans [ [https://github.com/brendangregg/perf-tools\](a](https://github.com/brendangregg/perf-tools](a) collection d'outils de perforation) qui m'a permis de jeter un coup d'oeil à l'intérieur du cache VFS. À ce stade, il semble que j'ai atteint la limite du débit d'E/S que mon stockage peut fournir.

À ce stade, je pense que je vais devoir soit continuer à augmenter le nombre de membres du cluster, soit chercher une solution de stockage de séries temporelles plus efficace en termes d'écriture.

Exemple de sortie de 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 : Depuis, nous avons migré vers une autre plate-forme où des disques SSD sont disponibles et, si les choses se sont bien passées pendant un certain temps, nous avons fini par constater la même baisse brutale des performances à mesure que nous avons ajouté de plus en plus de métriques. Bien que je n'aie pas de preuve définitive, je pense qu'il s'agit d'un problème de coin entre le fonctionnement du stockage de Carbon/Whisper et le nombre de métriques que nous stockons.

En fait, tant que le système dispose de suffisamment de RAM pour mettre en cache les fichiers Whisper pour la lecture, l'entrée-sortie se fait presque exclusivement en écriture et tout va bien. Cependant, une fois que la famine du cache FS s'installe et que les fichiers Whisper doivent être continuellement lus depuis le disque, cela consomme la bande passante de l'E/S et tout commence à se gâter.