Problema de desempenho do Oracle

2

Estamos usando uma máquina Oracle 11G que é muito poderosa; tem armazenamento redundante, etc. É uma fera do que me foi dito.

Acabamos de obter este DB para uma ferramenta que, quando cheguei como cooperativa, tinha 20 pessoas usando, agora com mais de 150 pessoas. Eu sou o único trabalhando nisso: (

Atualmente, temos um sistema implantado que distribui scripts PERL em todo o nosso data center, essencialmente nos dando uma espécie de poder de computação "grid".

Os scripts Perl executam uma espécie de simulação e relatam os resultados para o banco de dados. Eles selecionam / inserem. A carga não é muito alta para cada script, mas pode estar acontecendo entre 20 a 50 sistemas ao mesmo tempo.

Temos vários data centers e usuários atingindo o mesmo banco de dados com essa mesma abordagem.

Nosso principal problema com isso é que nosso banco de dados está sobrecarregado de conexões e tendo que abandonar alguns. Às vezes temos mais de 500 conexões. Estes são scripts perl antigos e eles não lidam bem com isso. Essencialmente eles falham e os resultados são perdidos. Eu prefiro evitar ter que reescrever muitos deles, pois eles são mal escritos e são uma dor de cabeça para se olhar.

O banco de dados em si não está sobrecarregado, apenas a sobrecarga de conexão é muito alta. Abrimos uma conexão, fazemos uma consulta rápida e depois descartar a conexão. Ligações muito curtas, mas muitas delas. A equipe do banco de dados basicamente disse que precisamos diminuir o número de conexões ou eles vão nos ignorar.

Como isso é distribuído em nosso farm, não podemos implementar conexões persistentes. Eu faço isso com o nosso servidor web; mas está em um sistema fixo. Os outros são scripts perl que são abertos e fechados pela ferramenta de distribuição e, portanto, não estão sempre em execução.

Qual seria a minha melhor abordagem para resolver esse problema? Os próprios scripts podem esperar que uma conexão seja aberta. Eles não precisam agir imediatamente. Algum tipo de sistema de filas?

Sugeri que você configure algumas instâncias de uma ferramenta chamada "SQL Relay". Talvez um em cada data center. Quão confiável é essa ferramenta? Quão boa é essa abordagem? Funcionaria para o que precisamos?

Poderíamos ter um para cada data center e retransmitir solicitações por meio dele para nosso banco de dados principal, mantendo um pipeline de conexões persistentes abertas? Isso faz sentido?

Existe alguma outra sugestão que você possa fazer? Alguma ideia? Qualquer ajuda seria muito apreciada.

Infelizmente eu sou apenas um estudante trabalhando para uma empresa muito grande e de alguma forma tudo isso caiu em meus ombros (literalmente não há ninguém para pedir ajuda; é uma empresa de hardware, todo mundo é engenheiros de hardware, e o banco de dados a equipe é inútil e na Índia) e eu estou completamente perdida como qual seria a melhor abordagem?

Estou extremamente sobrecarregado e este problema está interferindo no progresso contínuo e basicamente precisa ser resolvido o mais rápido possível; de preferência sem reescrever todo o sistema, comprar hardware (não vai acontecer), ou me atirar no pé.

AJUDE LOL!

    
por jreid42 12.01.2011 / 02:32

4 respostas

11

"Abrimos uma conexão, fazemos uma consulta rápida e depois descarta a conexão. Conexões muito curtas, mas muitas delas."

Eu tentaria com as conexões do servidor compartilhado. O Oracle em execução em uma caixa unix precisa de um processo unix para fazer o 'trabalho' solicitado por uma sessão. Convencionalmente, sob uma conexão dedicada, ele bifurca um novo processo unix quando uma sessão se conecta e mata quando a sessão é desconectada.

Em Servidores Compartilhados, o DBA define um número mínimo e máximo de conexões, digamos 100 e 250. Na inicialização, o banco de dados separa os 100 processos e eles aguardam por conexões. Se receber 150 solicitações, será acionado os 50 processos extras necessários. Se receber 300 solicitações, 50 delas ficarão disponíveis até que um dos 250 (máx.) Processos esteja disponível.

Importante, os processos não estão vinculados a uma sessão específica para a duração da sessão, mas apenas para uma chamada específica (por exemplo, uma inserção ou atualização individual). Isso tem algum efeito no uso da memória. Qualquer coisa retida entre as chamadas deve estar na memória compartilhada (SGA) e não na memória de processo (PGA). No entanto, com menos de 11g, o banco de dados pode mover a memória entre SGA e PGA, o que não é tão grande quanto costumava ser.

Leia mais aqui

    
por 12.01.2011 / 03:53
0

Você testou o sistema se você aumentar o número de conexões? Se você tem um ambiente separado para testar isso, seria bom.

A curto prazo, se você conseguir controlar QUANDO os scripts forem executados, você poderá gerenciá-los para não precisar localizar as conexões a qualquer momento. Em vez disso, você pode ser capaz de arrastá-lo para fora ao longo do tempo. Você diz que os scripts podem esperar por uma conexão, eu diria que parece ser o melhor lugar para começar.

Suponho que também seja possível encontrar melhorias de desempenho localizando as consultas que levam mais tempo para serem executadas. Pode ser possível encontrar melhorias adicionando um índice a uma tabela que pode não estar indexada.

    
por 12.01.2011 / 02:45
0

Você precisa de alguns dados para descobrir isso. Você tem o gerente empresarial da Oracle disponível? Muitas vezes lhe dirá exatamente o que você precisa fazer. Sem isso, você precisará incluir as mensagens de erro que os scripts recebem e qualquer coisa que apareça no log de alerta ao mesmo tempo. 500 conexões não são muito no mundo da Oracle, mas existem parâmetros de configuração que podem precisar ser aumentados.

    
por 12.01.2011 / 03:01
0

A conexão / desconexão do Oracle é bastante cara e o uso de recursos não é rastreado em visualizações normais de estatísticas do Oracle. Você pode ver isso em algum grau no modelo v $ system_time no tempo de conexão, mas eu já vi casos em que isso está desativado por um fator de quatro. Apenas para sair uma figura de estimativa - ter um par de conexões por segundo pode facilmente queimar um núcleo completo em 100%.

Se você tem a CPU para gravar, geralmente está tudo bem, exceto que você está introduzindo latência. A solução é usar o conjunto de sessões, ou seja, criar um conjunto de conexões com o banco de dados e ter uma camada de código que gerencia quem usa essas conexões.

O Oracle multi-threaded server é uma solução de hackers da Oracle e oferece menos do que se espera do nome e do marketing.

    
por 13.03.2011 / 06:42