Dimensioni consigliate del file di paging per SQL 2008R2 su Windows 2008R2


25

Questo articolo di Microsoft - Come determinare la dimensione appropriata del file di paging per le versioni a 64 bit di Windows Server 2008 eo Windows 2008 R2 fornisce indicazioni per il calcolo della dimensione del file di paging per Windows 2008 a 64 bit e Windows 2008 R2. Questo senza dubbio funziona benissimo per server di uso generale. Mi chiedo quale sia la guida per SQL Server 2008R2 in esecuzione su Windows 2008 / R2 a 64 bit?

Presumo che vogliamo che nella memoria vengano colpiti solo pochi dati della memoria, altrimenti SQL potrebbe colpire il disco due volte per i dati. SQL Server consente anche ai dati in memoria di colpire il file di paging? Ho cercato la documentazione in linea di SQL Server 2008 R2 come guida, ma non ho ancora trovato alcuna menzione dell'uso dei file di paging.

Ecco un potenziale scenario di utilizzo: dato un server fisico con 64 GB di RAM, è necessario un file di paging per l'intero 64 GB di RAM? Dovremmo attrezzarlo per 96 GB di file di paging? Sembra un po 'eccessivo per un singolo file. So che la saggezza convenzionale è stata che Windows accoppia il file di paging alla memoria nel tentativo di semplificare lo scambio di app sulla RAM, ma è vero? Un file di paging inferiore a 64 GB ostacolerà le prestazioni qui?

Risposte:


15

Non esistono impostazioni speciali per SQL Server che utilizza normalmente solo la memoria fisica

Fai quello che dice MS per Windows e basta

Oh, e compra più RAM comunque mentre siamo uno dei soggetti ... ;-)


6

Guarda dentro lock pages in memory. In questo modo, è possibile dare la preferenza al proprio account del servizio SQL di utilizzare la RAM disponibile piuttosto che il paging su disco. Per saperne di più sulle pagine di blocco in memoria, controlla questo link . Segue uno snippet:

L'opzione Blocca pagine in memoria dei criteri di Windows è disabilitata per impostazione predefinita. Questo privilegio deve essere abilitato per configurare Address Windowing Extensions (AWE). Questa politica determina quali account possono utilizzare un processo per conservare i dati nella memoria fisica, impedendo al sistema di eseguire il paging dei dati nella memoria virtuale su disco. Sui sistemi operativi a 32 bit, l'impostazione di questo privilegio quando non si utilizza AWE può compromettere significativamente le prestazioni del sistema. Il blocco delle pagine in memoria non è richiesto nei sistemi operativi a 64 bit.

Prova questa funzione prima di utilizzarla sui tuoi sistemi.


4
"Bloccare le pagine in memoria" potrebbe forse essere meglio descritto come una protezione, per evitare che il sistema operativo esegua il paging della memoria SQL. support.microsoft.com/kb/918483
Mark Storey-Smith il

4

Sì, per 64 GB di RAM sono necessari almeno 64 GB di file di scambio (consigliati 96 GB). Non a causa del potenziale scambio, ma a causa della progettazione di Gestione memoria di Windows. Ho già parlato di questo problema in precedenza nella dimensione del file di paging del sistema su macchine con RAM di grandi dimensioni :

Quando un processo richiede MEM_COMMITmemoria tramite VirtualAlloc/ VirtualAllocEx, la dimensione richiesta deve essere riservata nel file di paging. Questo era vero nel primo sistema Win NT, ed è ancora vero oggi vedi Gestione della memoria virtuale in Win32 :

Quando viene impegnata la memoria, vengono allocate le pagine fisiche della memoria e lo spazio è riservato in un file di paging.

L'alternativa sarebbe qualcosa come oom_killer .

Quindi segui la raccomandazione, a volte le cose sono un po 'più complesse di quello che sembrano. E non ho nemmeno toccato le complicazioni portate da AWE e il privilegio di blocco pagine ...


Molto interessante ... Come funziona quando si imposta un file di scambio più piccolo della RAM nella macchina? Se davvero dovessimo riservare lo spazio nel file di paging per ogni allocazione di memoria, non saremmo in grado di usare più della memoria della dimensione del file di paging? Non sono sicuro che funzioni in questo modo.
shlomoid,

1
Funziona esattamente così. Una regione VA impegnata deve essere supportata da una prenotazione di scambio reale. Una regione VA riservata non deve essere, ma SQL Server praticamente non richiede mai prenotazioni non impegnate.
Remus Rusanu,

2
Non penso sia corretto. La mia comprensione da varie fonti come i libri di Windows Internals è che lo spazio degli indirizzi virtuali impegnati deve essere supportato da qualcosa di fisico , file di pagina o RAM. Quindi, se si tenta di eseguire il commit della memoria virtuale> ([memoria fisica di Windows] + [dimensione del file di paging]), verrà visualizzato il famigerato messaggio di errore "Il sistema ha poca memoria virtuale". Mark Russinovich ne parla nella sezione intitolata "memoria impegnata" qui .
James L,

5
Penso che tu possa confermare a te stesso che le regioni VA impegnate non devono essere supportate da prenotazioni di scambio semplicemente avviando un sistema senza file di paging e confermando che Windows si avvia, e quindi ci devono essere più di 0 byte di VAS impegnati.
James L

Questo post è sbagliato: è perfettamente possibile eseguire senza un file di paging se si dispone di più memoria rispetto ai requisiti di commit massimi. Ciò significa che non è possibile scrivere comunque crash dump.
Steve365,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.