Ejecutar el comando "find" genera carga alta

Ejecuto este comando en un servidor Debian con unidades SSD configuradas como RAID 1:
ionice -c 3 find . -type f -amin -1440 -mmin +1441 -not -path custom/ -print0
En un camino que contiene más de 1.7M archivos y dirs.

Me di cuenta de que cada vez que ejecute este comando los picos de carga del servidor y me preguntaba si hay alguna manera que podría acelerar la velocidad de find por lo que no generará cargas tan altas.
También me preguntaba si aquí están las opciones específicas de SSD para permitir menos generación de carga find

No tiene sentido tratar de mantener la carga baja a toda costa. Lo importante es que su proceso retroceda si algo más importante necesita hacer uso de los recursos que ofrece su sistema.

ionice y nice / renice se puede utilizar para reducir la prioridad de modo que sólo se ejecuta cuando el sistema es por lo demás inactivo.

Esto se reduce a sistema de archivos y ajuste de procfs. Lo que usted explica como carga "alta" es la situación en la que otros procesos normales en el sistema son privados de lecturas y se ven obligados a esperar.

La situación se caracteriza por

  • Alto porcentaje de tiempo de espera de la CPU (cheque% wa superior)
  • Muchos procesos en estado D (sueño ininterrumpido debido a la espera de lecturas de disco)

El uso de noop scheduler no ayuda aquí ya que noop es un simple planificador FIFO, y no puede ayudarte a traer más justicia al juego de acceso al disco. Así que yo sugeriría ir con el planificador de plazo.

La idea del planificador de fechas límite es proyectar el plazo final para ciertas operaciones de E / S de disco, y mientras se mantienen dos colas simples: una para leer y otra para escribir; Puede sintonizar afinidad por lecturas sobre escrituras y tiempos cuánto tiempo puede tolerar que algunos leídos / escritos estén sentados en la cola antes de que se detenga la operación actual y se cubre la tarea de E / S expirada.

Además lo que quieres es tener una gran cantidad de entrada de directorio y archivos de datos inode en memoria RAM, en caché. Este tipo de caché ahorrará mucho IO de disco mientras que atraviesa tal estructura grande del directorio / del archivo.

 grep ^Slab /proc/meminfo 

Esto le dirá cuánta memoria está totalmente dedicada a la entrada de directorio y la caché de archivos. Detalles sobre qué y cómo se divide la memoria de Slab se pueden encontrar en

 /proc/slabinfo 

Puede ejecutar slabtop para obtener estadísticas de uso interactivo.

En última instancia, si usted decide crecer más de este tipo de caché que desea reducir el valor de

Sysctl -w vm.vfs_cache_pressure = 20

Esto se establece por defecto en 100, lo que ocurre cuando el sistema tiene poca memoria intentando reducir bastante la cantidad de memoria utilizada para almacenar en caché d_entry un archivo inodes vs cache de página (es decir, caché de datos de archivo / programa en RAM) Preferirá mantener esos d_entry / inode de archivo de caché y por lo tanto requieren menos operaciones de lectura para volver a leer los mismos datos del disco si se retiró de la memoria caché debido a la presión de la memoria.

Además, para mejorar sus capacidades de lectura de disco le recomiendo aumentar leer adelante.

Blockdev –getra / dev / sda

Blockdev –setra 2048 / dev / sda

Esto debería ayudarle a exprimir algunos IOPS adicionales especialmente si su sistema está haciendo más lecturas que escribe. (Para comprobar que iostat puede ayudar, la primera línea es siempre el uso agregado desde el tiempo de arranque tan fácil de imaginar razones de eso)

A continuación, lo que yo consideraría la afinación es la reducción de tamaño es nr_requests

Echo 32> / sys / block / sda / queue / nr_requests

Haciendo esto, tendrás básicamente lotes más cortos que permitirán más latencia a expensas de algún rendimiento que ganamos allí. Los sistemas con muchos procesos se beneficiarán de esto, ya que será más difícil para un solo proceso dominar la cola de IO, mientras que otros mueren de hambre.

Más información sobre esto también se puede encontrar aquí: hardware RAID controller tuning

Otro caso en el que usted puede tener cargas elevadas es si sus actividades normales del sistema se interrumpen por algún lote de escritura grande intermitente, por ejemplo, descarga de archivos grandes, copia, descompresión. Escritos también pueden saturar fácilmente el disco IO y para combatir estos Yo recomendaría a bajar sintonía después de algo.

Vm.dirty_background_ratio

Vm.dirty_ratio

Cuidado no vas demasiado bajo. Para obtener la idea, puede utilizar la herramienta atop y comprobar las estadísticas de disco donde se puede ver la cantidad de datos sucios normalmente se encuentra en la memoria; Cuántos procesos se benefician de la memoria sucia (columna WCANCL en las estadísticas de disco) y van un poco por encima de las tasas de uso.

Esto ayudará a traer en el mecanismo de núcleos para la reducción de retroceso que intenta ralentizar los procesos que afectan a los sistemas de IO haciendo pesadas escrituras. Para más información