Di quanta RAM ha effettivamente bisogno un server?

Ho parecchi server distribuiti in tutto il mondo. Stanno eseguendo Windows 2003 x64 con SQL Server 2005 x64 con 6 GB di RAM. Le scatole non hanno la configurazione migliore (o nemmeno accettabile), perché il ragazzo che le ha ordinate anni fa non sapeva davvero cosa stesse facendo.

Le caselle esauriscono la memoria in modo abbastanza coerente, finiscono per utilizzare il file di paging e tutto rallenta. In genere la commissione di commit è di 5,8 GB e quindi quando qualcuno deve fare qualcosa di intensivo (ad esempio eseguire un rapporto), quel numero passa attraverso il tetto.

Ho cercato di ottenere i poteri necessari per ordinare più memoria, ma sto ottenendo un'enorme opposizione (ad esempio, rendere il software più performante, costare troppo per tutti questi server o dimostrare che la scatola non ha memoria sufficiente, ecc. ..).

Esistono linee guida (o una formula) per la quantità di RAM necessaria per una scatola che posso presentare ai non-tecnici, in modo da poter finalmente ordinare più memoria?

Non è proprio un modo per dirlo facilmente perché dipende interamente dal tuo utilizzo e dall'applicazione. Stai esaurendo un server di database ... quanto è grande il database? Quali sono le tue statistiche di transazione?

I limiti del mondo reale sono evidenti nel tuo scenario. Stai correndo per un po 'su 6 concerti senza problemi, quindi si scambia e si rompe. Quindi 6 concerti non sono sufficienti.

Se le prestazioni sono sufficienti a influire sul business, i tuoi superiori dovrebbero sentire abbastanza lamentele che è prudente salvare la memoria. Scopri quanto costa il tuo tempo e poi scopri quanto costerà "ottimizzare" il server e risolvere i problemi di ottimizzazione, quando la memoria aggiunta al server potrebbe risolvere il problema per il costo della memoria e meno di mezz'ora di inattività.

Non conoscerai l'esatta quantità di memoria di cui hai bisogno fino a quando non ti dispieghi effettivamente nel tuo utilizzo nella vita reale e lavori da lì.

Detto questo, potresti voler verificare che la tua applicazione sia davvero il collo di bottiglia. Esegui il monitor delle prestazioni di Windows per visualizzare le statistiche di I / O del disco e la velocità effettiva della rete. Scopri qual è anche il tuo livello di frammentazione ( Google è un buon amico qui ). Potresti provare a controllare il codice anche per ovvi problemi in cui una query è enormemente inefficiente (di nuovo Google ).

Ma ancora una volta tutto dipende da quanto gravemente questo ha un impatto sul business. Vale la pena investire di più nell'ottimizzazione o è abbastanza brutto lanciarvi prima l'hardware e poi provare a sintonizzarlo?

Un modo semplice per vedere se hai bisogno di più RAM è di tracciare il contatore dei perfmon della Life Life Expectancy. Questo contatore indica per quanto tempo SQL Server ritiene che i dati verranno conservati nel pool di buffer prima di dover fare spazio per altri dati. Vuoi questo numero il più alto possibile. Con 6 GB di RAM installati (dovresti avere SQL impostato al massimo probabilmente a 4 concerti) probabilmente manterrai i dati in memoria solo per pochi minuti al massimo, quando qualcuno esegue un report di grandi dimensioni vedrai questo numero serbatoio fino a pochi secondi. Più RAM hai, più dati possono essere conservati in memoria e minore sarà la lettura dai dischi.

Ad esempio, i sistemi con cui sto lavorando al momento hanno 256 GB di RAM e conserviamo i dati in memoria per circa 12000 secondi circa.

Per favore, non chiedere un numero target da colpire, vuoi solo il numero più alto possibile. Senza sapere MOLTO di più sui tuoi sistemi non posso dare un buon numero per cui sparare.

Hmmmm. Bene, 6 concerti è una discreta quantità di RAM, anche per una grande installazione MSSQL. Potresti effettivamente voler cercare e assicurarti che il tuo codice sia davvero efficiente. Una transazione a 6 concerti è un po 'insolita ... Ho lavorato su sistemi di gestione stipendi statali che non hanno superato un concerto nell'elaborazione di fine anno 1099 ... E di averne uno in esecuzione spesso ? Non lo so. Con quale tipo di dati stai lavorando?

Detto questo, puoi riempire tutta la RAM che vuoi in una scatola a 64 bit, e la ram è sporca a buon mercato, quindi potresti anche metterne la maggior parte che puoi ... Non puoi davvero avere troppa RAM su un server di database.

Modifica: ora è decisamente obsoleto. Ho scatole MSSQL con 256 GB di RAM.

Prima di saltare la pistola sull'acquisto di più memoria (o qualsiasi altro componente), consiglierei di eseguire un'analisi delle prestazioni sul server. Puoi farlo da solo usando perfmon o puoi guardare usando strumenti di terze parti. È necessario analizzare le prestazioni sia del sistema operativo che del server SQL. IMHO, troppo spesso siamo pronti a lanciare un problema hardware prima che sia stata eseguita un'analisi corretta. Per quanto ne sai a questo punto, potrebbe essere un problema con una query, una procedura memorizzata, un piano di esecuzione, I / O del disco, utilizzo della CPU, ecc. Ecc. La pressione della memoria può spesso essere un sintomo di un altro collo di bottiglia nel sistema.

come ha detto "Satanicpuppy", non esiste una quantità eccessiva di RAM, ma 6 GB dovrebbero essere ok, forse dovresti ripensarci su ciò che fa il tuo server, non penso che tu abbia un problema "hardware", dovresti concentrati sulla tua programmazione SQL ...

Quando si tratta di server di database non esiste una memoria "sufficiente". Certo, dipende da cosa effettivamente fanno ed eseguono, ma se si tratta di un database costantemente utilizzato che contiene molti dati e fa query complesse - 6 GB potrebbero essere facilmente inadeguati.

Vorrei iniziare aggiornando un server problematico ad almeno 32 o 64 GB e vedere se aiuta. Altrimenti, passa all'ottimizzazione del database, alla risoluzione dei problemi delle applicazioni e al debug - che tutti, a meno che un idiota non abbia progettato il database, costino molto più di qualche stick di memoria di livello server (e anche se un idiota ha progettato la cosa, ottenendo un design persino ovvio gli errori corretti con il mantenimento del supporto potrebbero rivelarsi una vera sfida).

Detto questo, come ha affermato qualcun altro, potrebbe essere qualcos'altro che lo trattiene (a parte i problemi di progettazione del software), come una mancanza di prestazioni di I / O del disco o della rete, assumere un professionista DBA per passare attraverso il monitoraggio delle prestazioni SQL di base per un il giorno potrebbe rivelarsi utile.

Dovresti cercare di costruire più indici. Penso che in generale, la maggior parte delle persone sottoindicizzi il proprio database.

Questo è ancora codice aereo, non ho ancora testato completamente, ma dovrebbe portarti nella giusta direzione

http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100