Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a AMG_Novice_Usr [quote=AMG_Novice_Usr] [quote] se hai un ssd oppure no ed hai sufficiente ram meglio ridurre il file di paging, che in un caso velocizzerà il disco meccanico, nell'altro limiterà scritture su ssd. [/quote] Io ho la seguente situazione: disco meccanico da 1TB. RAM installata: 8GB file di paging: 8GB pertanto la memoria virtuale è di 16GB. Ci sono pro e contro nel ritoccare manualmente la size del file di paging. Esaminiamo i 2 casi estremi (dimmi/ditemi se sbaglio qualcosa): [b] Caso 1 (ho tanta RAM): [/b] se io avessi moltissima RAM installata, facciamo ad esempio 32GB, allora potrei tranquillamente rimuovere il file di paging e fare in modo che non venga più creato, insomma abolire per sempre il file di paging, che dovrebbe coincidere con la swap-area gestita dal long-term-scheduler del kernel dell'OS ... giusto? Se non ho capito male, il file di paging ospita le pagine (le pagine fisiche, invece quelle logiche, virtuali, stanno nella MMU) di processi, pagine che lo schedulatore a lungo termine ritiene di poter tenere sul disco, nell'area di paging appunto (file di paging = area di paging = swap-area), poichè quelle pagine, quelle parti di processo, vengono raramente utilizzate dal processo a cui appartengono, quindi invece di tenerle in RAM ed occupare così preziosa RAM per nulla, vengono swappate nel file di paging. Quelle poche volte che il processo in questione ha bisogno di indirizzare quelle pagine, allora quelle pagine vengono caricate nuovamente in RAM: l'accesso sul disco, sul file di paging, appena resosi necessario, causa utilizzo di quelle pagine, determina un elemento di lentezza, specialmente in caso di disco meccanico. Per tornare a noi, se io avessi 32GB di RAM, potrei abolire il file di paging: oltre a liberare dal disco 8GB di spazio (8GB nel mio caso, in generale libero i GB occupati dal file di paging), impongo al sistema di non swappare mai sul disco le pagine fisiche scarsamente indirizzate dai processi, ma di tenerle sempre in RAM (in questa situazione, memoria fisica = memoria virtuale). Se il sistema tiene tutte le pagine sempre in RAM, non ci sarà mai bisogno di accedere al disco, e ciò migliora la fluidità dell'utilizzo del PC. [b] Caso 2 (ho poca RAM): [/b] se io avessi poca RAM installata, 4GB ad esempio, allora devo avere un file di paging abbastanza grande, online consigliano: size del file di paging =RAM installata x 1.5 quindi: size del file di paging = 4GB x 1.5 = 6GB Questo perchè lo schedulatore a lungo termine avrà spesso bisogno di spostare le pagine fisiche meno frequentemente accedute dai vari processi concorrenti, dalla poca RAM che abbiamo al disco, al file di paging appunto, per non far saturare la RAM. [b] Conclusione: [/b] Io, con 8GB di RAM, cosa devo fare? Lascio il file di paging a 8GB? Oppure mi conviene ritoccare questa size? Avevo letto da qualche parte che la size di questo file fosse dinamica, quindi una size allocata all'occorrenza dall'OS, in funzione delle necessità attuali, un pò come il RAM-Disk in Amiga, quindi un'area che si allarga e si stringe da sola in base alle necessità, e che si può anche rendere statica tale size, impostarla manualmente. Come stanno esattamente le cose? grazie! [/quote] formattazione A sinistra Giustificata Nessuna

17 Aprile 2021 Postato da: AMG_Novice_Usr 100% accesso I/O al disco rigido: cause? soluzioni?

Buongiorno, vorrei chiedere un parere a voi esperti. Ho un notebook HP di ultima generazione, citare il modello esatto ha poca importanza, basti sapere che è un quad-core Core i5 di settima generazione, 8GB di RAM, un disco rigido a tracce (quindi non SSD) di 1TB, con sopra Win10 come OS. È sempre stato lento, con alti e bassi. Abbastanza recentemente ho notato, grazie ad un programma di performances-monitoring (uno dei tanti che esistono), che la percentuale di accesso al disco passa a gradino dallo 0% al 100%. https://drive.google.com/file/d/1UtA4Rkp-pUDu bH3HrFwkQ9KToAPNuJr4/view https://drive.google.com/file/d/1UELM9FoVwXZE NShx4V-uGc45j37nX78C/view è quasi sempre al 100%, ogni tanto passa istantaneamente allo 0%, per poi tornare subito al 100%. Questo fenomeno si manifesta sempre, compreso all’accensione. Ecco uno screenshot delle apps che il programma di performances-monitoring rileva come applicazioni che accedono in modalità I/O pesantemente/frequentemente sul disco. https://drive.google.com/file/d/18jFI3B_i_e0L qg7D50KJ-vvMw50krC4d/view https://drive.google.com/file/d/1Blbg7QCu3NtH QZwevRKg_ttmryQxmeb2/view

Commenti: 47  Aggiungi - Pagine: 1-2-3

