Sovraccarico della cpu

[More+]

Da quello che scrivi dubito che sia un problema software:

• non hai riscontrato processi impazziti
• hai lo stesso problema con distro diverse
• tutti quelli che usano Lenny non manifestano il tuo problema

Se fossi in te mi orienterei a indagare sull'hardware. Il classico collo di bottiglia è l'uso dell'HDD, se un processo swappa su HDD e magari l'HDD zoppica... (siamo a corto di idee  )

Comunque quando ti succede verifica l'uso dello swap:

Codice:

free

Se hai tanta RAM puoi impostare un utilizzo più aggressivo riducendo così l'uso dello swap.
http://forum.debianizzati.org/tuning/tecniche-di-ottimizzazione-t1340.30.html

[ZeNo]

Giusto per curiosità...

hai provato a tenere un "top" aperto in un terminale e vedere se c'è un processo in particolare che succhia tutta la CPU quando ad esempio apri un'altra sessione di terminale?

A me qualche volta capita di avere tutto rallentato a causa del player flash di iceweasel che si inceppa!

[Alez]

Continuo a negare la prova con top, non c'è un processo succhiarisorse.

Comunque ho installato il kernel 2.6.22 e su una decina di riavvi tutto è filato liscio, se non fosse per il fatto che s'impalla troppo tempo al boot nel caricamento iniziale del kernel... (quando si dice la sfiga).
Ho dato un occhio all'output di strace alla chiamata del terminale nei due casi -normale e rallentato- e sembrano identici, a sto punto sembra proprio che non faccia null'altro che rallentare! 

Ho pure fatto una prova del tutto priva di senso, pensando all'hard disk come causa: ho messo l'opzione noatime alla partizione root su fstab, e su una decina di tentativi non ho riscontrato rallentamenti. Ma temo sia solo un caso, vi farò sapere.

P.s. un'altra cosa che riscontro spesso, e sempre a caso, è che al boot si blocca per un minuto e più su populating /dev, voi ne sapete qualcosa? Comunque i due fenomeni non sembra abbino una correlazione, ma potrebbero avere una causa comune...

P.s. lo swap funge regolarmente. 

[Abbio]

quanta ram hai?

[tindal]

io non vedo chiamate che hanno impiegato molto tempo

evidentemente si ferma a fare qualcos'altro, e l'applicazione che stai usando c'entra solo marginalmente: per esempio, l'applicazione cerca di accedere ad una risorsa, questo tentativo genera l'attivazione di qualche altro processo che occupa tutta la cpu

prova ad avviare "top -d 0.5" in una shell e poi avvia gnome-terminal: vedi se c'è qualche processo che occupa il processore?

controlla anche nei log del kernel (var/log/messages, dmesg|less) se vedi qualche errore ripetuto molte volte

ciao
tindal

[More+]

P.s. un'altra cosa che riscontro spesso, e sempre a caso, è che al boot si blocca per un minuto e più su populating /dev, voi ne sapete qualcosa? Comunque i due fenomeni non sembra abbino una correlazione, ma potrebbero avere una causa comune...

