Ext4 uso y rendimiento

Tengo un grupo de máquinas que ejecutan carbono y grafito que necesito escalar para obtener más almacenamiento, pero no estoy seguro de si necesito escalar o escalar.

El clúster está compuesto actualmente por:

• 1 nodo de retransmisión: recibe todas las métricas y las reenvía al nodo de almacenamiento relevante
• 6 nodos de almacenamiento: alberga todos los archivos Whisper DB

El problema es que parece que cuando los discos llegaron al 80% de uso, el rendimiento cayó por un precipicio. Cluster write IOPS cayó de un nivel casi constante de 13k a un promedio más caótico de alrededor de 7k y el tiempo IOwait promedia el 54%.

He echado un vistazo a nuestro repositorio de configuración y no hay cambios desde principios de abril, por lo que este no es el resultado de un cambio de configuración.

Pregunta: ¿Aumentar el tamaño del disco volverá a controlar el rendimiento de E / S o necesito agregar más nodos de almacenamiento?

Nota: No hay SSD aquí, solo muchos y muchos husos.

Gráficos relevantes:

Estadísticas y cosas:

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

Editar: he cambiado el tamaño de uno de los nodos de almacenamiento, pero no ha tenido ningún efecto. También he encontrado la cachestatutilidad en [ https://github.com/brendangregg/perf-toolsfont>(una colección de herramientas de perf) que me ha dado un vistazo dentro del caché VFS. En este punto, parece que he alcanzado el límite en el rendimiento de E / S que puede proporcionar mi almacenamiento.

En este punto, creo que voy a tener que seguir escalando a más miembros del clúster o buscar una solución de almacenamiento de series de tiempo más eficiente en escritura.

Ejemplo de salida 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

Edición súper tardía: desde entonces hemos migrado a otra plataforma donde hay SSD disponibles y, si bien las cosas estuvieron bien durante algún tiempo, finalmente vimos la misma fuerte disminución en el rendimiento a medida que agregamos más y más métricas. Si bien no tengo ninguna prueba definitiva, creo que este es un caso decisivo entre cómo funciona el almacenamiento de carbono / susurro y la gran cantidad de métricas que almacenamos.

Básicamente, siempre y cuando el sistema tenga suficiente RAM para almacenar en caché cómodamente los archivos Whisper para lecturas, el IO es una escritura casi pura y todo es feliz. Sin embargo, una vez que se establece el hambre de caché FS y los archivos Whisper deben leerse continuamente en el disco que se come en su ancho de banda de E / S y todo comienza a ir al bote.

Parece que está ejecutando SSD, que pueden tener algunas características de rendimiento funky a medida que se llenan. El hecho de que cuando el uso cayó alrededor de 6/1, el rendimiento no volvió a la normalidad, refuerza esa teoría.

La razón detrás de esto es bastante complicada, pero básicamente se reduce a la necesidad de borrar fragmentos de flash escritos pero actualmente no utilizados antes de que se pueda volver a escribir. Parece que está escribiendo bastante duro, por lo que el proceso de supresión en ejecución en la unidad no tiene la oportunidad de mantener un suministro suficiente de fragmentos en blanco una vez que todos están escritos de una vez.

Los diferentes modelos de unidades tienen diferentes controladores y diferentes cantidades de fragmentos flash "de repuesto" para usar, y las unidades más grandes obviamente tienen más fragmentos para escribir antes de que se queden sin bits nuevos, por lo que es casi seguro que la actualización a unidades más grandes "resolvería" El problema para usted, al menos temporalmente. Las unidades de grado "Enterprise" tienden a mejorar en este aspecto, pero también lo hacen los modelos más nuevos de controlador de flash, por lo que es un poco difícil, en ausencia de pruebas de terceros confiables de un modelo de unidad en particular en un patrón de uso similar a tu propio.

También es posible que pueda seguir usando las unidades que tiene ahora por más tiempo, si agita algo como fstrimsobre ellas para decirle a la unidad "definitivamente puede borrar todos estos fragmentos en este momento ", aunque hacerlo en un sistema debe hacer otras cosas al mismo tiempo, es posible que no baje tan bien (querrá tener en cuenta bien las advertencias de rendimiento en la página de fstrimmanual).

En cuanto a si necesita más nodos, no puedo decirlo con certeza, pero no lo creo. La CPU no parece estar fuera de control, y dudo que esté saturando el sistema de E / S en otro lugar.

Se sabe que Ext3 / 4 sufre, desde el punto de vista del rendimiento, con una utilización superior al 80-85%. Esto se debe a una mayor fragmentación y a un menor rendimiento de reescritura.

¿Puede proporcionar dos iostat -k -x 60 3salidas, una cuando tiene menos del 80% de capacidad y otra cuando tiene más del 80%?

EDITAR: desde su e2freefragparece que /dev/vda3tiene mucho espacio libre. ¿Se puede agregar la salida de dfy df -i?

De todos modos, sus iostatresultados, combinados con sus gráficos (especialmente "Disk IOPS"), son bastante interesantes. Parece que su carga de trabajo está muy centrada en la escritura; cuando> 95% del total de IOPS emitidos son escrituras, no tiene ningún problema. Sin embargo, cuando su rendimiento se degrada, sus discos comienzan a servir un IOPS de lectura consistente. Estas lecturas / escrituras entremezcladas interrumpen la capacidad de los discos para combinar múltiples escrituras más pequeñas en otras más grandes (las lecturas generalmente son operaciones de bloqueo), lo que lleva a un rendimiento mucho más lento.

Por ejemplo, veamos el resultado de puños mostrado por iostat: cuando el total de IOPS del disco está dominado por escrituras (como en este caso), tu avgqu-szy awaitambos son muy bajos.

Pero en el segundo y el tercero iostatvemos muchas más lecturas que, al ser operaciones de bloqueo / bloqueo (vea la rrqm/scolumna: muestra 0, por lo que no se pueden combinar lecturas en su caso), interrumpen tanto la latencia ( await) como el rendimiento (KB / s) .

He visto un comportamiento similar cuando el host se queda sin caché de inodo, tal vez debido a la gran cantidad de pequeños archivos almacenados. Para ajustar su sistema para que prefiera la caché de inodo / dentry a expensas de la caché de datos, intente emitir echo 10 > /proc/sys/vm/vfs_cache_pressurey espere unos minutos: ¿cambia algo?