¿Puedo configurar mi sistema Linux para un almacenamiento en caché más agresivo del sistema de archivos?

No estoy preocupado por el uso de RAM (ya que tengo suficiente) ni por la pérdida de datos en caso de un apagado accidental (ya que mi energía está respaldada, el sistema es confiable y los datos no son críticos). Pero hago mucho procesamiento de archivos y podría usar un aumento de rendimiento.

Es por eso que me gustaría configurar el sistema para que use más RAM para el almacenamiento en caché de lectura y escritura del sistema de archivos, para captar archivos agresivamente (por ejemplo, leer todo el archivo al que accede una aplicación en caso de que el archivo sea de un tamaño razonable o al menos leer de antemano una gran parte de lo contrario) y eliminar los buffers de escritura con menos frecuencia. ¿Cómo lograr esto (puede ser posible)?

Uso los sistemas de archivos ext3 y ntfs (¡uso mucho ntfs!) Con XUbuntu 11.10 x86.

Mejorar el rendimiento de la memoria caché del disco en general es más que solo aumentar el tamaño de la memoria caché del sistema de archivos a menos que todo el sistema se ajuste a la RAM, en cuyo caso debe usar la unidad de RAM ( tmpfses bueno porque permite volver al disco si necesita la RAM en algún caso) para el almacenamiento en tiempo de ejecución (y quizás una secuencia de comandos initrd para copiar el sistema desde el almacenamiento a la unidad RAM al inicio).

No dijiste si tu dispositivo de almacenamiento es SSD o HDD. Esto es lo que he encontrado que funciona para mí (en mi caso sdaes un HDD montado en /homey sdbSSD montado en /).

Primero optimice la parte load-stuff-from-storage-to-cache:

Aquí está mi configuración para HDD (asegúrese de que AHCI + NCQ esté habilitado en BIOS si tiene conmutadores):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Vale la pena señalar que el caso de HDD es alto fifo_expire_async(generalmente de escritura) y largo slice_syncpara permitir que un solo proceso obtenga un alto rendimiento (configurado slice_syncen un número más bajo si encuentra situaciones en las que varios procesos esperan algunos datos del disco en paralelo). El slice_idlesiempre es un compromiso para establecer unidades de disco duro, pero en algún lugar en el rango de 3-20 debería estar bien en función del uso del disco y firmware del disco. Prefiero apuntar a valores bajos, pero establecerlo demasiado bajo destruirá su rendimiento. La quantumconfiguración parece afectar mucho el rendimiento, pero trate de mantenerlo lo más bajo posible para mantener la latencia en un nivel razonable. Establecer quantumdemasiado bajo destruirá el rendimiento. Los valores en el rango 3-8 parecen funcionar bien con discos duros. La peor latencia de caso para una lectura es ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms si he entendido el comportamiento del núcleo correctamente. El asíncrono es utilizado principalmente por las escrituras y, dado que está dispuesto a retrasar la escritura en el disco, configure ambas slice_async_rqy slice_asyncnúmeros muy bajos. Sin embargo, establecer slice_async_rqun valor demasiado bajo puede detener las lecturas porque las escrituras ya no se pueden retrasar después de las lecturas. Mi configuración intentará escribir datos en el disco como máximo después de 10 segundos después de que los datos se han pasado al núcleo, pero ya que se puede tolerar la pérdida de datos sobre la pérdida de potencia también fijados fifo_expire_asynca 3600000decir que 1 hora está bien por el retraso en el disco. Sin slice_asyncembargo, solo mantenga el nivel bajo, porque de lo contrario puede obtener una latencia de lectura alta.

El hdparmcomando es necesario para evitar que AAM elimine gran parte del rendimiento que permite AHCI + NCQ. Si su disco hace demasiado ruido, omita esto.

Aquí está mi configuración para SSD (serie Intel 320):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Aquí vale la pena señalar los valores bajos para diferentes configuraciones de corte. La configuración más importante para un SSD es la slice_idleque debe establecerse en 0-1. Establecerlo en cero mueve todas las decisiones de pedido a NCQ nativo, mientras que establecerlo en 1 permite que el núcleo ordene solicitudes (pero si el NCQ está activo, el hardware puede anular parcialmente el pedido del núcleo). Pruebe ambos valores para ver si puede ver la diferencia. Para la serie Intel 320, parece que el establecimiento slide_idlede 0da el mejor rendimiento, pero poniéndolo a 1da mejor latencia global (la más baja).

