11 votos

Ext4 uso y rendimiento de los

Tengo un clúster de máquinas de Carbón y Grafito que necesito a escala para obtener más almacenamiento, pero no estoy seguro de si tengo que escala hacia arriba o hacia fuera.

El clúster está compuesto de:

  • 1 Relé de Nodo: Recibe todos los parámetros de medición y remite a la correspondiente nodo de almacenamiento
  • 6 Nodos de Almacenamiento: las Casas de todo el Susurro de ficheros de base de datos

El problema es que parece que cuando los discos se puso en el barrio de 80% de uso, el rendimiento cayó de un acantilado. Clúster de IOPS de escritura cayó de una casi constante 13k más caótico promedio de alrededor de 7k y IOwait promedios de tiempo de 54%.

He echado un vistazo a través de nuestra config repo y no hay cambios desde principios de abril, así que esto no es el resultado de una configuración de cambio.

Pregunta: Va a aumentar el tamaño del disco traer IO desempeño de nuevo bajo control, o tengo que agregar más nodos de almacenamiento?

Nota: Ninguna de las Ssd de aquí, sólo un montón y un montón de ejes.

Gráficos:

disk usage iops cpu carbon cache metrics per second

Estadísticas y esas 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

11voto

Ryan Sampson Puntos 2898

Suena como que usted está ejecutando unidades de estado sólido, que puede tener algunos funky características de rendimiento medida que se llena. El hecho de que cuando el uso caído alrededor de 6/1, el rendimiento no volver a la normalidad, refuerza esa teoría.

La razón detrás de esto es todo bastante complicado, pero básicamente se reduce a la necesidad de poner en blanco escritas pero actualmente no utilizado trozos de flash antes de que se pueda escribir de nuevo. Parece que estás escribiendo bastante duro, por lo que la supresión de proceso que se ejecuta en la unidad no tiene una oportunidad para mantener un suministro suficiente de blanco en trozos una vez que están todos escritos a la vez.

Diferentes modelos de unidad tiene diferentes controladores, y diferentes cantidades de "repuesto" flash trozos de usar, y las unidades más grandes, obviamente, tienen más fragmentos para escribir antes de que se agoten fresco bits, por lo que es casi seguro que actualizar las unidades de "resolver" el problema, al menos temporalmente. "La empresa" grado de las unidades tienden a hacer mejor en este aspecto, pero también lo hacen los nuevos modelos de controlador de flash, así que es un poco de un crapshoot, en la ausencia de la confiabilidad de pruebas por parte de terceros de un particular modelo de la unidad en un patrón de uso similar a la suya.

Usted también puede ser capaz de salirse con la utilización de las unidades que tienen ahora por algún tiempo más, si la onda de algo como fstrim más de ellos a decirle a la unidad "definitivamente, usted puede borrar todos los de estos trozos justo ahora", a pesar de hacerlo en un sistema que usted necesita para estar haciendo otras cosas al mismo tiempo, podría no ir tan bien (tenga en cuenta también el rendimiento de las advertencias en la fstrim página de manual).

Si necesita más nodos, yo no puedo decir con seguridad, pero yo no lo creo. La CPU no parece estar fuera de control, y dudo que sería saturar el sistema de I/O en otros lugares.

3voto

shodanshok Puntos 2644

Ext3/4 están bien saber sufrir, desde un punto de vista del rendimiento, con la utilización por encima de 80-85%. Esto es debido al aumento de la fragmentación y la reducción de la reescritura de rendimiento.

Puede usted proporcionar dos iostat -k -x 60 3 salida, cuando menos del 80% de su capacidad, y más del 80%?

EDIT: a partir de su e2freefrag parece /dev/vda3 tiene un montón de espacio libre. Puedes añadir la salida de df y df -i?

De todos modos, su iostat resultados, combinados con sus gráficos (especialmente "IOPS de Disco"), son muy interesantes. Parece que su carga de trabajo es muy de escritura centrada en el; cuando >95% del total emitido IOPS se escribe, no tiene ningún problema. Sin embargo, cuando su rendimiento se degrada, sus discos comenzar a cumplir una constante de IOPS de lectura. Este entremezclado lee/escribe interrumpe los discos de la capacidad de la combinación de múltiples pequeños escribe en los más grandes (lee normalmente son el bloqueo de las operaciones), que llevan mucho más lento el rendimiento.

Por ejemplo, vamos a ver los puños resultado que muestra iostat: cuando el total de IOPS de disco están dominadas por las escrituras (como en este caso), su avgqu-sz y await son muy bajos.

Pero en el segundo y tercer iostat vemos muchas más lecturas que, siendo de bloqueo/estancamiento de las operaciones (véase el rrqm/s columna: muestra 0, por lo que no lee se pueden combinar en su caso), alteran tanto la latencia (await) y el rendimiento (KB/s).

He visto un comportamiento similar cuando el host de ejecutar fuera de la caché de inodos, tal vez debido a la gran cantidad de pequeños archivos almacenados. Para ajustar el sistema a preferir inodo/dentry caché a expensas de la caché de datos, intente emitir echo 10 > /proc/sys/vm/vfs_cache_pressure y esperar algunos minutos: ¿cambia algo?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: