/ 3 GB sul server win2k3 con 6 GB di RAM e PAE

Stiamo attualmente valutando l'aggiunta dell'interruttore / 3gb ad alcuni dei nostri server per aumentare il memeory disponibile per uno dei processi in esecuzione (che è compilato con l'insieme di flag di IMAGEFILELARGEADDRESSAWARE) che sta scompattando il limite 2gb.

Tuttavia, quello che sto cercando di capire è come la memory viene suddivisa tra il kernel ei processi utente su un server con RAM> 4 GB. Secondo il doco, Windows dividerà la memory 2gb / 2gb tra il kernel ei processi utente su un sistema 4gb. Quando abiliti / 3gb su un server, la memory è divisa 1gb / 3gb.

Quello che voglio sapere è come si divide la memory su un server con 6 GB di RAM e PAE abilitato? Il kernel è ancora limitato a 1 GB?

Ciao Sam

7 Solutions collect form web for “/ 3 GB sul server win2k3 con 6 GB di RAM e PAE”

Pensavo di submit un follow-up affinché altri cercassero di consolidare le informazioni in un unico post (in base a quanto ho appreso e alle altre informazioni già pubblicate).

PAE:

PAE permetterà ad un server Windows 32bit di utilizzare o più di 4 GB di RAM, con il massimo che dipende dalla versione delle windows in esecuzione (Wikipedia ha un bel riferimento qui )

Una cosa da notare: se è stata triggersta l'triggerszione di DEP (Data Execution Preventson) o NoExecution (NX), questo abiliterà efficacemente PAE senza wherer abilitarla esplicitamente nel boot.ini.

Linea inferiore, PAE non ha effetto della quantità di memory che un solo process a 32 bit può accedere. Interessa solo la quantità totale delle windows di memory in grado di "vedere" e di utilizzare (in modo da poter avere 2 processi ciascuno usando 2 GB, con Windows usando 2 GB su un sistema da 6 GB)

3GB:

In primo luogo, quando parlo della memory disponibile al singolo process a 32 bit, mi riferisco allo spazio di indirizzi virtuali dei processi. Per un process a 32 bit su un sistema operativo Windows 32bit questo è limitato a 4GB.

Su un sistema senza interruttore / 3 GB, il 4 GB di spazio di indirizzi virtuali è diviso da 2 GB / 2 GB tra il process in esecuzione e il kernel di Windows.

Quando abiliti l'interruttore da 3 GB, la divisione nello spazio di indirizzi virtuale viene modificata a 3GB / 1GB. Ciò consente al process di utilizzare più memory a scapito della memory del kernel. Nota: Windows consente solo ad un process di utilizzare più il 2GB o la memory se l'eseguibile è stato compilato con il set di flag IMAGEFILELARGEADDRESSAWARE.

Ora, come è stato accennato in altri post, la pena di utilizzare l'interruttore da 3 GB è che il kernel ha less memory a cui lavorare. E una delle vittime principali della ridotta memory è il numero di voci di tabella di pagina (PTE) disponibili. Una tabella di pagina è la struttura dei dati utilizzata dal gestore di memory virtuale di Windows per memorizzare la mapping tra indirizzi virtuali e indirizzi fisici in memory. Se si dispone di insufficienti PTE gratuiti, le windows potrebbero non assegnare la memory a un process quando richiesto, anche se il process non ha ancora esaurito lo spazio di indirizzi.

Il numero di PTE gratuito può essere misurato utilizzando perfmon (\ Memory \ Free System Table Entry Entries). Tutto sotto 5000 è considerato critico da Microsoft. Ad esempio, sui server citati nel post originale, senza l'interruttore da 3 GB e con il process in esecuzione, il numero di PTE gratuito era di circa 160 k. Dopo aver abilitato 3 GB, ma prima che il process fosse stato avviato, le windows avevano denunciato PTE da 3,5 K (una riduzione drastica). Questo numero sarebbe sceso rapidamente se avessimo avviato il process.

Il modo per compensare questa modifica drammatica è quello di abilitare l'interruttore USERVA nel boot.ini. Impostando USERVA = 2800, questo sposta la divisione da 3GB / 1GB in memory e 'restituisce' circa 250MB di nuovo al kernel per il suo utilizzo. A titolo esemplificativo, dopo aver impostato USERVA = 2800 nel boot.ini sul nostro sistema, il numero di PTE gratuito si trova ora intorno a 60k con il process in esecuzione (molto meglio di quanto abbiamo visto 3.5k).

Ulteriori informazioni sull'interruttore di USERVA sono disponibili nell'articolo di Microsoft KB.

Vale anche la pena ricordare che l'abilitazione di PAE ha anche un impatto sul numero di PTE gratuito. L'interruttore PAE fa sì che ciascuna voce PTE utilizzi due volte il normale spazio di indirizzi virtuale assegnato.

Speriamo che questo fornisca una sintesi sintetica delle informazioni per chiunque guardi in una data successiva.

Ciao Sam

Ascolta questa puntata di RunAs Radio.

Il focus principale di questo episodio riguarda l'ovvio "perché 64bit è migliore" – tuttavia l'ospite entra in "perché / 3GB vanno evitati". Fondamentalmente riduce notevolmente il numero di voci della tabella delle pagine disponibili sul sistema operativo. Il sistema operativo può diventare instabile.

In una shell di dado – Può essere appropriato per un server che gestisce una singola function (come un controller AD o SQL Server), tuttavia dovrebbe essere evitato in un sistema che fornisce molteplici funzioni. Alla fine della giornata "il tuo chilometraggio può variare" – ricorda che / 3GB può facilmente rendere il sistema operativo instabile.

Si consiglia di considerare un sistema a 64 bit anche se l'applicazione è solo 32 bit. Su Windows x64, i processi a 32 bit ottengono 4 GB di RAM, non 2 GB.

Per ulteriori informazioni, vedere la sezione di memory virtuale di KB294418 .

Da quello che so, l'interruttore PAE consente l'accesso a una memory superiore a 4 GB alle applicazioni sul server. Secondo questo tecno le applicazioni non conoscono veramente questo swapping di memory, è tutto gestito all'interno di Windows. Penso che utilizzando l'interruttore / 3 GB nel server da 6 GB limiterebbe il kernel a 1 GB. Un'altra limitazione introdotta dall'uso contemporaneo di / 3GB e / PAE è che il server non risolverà più di 16GB.

A less che non si sta cercando di estrarre each MB di memory per l'applicazione, è ansible utilizzare solo / PAE senza / 3 GB. In questo modo, se un giorno in giù la linea si pop in un totale di 24 o 32 GB di RAM, non dovrai cercare di capire perché Windows utilizza solo 16 GB.

Sul mio sistema precedente, ho usato l'interruttore / 3 GB perché una delle mie applicazioni ha bisogno di molta memory. Recentemente ho aggiornato un sistema Vista a 64 bit e ho aggiornato l'applicazione a una versione a 64 bit, che le concede il totale di 12 GB che ho adesso. Tuttavia, altre applicazioni a 32 bit sono ancora limitate allo stesso 3 GB di memory (o 2 GB senza l'interruttore) semplicemente perché non possono vedere oltre le size di un puntatore di indirizzi. (E in sisthemes a 32 bit, i puntatori di indirizzo sono 32 bit …)

Tuttavia, l'interruttore / 3 GB combinato con più di 3 GB di RAM è ancora utile finché Windows è in grado di gestire i puntatori di indirizzo più grandi. Permette a Windows di mantenere più applicazioni in memory, quindi si scambia molto less su disco, cosa che aumenta le performance.

PAE è un trucco hardware in cui il processre ha alcuni pin più per submit un indirizzo. Sono aumentati da 32 pin (bit) a 36 pin. Ciò consente fino a 64 GB di RAM per qualsiasi applicazione che sia a conoscenza di questi pin aggiuntivi. Microsoft fa bene questo uso nel loro software server, quindi Windows può gestire fino a 64 GB. Se il process che mangia quella memory è anche consapevole di questi pin aggiuntivi, potrebbe anche assegnare fino a 64 GB di RAM. Questa tecnica per le applicazioni è denominata Estensione estensioni indirizzo . Naturalmente, questo richiede anche un codice speciale all'interno dell'applicazione per elaborare questa memory e mi ricorda la vecchia era MS-DOS in cui i puntatori di applicazione erano limitati a soli 16 bit prima (64 KB), ma perché il processre aveva 20 pin (in seguito 24 ), è ansible utilizzare puntatori speciali a 32 bit per indicare un indirizzo o semplicemente attenersi ai puntatori più vecchi di 16 bit e rimanere limitati a soli 64 KB. (20 bit è 1024 KB e DOS ha usato tutto al di sopra del basso 640 KB, o 1 GB. 24 bit è 4 GB che è stato popolare per i primi processri 80386 come limite superiore.)

Come leggo l'eccellente post di Mark Russinovich Spingendo i limiti di Windows: memory fisica , sì … che 1 GB di memory disponibile al kernel su un'installazione a 32 bit di Windows con l'interruttore / 3 GB persiste anche su sisthemes con fino a 128GB di RAM (supportta su installazioni a 32 bit di W2K3 Datacenter).

Il limite massimo di 32 bit di 128 GB, supportto da Windows Server 2003 Datacenter Edition, deriva dal fatto che le strutture che Memory Manager utilizza per tenere traccia della memory fisica consumerebbero troppo dello spazio di indirizzi virtuale del sistema nei sisthemes più grandi. Il gestore di memory tiene traccia di each pagina di memory in una matrix chiamata il database PFN e, per performance, mappe l'integer database PFN in memory virtuale. Poiché rappresenta each pagina di memory con una struttura di dati a 28 byte, il database PFN su un sistema da 128 GB richiede circa 930 MB. Windows a 32 bit dispone di uno spazio di indirizzi virtuale da 4 GB definito dall'hardware che si suddivide per impostazione predefinita tra il process utente attualmente eseguito (ad es. Blocco note) e il sistema. Quindi 980MB consuma quasi la metà di 2 GB di spazio di indirizzi virtuali del sistema, lasciando solo 1GB per mappare il kernel, i driver di periferica, la cache del sistema e altre strutture di dati di sistema, rendendo così un taglio ragionevole: *

Raymond Chen, uno dei programmatori di shell Microsoft di Microsoft, ha una grande serie di articoli sul suo blog riguardo l'interruttore / 3 GB, PAE, AWE e NX. Dovrebbero essere richiesti lettura per chiunque cerca di capire come funziona, come interagisce e perché in molte circostanze probabilmente non è quello che vuoi:

http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.