Utilisation et performances d'Ext4

J'ai un cluster de machines exécutant Carbon et Graphite que j'ai besoin de faire évoluer pour plus de stockage, mais je ne sais pas si j'ai besoin de passer à l'échelle supérieure ou inférieure.

Le cluster est actuellement composé de:

• 1 nœud de relais: reçoit toutes les mesures et les transmet au nœud de stockage approprié
• 6 nœuds de stockage: hébergent tous les fichiers DB Whisper

Le problème est qu'il semble que lorsque les disques atteignent 80% d'utilisation, les performances tombent d'une falaise. Les IOPS d'écriture de cluster sont passés d'une valeur quasi constante de 13k à une moyenne plus chaotique d'environ 7k et le temps d'IOwait est en moyenne de 54%.

J'ai jeté un œil à notre dépôt de configuration et il n'y a aucun 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 ramènera-t-elle les performances d'E / S ou dois-je ajouter plus de nœuds de stockage?

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

Graphes pertinents:

Statistiques et trucs:

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

Edit: j'ai redimensionné l'un des nœuds de stockage, mais cela n'a pas eu d'effet. J'ai également trouvé l' cachestatutilitaire dans [ https://github.com/brendangregg/perf-tools diplomé (une collection d'outils de perf) qui m'a donné un aperçu 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 continuer à évoluer vers davantage de membres de cluster, ou voir comment trouver une solution de stockage de séries chronologiques plus efficace en é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: Nous avons depuis migré vers une autre plate-forme où les SSD sont disponibles et, bien que les choses aient été bonnes pendant un certain temps, nous avons finalement vu la même baisse brutale des performances en ajoutant de plus en plus de mesures. Bien que je n'ai pas de preuve définitive, je pense que c'est un cas d'angle entre le fonctionnement du stockage Carbon / Whisper et le nombre de mesures que nous stockons.

Fondamentalement, tant que le système dispose de suffisamment de RAM pour mettre en cache confortablement les fichiers Whisper pour les lectures, l'IO est une écriture presque pure et tout est satisfaisant. Cependant, une fois que la famine du cache FS est installée et que les fichiers Whisper doivent être continuellement lus sur le disque qui consomme dans votre bande passante d'E / S et que tout commence à tourner.

On dirait que vous utilisez des SSD, qui peuvent avoir des caractéristiques de performance géniales à mesure qu'ils sont pleins. Le fait que lorsque l'utilisation a chuté vers 6/1, les performances ne sont pas revenues à la normale, renforce cette théorie.

La raison derrière tout cela est plutôt compliquée, mais se résume essentiellement à la nécessité de supprimer les morceaux de flash écrits mais actuellement inutilisés avant de pouvoir être réécrits. Il semble que vous écriviez assez fort, de sorte que le processus de suppression en cours d'exécution dans le lecteur n'a pas la possibilité de conserver une quantité suffisante de morceaux supprimés une fois qu'ils sont tous écrits une seule fois.

Différents modèles de disques ont différents contrôleurs et différentes quantités de blocs flash "de rechange" à utiliser, et les disques plus gros ont évidemment plus de blocs à écrire avant de manquer de nouveaux bits, il est donc presque certain que la mise à niveau vers des disques plus gros "résoudra" le problème pour vous, au moins temporairement. Les disques de type «entreprise» ont tendance à mieux faire à cet égard, mais les nouveaux modèles de contrôleur flash aussi, donc c'est un peu un jeu d'enfant, en l'absence de tests tiers fiables d'un modèle de disque particulier dans un modèle d'utilisation similaire à le tien.

Vous pourriez également être en mesure de vous en sortir en utilisant les lecteurs que vous avez maintenant pendant un certain temps, si vous agitez quelque chose comme fstrimdessus pour dire au lecteur "vous pouvez certainement effacer tous ces morceaux en ce moment ", bien que le faire sur un système vous devez faire d'autres choses en même temps peut ne pas descendre si bien (vous voudrez bien noter les avertissements de performances dans la fstrimpage de manuel).

Quant à savoir si vous avez besoin de plus de nœuds, je ne peux pas le dire avec certitude, mais je ne le pense pas. Le processeur ne semble pas hors de contrôle, et je doute que vous saturiez le système d'E / S ailleurs.

Ext3 / 4 sont bien connus pour souffrir, du point de vue des performances, avec une utilisation supérieure à 80-85%. Cela est dû à une fragmentation accrue et à des performances d'écriture différée réduites.

Pouvez-vous fournir deux iostat -k -x 60 3sorties, une lorsque la capacité est inférieure à 80% et l'autre lorsqu'elle est supérieure à 80%?

EDIT: à partir de votre, e2freefragil semble /dev/vda3avoir beaucoup d'espace libre. Pouvez-vous ajouter la sortie de dfet df -i?

Quoi qu'il en soit, vos iostatrésultats, combinés avec vos graphiques (en particulier "Disk IOPS"), sont assez intéressants. Il semble que votre charge de travail soit très centrée sur l'écriture; lorsque> 95% du nombre total d'E / S par seconde émises sont des écritures, vous n'avez aucun problème. Cependant, lorsque vos performances se dégradent, vos disques commencent à servir une IOPS de lecture cohérente. Cette lecture / écriture mélangée perturbe la capacité des disques à combiner plusieurs écritures plus petites en plus grandes (les lectures sont généralement des opérations de blocage), ce qui entraîne des performances beaucoup plus lentes.

Par exemple, voyons le résultat des poings montré par iostat: lorsque le total des IOPS de disque est dominé par les écritures (comme dans ce cas), votre avgqu-szet awaitsont tous deux très faibles.

Mais dans les deuxième et troisième, iostatnous voyons beaucoup plus de lectures qui, étant des opérations de blocage / blocage (voir la rrqm/scolonne: il montre 0, donc aucune lecture ne peut être fusionnée dans votre cas), perturbent à la fois la latence ( await) et le débit (Ko / s) .

J'ai vu un comportement similaire lorsque l'hôte manque de cache d'inode, peut-être en raison du nombre considérable de petits fichiers stockés. Pour régler votre système pour préférer le cache inode / dentry au détriment du cache de données, essayez d'émettre echo 10 > /proc/sys/vm/vfs_cache_pressureet attendez quelques minutes: cela change-t-il quelque chose?