100% accesso I/O al disco rigido: cause? soluzioni?

OS X, Linux e tutti gli altri OS

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda clros » dom apr 18, 2021 10:55 am

Sono interessanti le considerazioni che hai fatto e intriganti le domande che hai posto sul paging. Io personalmente non ti saprei rispondere.

Però penso che, in relazione al tuo problema, questi parametri non c'entrino nulla; il solito "buon vecchio windows" regola tutto automaticamente in modo da avere prestazioni ottimali, l'utente "normale" non dovrebbe toccare nulla se non in casi particolari.

Questo per dirti che non credo che la dimensione e le impostazioni del file di paging c'entri qualcosa con il tuo problema, considerando anche la quantità di RAM e la capacità del tuo disco...
Only AMIGA makes it possible !!
La colpa è sempre del Kernel!!
...un bit è formato da 8 byte...

Claudio "CP" La Rosa
Avatar utente
clros

Supremo
 
Messaggi: 3422
Iscritto il: ven mag 07, 2004 2:41 pm
Località: SYS 64738

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » dom apr 18, 2021 11:04 am

Ci sono dei programmi, anche microsoft, che monitorano le attività di sistema a basso livello, con uno di questi io avevo scoperto che il sistema si impallava per via di una considerevole mole di interrupt da gestire che arrivavano dal controller disco. Purtroppo non ricordo il nome del programma.
Nel mio caso si trattava dei dischi ...


Mi interesserò a questa faccenda del bombardamento di IRQs da parte di HW "difettoso", è una teoria interessante ...

Tuttavia pensavo al contrasto, almeno per me (ribadisco la mia ignoranza), fra questi 2 fattori:

impegno temporale della CPU = diciamo 5 - 10%.
vs
attività IO su disco = 100%

Se il controller del mio disco scatenasse un bombardamento incessante di IRQs verso la CPU, i vari processi concorrenti schedulati dall'OS sarebbero continuamente interrotti per essere gestiti. La gestione delle ISR (Interrupt Service Routines), associate a questi IRQs, è chiaramente a carico esclusivo della CPU: pertanto la CPU dovrebbe essere sempre iper-impegnata nel continuo ingresso in questi vettori di interrupt, gestione degli stessi, uscita dagli stessi (ritorno al main), ecc ...

Quello che mi sdubbia è che a fronte di un bombardamento da interrupt che giustificherebbe un impegno IO su disco del 100%, mi sarei aspettato un paragonabile impegno di CPU ... e invece osservo un tempo di impegno CPU del 5 - 10%, non confrontabile con il 100% IO del disco.

Come spieghi tale discrepanza?

Forse nel mio caso potrebbero essere IRQs scatenati da altro HW ...
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » dom apr 18, 2021 11:06 am

Dovresti controllare bene, ma se hai subito un altro HDD o SSD a portata di mano, prova a cambiarlo e vedi cosa succede.


Non ce l'ho, ma potrei pensare di acquistarne uno.
Quali sono secondo te, tu che hai molta più esperienza di me, prezzi ragionevoli per un SSD da 500GB o 1TB?

Altra cosa probabile è l'eventuale lettore CD/DVD che, sempre per guasti, interferisce con il disco.


Ho un driver DVD integrato nel notebook, che non uso mai, dato che negli ultimi anni ho abbandonato i supporti CD/DVD.
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda clros » dom apr 18, 2021 11:19 am

AMG_Novice_Usr ha scritto:Tuttavia pensavo al contrasto, almeno per me (ribadisco la mia ignoranza), fra questi 2 fattori:

impegno temporale della CPU = diciamo 5 - 10%.
vs
attività IO su disco = 100%

Se il controller del mio disco scatenasse un bombardamento incessante di IRQs verso la CPU, i vari processi concorrenti schedulati dall'OS sarebbero continuamente interrotti per essere gestiti. La gestione delle ISR (Interrupt Service Routines), associate a questi IRQs, è chiaramente a carico esclusivo della CPU: pertanto la CPU dovrebbe essere sempre iper-impegnata nel continuo ingresso in questi vettori di interrupt, gestione degli stessi, uscita dagli stessi (ritorno al main), ecc ...

