Problemi schedulatore multiprocessore

4 risposte [Ultimo contenuto]

Sab, 06/11/2010 - 19:11

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 931

Domanda niubba, ma questo e' un problema fastidioso che ho da diverso tempo e non sono mai riuscito a risolvere.
Il mio sistema al lavoro e' una Debian 5.0 Lenny con kernel 2.6.26-2-amd64 su un quad-core con quattro gingilli come questo:

cache size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 6144 KB
physical id&nbsp;&nbsp;&nbsp;&nbsp; : 0
siblings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 4
core id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 0
cpu cores&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 4
apicid&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 0
initial apicid&nbsp; : 0
fpu&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes
fpu_exception&nbsp;&nbsp; : yes
cpuid level&nbsp;&nbsp;&nbsp;&nbsp; : 10
wp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : yes
flags&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov

pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm

constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 5323.79
clflush size&nbsp;&nbsp;&nbsp; : 64
cache_alignment : 64
address sizes&nbsp;&nbsp; : 36 bits physical, 48 bits virtual
power management:

Spesso lancio diversi jobs single-thread in background che macinano numeri per qualche ora, e ciascuno di questi tende ad usare il 100% della CPU. Per evitare che il computer diventi poco responsivo, i jobs hanno sempre il piu' alto valore di nice possibile per l'utente (19).
Il problema e' che pur utilizzando il nice, non posso lanciare piu' di 4 di questi jobs senza che il sistema diventi inutilizzabile, le shell ripetano per 10-20 volte i caratteri premuti ("ttttttoooooooooooooppppp"), l'audio vada in gloria, tutto vada a scatti... fino a che non ne ammazzo uno o questo muore di morte naturale.

La mia domanda e': che c'e' di sbagliato nella configurazione del mio sistema? ricordo che mandare piu' jobs in background era la prassi su un singolo processore di una Silicon Graphics o su vecchi sistemi Linux che usavo in passato (non sono sicurissimo di questa seconda parte, in realta'), ma pensavo che ridurre la priorita' di un processo fosse sufficiente a non creare problemi.

Se qualcuno ha suggerimenti, sono ben accetti.
eNjoy

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Lun, 08/11/2010 - 18:02

paolo

(Webmaster)

Offline

Iscritto: 04/10/2004

Messaggi: 1260

Dai un occhiata a questo: http://packages.debian.org/unstable/admin/cpulimit
Comunque ho gli stessi problemi anche io, a me sembra che gli ultimi kernel abbiano dei gravi problemi di starvation, ma non sono ancora riuscito a trovare documentazione in merito.

Paolo Mainardi
CTO Twinbit http://www.twinbit.it
Vice Presidente -- ILDN - Italian Linux DIstro Network

Mer, 10/11/2010 - 20:08

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 931

Gia', e' abbastanza sconsolante. Secondo me e' qualche magagna nella configurazione di default dello schedulatore (non azzardo a dire che ci sono limitazioni nello schedulatore stesso...).
Mi sono messo a leggere qualcosa in giro, sopratutto per il tuning dello schedulatore tramite sysctl, ma c'e' una foresta sconfinata di parametri con un prato inglese (ben rasato, tra l'altro) di documentazione.
L'installer Debian domanda che tipo di uso verra' fatto del sistema che deve essere installato, con una scelta tra un paio di tipi di server e l'uso desktop, se non ricordo male, e suppongo che un minimo di configurazione fine venga fatto a quel livello. Il problema e' che non ho la piu' pallida idea di cosa abbia scelto.
Questo sistema ha un uptime di ~380 giorni, ma non so se sia questo il problema. Magari protrei provare un altro kernel piu' fresco, ma in tutta sincerita' mi rode non poco doveric mettere mano, perche' a mio avviso e' una questione basilare, se fosse una vera regressione, mi dispiacerebbe veramente per il kernel...

eNjoy

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Gio, 11/11/2010 - 12:28

mcortese

(Guru)

Offline

Iscritto: 27/02/2009

Messaggi: 640

Non mi stupirei che lo scheduler fosse ottimizzato proprio per applicazioni di tipo server, visto che da qualche tempo l'evoluzione del kernel tiene più in considerazione le esigenze dell'ambiente enterprise che di quello puramente desktop. Le motivazioni sono due, una tecnica e l'altra politica.

Innanzitutto è più facile misurare le prestazioni in presenza dei carichi standard che caratterizzano i server web e database SQL, piuttosto che costruire dei benchmark per l'ambiente desktop, dove l'unità stessa di misura non è chiara: è la latenza massima, la latenza media che ci interessa? o il tempo impiegato per compilare un sorgente? o il numero di pagine web aperte al secondo? o il tempo per lanciare OOo?

La considerazione "politica" invece deriva dall'analisi di chi davvero ha maggiormente contribuito allo sviluppo del kernel negli ultimi anni: non Canonical, che sarebbe interessata a far funzionare al meglio l'ambiente desktop, ma Red Hat, Novell, IBM... tutti fornitori di sistemi enterprise.

Sab, 13/11/2010 - 20:50

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 931

Posso dire di essere daccordo con te, Matteo, perche' sicuramente l'ambiente server e' sia piu' "facile" da definire che piu' allettante sotto molti punti di vista. Pero', se vogliamo, l'ambiente desktop potrebbe essere visto come un caso particolare di ambiente server, in cui la latenza e' un problema da tenere a bada.

Al di la' delle considerazioni di logistica, il problema che riportavo mi sembra piuttosto banale, e il tipo di carico in questione non doveva mettere in ginocchio il sistema cosi'. Non essendo un mago del kernel, non ho la piu' pallida idea di cosa fosse la causa, ma sospetto che la colpa possa non essere totalmente del kernel stesso.

Infatti la macchina in questione aveva un uptime piuttosto alto (oltre un anno) e pur avendo fatto due o tre logout dalla sessione grafica, non ho mai riavviato. Per questo sospetto lo "stess ripetuto" come causa delle malefatte del kernel, nonche' diversi aggiornamenti di libc col sistema in corsa.

Percio' sia per motivi di sicurezza che per tentare di ovviare al problema, ho montato (e quindi riavviato) un kernel 2.6.32 dai backports e come per magia tutto sembra risolto. Non solo: se ho 4 processi concorrenti a priorita' normale, in sessione grafica non me ne accorgo neanche, l'audio non traballa e la tastiera non balbetta.

Il semplice fatto che lo schedulatore sia pane per denti del calibro di Colivas e Morton mi riempie di modestia e mi fa capire che e' meglio che mi faccia da parte, mi prenda il mio sacchetto di popcorn e mi goda lo spettacolo dello sviluppo dagli spalti, dove c'e' aria fresca e il problema piu' grosso e' quale sfondo del desktop si addica meglio al mio umore.

Tanto per la cronaca, mentre cercavo la su' menzionata documentazione, sono incappato in suggerimenti su come usare sysctl sui telefonini Android e ho realizzato la Verita' del Giorno: la mia Lenny fa girare lo stesso kernel del mio telefono...
[sfumato su nero, musica in crescendo ]

eNjoy

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Problemi schedulatore multiprocessore

Home

About

Network ILDN

Social link