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.
fuente
Respuestas:
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 defstrimmanual).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.
fuente
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 dedfydf -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), tuavgqu-szyawaitambos son muy bajos.Pero en el segundo y el tercero
iostatvemos muchas más lecturas que, al ser operaciones de bloqueo / bloqueo (vea larrqm/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?fuente
iostat[agregado al final de mi pregunta] ya que ninguno de los nodos de almacenamiento está debajo. Tengo otras instancias con menos del 80% de uso, pero nada con una carga de trabajo similar a estas.