Linux:
El kernel de Linux tiene una gran implementación para el asunto y tiene muchas características/configuraciones destinadas a administrar los recursos para el proceso en ejecución (sobre gobernadores de CPU, sysctl o cgroup), en tal situación, es necesario ajustar esas configuraciones junto con el ajuste de intercambio (si es necesario). recomendado, básicamente estarás adaptando el modo de funcionamiento por defecto a tu electrodoméstico.
Las pruebas comparativas, las pruebas de estrés y el análisis de la situación después de aplicar los cambios son imprescindibles, especialmente en los servidores de producción. La ganancia de rendimiento puede ser muy importante cuando la configuración del núcleo se ajusta al uso necesario; por otro lado, esto requiere pruebas y una buena comprensión de las diferentes configuraciones, lo que requiere mucho tiempo para un administrador.
Linux usa gobernadores para equilibrar la carga de los recursos de la CPU entre la aplicación en ejecución, muchos gobernadores están disponibles; dependiendo del kernel de su distribución, es posible que algunos gobernadores no estén disponibles (se puede reconstruir el kernel para agregar gobernadores que faltan o que no están aguas arriba). puede verificar cuál es el gobernador actual, cambiarlo y, lo que es más importante, en este caso, ajustar su configuración.
Documentaciones adicionales:lectura, guía, pregunta similar, escalado de frecuencia, elección de gobernador, gobernador de rendimiento y cpufreq.
Control del sistema:
Sysctl es una herramienta para examinar y cambiar los parámetros del kernel en tiempo de ejecución, los ajustes se pueden hacer permanentes con el archivo de configuración /etc/sysctl.conf , esta es una parte importante de esta respuesta, ya que muchas configuraciones del kernel se pueden cambiar con Sysctl, se puede mostrar una lista completa de las configuraciones disponibles con el comando sysctl -a , los detalles están disponibles en este y este artículo.
Grupo C:
El kernel proporciona la característica:grupos de control, que en esta guía se denominan por su nombre más corto cgroups. Los Cgroups le permiten asignar recursos como tiempo de CPU, memoria del sistema, ancho de banda de la red o combinaciones de estos recursos entre grupos de tareas (procesos) definidos por el usuario que se ejecutan en un sistema. Puede monitorear los cgroups que configura, denegar el acceso de cgroups a ciertos recursos e incluso reconfigurar sus cgroups dinámicamente en un sistema en ejecución. El servicio cgconfig (configuración del grupo de control) se puede configurar para iniciarse en el momento del arranque y restablecer sus cgroups predefinidos, haciéndolos así persistentes entre reinicios.
Fuente, lectura adicional y pregunta sobre el asunto.
Carnero:
Esto puede ser útil si el sistema tiene una cantidad limitada de memoria RAM; de lo contrario, puede desactivar el intercambio para usar principalmente la memoria RAM. El sistema de intercambio se puede ajustar por proceso o con la configuración de intercambio. Si es necesario, los recursos (ram) se pueden limitar por proceso con ulimit (también se usa para limitar otros recursos).
Disco:
La configuración de E/S del disco (Programador de E/S) se puede cambiar, así como el tamaño del clúster.
Alternativas:
Se pueden utilizar otras herramientas como nice, cpulimit, cpuset, tasket o ulimit como alternativa.
La mejor respuesta a esto es "chupar y ver"... realizar algunas pruebas de estrés y ver qué da los mejores resultados. Esto se debe a que pequeños matices en el comportamiento de sus subprocesos pueden causar diferencias en el rendimiento.
Lo siguiente basado en gran medida en mi propia experiencia...
¿Por dónde empezar?
La capacidad de Linux para evitar que los subprocesos se queden sin recursos es bastante buena. No significa necesariamente que cada subproceso obtendrá una parte equitativa del pastel, pero todos los subprocesos al menos obtendrán un poco de pastel. Si tiene dos subprocesos que compiten por el tiempo de CPU... digamos que uno intenta usar el 100 % de la CPU y otro intenta usar solo el 10 %... entonces no se sorprenda si eso se equilibra en 91 % y 9 % o en alguna parte alrededor de eso.
El rendimiento general puede reducir el lugar donde un recurso en particular es muy sobre suscrito. Esto es especialmente cierto para el disco IO en discos duros giratorios. La cabeza tiene que moverse físicamente (buscar) entre lugares en el disco y continuamente oscilar entre diferentes archivos puede causar una ralentización significativa. Pero este efecto es a menudo bastante pequeño si un subproceso está muy ligado a IO y a otro le gustaría hacer un poco. IO.
Juntas, estas dos cosas significan que a menudo es mejor tener un 20 % de suscripciones superiores a un 20 % de suscripciones inferiores. En otras palabras, no reserve tiempo de CPU para subprocesos que no intentan usar mucha CPU.
Por ejemplo:si tiene subprocesos vinculados a la CPU y tenía subprocesos vinculados a la E/S del disco y tiene 8 núcleos y 1 disco duro, entonces comience con 8 subprocesos vinculados a la CPU y un subproceso vinculado a la E/S del disco duro. 7 y 1 podrían dejar un núcleo inactivo la mayor parte del tiempo. Es casi seguro que 8 y 1 no privarán al subproceso HD, lo que significa que usará HD y CPU por completo.
El peligro de los subprocesos de corta duración
Solo tenga cuidado de que Linux puede tener problemas con mucho de hilos de corta duración. Esto es más obvio con los intentos deliberados de dañar un sistema. Pero la generación continua de subprocesos/procesos puede hacer que Linux se comporte mal.
En su pregunta, ha descrito subprocesos de trabajo dedicados que suenan como subprocesos de larga duración. Esto suena como el enfoque correcto.
El efecto autobús de Londres
Esperas media hora a que llegue un autobús y luego llegan 5 a la vez. Esto sucede porque los pasajeros que suben al autobús delantero lo reducen. La falta de pasajeros en los autobuses posteriores los acelera provocando un efecto de aglomeración.
El mismo problema puede existir en subprocesos, especialmente con subprocesos que compiten por recursos. Si tiene subprocesos que alternan de manera predecible entre tareas, por ejemplo, leer de un disco y luego escribir en otro, entonces pueden tender a agruparse en lugar de dispersarse estocásticamente como es de esperar. Entonces, un recurso puede retrasar el uso de otro. Por esta razón, a veces puede ser mejor subdividir aún más las tareas de un hilo.
cgrupos
Evitaré entrar en demasiados detalles. Pero debo mencionar que Linux tiene una capacidad llamada "cgroups" que le permite agrupar procesos y limitar sus recursos colectivos. Esto puede ser muy útil para mejorar el rendimiento.
Hay una breve discusión de ellos aquí. Pero te aconsejo que pases un poco de tiempo en Google para ver su capacidad completa porque pueden ayudarte a largo plazo.