Come stimate la quantità di memoria da acquistare?

Ho un'applicazione server personalizzata che funziona su Windows 2008 R2. È un servizio Windows cresciuto in casa scritto in .Net che supporta numerosi terminali personalizzati. Ho una macchina di prova che ha una specifica simile al server live e ho una serie di simulatori client che posso usare per produrre un carico che è una ragionevole approssimazione del sistema reale. Devo essere in grado di supportare 12.000 di questi e al momento il server sta esaurendo la memoria (il paging sta attraversando il tetto).

Il mio piano era di avviare solo 100 simulatori, misurare l'utilizzo della memoria, quindi riavviare ancora 100 volte misurare la memoria e ripetere fino a quando il paging inizia a salire (in realtà prenderò più di tre punti dati). Questo dovrebbe darmi una cifra per la quantità di memoria aggiuntiva richiesta per 100 simulatori e mi consente di proiettare quanta memoria è richiesta. Ho solo bisogno di un'idea approssimativa di +/- 30 GB per evitare di acquistare l'intero 2 TB (valore di $ 150.000) che il server prenderà. La mia domanda è se si tratta di un metodo ragionevole da utilizzare e, in caso affermativo, quali contatori delle prestazioni monitorereste per fornire la quantità di memoria effettivamente utilizzata?

Sto specificamente parlando della memoria qui come la differenza tra working set, byte privati, commit, condiviso, virtuale e tutti gli altri termini di memoria mi confondono. Penso di riuscire a monitorare da solo CPU, IO e reti. L'altra cosa che ho notato è che .Net Cache regola l'utilizzo della memoria in base a ciò che è disponibile, il che rende difficile individuare una tendenza.

Onestamente? Io no .
Quando si specifica un server che vedrà qualsiasi tipo di carico di lavoro reale, mi si accumula tutta la RAM che posso ragionevolmente permettermi (i sistemi hanno maggiori probabilità di essere vincolati dalla RAM rispetto alla CPU o al disco: l'unico altro collo di bottiglia garantito è il lato frontale autobus).

Se si vuole capire la quantità di RAM l'applicazione può utilizzare un test di carico di base come hai proposto è un buon inizio, ma se già avete questo sistema in produzione (suona come si fa) e il sistema di produzione è scambiare la tua l'attività è più semplice: scopri quanto spazio di swap stai utilizzando -> Aggiungi almeno 2 volte quella RAM (arrotonda per adattarla ai vincoli delle dimensioni DIMM del tuo sistema).

Se esegui un test di carico per ottenere numeri approssimativi ed estrapolare da lì, ricorda di considerare alcune cose:

1. La curva di memoria sarà probabilmente due segmenti distinti
   (la nitidezza iniziale aumenta man mano che vengono memorizzati nella cache quadri / librerie condivise, quindi una curva leggermente meno ripida quando viene inserito in memoria il codice non condivisibile di ogni nuova app)

2. Hai ancora bisogno di RAM libera per la memorizzazione nella cache del disco e della libreria condivisa e per il sistema operativo.
   (Questo dovrebbe essere almeno un paio di concerti su ciò di cui la tua app ha bisogno)

3. TUTTO il software perde memoria (almeno tutto il software pratico lo fa), quindi fai attenzione ai tuoi test e assicurati di avere lo spazio per affrontare una perdita.

4. Il tuo carico probabilmente aumenterà nel corso della vita del server. Pianificare di conseguenza.
   (Se non si dispone di buoni numeri di pianificazione della capacità, raddoppiare il carico di lavoro di oggi e pianificare di gestirlo).

5. Acquistare troppa RAM oggi è più economico che far cadere il tuo ambiente domani.

   • Primo corollario: se acquisti un server leggermente più grande di quello di cui hai bisogno, sei l'amministratore prescient che ha fatto funzionare l'azienda. Sarai in gran parte ignorato e non apprezzato.
   • Secondo corollario: se ridimensionate la macchina e ci sono problemi, siete il buffone incompetente che non poteva prevedere una crescita del 500% e tutti vi odiano.

Grazie, l'aggiornamento almeno fornisce a tutti un indizio. Il fatto che stai contemplando 2 TB di memoria significa che stai giocando in un campo da baseball diverso dalle solite configurazioni. Grande sistema. odio pensare a quanto calore si diffonderà.

Dato che si tratta di un processo server interno e che si sta esaurendo la memoria (non si dice a quale livello si avvia il paging), ma vorrei eliminare la possibilità che il processo server stia consumando quantità di memoria sempre maggiori prima di andare ulteriore. Se ciò accade, non fa alcuna differenza ciò che fai, il sistema si fermerà a un certo punto.

Non conosco strumenti generici che puoi usare per darti molto più di una semplice panoramica di ciò che sta succedendo ... cosa viene fornito con Windows. Il processo di assistenza stesso è una scatola nera e il team di sviluppo deve fornire strumenti di monitoraggio.

Ritorno rapido del calcolo della busta:

2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session

Questo non sarebbe fuori dall'intervallo del normale set di lavoro di exe .net.

Il servizio ha più thread? Se stanno lanciando un thread per ogni connessione, varrebbe la pena vedere come lo stanno facendo. ProcExp.exe di microsoft è un modo semplice per vedere se hai più thread e cosa stanno consumando. Non conosce .net ma ti darà contatori win32.

Potete indicare quanta memoria e quante connessioni avete avuto durante i test prima di iniziare il paging?

Quindi, come stabilire se il processo del server presenta problemi di perdita di memoria? Potrebbe accumulare più memoria ad ogni sessione connessa, oppure potrebbe accumulare memoria e non liberarli mai.

Quello che potresti fare è: scegliere un numero di sessioni che non provoca il paging e simulare quel numero di connessioni. - Esegui la simulazione per alcune ore e usa perfmon per guardare i contatori di memoria di base. - Ripetere questi test con sessioni che si collegano brevemente e si disconnettono.

L'idea è di vedere se il servizio consuma sempre più memoria con ogni sessione, o se le sessioni aperte provocano un uso sempre maggiore della memoria.