Pro e contro dell'uso di SetProcessWorkingSetSize

Question

Ho un problema con la gestione della memoria nella mia applicazione. La memoria dell'applicazione sta crescendo rapidamente durante il runtime. Sto usando i set di dati nella modalità disconnessa. Per ovviare a questo problema, sto svuotando il DS frequentemente e usando anche SetProcessWorkingSetSize per gestire l'utilizzo della memoria. Sta funzionando bene nel mio computer di sviluppo. Quali sono i pro e i contro dell'uso di SetProcessWorkingSetSize?

Answer 1

SetProcessWorkingSetSize() controlla la quantità di RAM utilizzata dal processo, altrimenti non influisce sulle dimensioni della memoria virtuale del processo. Windows è già abbastanza bravo a controllarlo dinamicamente, scambiando le pagine di memoria su richiesta quando un altro processo ha bisogno di RAM. Facendo ciò manualmente, si rallenta molto il programma, causando molti errori di pagina quando Windows è costretto a scambiare nuovamente le pagine di memoria. SetProcessWorkingSetSize viene in genere utilizzato per aumentare la quantità di RAM allocata per un processo. O forzare un assetto quando l'app sa che resterà inattivo per un lungo periodo. Anche fatto automaticamente dalle vecchie versioni di Windows quando si riduce a icona la finestra principale dell'app.

Non è necessario eseguire il pinvoke di questo btw, è possibile utilizzare le proprietà Process.GetCurrentProcess.Min/MaxWorkingSet.

Answer 2

L'unico caso di utilizzo corretto che ho visto per questa chiamata è quando SAPETE che il vostro processo sta per intasare molta RAM del sistema e volete riservarlo per la durata. Lo usi per dire al sistema operativo "Sì, mangerò gran parte della RAM del sistema durante tutta la mia corsa e non mi intrometterò".

In questa situazione, lasciare il comportamento predefinito del sistema operativo in posizione non è corretto. Il sistema operativo assegna un numero predefinito di MB di RAM a ciascun processo, in pratica il suo spazio di lavoro. Le sue euristiche di gestione delle risorse non sono oracoli, quindi se rilevano un processo che mangia molto più della sua quota di risorse di sistema (come la RAM), cercheranno di recuperare il più possibile. Per il tuo processo questo significa che il sistema operativo sprecherà molta CPU (e quindi danneggerà le tue prestazioni) effettuando il paging della memoria dentro e fuori lo spazio degli indirizzi quando non è necessario.

Answer 3

Abbiamo scoperto che, per un'applicazione GUI scritta in Delphi per Win32/Win64 o scritta in modo simile che utilizza librerie grandi e pesanti sopra l'API Win32 (GDI, ecc.), Vale la pena chiamare SetProcessWorkingSetSize una volta.

Chiamiamo con i parametri -1, -1, entro una frazione di secondo dopo che l'applicazione è stata completamente aperta e ha mostrato all'utente la finestra principale. In questo caso, SetProcessWorkingSetSize (... -1, -1) rilascia un sacco di codice di avvio che sembra non essere più necessario. La memoria ripristina rapidamente a circa 1/3 di quello che sarebbe stato senza SetProcessWorkingSetSize (... -1, -1), ma non cresce più. Pertanto, abbiamo salvato in modo efficace 2/3 della memoria del codice di avvio (caricamento e analisi dei file di configurazione, inizializzazione della GUI, ecc.) Che potrebbe non essere mai stato necessario.

Se si dispone di un'applicazione GUI, è possibile eseguire il test sulla propria applicazione allo stesso modo - basta chiamarlo una volta e vedere quanti memoria sono stati rilasciati definitivamente.

Anche per un'applicazione server (servizio) che non dispone di GUI - Penso che chiamare SetProcessWorkingSetSize una volta che il server è stato caricato e inizializzato completamente potrebbe essere stato utile.