2013-05-17 6 views
5

Sto riscontrando una notevole differenza nell'utilizzo della memoria dell'applicazione .Net utilizzando la stessa app su due copie dello stesso database. L'unica differenza è che nello scenario 1 sto utilizzando una copia locale del database registrata su un'istanza di SQL Server 2005 Express - e nello scenario 2 sto utilizzando una copia remota del database registrata su un'istanza di SQL Server 2008 Enterprise.L'utilizzo della memoria del client SQL Express è diverso dall'utilizzo della memoria del client SQL Enterprise

A mia conoscenza, mi aspetto solo una differenza nelle prestazioni SQL e nell'utilizzo della memoria SQL (poiché Express ha un limite di 1 GB).

Tuttavia, quello che vedo è un'enorme differenza (1 GB) di utilizzo della memoria tra di essi, ovvero lo scenario SQL Express che utilizza principalmente 1 GB di memoria in più. SQL Express sembra anche essere molto più lento in particolare lavorando con tabelle grandi e query di grandi dimensioni - ma mi aspetterei che questa memoria colpisca essere in SQL e non nella mia applicazione consumatore/client ???

L'app si collega al server SQL utilizzando System.Data.SqlClient.SqlConnection ed esegue frequenti operazioni SqlCommand e SqlBulkCopy.

Qualsiasi pensiero utile sarebbe molto apprezzato!

+0

È un'app client ricca? Tutto ciò che differisce è la stringa di connessione? – Rikalous

+0

Quasi, è un'applicazione .Net (non un'app GUI, ma un servizio) che si connette a SQL. E sì, l'unica differenza tra i due scenari di test è la stringa di connessione ... – Jackfruit

+0

Come stai misurando l'utilizzo della memoria? Sta consumando molta memoria in un colpo o in un graduale aumento nel tempo? – Rikalous

risposta

1

Per la seconda domanda sull'espressione lenta su grandi tabelle e query, è normale perché la versione Express consuma più memoria e disco rispetto alla versione aziendale. La versione Enterprise utilizza una funzionalità denominata Avanzata-Lettura e scansione (a.k.a scansioni di giostra), che presenta un'enorme differenza nelle prestazioni di query di grandi dimensioni.

Ad esempio:

Si supponga che UtenteA e UtenteB sia eseguire il comando SELECT * FROM Customer, che si traduce in una scansione di tabella. UtenteA invia prima il comando; UtenteB emette il comando 20 secondi dopo. La tabella ha 100 milioni di righe (è una tabella molto grande) e la scansione è in esecuzione su una macchina su cui non è installata Enterprise Edition. La scansione della tabella per UtenteA inizia a leggere la tabella Clienti nella prima pagina della tabella. Venti secondi dopo, la scansione per UtenteB inizia a leggere le pagine che UserA ha già letto, anche se alcune pagine potrebbero essere già state svuotate dalla cache. A volte questo processo crea una tremenda contesa del disco e attira la memoria.

L'edizione Enterprise esegue un read-ahead avanzato e scansiona leggermente. A differenza delle versioni non Enterprise Edition, quando UserA emette il comando SELECT * FROM Customer, Enterprise Edition inizia la scansione della tabella Clienti. Quando UserB emette lo stesso comando 20 secondi dopo, la ricerca tabella per UtenteB inizia esattamente dove sta attualmente leggendo UserA. Le query UserA e UserB leggeranno entrambe l'ultima pagina della tabella Customers all'incirca nello stesso momento, ma la scansione dell'UtenteB tornerà all'inizio della tabella Clienti per analizzare le pagine che UserA aveva scansionato prima che l'Utente B iniziasse la sua query. Questo processo riduce drasticamente la contesa del disco e l'assorbimento di memoria.

+2

Il punto chiave qui è che l'azienda "mangia" tutta la memoria a meno che non si specifichi una dimensione massima nella configurazione. Il prodotto presuppone che sia l'unica applicazione in esecuzione su un server e si configura in modo appropriato – Hogan

+0

Sì, ma un altro punto chiave per le tabelle di grandi dimensioni è la funzione di impresa denominata "giostra" (come spiegato nella risposta :))! – dixpac

+0

Che non ha nulla a che fare con la domanda dell'OP. – Hogan