No, però dal nome potrebbe essere che hai aderito (all'installazione lo chiede) all'invio delle informazioni dell'utilizzo dei pacchetti agli sviluppatori

P.s. lo swap funge regolarmente. 

Cioè, usi molto swap oppure non lo usi per niente?

[Abbio]

/dev penso sia relativo alle device del sistema....

[Alez]

Salve ragazzi! 
Rispondo alle varie domande:

• Da quando ho messo l'opzione noatime a fstab, ditemi quello che volete, ma ora almeno il terminale si apre subito, quindi la prova con top non riscontra problemi. Comunque proverò a levare l'opzione per verificare che il ritardo torni, perché se torna non posso fare a meno di pensare che quell'opzione centri qualcosa! Giusto per la cronaca, ricordo che con il filesystem reiserfs, l'opzione noatime serve a non aggiornare il tempo di accesso agli inode, quindi in teoria a risparmiare un pochettino di tempo (non i miei 15 secondi  ).
  Comunque se devo essere pignolo, capita ancora che il terminale si apra a volte in un attimo, altre volte in un paio di secondi, mantenendo questo comportamento per tutta la sessione. Cioè in pratica non c'è nulla di casuale visto che il comportamento è sempre lo stesso identico per tutta la sessione, la casualità semmai è che in alcune sessioni avviene e in altre no, per questo non credo che centri un processo succhiarisorse, ma qualcosa che va storto al boot.
• Non ho trovato errori ripetuti nei log, forse qualcosa di strano, ma non ripetuto.
• Dite che il rallentamento su populating /dev centri con le statistiche sui pacchetti? Come mai?
• Ho 640 MB di ram e lo swap funziona, nel senso che quando serve comincia a riempirsi, e comunque:

Codice:

# swapon -s
Filename Type Size Used Priority
/dev/hda6                               partition 714852 0 -1

Infine, vi faccio un regalo, vi allego il log di dmesg.

[More+]

• Dite che il rallentamento su populating /dev centri con le statistiche sui pacchetti? Come mai?

populating lo avevo spacciato per le info mandate ai mainteners ...perchè proprio in questi giorni stavo manipolando un plugin chiamato così.
http://wiki.debian.org/DevFAQ

Ma che filesystem stai usando?

Infine, vi faccio un regalo, vi allego il log di dmesg.

grazie, ma essendo tradizionalista lo scarto a Natale 

[Alez]

Sto usando ReiserFs su due partizioni, root e home.

Giusto per, ma non è che è qualche problema con il fantomatico file /etc/hosts? Se non sbaglio diverse applicazioni durante l'avvio lo leggono e se è configurato male ci sono dei rallentamenti... (solo che questo non spiegherebbe la casualità del fenomeno)
Il mio:

Codice:

127.0.0.1 localhost
192.168.0.11 acer

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

P.s. Ma Debian 5 avrà il kernel 2.6.24? O il 25?
P.p.s. L'opzione noatime non è la soluzione, il problema se si è appena riverificato... 

[Abbio]

io come seconda linea a differenza della tua ho

Codice:

127.0.1.1 debian.workgroup debian

che è un indirizzo locale alla macchina mentre tu ne hai uno del tipo 192.* che indica una RETE locale.... non vorrei che utilizzandolo così il sistema non vado ogni tanto a reperire informazioni su rete locale, ma comunque questo spiegherebbe solo il ritardo a aprire applicazioni e non il carico ingente di CPU

[tindal]

mah... in dmesg non c'è nulla

a questo punto mi viene un dubbio: sei sicuro che si sovraccarichi la cpu? hai un indicatore o qualcos'altro che conferma questa tesi?
perchè altrimenti il sistema potrebbe essere semplicemente in attesa di un timeout (come quando c'è un problema in /etc/hosts), e la cura è del tutto diversa

nella prima riga di /etc/hosts prova ad aggiungere "localhost.localdomain"

ciao
tindal

[Alez]

mah... in dmesg non c'è nulla

a questo punto mi viene un dubbio: sei sicuro che si sovraccarichi la cpu? hai un indicatore o qualcos'altro che conferma questa tesi?
perchè altrimenti il sistema potrebbe essere semplicemente in attesa di un timeout (come quando c'è un problema in /etc/hosts), e la cura è del tutto diversa

nella prima riga di /etc/hosts prova ad aggiungere "localhost.localdomain"

Grazie tindal per la cortese lettura del dmesg!

Certo che sono sicuro! 
Ho l'applet del monitor di sistema, ma possa anche verificare con top. Si vede letteralmente riempirsi tutto il grafico di quel bel blu schiattacpu per mooolti interminabili secondi e inoltre è tutto meno reattivo.

Provo con il file host, ma tanto ormai sono convinto che è un fenomeno che si manifesta solo col kernel 2.6.24, infatti, come già scrissi, era un problema verificatosi anche con ubuntu. Quando uso il 2.6.22, per esempio, il terminale è un flash, e durante tutte le operazioni di aptitude la cpu oascilla tra valori alti e bassi, mentre sul 24 schizza per tutto il tempo al 100% congelando il sistema nei momenti più critici!
A questo punto spero nelle nuove versioni del kernel...

[YvesBsAs]

Forse una fagianata, ma ho avuto un problema del genere con la Kubuntu Hardy, in realtà la CPU non sovraccaricava troppo, ma il "crond" mi impallava l'HD e di conseguenza rallentava tutto, i sintomi sono molto simili a quelli che descrivi, ho disattivato "cron" ed "anacron" dai servizi in avvio automatico ed ora è vivibile, dai un occhiata che non sia quello:

http://forum.ubuntu-it.org/index.php/topic,202890.0.html

Ciao.

[ZeNo]

A questo punto io proverei a fare anche un test della RAM con memtest86.. Poi, giusto per curiosità proverei a fare un lsof a macchina appena accesa sui software primi in classifica in un top...

lsof | grep apache (giusto come esempio)

Non è che c'è qualche soft che ti occupa tutto il disco?

My 2 cents