Este es un seguimiento de:Escritura en red de alta velocidad con almacenamiento de gran capacidad. La configuración ha cambiado notablemente.
Tengo un grupo con uno individual raid-z2con 6 unidades, todas las unidades Exos X18 CMR. Usando fiopruebas manuales, sé que la matriz puede soportar alrededor de 800 MB/s de escrituras secuenciales en promedio, lo cual está bien y en línea con el rendimiento esperado de esta matriz. La máquina es una Ryzen5 Pro 2400 GE (4C/8T, 3,8 GHz boost) con 32G ECC RAM, unidad de sistema/arranque NVMe y 2 puertos Ethernet de 10 Gbps (Intel x550-T2). Estoy ejecutando un sistema Arch actualizado con zfs 2.1.2-1.
Mi caso de uso es un archivo de video de video comprimido, en su mayoría grande (~30G), de escritura una vez, lectura una vez. He deshabilitado atime, configurado recordsize=1M, configurado compressios=offy dedup=offcomo los datos son realmente incompresibles y las pruebas mostraron un peor rendimiento que compression=lz4a offpesar de lo que decía Internet y no hay datos duplicados por diseño. Este grupo se comparte a través de la red a través de Samba. Sintonicé mi red y Samba hasta el punto en que la transferencia desde NVMe NTFS en una máquina Windows a NVMe ext4 alcanza 1 GB/s, es decir, razonablemente cerca de saturar el enlace de 10 Gbps con tramas gigantes de 9K.
Aquí es donde me encuentro con problemas. Quiero poder transferir un archivo de video completo de 30G a 1 GB/s a la raid-z2matriz que solo admite escritura secuencial de 800 MB/s. Mi plan es utilizar las páginas sucias basadas en RAM para absorber el excedente y dejar que se descargue en el disco después de que se "completa" la transferencia en el lado del cliente. Pensé que todo lo que necesitaría son (1024-800)*30~=7Gpáginas sucias en la RAM que puedan eliminarse al disco aproximadamente 10 segundos después de que se complete la transferencia. Entiendo las implicaciones de esto para la integridad de los datos y el riesgo es aceptable ya que siempre puedo transferir el archivo nuevamente más tarde por hasta un mes en caso de que una pérdida de energía provoque que el archivo se pierda o quede incompleto.
Sin embargo, no puedo hacer que ZFS se comporte de la manera que espero... He editado mi /etc/modprobe.d/zfs.confarchivo de esta manera:
options zfs zfs_dirty_data_max_max=25769803776
options zfs zfs_dirty_data_max_max_percent=50
options zfs zfs_dirty_data_max=25769803776
options zfs zfs_dirty_data_max_percent=50
options zfs zfs_delay_min_dirty_percent=80
Ejecuté el mkinitcpio -Pcomando apropiado para actualizar mi initramfs y confirmé que la configuración se aplicó después de reiniciar:
# arc_summary | grep dirty_data
zfs_dirty_data_max 25769803776
zfs_dirty_data_max_max 25769803776
zfs_dirty_data_max_max_percent 50
zfs_dirty_data_max_percent 50
zfs_dirty_data_sync_percent 20
Es decir, configuré el máximo de páginas sucias en 24G, que es mucho más que los 7G que necesito, y mantengo presionado para comenzar a retrasar las escrituras hasta que se use el 80% de esto. Hasta donde tengo entendido, el grupo debería poder absorber 19G en RAM antes de comenzar a rechazar las escrituras del cliente (Samba) con latencia.
Sin embargo, lo que observo al escribir desde el cliente de Windows es que después de aproximadamente 16 segundos a una velocidad de escritura de ~1 GB/s, el rendimiento de escritura cae por un precipicio ( iostattodavía muestra los discos trabajando duro para vaciar los datos), lo que sólo puedo suponer que es el retroceso. Mecanismo para la limitación de escritura de ZFS. Sin embargo, esto no tiene sentido ya que, al menos, incluso si no se eliminó nada durante los 16 segundos, debería haberse asentado 3 segundos después. Además, se cae una vez más al final, vea la imagen: [ 
][https://i.stack.imgur.com/Yd9WH.png]
Intenté ajustar para zfs_dirty_data_sync_percentcomenzar a escribir antes porque el búfer de páginas sucias es mucho más grande que el predeterminado y también intenté ajustar la escala de io activa para zfs_vdev_async_write_active_{min,max}_dirty_percentque se active antes y acelerar las escrituras más rápido con el buffer sucio grande. Ambos simplemente movieron ligeramente la posición del acantilado, pero no se acercaron a lo que esperaba.
Preguntas:
- ¿He entendido mal cómo funciona el retraso de limitación de escritura?
- ¿Es posible lo que estoy intentando hacer?
- Si es así, ¿qué estoy haciendo mal?
Sí, lo sé, literalmente estoy persiguiendo un par de segundos y nunca recuperaré el esfuerzo invertido en lograrlo. Está bien, es personal entre ZFS y yo en este momento, y una cuestión de principios;)
Respuesta1
También debe aumentar zfs_txg_timeoutel parámetro desde su valor predeterminado actual de 5 segundos a algo así como 7G/0,2G/s = 35s, por lo que configurarlo en 40s debería ser suficiente.
En tus /etc/modprobe.d/zfs.conf:
options zfs zfs_txg_timeout=40
Tenga en cuenta que ARC es exactamente eso, un caché de "lectura" con cero participación en el caché de escritura, así que asegúrese de que su ARC no esté configurado para consumir los 7G+ adicionales de datos que su caché de escritura en bloque debe absorber por flujo de escritura de 30 GB. La caché de escritura para ZFS es como cualquier otra caché de escritura de bloque simple (como el commitparámetro para sistemas de archivos ext4), así que asegúrese de realizar pruebas en no producción para garantizar que no se agote la RAM durante todos los escenarios de transferencia.
Respuesta2
Cada escritura actualizará el ARC si zfs Primarycache = all (predeterminado). Si la latencia de lectura no es importante para los datos que está escribiendo actualmente, le sugiero configurar zfs primariocache=meta.
Respuesta3
Actualmente no tienes suficiente RAM o recursos de almacenamiento para lo que estás buscando.
Diseñe en torno a los niveles de rendimiento de E/S deseados y su rendimiento en el peor de los casos.
Si necesita un rendimiento de 1 GB/s en todas las condiciones para el conjunto de datos de trabajo que se describe, asegúrese de que el número de ejes del disco o el rendimiento de la interfaz sean capaces de admitirlo.