Estoy usando Proxmox en un servidor dedicado. Para producción sigo usando ext4, pero decidí empezar a jugar con ZFS.
Así que he creado dos grupos de almacenamiento ZFS separados con diferentes tamaños de registros:
- 128k para todo excepto MySQL/InnoDB
- 16k para MySQL/InnoDB (porque 16k es el tamaño de página predeterminado de InnoDB que estoy usando)
Agregué ese grupo de 16k para verificar si realmente hace una diferencia en el rendimiento de la base de datos MySQL/InnoDB. Realmente así es. Tengo aproximadamente un 40 % más de transacciones por segundo y un 25 % menos de latencia (lo he probado exhaustivamente conbanco de sistemasytpcc).
Por razones prácticas, en este momento preferiría usar un grupo grande con un tamaño de registro de 16k en lugar de dos partes separadas (16k y 128k).Sé que puedo crear subvolúmenes en un único grupo ZFS y darles diferentes tamaños de registros, pero esto también es algo que quiero evitar. Prefiero mantener esto manejable desde la GUI de Proxmox.
Mis preguntas:
¿Qué desventajas puedo encontrar si empiezo a usar un tamaño de registro pequeño (16k) para todo en lugar de 128k (era el valor predeterminado en Proxmox)?
¿La imagen del disco QEMU tiene un equivalente de innodb_page_size? Si es así, ¿qué talla es?
He intentado comprobarlo con
qemu-img info:$ qemu-img info vm-100-disk-0.raw image: vm-100-disk-0.raw file format: raw virtual size: 4 GiB (4294967296 bytes) disk size: 672 MiB
El uso del servidor es:
- contenedores para www/php (toneladas de archivos pequeños, pero dentro de un archivo de disco contenedor)
- contenedores para aplicaciones java/spring (producen muchos registros)
- contenedores para bases de datos mysql/innodb (no se requiere explicación)
- Operaciones de copia de seguridad/restauración locales, incluida la compresión de copias de seguridad.
- jugar con archivos gzip grandes (no todos los días, baja prioridad)
Respuesta1
Respuesta corta:Realmente depende del caso de uso esperado. Como regla general, el tamaño de registro predeterminado de 128 K es una buena opción en discos mecánicos (donde la latencia de acceso está dominada por el tiempo de búsqueda + el retraso de rotación). Para un grupo totalmente SSD, probablemente usaría 16K o como máximo 32K (solo si este último proporciona un aumento significativo en la eficiencia de compresión de sus datos).
Respuesta larga:Con un grupo de HDD, recomiendo seguir con el tamaño de registro predeterminado de 128 K para conjuntos de datos y usar también el tamaño de bloque de vol de 128 K para zvol. La razón es que la latencia de acceso para un disco duro de 7,2 K RPM está dominada por el tiempo de búsqueda, lo que nonoescalar con tamaño de registro/tamaño de bloque de vol. Hagamos algunos cálculos: un HDD de 7,2K tiene un tiempo de búsqueda promedio de 8,3ms, mientras que leer un bloque de 128K solo toma ~1ms. Por lo tanto, ordenar una búsqueda principal (con un retraso de más de 8 ms) para leer pequeños bloques de 16K parece un desperdicio, especialmente considerando que para lecturas/escrituras más pequeñas todavía se ve afectado por la latencia r/m/w. Además, un tamaño de registro pequeño significa una mayor sobrecarga de metadatos y una peor compresión. Entonces, mientras InnoDB emite 16K IO, y para un conjunto de datos dedicado se puede usar un tamaño de registro de 16K para evitar r/m/w y amplificación de escritura, para conjuntos de datos de uso mixto (es decir, aquellos que se usan no solo para la base de datos en sí sino también para fines más generales). cargas de trabajo también) Yo sugeriría permanecer en 128K, especialmente considerando el impacto de la compresión de los registros de tamaño pequeño.
Sin embargo, para un grupo de SSD, usaría un tamaño de volblock/registro mucho más pequeño, posiblemente en el rango de 16-32K. La razón es que los SSD tienen un tiempo de acceso mucho menor pero una resistencia limitada, por lo que escribir un bloque completo de 128K para escrituras más pequeñas parece excesivo. Además, la amplificación del ancho de banda IO comandada por registros de gran tamaño es mucho más preocupante en un dispositivo con altos IOP que los SSD modernos (es decir, corre el riesgo de saturar su ancho de banda).antesalcanzando el límite de IOP).
Respuesta2
recomiendo sintonizarsiempre y cuandote encuentras con un problema.
ZFS tiene por defecto tamaños de registro de 128K, lo cual es aceptable y válido para la mayoría de las configuraciones y aplicaciones.
Las excepciones a esto incluyen:
- determinadas aplicaciones de bases de datos; un valor menor puede ser apropiado.
La desventaja es que la compresión será mucho menos efectiva, lo que puede tener un mayor impacto en el rendimiento que el mayor número de transacciones. - grandes cargas de trabajo multimedia (por ejemplo, edición de vídeo); un valor mayor es útil
- cargas de trabajo específicas que quedan fuera de los casos de uso normales de ZFS
Si cree que el rendimiento del punto de referencia de la base de datos es mejor con un determinado tamaño de registro, ¡úselo!
¿Pero has probado con un modelo realista?sin evaluación comparativacarga de trabajo para asegurarse de que se está adaptando a lo correcto?
Respuesta3
Por si sirve de algo, se recomienda establecer "recordsize=16K" según la propia documentación de zfs.
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb
EDITAR: Acabo de revertir esta configuración después de cambiarla durante menos de 12 horas en un servidor proxmox para un servidor virtual con una base de datos bastante grande (>60 GB de datos). El servidor se atrasó seriamente en el análisis de datos. De hecho, el 'z_rd_int_' los procesos saltaron de un bajo uso de CPU a aproximadamente el 5% cada uno, mientras que 'z_wr_int_'procesado disminuyó el uso de la CPU, probablemente porque se trataron menos datos.
Sin embargo, cambiar el algoritmo hash a edonr ( zfs set checksum=edonr vmpool) tuvo un impacto positivo: perf topya no se muestra SHA256TransformBlockscomo la función principal del núcleo.
Por lo tanto, la recomendación no parece ser buena en todos los casos: se puede volver al conjunto original.