ARGOMENTO:

... vi sembra normale che su una macchina con 4 processi in elaborazione e 3 in attesa di elaborazione io abbia questa situazione?

e anche questa ...

Puo succedere se (come fa' spesso il server del SETI) manda WU a (lenta) ripetizione e con deadline a decrescere, cosi che lo scheduler stoppa quelle in esecuzione e fa partire quella appena scaricata perche con deadline piu' corta. Se hai il flag "leave in memory" abilitato, il client associato alle WU messe in pausa rimane in memoria e cosi' ne vedrai tanti quante la WU iniziate e fermate.
Per liberare la RAM puoi stoppare e rilanciare BOINC, e per non avere piu' questo problema in futuro puoi:
1) togliere il flag "leave in memory"
2) fare il detach del SETI (che e' l'unico server che fa questo scherzetto massivamente)

strano, sto scherzetto non me lo fa (faceva) su ubuntu.

P.S. ridimensiona (size=700) le immagini.

Con 7 wu in totale in cache non è normale, che versione di BOINC stai utilizzando? Seguendo le indicazioni di astroale la situazione è cambiata?

astroale ha scritto:

Puo succedere se (come fa' spesso il server del SETI) manda WU a (lenta) ripetizione e con deadline a decrescere, cosi che lo scheduler stoppa quelle in esecuzione e fa partire quella appena scaricata perche con deadline piu' corta. Se hai il flag "leave in memory" abilitato, il client associato alle WU messe in pausa rimane in memoria e cosi' ne vedrai tanti quante la WU iniziate e fermate.
Per liberare la RAM puoi stoppare e rilanciare BOINC, e per non avere piu' questo problema in futuro puoi:
1) togliere il flag "leave in memory"
2) fare il detach del SETI (che e' l'unico server che fa questo scherzetto massivamente)

Allora:
1. il flag era già tolto ... nel dubbio l'ho rimesso e poi l'ho rilevato;
2. cosa intendi con "fare il detach"?

Nel frattempo ho fatto alcune prove facendo fare una query abbastanza pesante su un db di SQL Server abbastanza grande; ecco i risultati mediando 6 prove per ciascun dato (memoria al 50% e processore/processori al 100%):
- con BOINC chiuso (prima stranezza: le decine di processi di cui sopra sono rimasti aperti in memoria) il tempo medio della query è stato di 2.08 sec.;
- con BOINC attivo 2.29 sec;
Ho quindi riavviato la macchina lasciando BOINC inattivo (finalmente la memoria si è svuotata):
- tempo medio 1.49 sec;
- ho riavviato BOINC ... tempo medio 1.59 sec

Da questi primi dati (soggetti sicuramente ad errori di varia natura) si può dire ch sicuramente BOINC non è proprio trasparente ... inoltre andando a vedere le priorità date alle decine di processi di cui sopra ho scoperto che non erano tutti a bassa ma si andava da bassa a superiore al normale passando per inferiore al normale e normale ...

Sicuramente farò altre prove ma queste mi hanno lasciato con un po' di amaro in bocca ... vedremo le prossime ...

Purtroppo o per fortuna dovrebbe essere una soluzione legata a SETI. Potresti rifare la stessa prova con un altro progetto?

paprita ha scritto:

astroale ha scritto:

Puo succedere se (come fa' spesso il server del SETI) manda WU a (lenta) ripetizione e con deadline a decrescere, cosi che lo scheduler stoppa quelle in esecuzione e fa partire quella appena scaricata perche con deadline piu' corta. Se hai il flag "leave in memory" abilitato, il client associato alle WU messe in pausa rimane in memoria e cosi' ne vedrai tanti quante la WU iniziate e fermate.
Per liberare la RAM puoi stoppare e rilanciare BOINC, e per non avere piu' questo problema in futuro puoi:
1) togliere il flag "leave in memory"
2) fare il detach del SETI (che e' l'unico server che fa questo scherzetto massivamente)

Allora:
1. il flag era già tolto ... nel dubbio l'ho rimesso e poi l'ho rilevato;

Dimenticavo di dirti che ogni volta che cambi il profilo (anche solo quel flag) devi fare un UPDATE perchè questo venga riapplicato.

2. cosa intendi con "fare il detach"?

Abortire il SETI ed elaborare per un altro progetto.

Il fatto che tu avessi tutti quei processi in RAM credo possa essere dovuto a due diversi casi:
1) quello che avevo già detto prima ma, visto il basso numero di WU in coda, combinato con un abort dal server di un tot di WU che quindi sono scomparse dalla coda prima che te ne accorgessi
2) poca RAM a disposizione (fisica, o percentuale impostata nelle preferenze) che fa si che vari tentatvi di start del client abortiscano lasciando cadaveri in RAM (questo spiegherebbe anche perchè alla chiusura di BOINC i cadaveri ormai senza connessione con lo scheduler non si sono chiusi)

Una terza più remota ipotesi potrebbe essere quella di incasinamento dei permessi dei file di progetto (SETI) o dello scheduler (BOINC).