Quello che mi sdubbia è che a fronte di un bombardamento da interrupt che giustificherebbe un impegno IO su disco del 100%, mi sarei aspettato un paragonabile impegno di CPU ... e invece osservo un tempo di impegno CPU del 5 - 10%, non confrontabile con il 100% IO del disco.

Come spieghi tale discrepanza?



Molto interessanti le tue osservazioni! :felice:
Non ti so rispondere nel dettaglio, so di sicuro che l'OS (Windows sicuro, ma immagino qualsiasi altro OS), gestiscono gli interrupt in maniera "differita"; all'arrivo di un IRQ non avviano per forza subito la corrispondente ISR, ma si limitano a prendere nota che un determinato interrupt è stato generato da un determinata periferica e continuano il loro lavoro.
Nei momenti più "rilassanti", decisi da politiche diverse per ogni OS (per esempio, quando il tempo di IDLE è alto o ci sono pochi processi da schedulare) allora l'OS prende in considerazione gli interrupt che aveva messo da parte.
Tutto questo per non togliere risorse CPU ai processi importanti e dare l'impressione che tutto sia il più fluido possibile.
Ovviamente non so con certezza se sia questo il caso, però è così che l'OS funziona; quasi nessun interrupt viene servito subito, specie quelli meno importanti.

Forse nel mio caso potrebbero essere IRQs scatenati da altro HW ...

E' sicuramente possibile!
Only AMIGA makes it possible !!
La colpa è sempre del Kernel!!
...un bit è formato da 8 byte...

Claudio "CP" La Rosa
Avatar utente
clros

Supremo
 
Messaggi: 3422
Iscritto il: ven mag 07, 2004 2:41 pm
Località: SYS 64738

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda clros » dom apr 18, 2021 11:28 am

AMG_Novice_Usr ha scritto:
Dovresti controllare bene, ma se hai subito un altro HDD o SSD a portata di mano, prova a cambiarlo e vedi cosa succede.


Non ce l'ho, ma potrei pensare di acquistarne uno.
Quali sono secondo te, tu che hai molta più esperienza di me, prezzi ragionevoli per un SSD da 500GB o 1TB?



Purtroppo non saprei aiutarti, personalmente non ho mai avuto esigenze di grandi capacità e velocità estreme (sono uno sviluppatore software e uso principalmente Visual Studio; mi basta e mi avanza hardware normalissimo a basso prezzo che si trova su Amazon o nei negozi sotto casa, ho sempre preso i più economici ma di marche conosciute).

Altra cosa probabile è l'eventuale lettore CD/DVD che, sempre per guasti, interferisce con il disco.


Ho un driver DVD integrato nel notebook, che non uso mai, dato che negli ultimi anni ho abbandonato i supporti CD/DVD.

Mi capitò su un mio vecchio portatile che all'improvviso il boot dall'HDD era diventato leeeeeeeeeeeentissimo.
Staccai il lettore CD-ROM (che non usavo mai nemmeno io) e tutto ritornò a funzionare bene.
Only AMIGA makes it possible !!
La colpa è sempre del Kernel!!
...un bit è formato da 8 byte...

Claudio "CP" La Rosa
Avatar utente
clros

Supremo
 
Messaggi: 3422
Iscritto il: ven mag 07, 2004 2:41 pm
Località: SYS 64738

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMIGASYSTEM » dom apr 18, 2021 11:32 am

AMG_Novice_Usr ha scritto: Parliamo del file di paging

Direi di lasciarlo stare e di non dare misure ma far gestire automaticamente al sistema che prenderà quello che al momento gli serve, su Windows il file di paging è importante e necessario, se lo elimini prima o poi se lavori in contemporanea con più programmi di un certo peso riceverai degli errori.

Se vuoi realmente e non teoricamente alleggerire e velocizzare Windows segui quanto da me descritto !
Immagine - AfA One - AfA One PPC - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 4498
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » dom apr 18, 2021 12:11 pm

Nei momenti più "rilassanti", decisi da politiche diverse per ogni OS (per esempio, quando il tempo di IDLE è alto o ci sono pochi processi da schedulare) allora l'OS prende in considerazione gli interrupt che aveva messo da parte.


Questo servizio in differita delle ISR pending da parte degli OS non lo conoscevo! Interessante e sensato.

