Linux :
Le noyau Linux a une excellente implémentation en la matière et possède de nombreuses fonctionnalités/paramètres destinés à gérer les ressources pour le processus en cours d'exécution (sur les gouverneurs CPU, sysctl ou cgroup), dans une telle situation, régler ces paramètres avec l'ajustement du swap (si nécessaire) est recommandé, en gros vous adapterez le mode de fonctionnement par défaut à votre appareil.
Benchmark, stress tests et analyse de situation après application des changements sont indispensables surtout sur les serveurs de production. Le gain de performances peut être très important lorsque les paramètres du noyau sont ajustés à l'usage nécessaire, par contre cela nécessite des tests et une bonne compréhension des différents paramètres ce qui est chronophage pour un admin.
Linux utilise des gouverneurs pour équilibrer la charge des ressources CPU entre l'application en cours d'exécution, de nombreux gouverneurs sont disponibles ; selon le noyau de votre distribution, certains gouverneurs peuvent ne pas être disponibles (la reconstruction du noyau peut être effectuée pour ajouter des gouverneurs manquants ou non en amont). vous pouvez vérifier quel est le gouverneur actuel, le modifier et, plus important encore, dans ce cas, régler ses paramètres.
Documentations complémentaires :lecture, guide, question similaire, mise à l'échelle fréquentielle, choix du gouverneur, le gouverneur de performance et cpufreq.
SysCtl :
Sysctl est un outil pour examiner et modifier les paramètres du noyau lors de l'exécution, les ajustements peuvent être rendus permanents avec le fichier de configuration /etc/sysctl.conf , c'est une partie importante de cette réponse car de nombreux paramètres du noyau peuvent être modifiés avec Sysctl, une liste complète des paramètres disponibles peut être affichée avec la commande sysctl -a , les détails sont disponibles sur ceci et cet article.
Groupe C :
Le noyau fournit la fonctionnalité :les groupes de contrôle, qui sont appelés par leur nom plus court cgroups dans ce guide. Les groupes de contrôle vous permettent d'allouer des ressources telles que le temps CPU, la mémoire système, la bande passante du réseau ou des combinaisons de ces ressources parmi des groupes de tâches (processus) définis par l'utilisateur s'exécutant sur un système. Vous pouvez surveiller les groupes de contrôle que vous configurez, refuser l'accès des groupes de contrôle à certaines ressources et même reconfigurer dynamiquement vos groupes de contrôle sur un système en cours d'exécution. Le service cgconfig (configuration du groupe de contrôle) peut être configuré pour démarrer au démarrage et rétablir vos cgroups prédéfinis, les rendant ainsi persistants lors des redémarrages.
Source, lectures complémentaires et question sur le sujet.
Ram :
Cela peut être utile si le système dispose d'une quantité limitée de RAM, sinon vous pouvez désactiver le swap pour utiliser principalement la RAM. Le système d'échange peut être ajusté par processus ou avec les paramètres d'échange. Si nécessaire, les ressources (ram) peuvent être limitées par processus avec ulimit (également utilisé pour limiter d'autres ressources).
Disque :
Les paramètres d'E/S du disque (planificateur d'E/S) peuvent être modifiés ainsi que la taille du cluster.
Alternatives :
D'autres outils comme nice, cpulimit, cpuset, taskset ou ulimit peuvent être utilisés comme alternative en la matière.
La meilleure réponse à cela est "suce et tu verras"... effectuez des tests de résistance et voyez ce qui donne les meilleurs résultats. En effet, des nuances très mineures dans le comportement de vos threads peuvent entraîner des différences de performances.
Ce qui suit est largement basé sur ma propre expérience...
Par où commencer ?
La capacité de Linux à empêcher les threads de mourir de faim est plutôt bonne. Cela ne signifie pas nécessairement que chaque thread obtiendra une part égale du gâteau, mais tous les threads recevront au moins un peu de gâteau. Si vous avez deux threads en concurrence pour le temps CPU... disons un essayant d'utiliser 100% CPU et un autre essayant d'utiliser seulement 10%... alors ne soyez pas surpris si cela s'équilibre à 91% et 9% ou quelque part autour de ça.
Les performances globales peuvent réduire où une ressource particulière est fortement plus souscrit. Cela est particulièrement vrai pour les E/S disque sur les disques durs en rotation. La tête doit physiquement se déplacer (rechercher) entre les emplacements sur le disque et continu osciller entre différents fichiers peut entraîner un ralentissement important. Mais cet effet est souvent assez faible si un thread est fortement lié aux E/S et qu'un autre aimerait en faire un peu IO.
Ensemble, ces deux éléments signifient qu'il est souvent préférable d'être 20 % sursouscrit que 20 % sous-souscrit. En d'autres termes, ne réservez pas de temps CPU pour les threads qui n'essaient pas d'utiliser beaucoup de CPU.
Par exemple :si vous avez des threads liés au processeur et des threads liés aux E/S de disque et que vous avez 8 cœurs et 1 disque dur, alors commencez par 8 threads liés au processeur et un thread lié aux E/S du disque dur. 7 et 1 peuvent simplement laisser un cœur inactif la plupart du temps. 8 et 1 n'affameront certainement pas le thread HD, ce qui signifie que vous utiliserez pleinement à la fois la HD et le CPU.
Le danger des threads de courte durée
Méfiez-vous simplement que Linux peut lutter avec beaucoup de fils de courte durée. Ceci est plus évident avec des tentatives délibérées d'endommager un système. Mais la génération continue de threads/processus peut pousser Linux à mal se comporter.
Dans votre question, vous avez décrit des threads de travail dédiés qui ressemblent à des threads de longue durée. Cela semble être la bonne approche.
L'effet bus de Londres
Vous attendez une demi-heure pour un bus puis 5 arrivent en même temps. Cela se produit parce que les passagers qui montent dans le bus avant le ralentissent. Le manque de passagers dans les derniers bus les accélère, provoquant un effet de regroupement.
Le même problème peut exister dans les threads, en particulier avec les threads en concurrence pour les ressources. Si vous avez des threads alternant de manière prévisible entre les tâches, par exemple la lecture d'un disque puis l'écriture sur un autre, ils peuvent avoir tendance à se regrouper plutôt qu'à se disperser de manière stochastique comme vous pouvez vous y attendre. Ainsi, une ressource peut ralentir l'utilisation d'une autre. Pour cette raison, il peut parfois être préférable de subdiviser davantage les tâches d'un thread.
cgroups
J'éviterai d'entrer dans trop de détails. Mais je dois mentionner que Linux a une capacité appelée "cgroups" qui vous permet de regrouper des processus et de limiter leurs ressources collectives. Cela peut être très utile pour optimiser les performances.
Il y a une courte discussion à leur sujet ici. Mais je vous conseillerais de passer un peu de temps sur google pour voir leur pleine capacité car ils peuvent vous aider à long terme.