Nel frattempo ho fatto alcune prove facendo fare una query abbastanza pesante su un db di SQL Server abbastanza grande; ecco i risultati mediando 6 prove per ciascun dato (memoria al 50% e processore/processori al 100%):
- con BOINC chiuso (prima stranezza: le decine di processi di cui sopra sono rimasti aperti in memoria) il tempo medio della query è stato di 2.08 sec.;
- con BOINC attivo 2.29 sec;
Ho quindi riavviato la macchina lasciando BOINC inattivo (finalmente la memoria si è svuotata):
- tempo medio 1.49 sec;
- ho riavviato BOINC ... tempo medio 1.59 sec

Da questi primi dati (soggetti sicuramente ad errori di varia natura) si può dire ch sicuramente BOINC non è proprio trasparente ... inoltre andando a vedere le priorità date alle decine di processi di cui sopra ho scoperto che non erano tutti a bassa ma si andava da bassa a superiore al normale passando per inferiore al normale e normale ...

Sicuramente farò altre prove ma queste mi hanno lasciato con un po' di amaro in bocca ... vedremo le prossime ...

Tieni conto che la priorità critica è solo quella dei client (gli unici che consumano pesantemente CPU time). Quelli girano a priorita idle o quasi, gli altri come lo scheduler vanno a priorità normale. L'unica volta che lo scheduler (boinc.exe) rompe le scatole è durante i benchmark che sono eseguiti tipicamente alla startup di BOINC (o ogni 4 giorni circa) e viaggiano per 40 secondi in full CPU a priorità normale.
Se tuttavia hai poca RAM allora l'aumento dell'attività su disco della memoria virtuale, o viceversa il minor spazio a disposizione per SQL può certamente penalizzare le performance. In questo caso potresti provare l'attach di un progetto che usa poca RAM, il più parsimonioso in assoluto è lo Spinhenge@home.

Medesima situazione con PrimeGrid (e considerate che sul PC di cui sto parlando scaccolo SOLO su PrimeGrid) da quando ho installato la 6.10.24 (idem con la 25)

Mi è capitato 2 volte, mandando quasi in blocco BOINC per mancanza di RAM: ho risolto a mano sospendendo le WU "pronte per l'elaborazione" e parte di quelle "in attesa" e aspettando pazientemente che terminasse quelle iniziate.
Una volta ridotta la coda di quelle già iniziate a 10 ho sbloccato quelle "pronte per l'elaborazione" e la situazione si è normalizzata... per ricapitare 10 giorni dopo

io avevo un problema simile delle wu in memoria che non scomparivano all'uscita ed era perché non uscivo correttamente da boinc:
1) controlla che sia abilitata la schermata di uscita del manager in Avanzate -> Opzioni
2) quando fai esci sul manager, controlla che ci sia un segno di spunta nella voce "ferma applicazioni scientifiche" (o qualcosa del genere, io ho boinc in inglese e c'è "stop running science apps when exiting") nella schermata di uscita che compare. Così facendo BOINC dovrebbe chiudere tutti i processi che era stato lui ad avviare. Se qualcuno resta in memoria, potenzialmente è un difetto di boinc che se riproducibile andrebbe segnalato come bug.

Venturini Dario ha scritto:

Purtroppo o per fortuna dovrebbe essere una soluzione legata a SETI. Potresti rifare la stessa prova con un altro progetto?

Almeno per ora non sono iscritto ad altri progetti ... sono un affezionado del Seti da quasi 10 anni anche se per molto tempo non ho operato ...

astroale ha scritto:

Il fatto che tu avessi tutti quei processi in RAM credo possa essere dovuto a due diversi casi:
2) poca RAM a disposizione (fisica, o percentuale impostata nelle preferenze) che fa si che vari tentatvi di start del client abortiscano lasciando cadaveri in RAM (questo spiegherebbe anche perchè alla chiusura di BOINC i cadaveri ormai senza connessione con lo scheduler non si sono chiusi)

La RAM è 4GB e nelle preferenze avevo settato il 50%

Tieni conto che la priorità critica è solo quella dei client (gli unici che consumano pesantemente CPU time). Quelli girano a priorita idle o quasi, gli altri come lo scheduler vanno a priorità normale.

Purtroppo credo che non sia così ... i dati di priorità riportati si riferivano solo ai client che, come già detto, arrivavano, almeno in un paio di casi, a superiore al normale ...

cenit ha scritto:

io avevo un problema simile delle wu in memoria che non scomparivano all'uscita ed era perché non uscivo correttamente da boinc:
1) controlla che sia abilitata la schermata di uscita del manager in Avanzate -> Opzioni
2) quando fai esci sul manager, controlla che ci sia un segno di spunta nella voce "ferma applicazioni scientifiche" (o qualcosa del genere, io ho boinc in inglese e c'è "stop running science apps when exiting") nella schermata di uscita che compare. Così facendo BOINC dovrebbe chiudere tutti i processi che era stato lui ad avviare. Se qualcuno resta in memoria, potenzialmente è un difetto di boinc che se riproducibile andrebbe segnalato come bug.

Non ricordo come fossero tali settaggi ... cmq ora sono tutti settati come da tuo consiglio ...

Prova in atto: orari variabili giornalieri.

da Lunedì a Giovedì 16:00-07:00
Venerdì 12:00-11:59
Sabato 12:00-11:59
Domenica 12:00-07:00

Sospeso al di fuori di questi orari e alla massima potenza (CPU e RAM) all'interno ... vediamo che succede ...

paprita ha scritto:

astroale ha scritto:

Tieni conto che la priorità critica è solo quella dei client (gli unici che consumano pesantemente CPU time). Quelli girano a priorita idle o quasi, gli altri come lo scheduler vanno a priorità normale.

Purtroppo credo che non sia così ... i dati di priorità riportati si riferivano solo ai client che, come già detto, arrivavano, almeno in un paio di casi, a superiore al normale ...

Questo e' quello che dovresti vedere da process explorer sui client per la CPU:



Se vedi qualcosa di diverso da un "low" su task manager e un 4 su process explorer c'e' qualcosa che non va', perche' i processi che possono girare a priorita' differenti sono:

1) il client del progetto QCN che legge l'accelerometro USB
2) i client che caricano la GPU (ma se ho capito non e' il tuo caso)

in entrambi i casi il consumo di CPU di questi processi dovrebbe essere ridottissimo (a meno di malfunzionamenti)

paprita ha scritto:

Prova in atto: orari variabili giornalieri.

da Lunedì a Giovedì 16:00-07:00
Venerdì 12:00-11:59
Sabato 12:00-11:59
Domenica 12:00-07:00

Sospeso al di fuori di questi orari e alla massima potenza (CPU e RAM) all'interno ... vediamo che succede ...

Con mio immenso piacere il primo giorno ha funzionato ...
Vediamo se funzionano anche gli altri giorni (a questo punto sono fiducioso ... )

Dopo un po' di giorni di prove forse ho svelato l'arcano ... ma vado per ordine ... come già spiegato, ho delle macchine su cui girano dei processi abbastanza pesanti ... in particolare su una (SQL Server) e purtroppo la questione delle priorità non è sufficiente ... il primo del mese (febbraio) ho, quindi, settato gli orari sulle 3 macchine in modo da NON avere boinc in funzione durante l'orario si lavoro giornaliero in cui i server sono più stressati. Lavorando SOLO in logica positiva (settare l'orario in cui BOINC è attivo) ho dovuto mettere, per ciascun giorno, l'orario di resume e poi l'orario di suspend del giorno dopo:

Macchina 1 e macchina 2
LUN 17:00-07:00
MAR 17:00-07:00
MER 17:00-07:00
GIO 17:00-07:00
VEN 14:00-14:00
SAB 14:00-14:00
DOM 14:00-07:00

che dal mio modo di vedere (e come detto anche qualche post fa) doveva significare che l'elaborazione doveva iniziare alle 17 del lunedì per fermarsi alle 07 del martedì e così via fino al venerdì dove sarebbe dovuta partire alle 14 per rimanere attiva, senza sosta, fino al lunedì mattina alle 07:00

Sulla macchina 3, con la stessa logica, ho messo orari leggermente differenti per il W.E.:

Macchina 3
LUN 17:00-07:00
MAR 17:00-07:00
MER 17:00-07:00
GIO 17:00-07:00
VEN 14:00-13:55
SAB 14:00-13:55
DOM 14:00-07:00

Dopo una settimana Boinc ha funzionato come segue:
Macchina 1 e 2.................Macchina 3
LUN 07:00-17:00...............07:00-17:00.....TUTTE DISATTIVE
MAR 07:00-17:00..............07:00-17:00.....TUTTE DISATTIVE
MER 07:00-17:00..............07:00-17:00.....TUTTE DISATTIVE
GIO 07:00-17:00...............07:00-17:00.....TUTTE DISATTIVE
VEN 1 e 2 SEMPRE ATTIVE....13:55-14:00......DISATTIVA per 5 minuti
SAB 1 e 2 SEMPRE ATTIVE....13:55-14:00......DISATTIVA per 5 minuti
DOM 07:00-14:00...............07:00-14:00.....TUTTE DISATTIVE

Come vedete, in prima istanza, i risultati non coincidono con gli orari inseriti.

A questo punto ho tirato le conclusioni: inserendo PRIMA un orario maggiore e poi uno MINORE (es. 17:00-07:00) lui lo interpreta in logica NEGATIVA, come dire "Disattiva il sistema dalle 07:00 alle 17:00".
Se applicate questa logica vedrete che tutto torna.

Ora ho inserito gli orari in questa logica; vi farò sapere se, effettivamente, ho risolto il problema oppure ho scritto un sacco di caxxate ...

Se è vero, credo che sia da segnalare agli sviluppatori...

Dopo una settimana di "osservazione" confermo la cosa ... chi dovrei avvisare?

Gli sviluppatori di BOINC. Non è certo un bug ma mi sembra che il manager si comporti in maniera abbastanza stupida