utente amiga quadratico medio Post inviati: 701	Commento AMG_Novice_Usr 18 Aprile 2021    10:32:21
	Citazione se hai un ssd oppure no ed hai sufficiente ram meglio ridurre il file di paging, che in un caso velocizzerà il disco meccanico, nell'altro limiterà scritture su ssd. Io ho la seguente situazione: disco meccanico da 1TB. RAM installata: 8GB file di paging: 8GB pertanto la memoria virtuale è di 16GB. Ci sono pro e contro nel ritoccare manualmente la size del file di paging. Esaminiamo i 2 casi estremi (dimmi/ditemi se sbaglio qualcosa): Caso 1 (ho tanta RAM): se io avessi moltissima RAM installata, facciamo ad esempio 32GB, allora potrei tranquillamente rimuovere il file di paging e fare in modo che non venga più creato, insomma abolire per sempre il file di paging, che dovrebbe coincidere con la swap-area gestita dal long-term-scheduler del kernel dell'OS ... giusto? Se non ho capito male, il file di paging ospita le pagine (le pagine fisiche, invece quelle logiche, virtuali, stanno nella MMU) di processi, pagine che lo schedulatore a lungo termine ritiene di poter tenere sul disco, nell'area di paging appunto (file di paging = area di paging = swap-area), poichè quelle pagine, quelle parti di processo, vengono raramente utilizzate dal processo a cui appartengono, quindi invece di tenerle in RAM ed occupare così preziosa RAM per nulla, vengono swappate nel file di paging. Quelle poche volte che il processo in questione ha bisogno di indirizzare quelle pagine, allora quelle pagine vengono caricate nuovamente in RAM: l'accesso sul disco, sul file di paging, appena resosi necessario, causa utilizzo di quelle pagine, determina un elemento di lentezza, specialmente in caso di disco meccanico. Per tornare a noi, se io avessi 32GB di RAM, potrei abolire il file di paging: oltre a liberare dal disco 8GB di spazio (8GB nel mio caso, in generale libero i GB occupati dal file di paging), impongo al sistema di non swappare mai sul disco le pagine fisiche scarsamente indirizzate dai processi, ma di tenerle sempre in RAM (in questa situazione, memoria fisica = memoria virtuale). Se il sistema tiene tutte le pagine sempre in RAM, non ci sarà mai bisogno di accedere al disco, e ciò migliora la fluidità dell'utilizzo del PC. Caso 2 (ho poca RAM): se io avessi poca RAM installata, 4GB ad esempio, allora devo avere un file di paging abbastanza grande, online consigliano: size del file di paging =RAM installata x 1.5 quindi: size del file di paging = 4GB x 1.5 = 6GB Questo perchè lo schedulatore a lungo termine avrà spesso bisogno di spostare le pagine fisiche meno frequentemente accedute dai vari processi concorrenti, dalla poca RAM che abbiamo al disco, al file di paging appunto, per non far saturare la RAM. Conclusione: Io, con 8GB di RAM, cosa devo fare? Lascio il file di paging a 8GB? Oppure mi conviene ritoccare questa size? Avevo letto da qualche parte che la size di questo file fosse dinamica, quindi una size allocata all'occorrenza dall'OS, in funzione delle necessità attuali, un pò come il RAM-Disk in Amiga, quindi un'area che si allarga e si stringe da sola in base alle necessità, e che si può anche rendere statica tale size, impostarla manualmente. Come stanno esattamente le cose? grazie!
	A500-Plus + A501 + switch meccanico per selezione Double-kickstart 1.3 v. 34.5 / 3.1 v. 40.63 /// A600, Rev. MB. 1.5, espansione in trap-door 1MB chip-ram, Kick-Cloanto 45.66, HDD interno a tracce da 2GB modello MK2104MAV by Toshiba su porta IDE: partizione DH1 con WB2.1 (default) + partizione DH2 con WB3.1 /// A500, Kick 1.3 v. 34.5, scheda espansione in trap-door da 512KB /// A600, espansione da 4MB-fast-ram innestata con zoccolo direttamente su 68K, Kick 2.05 v. 37.300, espansione di chip-ram in trap-door da 1MB, CF da 4GB su adattatore interno CF/IDE: partizione DH0 con CWB GAAE, partizione DH1 con WB2.1, partizione DH2 con WB1.3 /// A500, Rev. MB 6A, Kick 1.3 v. 34.5, A520-TV-RF-Modulator /// A500, PWR-LED ROSSO. Kick 1.2 v. 33.180 /// A500-Plus, PWR-LED ROSSO, Kick 2.04 v. 37.175, Driver DF1 esterno Savage DMF 322, A590 alimentato da alimentatore di CD32, con dentro espansione da 2MB di fast-ram + HDD SCSI Seagate ST32151N da 2GB - DH0 con WB 2.04 e DH1 con WB 1.2 /// A1200, 68EC020, Kick 3.0 v. 39.106, HDD a tracce Hitachi 40GB interno su porta IDE con installato CWB, espansione A1208 in trap-door da 8MB-fast-ram, PLipBox su porta parallela per collegamento via Ethernet a Internet /// Commodore 64 Assy NO. 250425 + floppy drive 5’’ 1/4 modello 1541