La mia conoscenza degli OS (che sono un mondo) è assai limitata, io di professione scrivo FW per microcontrollori (cpu: ARM/Cortex prevalentemente), più che altro per applicazioni industriali e di automazione, dove spesso hai necessità real-time che mal si conciliano con gli OS, per cui spesso non abbiamo OS/RTOS sui micro, quindi sviluppiamo FW bare-metal, ex-novo, in cui appunto è importante che ad una IRQ segui l'esecuzione della corrispondente ISR con tempo di latenza di 10ns (es: IRQs per la lettura di encoders incrementali veloci).

Effettivamente l'OS, specialmente se desktop-oriented, deve dare molto spazio all'utente, a costo di mettere per "lungo" tempo da parte IRQs, per poi prendersene cura successivamente durante una lunga fase di idle ... tutto perfettamente logico!
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » dom apr 18, 2021 12:41 pm

servizio in differita delle ISR


L'unica forma di servizio in differita sostenibile, anzi, direi pure "richiesta/fondamentale", nel mondo da cui provengo io, è la seguente (mi scuso per l'OTP parziale nel quale sto incorrendo):

servizio in differita dell'interrupt "PendSV" (Pending Super-Visor Call):

se hai un RTOS, tipo FreeRTOS, che gira su un microcontrollore mono-core per applicazioni embedded, è importante accertarsi che lo scheduler dei processi possa effettuare il cambio di contesto, fra il task attuale da sottoporre a preemption, e quello successivo al quale dobbiamo consegnare la CPU, in modo che il contesto del processo da abbandonare/freezare sia FUORI da ogni interrupt.

Se lo scheduler facesse le push nello stack del task da abbandonare/freezare, mentre questo task è ancora interrotto da un IRQ oppure peggio ancora da più IRQs nested, incorreremmo in problemi, probabilmente in crash, ad ogni modo situazioni non prevedibili, perchè quando poi lo scheduler riassegnerà la CPU a questo task, quindi quando riavremo le pop dallo stack di questo task (ripristino di quel contesto), avremmo il ripristino di un contesto di task interrotto da IRQs, quindi con una situazione di registri R0, R1, ... R15 particolare/sbagliata, flags particolari (modalità Handler, non Thread), insomma un ripristino di contesto "strano".

Quindi è importante servire in differita l'IRQ "PendSV" che si occupa della chiamata di sistema che determina il cambio di contesto.

Mi spiego meglio:

ad ogni tick di sistema, diciamo ogni 100us, l'IRQ scatenato dal tick di sistema setta il flag di avvenuto interrupt del PendSV, ma l'IRQ del PendSV non viene effettivamente servita fino a quando il program-counter PC della CPU non ritorna al task interrotto dai vari interrupts annidati: facciamo conto che il PC prima esca dall'IRQ ad altissima priorità, tornando ad un IRQ a media priorità, adesso finisce di eseguire questo IRQ, poi esce da questo IRQ ed il PC entra in un IRQ a bassa priorità, poi eseguiamo quest'ultimo IRQ, poi una volta terminato il PC ne esce e torna nel loop "while(1) { ... } " del task interrotto da questi IRQs nested.

Solo adesso l'OS serve l'IRQ "PendSV", per effettuare lo switch-context, poichè adesso l'immagine di CPU da salvare nello stack del task che stiamo per lasciare è un'immagine di CPU di task in condizioni normali, di running, non più di task interrotto.
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » dom apr 18, 2021 12:46 pm

Direi di lasciarlo stare e di non dare misure ma far gestire automaticamente al sistema che prenderà quello che al momento gli serve, su Windows il file di paging è importante e necessario, se lo elimini prima o poi se lavori in contemporanea con più programmi di un certo peso riceverai degli errori.


Ciao Carlo!
Ok, lo lascio stare così.

Se vuoi realmente e non teoricamente alleggerire e velocizzare Windows segui quanto da me descritto !


Si certo, e infatti l'ho fatto, almeno credo.

Ho postato nel dettaglio i punti e gli screenshots, e infatti mi interessa moltissimo avere il tuo parere nel dettaglio, magari sapere da te se ho seguito i giusti steps, come da te intesi, oppure magari se manca qualcosa, se qualcosa può essere fatto meglio, ecc ... fammi sapere, grazie!!
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda clros » dom apr 18, 2021 12:55 pm