Para obtener más información sobre estos ajustables, consulte http://www.linux-mag.com/id/7572/ .

Ahora que hemos configurado el kernel para cargar cosas desde el disco a la memoria caché con un rendimiento razonable, es hora de ajustar el comportamiento de la memoria caché:

Según los puntos de referencia que he hecho, no me molestaría en configurar la lectura anticipada blockdeven absoluto. La configuración predeterminada del kernel está bien.

Configure el sistema para que prefiera intercambiar datos de archivos sobre el código de la aplicación (esto no importa si tiene suficiente RAM para mantener todo el sistema de archivos y todo el código de la aplicación y toda la memoria virtual asignada por las aplicaciones en la RAM). Esto reduce la latencia para intercambiar entre diferentes aplicaciones sobre la latencia para acceder a archivos grandes desde una sola aplicación:

echo 15 > /proc/sys/vm/swappiness

Si prefiere mantener las aplicaciones casi siempre en la RAM, puede configurar esto en 1. Si configura esto en cero, el núcleo no se intercambiará a menos que sea absolutamente necesario para evitar OOM. Si tenía memoria limitada y trabajaba con archivos grandes (p. Ej., Edición de video HD), entonces podría tener sentido establecer esto cerca de 100.

Hoy en día (2017) prefiero no tener ningún intercambio si tienes suficiente RAM. Al no tener intercambio, generalmente perderá 200-1000 MB de RAM en una máquina de escritorio de larga ejecución. Estoy dispuesto a sacrificar eso para evitar la latencia del peor de los casos (intercambiando el código de la aplicación cuando la RAM está llena). En la práctica, esto significa que prefiero OOM Killer a intercambiar. Si permite / necesita intercambiar, es posible que desee aumentar /proc/sys/vm/watermark_scale_factortambién para evitar cierta latencia. Sugeriría valores entre 100 y 500. Puede considerar esta configuración como el uso de CPU comercial para una latencia de intercambio más baja. El valor predeterminado es 10 y el máximo posible es 1000. Un valor más alto debería (de acuerdo con la documentación del kernel ) dar como resultado un mayor uso de la CPU para los kswapdprocesos y una menor latencia de intercambio general.

Luego, dígale al kernel que prefiera mantener la jerarquía de directorios en la memoria sobre el contenido del archivo en caso de que se necesite liberar algo de RAM (nuevamente, si todo encaja en la RAM, esta configuración no hace nada):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Ajuste vfs_cache_pressureun valor bajo tiene sentido porque en la mayoría de los casos, el núcleo necesita conocer la estructura del directorio antes de poder usar el contenido del archivo de la memoria caché y vaciar la memoria caché del directorio demasiado pronto hará que la memoria caché del archivo sea casi inútil. Considere ir a 1 con esta configuración si tiene muchos archivos pequeños (mi sistema tiene alrededor de 150,000 fotos de 10 megapíxeles y cuenta como un sistema de "muchos archivos pequeños"). Nunca lo ajuste a cero o la estructura del directorio siempre se mantiene en la memoria, incluso si el sistema se está quedando sin memoria. Establecer esto en gran valor es sensato solo si tiene solo unos pocos archivos grandes que se vuelven a leer constantemente (nuevamente, la edición de video HD sin suficiente RAM sería un ejemplo). La documentación oficial del kernel dice que "

Excepción: si tiene una cantidad realmente masiva de archivos y directorios y rara vez toca / lee / enumera todos los archivos con una configuración vfs_cache_pressuresuperior a 100, puede ser sabio. Esto solo se aplica si no tiene suficiente RAM y no puede mantener toda la estructura de directorios en RAM y aún tiene suficiente RAM para la caché de archivos y procesos normales (por ejemplo, servidor de archivos de toda la empresa con mucho contenido de archivo). Si siente que necesita aumentar por vfs_cache_pressureencima de 100, está ejecutando sin suficiente RAM. El aumento vfs_cache_pressurepuede ayudar, pero la única solución real es obtener más RAM. Habiendo vfs_cache_pressureestablecido en alto número sacrifica el rendimiento promedio para tener un rendimiento más estable en general (es decir, se puede evitar muy mal comportamiento peor caso, pero tener que lidiar con un peor rendimiento global).

