Quanta RAM o servidor realmente precisa?

Eu tenho muitos servidores implantados em todo o mundo. Eles estão executando o Windows 2003 x64 com o SQL Server 2005 x64 com 6 GB de RAM. As caixas não têm a melhor (ou até aceitável) configuração, porque o cara que as encomendou anos atrás não sabia realmente o que estava fazendo.

As caixas estão ficando constantemente sem memória, acabam usando o arquivo de paginação e tudo fica mais lento. Normalmente, a taxa de confirmação é de 5,8 GB e, quando alguém precisa fazer algo intensivo (por exemplo, executar um relatório), esse número passa pelo telhado.

Eu tenho tentado obter os poderes que requerem mais memória, mas estou recebendo uma oposição massiva (por exemplo, tornar o software mais eficiente, custar muito para todos esses servidores ou provar que a caixa não possui memória suficiente, etc. ..)

Existem diretrizes (ou uma fórmula) para quanta RAM uma caixa precisa que eu possa apresentar para não-técnicos, para que possamos finalmente pedir mais memória?

Não há realmente nenhuma maneira de dizer facilmente, porque é totalmente dependente do seu uso e do aplicativo. Você está chegando ao limite de um servidor de banco de dados ... qual o tamanho do banco de dados? Quais são as suas estatísticas de transação?

As limitações do mundo real são óbvias no seu cenário. Você está concorrendo por um tempo em 6 shows sem problemas, então ele está trocando e se debatendo.

Se o desempenho é suficiente para impactar os negócios, seus superiores devem ouvir reclamações suficientes de que é prudente aumentar a memória. Descubra quanto custa seu tempo e, em seguida, quanto vai custar para "ajustar" o servidor e solucionar problemas de ajuste, quando a memória adicionada ao servidor pode muito bem resolver o problema do custo de memória e menos de meia hora de tempo de inatividade.

Você não saberá a quantidade exata de memória necessária até realmente implantar seu uso na vida real e trabalhar a partir daí.

Dito isso, convém verificar se seu aplicativo é realmente o gargalo. Execute o monitor de desempenho do Windows para ver as estatísticas de E / S do disco e a taxa de transferência de rede. Veja também qual é o seu nível de fragmentação (o Google é um bom amigo aqui ). Você também pode tentar auditar o código quanto a problemas óbvios quando uma consulta estiver sendo extremamente ineficiente ( Google novamente ).

Mas, novamente, tudo depende de quanto isso está impactando os negócios. Vale mais a pena investir no ajuste ou é ruim o suficiente para lançar o hardware primeiro e depois tentar ajustá-lo?

Uma maneira fácil de verificar se você precisa de mais RAM é traçar um gráfico do contador de desempenho da vida útil da página. Esse contador informa quanto tempo o SQL Server considera que os dados serão mantidos no buffer pool antes de precisar abrir espaço para outros dados. Você deseja esse número o mais alto possível. Com 6 Gigs de RAM instalados (você deve ter o SQL configurado no máximo em provavelmente 4 GB), você provavelmente só manterá os dados na memória por alguns minutos, no máximo, quando alguém executar um grande relatório, verá esse tanque de números até alguns segundos. Quanto mais RAM você tiver, mais dados poderão ser mantidos na memória e menos leitura dos discos precisará ser feita.

Por exemplo, os sistemas com os quais estou trabalhando no momento têm 256 Gigs de RAM e mantemos os dados na memória por cerca de 12000 segundos.

Por favor, não peça um número alvo, apenas o número mais alto possível. Sem saber muito mais sobre seus sistemas, não posso dar um bom número para procurar.

Hmmmm. Bem, 6 GB são uma quantidade razoável de RAM, mesmo para uma grande instalação do MSSQL. Você pode realmente procurar e garantir que seu código seja realmente eficiente. Uma transação de 6 GB é um pouco incomum ... Eu trabalhei em sistemas de folha de pagamento em todo o estado que não superaram um show no processamento do ano 1099 ... E para ter um rodando com frequência ? Eu não sei. Com que tipo de dados você está trabalhando?

Dito isto, você pode encher a quantidade de RAM que desejar em uma caixa de 64 bits, e a memória RAM é muito barata, por isso, pode colocar o máximo possível lá dentro ... Você realmente não pode ter muita memória RAM em um servidor de banco de dados.

Edit: Isso está desatualizado agora. Eu tenho caixas MSSQL com 256 GB de RAM.

Antes de começar a comprar mais memória (ou qualquer outro componente), recomendo executar uma análise de desempenho no servidor. Você pode fazer isso sozinho usando perfmon ou pode usar ferramentas de terceiros. Você deve analisar o desempenho do servidor OS e SQL. IMHO, muitas vezes estamos prontos para lançar um problema em hardware antes que uma análise adequada seja feita. Pelo que você sabe, neste momento, pode haver um problema com uma consulta, procedimento armazenado, plano de execução, E / S de disco, utilização da CPU, etc. etc. A pressão da memória geralmente pode ser um sintoma de outro gargalo no sistema.

como "Satanicpuppy" disse, não existe muita memória RAM, mas 6 GB devem estar ok, talvez você deva repensar o que seu servidor faz, não acho que você tenha um problema de "hardware", você deveria concentre-se na sua programação SQL ...

Quando se trata de servidores de banco de dados, não existe memória "suficiente". Claro, depende do que eles realmente fazem e executam, mas se for um banco de dados constantemente utilizado, contendo muitos dados e realizando consultas complicadas - 6 GB podem ser facilmente inadequados.

Eu começaria atualizando um servidor problemático para pelo menos 32 ou 64 GB e ver se isso ajuda. Caso contrário, ative o ajuste do banco de dados, a solução de problemas e a depuração de aplicativos - que, a menos que um idiota tenha projetado o banco de dados, custam muito mais do que algumas varas de memória de nível de servidor (e mesmo que um idiota tenha projetado isso, obtendo um design ainda mais óbvio) erros corrigidos com suporte retido podem ser um grande desafio).

Dito isso, como outra pessoa afirmou - poderia ser outra coisa que o impede (além de problemas de design de software), como a falta de desempenho de E / S de disco ou de rede - contratar um profissional de DBA para passar pelo monitoramento básico de desempenho SQL dia poderia ser útil.

Você deve criar mais índices. Eu acho que, em geral, a maioria das pessoas sub-indexa seu banco de dados.

Ainda é um código de ar, ainda não testei completamente, mas deve levá-lo na direção certa

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