AMG_Novice_Usr ha scritto:

---CUT--
Solo adesso l'OS serve l'IRQ "PendSV", per effettuare lo switch-context, poichè adesso l'immagine di CPU da salvare nello stack del task che stiamo per lasciare è un'immagine di CPU di task in condizioni normali, di running, non più di task interrotto.


OT

Interessantissimo, non avevo mai pensato al fatto che lo scheduler, al cambio di contesto, dovesse tener conto degli interrupt pendenti in quel momento! Estremamente interessante e sensato!!

Siamo OT, ti dico solo che mi interesso di architetture degli OS sia per curiosità che per hobby; vorrei scriverne uno per una CPU "particolare" che stiamo realizzando.
Se ti può interessare, anche solo a livello di curiosità, dai un'occhiata qui: http://www.ternary-computing.com
Il sito non è aggiornato da diversi mesi ma il progetto sta andando avanti!

Scusate tutti per l'OT!
/OT
Only AMIGA makes it possible !!
La colpa è sempre del Kernel!!
...un bit è formato da 8 byte...

Claudio "CP" La Rosa
Avatar utente
clros

Supremo
 
Messaggi: 3422
Iscritto il: ven mag 07, 2004 2:41 pm
Località: SYS 64738

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMIGASYSTEM » dom apr 18, 2021 1:12 pm

AMG_Novice_Usr ha scritto:Si certo, e infatti l'ho fatto, almeno credo.

Si ho letto, ma accertati di aver disabilitato realmente gli aggiornamenti su Win10? se hai usato normali funzioni queste solitamente non funzionano, se invece sei intervenuto sul servizio allora OK

Per quanto riguarda i programmi in background usa Hijackthis, con questo programma puoi eliminare applicazioni in background invasive ma anche infezioni, puoi anche stoppare servizi.

Tutto quello che fixi lo trovi nel tab backup e poi ripristinare tutto, praticamente puoi eliminare quasi tutto fatto eccezione dell'Antivirus e tutto ciò che appartiene a Windows, occhio a non sbagliare.
Immagine - AfA One - AfA One PPC - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 4498
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » mar apr 20, 2021 10:26 am

Si ho letto, ma accertati di aver disabilitato realmente gli aggiornamenti su Win10? se hai usato normali funzioni queste solitamente non funzionano, se invece sei intervenuto sul servizio allora OK


Adesso la situazione è notevolmente migliorata, soprattutto da quando, anzichè limitarmi alla GUI del pannello di controllo,
batto da riga di comando:

services.msc

vado poi sul servizio inutile, e anzichè arrestarlo e basta, vado in proprietà di quel servizio e:

tipo di avvio:
disabilitato

Ho disattivato in questo modo anche il servizio:

SearchIndexer.exe

così l'indicizzazione è solo un ricordo.
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMG_Novice_Usr » mar apr 20, 2021 10:28 am

Per quanto attiene alla swap-area, qui c'è una lista completa di comandi da shell per la gestione del file di paging:

https://www.itprotoday.com/windows-78/modify-pagef ile-configuration-command-line
http://www.it-word.net/command/Windows/wmic/en-us/ wmicPAGEFILESET.html

Mi chiedo soltanto se ha davvero un senso creare una partizione a sè, diversa da quella C: di sistema, ad esempio P: ,
e lì metterci il file di paging ... qualcuno mi sa spiegare il perchè di questa eventuale convenienza?

Se le 2 partizioni, quella di sistema e quella di paging/swap, fossero su 2 dischi fisici diversi, mi tornerebbe già di più,
ma essendo sullo stesso disco, mi sfugge il perchè prevedere una partizione dedicata allo swap dovrebbe convenire ...

In effetti Ubuntu, quando lo istalli in dual-boot da pennetta live su un sistema nativo Windows ti fa fare una cosa del genere,
ovvero ti fa installare una partizione Home, una di root (di sistema, insomma) ed una di swap ...
Avatar utente
AMG_Novice_Usr

Veterano
 
Messaggi: 174
Iscritto il: ven mag 01, 2020 10:10 am
Località: Pisa

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda AMIGASYSTEM » mar apr 20, 2021 1:21 pm

