Tamanho do SqlServer.exe no gerenciador de tarefas

[NIK]

Pessoal... boa tarde.

Gostaria de uma informação dos usuarios experts.

Tenho um servidor e quando vou verificar o gerenciador de tarefas do windows e classifico por uso de memória, vejo que a tarefa que utiliza mais memória é o sqlservr.exe com 1.643.948 K.

Gostaria de entender se este tamanho é muito ou pouco? se isso pode me trazer algum problema para o trafego de informações? e se tenho (caso seja grande) como diminuir isso ou como administrar esse tamanho?

Meu banco tem 5.980.819 K de tamanha total.

Se alguém puder me ajudar a enteder como devo fazer essas analises eu agradeço.

Obriagado

NIK

[fulvio]

Boa tarde NIK,

O uso de memória está associada basicamente a dois fatores principais: Acessos simultâneos (usuários) e aplicativo.

Acessos simultâneos: quanto maior a quantidade de usuários simultâneos em seu banco, maior será o consumo de memória, uma vez que as conexões abertas e as transações executadas na base possuem correlação direta com a memória utilizada.

Aplicativo: consultas mal feitas e recordsets não fechados são os principais "erros" encontrados em aplicativos.

Quando falo em consultas mal feitas, estou me referindo aos "select * from ...." que o desenvolvedor utiliza para ganhar tempo, pois não precisará identificar os campos que realmente serão utilizados. Então o * trás tudo!!! rs. Poupa tempo também na hora de implementar novos campos, pois o recordset já está pronto!! Não precisará fazer nada para referenciar um novo campo. Isso faz com que a memória seja penalisada, pois terá mais dados inúteis "carregados".

Quando falo em recordsets não fechados me refiro ao processo de: criação dos acessos, carga dos dados e, no final de sua utilização, o desenvolvedor esquecer de fechar e desalocar o espaço utilizado pelo recordset. Mas ai vem a dúvida: o escopo do recordset termina no escopo da função / implementação? Está correto!!! Mas a memória não é desalocada de imediato. Mas e os recordsets globais?? Vai ficar alocado até que o aplicativo seja finalizado. Quem fará a desalocação? O sistema operacional, quando precisar de mais espaço, ou periodicamente pelo garbage collector. Nesta situação, o garbage collector desalocará as memórias das variáveis globais e também das variáveis de escopo, caso ainda não tenha sido desalocada.

Hoje a tecnologia está mais barata, ficando as vezes mais "fácil" resolver o problema via hardware. Mas se a análise não for realizada como um todo, o problema será apenas protelado...

Estes dois pontos para mim são os mais críticos quando se refere a utilização de memória.

[NIK]

Fulvio... obrigado pela resposta.

Porém nossas aplicações são da RM/Totvs, ou seja, todas essas dúvidas colocadas por você realmente não sei se existem, porém, acredito que não seja o caso.

Quando me refiro a preocupação, apenas penso no espaço utilizado, pois não tenho nenhuma referencia... Será que você poderia me passar alguma noção em cima dos números que enviei? não sei nem se isso teria que ser uma preocupação.. rsrs.

Obrigado

NIK

Boa tarde NIK,

O uso de memória está associada basicamente a dois fatores principais: Acessos simultâneos (usuários) e aplicativo.

Acessos simultâneos: quanto maior a quantidade de usuários simultâneos em seu banco, maior será o consumo de memória, uma vez que as conexões abertas e as transações executadas na base possuem correlação direta com a memória utilizada.

Aplicativo: consultas mal feitas e recordsets não fechados são os principais "erros" encontrados em aplicativos.

Quando falo em consultas mal feitas, estou me referindo aos "select * from ...." que o desenvolvedor utiliza para ganhar tempo, pois não precisará identificar os campos que realmente serão utilizados. Então o * trás tudo!!! rs. Poupa tempo também na hora de implementar novos campos, pois o recordset já está pronto!! Não precisará fazer nada para referenciar um novo campo. Isso faz com que a memória seja penalisada, pois terá mais dados inúteis "carregados".

Quando falo em recordsets não fechados me refiro ao processo de: criação dos acessos, carga dos dados e, no final de sua utilização, o desenvolvedor esquecer de fechar e desalocar o espaço utilizado pelo recordset. Mas ai vem a dúvida: o escopo do recordset termina no escopo da função / implementação? Está correto!!! Mas a memória não é desalocada de imediato. Mas e os recordsets globais?? Vai ficar alocado até que o aplicativo seja finalizado. Quem fará a desalocação? O sistema operacional, quando precisar de mais espaço, ou periodicamente pelo garbage collector. Nesta situação, o garbage collector desalocará as memórias das variáveis globais e também das variáveis de escopo, caso ainda não tenha sido desalocada.

Hoje a tecnologia está mais barata, ficando as vezes mais "fácil" resolver o problema via hardware. Mas se a análise não for realizada como um todo, o problema será apenas protelado...

Estes dois pontos para mim são os mais críticos quando se refere a utilização de memória.

[fulvio]

Bom dia NIK,

Pode ter certeza que todas estes problemas existem sim... rs... independente da empresa que desenvolveu.

A sua preocupação é válida. Prevenção é sempre importante.

Uma proporção entre Banco X Memória infelizmente não existe, pois cada implementação possui sua particularidade. Nunca pesquisei, mas dê uma olhada na net que poderá encontrar estudos a respeito disso.

Um exemplo: aqui trabalhamos com um banco específico que é mais ou menos 6 vezes maior que o seu. A modelagem e o aplicativo não são bem estruturados.... rs. A memória utilizada é cerca de 11 vezes maior que a sua (onde tivemos que aumentá-la).

Mesmo tendo um software "fechado", há formas de monitorar suas atividades, como o Trace, tunig do sql, monitoramento de conexões por usuários, etc.

[NIK]

Obrigado Fulvio... irei pesquisar e se achar algo importante e relevante... coloco aqui.

Abs

NIK

Bom dia NIK,

Pode ter certeza que todas estes problemas existem sim... rs... independente da empresa que desenvolveu.

A sua preocupação é válida. Prevenção é sempre importante.

Uma proporção entre Banco X Memória infelizmente não existe, pois cada implementação possui sua particularidade. Nunca pesquisei, mas dê uma olhada na net que poderá encontrar estudos a respeito disso.

Um exemplo: aqui trabalhamos com um banco específico que é mais ou menos 6 vezes maior que o seu. A modelagem e o aplicativo não são bem estruturados.... rs. A memória utilizada é cerca de 11 vezes maior que a sua (onde tivemos que aumentá-la).

Mesmo tendo um software "fechado", há formas de monitorar suas atividades, como o Trace, tunig do sql, monitoramento de conexões por usuários, etc.