Linux:
Il kernel Linux ha un'ottima implementazione per la questione e ha molte funzionalità/impostazioni intese a gestire le risorse per il processo in esecuzione (su governatori della CPU, sysctl o cgroup), in tale situazione è necessario ottimizzare tali impostazioni insieme alla regolazione dello scambio (se necessario) consigliato, in pratica andrai ad adattare la modalità di funzionamento predefinita al tuo elettrodomestico.
Benchmark, stress test e analisi della situazione dopo l'applicazione delle modifiche sono un must soprattutto sui server di produzione. Il miglioramento delle prestazioni può essere molto importante quando le impostazioni del kernel vengono adattate all'utilizzo necessario, d'altra parte ciò richiede test e una buona comprensione delle diverse impostazioni che richiede tempo per un amministratore.
Linux utilizza i governatori per bilanciare il carico delle risorse della CPU tra l'applicazione in esecuzione, sono disponibili molti governatori; a seconda del kernel della tua distribuzione, alcuni governatori potrebbero non essere disponibili (è possibile ricostruire il kernel per aggiungere governatori mancanti o non originali). puoi controllare qual è l'attuale governatore, cambiarlo e, cosa più importante in questo caso, regolarne le impostazioni.
Documentazioni aggiuntive:lettura, guida, domanda simile, ridimensionamento della frequenza, scelta del regolatore, regolatore delle prestazioni e cpufreq.
SistCtl:
Sysctl è uno strumento per esaminare e modificare i parametri del kernel in fase di esecuzione, le modifiche possono essere rese permanenti con il file di configurazione /etc/sysctl.conf , questa è una parte importante di questa risposta poiché molte impostazioni del kernel possono essere modificate con Sysctl, un elenco completo delle impostazioni disponibili può essere visualizzato con il comando sysctl -a , i dettagli sono disponibili su questo e questo articolo.
Gruppo C:
Il kernel fornisce la caratteristica:gruppi di controllo, che in questa guida sono chiamati con il loro nome più breve cgroups. I cgroup consentono di allocare risorse come il tempo della CPU, la memoria di sistema, la larghezza di banda della rete o combinazioni di queste risorse tra gruppi di attività (processi) definiti dall'utente in esecuzione su un sistema. Puoi monitorare i cgroup che configuri, negare ai cgroup l'accesso a determinate risorse e persino riconfigurare i tuoi cgroup in modo dinamico su un sistema in esecuzione. Il servizio cgconfig (control group config) può essere configurato per avviarsi al momento dell'avvio e ristabilire i tuoi cgroup predefiniti, rendendoli così persistenti dopo i riavvii.
Fonte, ulteriori letture e domanda in merito.
Ariete:
Questo può essere utile se il sistema ha una quantità limitata di ram, altrimenti puoi disabilitare lo swap per utilizzare principalmente la ram. Il sistema di swap può essere regolato per processo o con le impostazioni di swappiness. Se necessario, le risorse (ram) possono essere limitate per processo con ulimit (usato anche per limitare altre risorse).
Disco:
Le impostazioni di I/O del disco (I/O Scheduler) possono essere modificate così come la dimensione del cluster.
Alternative:
Altri strumenti come nice, cpulimit, cpuset, taskset o ulimit possono essere usati come alternativa per la questione.
La migliore risposta a questo è "succhialo e guarda" ... esegui alcuni stress test e vedi cosa dà i migliori risultati. Questo perché sfumature minime nel comportamento dei tuoi thread possono causare differenze nelle prestazioni.
Quanto segue in gran parte basato sulla mia esperienza...
Da dove iniziare?
La capacità di Linux di impedire ai thread di morire di fame è piuttosto buona. Non significa necessariamente che ogni thread riceverà una quota uniforme della torta, ma tutti i thread avranno almeno un po' di torta. Se hai due thread che si contendono il tempo della CPU... diciamo che uno cerca di usare il 100% della CPU e un altro che prova a usare solo il 10%... allora non sorprenderti se questo si bilancia al 91% e al 9% o da qualche parte attorno a questo.
Le prestazioni complessive possono ridursi dove una particolare risorsa è pesantemente sottoscritto in eccesso. Ciò è particolarmente vero per l'IO su disco su dischi rigidi rotanti. La testa deve spostarsi fisicamente (cercare) tra i punti del disco e continuo l'oscillazione tra file diversi può causare un rallentamento significativo. Ma questo effetto è spesso abbastanza piccolo se un thread è fortemente legato all'IO e un altro vorrebbe fare un po' IO.
Insieme, queste due cose significano che spesso è meglio avere il 20% di abbonamento in più che il 20% di abbonamento in meno. In altre parole, non riservare il tempo della CPU per i thread che non stanno tentando di utilizzare molta CPU.
Ad esempio:se hai thread associati alla CPU e thread associati all'IO del disco e hai 8 core e 1 disco rigido, allora inizia con 8 thread associati alla CPU e un thread associato all'IO del disco rigido. 7 e 1 potrebbero lasciare un core inattivo per la maggior parte del tempo. 8 e 1 quasi certamente non faranno morire di fame il thread HD, il che significa che utilizzerai completamente sia HD che CPU.
Il pericolo di thread di breve durata
Fai solo attenzione che Linux può lottare con molto di fili di breve durata. Questo è più ovvio con tentativi deliberati di danneggiare un sistema. Ma la generazione continua di thread/processi può spingere Linux a comportarsi male.
Nella tua domanda hai descritto thread di lavoro dedicati che suonano come thread di lunga durata. Sembra l'approccio giusto.
L'effetto autobus di Londra
Aspetti mezz'ora per un autobus, poi ne arrivano 5 in una volta. Ciò accade perché i passeggeri che salgono sul bus anteriore lo rallentano. La mancanza di passeggeri sugli autobus successivi li accelera causando un effetto di raggruppamento.
Lo stesso problema può esistere nel threading, specialmente con i thread che si contendono le risorse. Se hai thread che si alternano in modo prevedibile tra le attività, ad esempio leggendo da un disco e poi scrivendo su un altro, allora potrebbero tendere a raggrupparsi piuttosto che a disperdersi stocasticamente come ci si potrebbe aspettare. Quindi una risorsa può rallentare l'uso di un'altra. Per questo motivo a volte può essere meglio suddividere ulteriormente i compiti di un thread.
cgroups
Eviterò di entrare troppo nei dettagli. Ma dovrei menzionare che Linux ha una capacità chiamata "cgroups" che ti consente di raggruppare i processi e limitare le loro risorse collettive. Questo può essere molto utile per ottimizzare ulteriormente le prestazioni.
C'è una breve discussione su di loro qui. Ma ti consiglierei di dedicare un po' di tempo a Google per vedere tutte le loro capacità perché potrebbero aiutarti a lungo termine.