AMG_Novice_Usr ha scritto:
Si ho letto, ma accertati di aver disabilitato realmente gli aggiornamenti su Win10? se hai usato normali funzioni queste solitamente non funzionano, se invece sei intervenuto sul servizio allora OK


Adesso la situazione è notevolmente migliorata, soprattutto da quando, anzichè limitarmi alla GUI del pannello di controllo,
batto da riga di comando:

services.msc

Quella e una delle tantissime scorciatoi come gpedit.msc, diskmgmt.msc, eventvwr.msc e tanti altri comandi con estensione ".msc" ci sono anche le scorciatoie con estensione ".cpl" per raggiungere ogni cosa con un click, naturalmente sono strumenti sconosciuti ai meno esperti Windows, comunque per raggiungere i "Servizi" ci arrivi comodamente anche dalla GUI "Gestione".

Ma attenzione lo strumento consigliato "Hijackthis" è indispensabile per chi vuole tenere Windows sotto controllo, strumento usato da tutti gli esoerti Windows.

Il file di paging su partizione dedicata swap creata da Linux e utilizzata anche da Amiga OS4 non è necessaria su Windows, i nuovi sistemi Windows per esempio creano Il file di paging dinamico automaticamente durante l'installazione.

Inoltre spostando il file di paging su altra partizione le testine di lettura\scrittura salterebbero da una partizione all'altra rallentando le operazioni, inoltre essendo un solo disco fisico il controller è lo stesso.
Immagine - AfA One - AfA One PPC - AROS One x86 - AROS One 68K - WinUAE OS 4.1 -

Miei AMIGA
Amiga 4000/Cyberstorm MK II/060/Picasso RAM 6MB Kick 3.1
Amiga 1200/030 Ram 16 Mega HD 500 MB
Amiga 1200/040 Ram 32 Mega HD 500 MB
Amiga 600 HD 20 MB
Amiga 600 Doppio Kickstart 2.05-1.3
Amiga 500 Plus Doppio Kickstart 204-1.3
Amiga 500
CD32/SX-32 MK1 RAM 8 MB HD 4G
CD32 Standard
Avatar utente
AMIGASYSTEM

Staff
 
Messaggi: 4498
Iscritto il: ven lug 25, 2008 8:39 pm
Località: Brindisi

Re: 100% accesso I/O al disco rigido: cause? soluzioni?

Messaggioda clros » mar apr 20, 2021 3:28 pm

AMG_Novice_Usr ha scritto:Mi chiedo soltanto se ha davvero un senso creare una partizione a sè, diversa da quella C: di sistema, ad esempio P: ,
e lì metterci il file di paging ... qualcuno mi sa spiegare il perchè di questa eventuale convenienza?


Mettere un file di paging in un'altra partizione, non credo avrebbe senso.

Come faceva notare anche AMIGASYSTEM, non sarebbe logico fare un'altra partizione per il file di paging sullo STESSO disco, poichè il controller è unico (e anche le testine del disco).

Nel caso di partizione di swap ( e quindi NON di un file di swap "normale") si ha però un vantaggio: tale partizione ha un filesystem differente rispetto alle altre partizioni (o forse è solo una partizione RAW) per cui la sua gestione è estremamente più semplice e immagino anche più veloce rispetto alle partizioni "normali".

Windows storicamente usa un "normale" file nel "normale" filesystem mentre Linux e anche OS4 usano una partizione dedicata.
E' solo una scelta implementativa; la soluzione di Windows dovrebbe essere più lenta, ma è più facile da gestire (è un normale file, utilizzabile con le consuete funzioni di sistema) e inoltre la sua grandezza non dovrebbe essere fissa come una partizione dedicata.
La differenza di prestazioni tra una partizione dedicata e un file, considerando le caratteristiche dei PC degli ultimi 10-15 anni, non credo sia apprezzabile ad "occhio nudo" (= alla fine è la stessa cosa)
Only AMIGA makes it possible !!
La colpa è sempre del Kernel!!
...un bit è formato da 8 byte...

Claudio "CP" La Rosa
Avatar utente
clros

Supremo
 
Messaggi: 3422
Iscritto il: ven mag 07, 2004 2:41 pm
Località: SYS 64738

PrecedenteProssimo

Torna a Altri sistemi operativi

Chi c’è in linea

Visitano il forum: Nessuno e 6 ospiti