Finalmente, dígale al núcleo que use hasta el 99% de la RAM como caché para las escrituras e indique al núcleo que use hasta el 50% de la RAM antes de ralentizar el proceso que está escribiendo (el valor predeterminado dirty_background_ratioes 10). Advertencia: Yo personalmente no haría esto, pero usted afirmó tener suficiente RAM y está dispuesto a perder los datos.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

Y diga que 1h de retraso de escritura está bien incluso para comenzar a escribir cosas en el disco (de nuevo, no haría esto):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Si coloca todo eso /etc/rc.locale incluye el siguiente al final, todo estará en caché lo antes posible después del arranque (solo haga esto si su sistema de archivos realmente cabe en la RAM):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

O una alternativa un poco más simple que podría funcionar mejor (solo caché /homey /usr, solo haga esto si su /homey /usrrealmente encaja en RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

En primer lugar, NO le recomiendo que continúe usando NTFS, ya que la implementación de NTFS en Linux sería un problema de rendimiento y seguridad en cualquier momento.

Hay varias cosas que puedes hacer:

• use algunos fs más nuevos como ext4obtrfs
• intenta cambiar tu planificador io, por ejemplo bfq
• apagar el intercambio
• usar algún precargador automático como preload
• usar algo como systemdprecargar mientras arranca
• ... y algo más

Quizás quieras probarlo :-)

Leer por adelantado:

En sistemas de 32 bits:

blockdev --setra 8388607 /dev/sda

En sistemas de 64 bits:

blockdev --setra 4294967295 /dev/sda

Escribe detrás del caché:

echo 100 > /proc/sys/vm/dirty_ratio

Esto usará hasta el 100% de su memoria libre como caché de escritura.

O puede salir y usar tmpfs. Esto solo es relevante si tiene suficiente RAM. Pon esto en /etc/fstab. Reemplace 100G con la cantidad de RAM física.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Entonces:

mkdir /mnt/tmpfs; mount -a

Luego use / mnt / tmpfs.

Puede establecer el tamaño de lectura anticipada con blockdev --setra sectors /dev/sda1, donde sectores es el tamaño que desea en sectores de 512 bytes.

Mi configuración asesina es muy simple y muy efectiva:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

La explicación de la documentación del kernel :

vfs_cache_pressure

Controla la tendencia del kernel a recuperar la memoria que se utiliza para almacenar en caché los objetos de directorio e inodo.

Con el valor predeterminado de vfs_cache_pressure = 100, el núcleo intentará reclamar dentries e inodes a una tasa "justa" con respecto a pagecache y swapcache reclaman. La disminución de vfs_cache_pressure hace que el kernel prefiera retener caché de dentry e inode. Cuando vfs_cache_pressure = 0, el núcleo nunca reclamará dentries e inodos debido a la presión de la memoria y esto puede conducir fácilmente a condiciones de falta de memoria. El aumento de vfs_cache_pressure más allá de 100 hace que el núcleo prefiera reclamar dentries e inodes.

vfs_cache_pressure en 2000 hace que la mayor parte de la computación ocurra en la RAM y las escrituras de disco muy tardías.

No está relacionado con el almacenamiento en caché de escritura, pero está relacionado con las escrituras:

• Para un sistema ext4, puede deshabilitar el diario por completo

  Esto reducirá el número de escrituras de disco para cualquier actualización en particular, pero puede dejar que el sistema de archivos tenga un estado inconsistente después de un apagado inesperado, que requiera un fsck o algo peor.

Para evitar que las lecturas de disco activen escrituras de disco:

• Montar con el relatime o la noatime opción

  Cuando lee un archivo, los metadatos del "último tiempo de acceso" para ese archivo generalmente se actualizan. La noatimeopción deshabilitará ese comportamiento. Esto reduce las escrituras de disco innecesarias, pero ya no tendrá esos metadatos. Algunas distribuciones (por ejemplo, Manjaro) han adoptado esto como el valor predeterminado en todas las particiones (probablemente para aumentar la vida útil de los SSD de modelos anteriores).

  relatimeactualiza el tiempo de acceso con menos frecuencia, de acuerdo con las heurísticas que ayudan a admitir aplicaciones que utilizan el atime. Este es el valor predeterminado en Red Hat Enterprise Linux.

Otras opciones:

• En los comentarios anteriores, Mikko compartió la posibilidad de montar con la opción de nobarrier . Pero Ivailo citó a RedHat que advierte contra eso. ¿Qué tanto quieres ese 3% extra?