UbuntuFacile.org - Forum » Applicazioni.
aMule e il processore schizza al 100%
(4 articoli)-
Ho aggiornato da un mesetto l'applicazione aMule tramite il repository di GetDeb.
Ho così installato la versione 2.20 SVN. Attualmente è aggiornata al 15 marzo.
Il problema che mi dà è questo: dopo pochi minuti dall'avvio, il processore schizza al 100% di utilizzo ogni 4-5 secondi, e ci rimane al 100% per 8-10 secondi. E la cosa si ripete ciclicamente.
Ora io ho un processore dual core, quindi il sistema non si inchioda. Ma vorrei comunque sapere se è un problema di aMule oppure se c'è qualcos'altro che non va nel mio sistema, e che causa questo problema ad aMule.
Che voi sappiate è un problema riscontrato da altri? Possibile che aMule abbia un bug così grosso?
RobertoPubblicato 8 mesi fa # -
Che voi sappiate è un problema riscontrato da altri? Possibile che aMule abbia un bug così grosso?
Si ... Si...
aMule consuma un sacco di CPU soprattutto all'avvio quando crea il checksum dei file condivisi, questo dipende da quanti file hai in condivisione e quanto sono grossi.
A me non è mai capitato che arrivasse al 100%, ma si legge spesso sui forum, se non risolvi il problema diminuendo i file condivisi, oppure aspettando che finisca di creare i checksum, il mio consiglio è quello di provare un'altra versione.Pubblicato 8 mesi fa # -
Ho trovato questo sul wiki di aMule:
Inoltre nelle versioni di aMule precedenti la 2.0.0-rc4, i filesystem con codifica UTF-8 (per esempio con SUSE 9.1) potrebbero presentare problemi quando qualche file o cartella condivisa contiene un carattere speciale. Se questo è il tuo problema, c'è un rimedio (grazie nachbarnebenan): dopo che aMule ha calcolato gli hash dei file condivisi (cioè quando smette di occupare la CPU) chiudi aMule e codifica ~/.aMule/known.met in UTF-8 (lo puoi fare con recode con il seguente comando: recode u8 ~/.aMule/known.met). Questo va fatto ogni volta che un file viene aggiunto o modificato nelle cartelle condivise. Forse è meglio aggiornare aMule all'ultima versione.
Se niente finora ti ha aiutato, è successo qualcosa al file known.met , forse qualche programma esterno o qualche altro utente lo ha rovinato. E' meglio cancellarlo, far partire aMule e lasciare che ricalcoli tutti gli hash dei file.
Allora ho cancellato i file known.met, known2.met, known-64.met. Poi ho riavviato aMule.
L'hashing dei file è stato molto lungo. E continuava a prendere 100% di CPU, soprattutto con i file grandi.
Dopo si è stabilizzato. Quindi il problema sembrerebbe risolto.
Ho notato però che quando aMule si blocca, perchè si blocca proprio per alcuni secondi, e la CPU va al 100%, anche l'accesso al disco con Nautilus è lentissimo.
E' possibile che dipenda dal fatto che le directory "incoming" e "temp" sono su una partizione NTFS ?
Sapevo che una volta aMule aveva problemi anche con FAT32.
RobertoPubblicato 8 mesi fa # -
Per la cronaca, ho notato dopo alcuni esperimenti che sia aMule che Transmission (e pure Deluge) mandavano il processore a palla se scrivevano sulla partizione NTFS.
Insomma, ho piallato l'unico disco che avevo in NTFS e l'ho formattato in ext3 con gParted.
Adesso va tutto bene.
La cosa "carina" è che da windows riesco tranquillamente ad accedere le partizioni ext3 (sebbene manchi il supporto per il journaling) tramite un driver open source.
Adesso zero problemi con qualsiasi programma. :)
Rob
Pubblicato 3 mesi fa #
Feed RSS per questa discussione
Replica
Devi aver fatto il login per poter pubblicare articoli.

