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)&