2 votos

¿Qué tipo de metadatos se cargan / desalojan principalmente de ARC en mi sistema ZFS?

Estoy tratando de comprobar cómo mi agrupación de ZFS del ARCO se utiliza, motivado por "necesito más RAM, aunque caro".

He 128GB rápido ECC y el uso de NVMe unidades de estado sólido para L2ARC, pero sigue haciendo un montón de pequeñas IO leer paliza relacionados con una mezcla de DDT/spacemaps. El sistema es specced para el DDT y tiene alrededor de 3,5 x ~ 4x dedup relación, así que por favor no "DDT es baad", responde, yo lo sé, pero necesita DDT, así que estoy trabajando para minimizar el resto de lectura-thrash asegurándose de que al menos que el ddt/spacemap metadatos es casi todos los retenidos en el ARCO una vez que el sistema se caliente.

La manera en que yo estoy esperando que la memoria RAM a utilizar es - DDT es de unos 35-40 GB, y he usado sysctls para reservar 85GB de ARCO para los metadatos. También he establecido spacemap tamaño de bloque a un tamaño mayor, y defragged la piscina (copiado a la nueva piscina), que parece que está ayudando mucho. Pero porque no puedo ver los valores de cuánto de los diferentes tipos de metadatos se carga o expulsados (ddt/spacemap/otros), y no hay herramientas para establecer ZFS ddt tamaño de bloque o de la precarga del DDT entradas de ARCO, estoy en la oscuridad en cuanto al impacto exacto, o si más de RAM te va a ayudar, o de otras maneras sistemáticas para hacerlo mejor.

He buscado soluciones. zdb, arc-stats etc no exponen un desglose de los metadatos de ARCO situación, sólo una suma fija para todos los metadatos.

Hay una forma sencilla de obtener un sentido de lo que está pasando, con el fin de evaluar la posibilidad de que más de RAM te va a ayudar, incluso si no es precisa o para obtener algunos de los mejores sentido (aunque impreciso) de desglose de las cantidades de ddt/spacemap/"otros" metadatos MRU/MFU ser cargado/caché/desalojado?

2voto

Dan Puntos 186

No creo que haya ninguna herramienta incorporada como arcstats para este propósito, especialmente desde que está en FreeBSD, que supongo que no tiene mdb (de illumos / Solaris).

La solución más simple sería el de dar un poco más de RAM y ver si eso ayuda. Por supuesto, eso cuesta dinero, pero puede ser menos costoso que el tiempo tratando de averiguar la respuesta (si usted está siendo pagado por este trabajo).

La siguiente cosa más fácil que intentar, sería ocupar el ARCO de los límites de memoria mientras se ejecuta una prueba de carga de trabajo. El impacto que estos tienen sobre las cargas de trabajo a menudo es poco intuitivo, así que mi recomendación sería empezar con la configuración predeterminada, y poco a poco cambiar las cosas para que sea más complicado. Es posible que, por ejemplo, cuando se trató de establecer el mínimo de memoria reservada para los metadatos, en realidad establecer el máximo por error, lo que provocaría que paliza como la que usted describe - así que asegúrese de leer la "docs" para estas opciones cuidadosamente.

Por último, si eres un poco intrépido y bastante confianza en su capacidad para analizar datos complejos para determinar la respuesta a su pregunta, usted puede también utilizar DTrace para esto. Esta sonda se activa cada vez que un error de caché que sucede en el ARCO:

DTRACE_PROBE4(arc__miss, arc_buf_hdr_t *, hdr, blkptr_t *, bp,
    uint64_t, lsize, zbookmark_phys_t *, zb);

Así, se podría escribir un D de secuencia de comandos que está a la escucha de la :::arc_miss de la sonda, y el uso de args[0], args[1], y / o la traza de averiguar qué tipo de solicitudes que han desaparecido de la memoria caché.

Sospecho que el camino más fácil es mirar el tipo de la blockptr_t en args[1]. Por desgracia eso es algo molesto para extraer, porque es parte de un campo de bits. La definición del bloque puntero de objeto se puede encontrar aquí, y usted quiere que su DTrace secuencia de comandos para la salida de la misma cosa que BP_GET_TYPE(args[1]) sería la salida, y luego interpretar esos valores mediante la comparación de los valores de dmu_object_type desde aquí.

Alternativamente, me puede recomendar un simple script que potencialmente es más involucrados a interpretar. Iba a recoger la traza cada vez que la sonda de incendios, y entonces usted puede post-proceso de los rastros para hacer una llama gráfico para facilitar la interpretación. Los nombres de método en ZFS son bastante descriptivo en general (al menos, todos ellos tienen acrónimos, por ejemplo ddt "dedup tabla" que usted puede buscar en línea), por lo que probablemente, usted puede averiguar lo que las personas que llaman están haciendo de esa manera.

Si hay un montón de valores que muestra que no son de archivo o de directorio de datos, usted probablemente necesita para mantener a más de metadatos en la memoria caché. Usted puede hacer que sea dedicando más espacio para que el uso de los ajustadores, o dándole a la máquina más de RAM.

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: