... esperava poder obter ... uma estimativa aproximada do que deveríamos estar executando.
Sem mais informações sobre suas consultas e tamanhos de dados, é realmente difícil fornecer qualquer tipo de estimativa, muito menos uma estimativa precisa.
Banco de dados: sql server 2008 r2 enterprise database
Windows: Windows 2008 r2 Enterprise de 64 bits, com certeza executando no VMware.
Processador: CPU Intel (R) Xeon (R) E7-4860 a 2,27GHz 2,26 GHz (2 processadores)
Memória instalada: 4GB
Dois processadores (suponho que isso seja exposto na VM como 2 núcleos) podem ou não estar com fornecimento insuficiente. Os núcleos atribuídos a uma VM não são necessariamente mapeados diretamente para núcleos físicos (ou mesmo autorizados a usar 100% de um único núcleo quando necessário!); Portanto, você pode achar que esse é um recurso mais flexível que a memória. Sem mais informações sobre sua carga de trabalho ou configuração de hardware / virtualização, eu diria que aumentar para 4 seria bom.
Alocação de memória. Oh garoto. Isso é muito pouco provisionado para a carga de trabalho. O próprio Windows precisa de um mínimo de 2-3 GB para permanecer feliz, e cada um dos 2 usuários que executam Lances na caixa exigirá pelo menos 500 MB cada. E com isso, a caixa já está no máximo, e eu nem comecei a descobrir quanto o banco de dados vai precisar.
A maioria dos usuários interage com o banco de dados através do site asp.net e do servidor de relatório.
Você não disse, mas se eles estiverem rodando na mesma caixa, os requisitos de memória para eles também deverão ser levados em consideração.
Por fim, temos uma operação de armazenamento de dados bastante envolvida que provavelmente gera 3 milhões de registros por dia por meio de pacotes SSIS que também são executados no servidor.
Supondo que isso seja executado à noite quando não houver usuários ativos no sistema, não vejo isso como um problema, a menos que esteja demorando muito para ser executado. Essa parte das coisas é a menor das suas preocupações; usuários ao vivo são mais importantes.
Nossas solicitações anteriores de memória adicional foram negadas com a resposta comum de que precisamos para executar mais otimizações de consulta.
Como demonstrei acima, a quantidade atual de memória provisionada é completamente inadequada. Ao mesmo tempo, porém, no outro extremo do espectro, é extremamente improvável que você consiga fornecer memória suficiente provisionada para manter todo o banco de dados na memória de uma só vez.
Mesmo que você tenha uma resposta geral como essa (que, a propósito, provavelmente teve mais a ver com a persuasão de sua justificativa para recursos adicionais, e não com o uso real dos recursos), é muito provável que a eficiência do banco de dados seja melhorado. No entanto, não há uma quantidade única de ajustes que possa resolver os problemas que você está enfrentando agora; a sugestão disso é completa para mim.
Eu adotaria a abordagem geral de que a quantidade de memória atualmente provisionada está abaixo do mínimo necessário (que deve ser corrigido o mais rápido possível), e podem ser necessários recursos adicionais para melhorar a experiência do usuário para um nível utilizável enquanto são feitas melhorias para aumentar a eficiência de os sistemas.
Aqui estão alguns pensamentos (em ordem de ataque):
Você ganhará se puder provar quanto desempenho melhora toda vez que obtém mais recursos provisionados. Acompanhe as métricas de desempenho usando o log do Monitor de Desempenho (nota: a parte de log é muito importante), incluindo os tempos de resposta do site, se possível. Comece a fazer isso agora , antes de fazer qualquer outra coisa. Quando você finalmente obtém a quantidade mínima de memória (você não receberá 32 GB imediatamente), de repente você agora tem evidências de que a memória adicionada melhorou as coisas ... o que significa que adicionar ainda mais provavelmente ajudaria também! Se você não coletar uma linha de base na configuração atual, sentirá falta do barco quando as coisas subirem até o nível mínimo recomendado.
Analise as estatísticas de espera do seu servidor . Isso mostrará qual é o maior gargalo no sistema. Você provavelmente terá PAGEIOLATCH_XXo tempo de espera mais comum / mais alto, o que indica muita E / S sendo feita para buscar páginas do disco. Isso pode ser aliviado com a adição de memória, para que as E / S físicas se tornem menos frequentes, pois os dados necessários já estão na memória. Embora essa análise seja praticamente uma conclusão precipitada, o fato de você ter reunido essas estatísticas fornece mais munição ao justificar a necessidade de recursos.
Como mencionei acima, o requisito mínimo para memória não está sendo atendido. Colete o conjunto de requisitos de hardware recomendados para todo o software que você está executando e talvez também faça capturas de tela do Gerenciador de Tarefas. Isso por si só deve ser suficiente para justificar pelo menos 4-8 GB a mais, no local. Se eles ainda recusarem, tente convencê-los a permitir que você experimente por uma semana e devolva depois disso (você está coletando estatísticas de desempenho, para que não precise devolvê-lo, porque no meio da semana você ' será capaz de provar o quanto melhorou a situação). Se eles ainda recusarem, você está sendo preparado para falhar; URLT .
Se você puder descarregar parte da carga de trabalho (em particular, evite a comunicação remota, se possível), isso aumentará a quantidade de memória disponível para o banco de dados, o que é mais crítico.
Você não poderá ajustar o banco de dados inteiro na memória de uma só vez, o que significa que você precisa definir a configuração de memória máxima do SQL Server com muito cuidado para evitar a confirmação excessiva de memória , o que prejudica o desempenho como nada mais . O comprometimento excessivo é realmente ainda pior do que simplesmente não conseguir caber todos os dados na memória. É muito provável que você esteja nesse cenário agora, simplesmente porque não há memória disponível, e é provável que a configuração de memória máxima esteja definida como padrão (ilimitada).
Como você está executando o SQL Server Enterprise Edition e a memória é premium, eu consideraria fortemente implementar a compactação de dados . Isso compensará um aumento no uso da CPU por economia de espaço na memória (e, portanto, acesso a disco reduzido, comparativamente muito lento).
Ajuste o banco de dados. É provável que as estruturas e consultas possam usar melhorias no que diz respeito aos padrões de indexação e acesso. Além disso, se muitos dados estiverem sendo varridos e agregados com frequência, a criação de visualizações indexadas, tabelas de resumo ou relatórios pré-computados pode ser muito útil.
Isso pode ser longo, porque provavelmente significa mais provisionamento de hardware, mas implemente uma solução de cache. A consulta mais rápida é aquela que você nunca faz .
Essas são apenas algumas idéias. O ponto principal é que o ajuste sozinho não resolverá os problemas aqui, nem o hardware sozinho, embora o último provavelmente alivie a maioria dos problemas imediatos. É assim que funciona: jogue o hardware no problema a curto prazo para apagar o fogo e jogue o problema no longo prazo para corrigir a causa raiz da melhor maneira possível.