Já falei algumas vezes por aqui que eu trabalho no Expresso Itamarati, uma empresa de transporte de passageiros do interior de São Paulo, que inclusive foi alvo de aquisição recente. Pois bem, aqui temos um sistema de venda online e, me desculpem os puristas dos milisegundos, realtime de venda de passagens, desenvolvido todo por mim, em Java (haviam planos para Rails esse ano, vamos ver).

Acreditem, tem duas aplicações "servidoras" desse sistema em um PIII com 256Mb com um monte de gente conectada nele, e não está lento! A lentidão reside no jeito que se faz as coisas, certo? ;-)

Pois bem, no último feriadão, na Páscoa, tivemos aquele medo geral da turma em relação aos problemas com o setor aéreo, e, resultado, uma boa parte viajou de carro ou de ônibus, o que foi interessante para nós aqui. Só que notei um comportamento estranho do sistema devido ao número muito maior de acessos (tanto no sistema em si como o site da empresa), e tive que investigar para ver o que estava acontecendo.

A causa era que o número de cursores do Oracle, que é o banco que utilizamos na aplicação, foi "estourado", providenciando várias mensagens simpáticas de erro nos logs dos servidores da aplicação (ah, vale uma observação: essa aplicação não é J2EE). Para evitar que isso se repita, decidi monitorar o número de cursores abertos e verificar se eles se aproximam do valor máximo (que já duplicamos depois dessa experiência).

Trocando uma idéia com o DBA aqui chegamos na seguinte consulta:

select abertos, maximo, round(100/(maximo/abertos),2) as porcentagem from 
(select count(*) as abertos from v$open_cursor),
(select value as maximo from v$parameter where name= 'open_cursors')

Essa consulta retorna o número máximo de cursores alocados na configuração do banco e quantos estão em uso. Coloquei uma thread no sistema para verificar regularmente se tem algum limite chegando, e se tiver, liberar alguns recursos do sistema, deixando o banco de dados feliz e tudo funcionando, somente com algum "pipoco" rápido para o nosso usuário.

Agora o engraçado foi detalhar essa solução para um gerente (ei, sou gerente também!):

Eu: _E com isso vamos ter monitoramento que vai evitar mal-funcionamento, deixando o sistema um pouco instável por muito pouco tempo mas garantindo que a carga vai ficar normal em situações de muitos acessos ...
Gerente: _Instável por quanto tempo?
Eu: _Um minuto, menos, por aí.
Gerente: Ah, não sei não hein, acho que vai ficar complicado ...

Aquele negócio né: dá a mão, quer o braço. ;-)

Comentários

Comentários fechados.

• TaQ dom, 22 de abril de 2007, 14:03:40 -0300

  Rael,

  Eu devia ter feito um teste de sobrecarga levando em conta o apagão aéreo. ;-)
  E a versão em Rails ... depois que a empresa aqui foi alvo de uma aquisição, como já mencionei, todos os planos mais audaciosos foram colocados de molho até segunda ordem. Vamos ver o que vai virar.

• Rael (Peter Parker) dom, 22 de abril de 2007, 08:35:49 -0300

  É TaQ, se tivesse feito teste de sobrecarga, isso não teria acontecido! :)
  (Hahaha, brincadeira, você sabe que eu trabalho com isso, então, só estou enchendo!)
  É realmente incrível essa fud de Java ser lerdo, né?
  E a versão em Rails, alguma previsão de sair do forno?

• marcelo toscano sex, 20 de abril de 2007, 04:06:00 -0300

  Nem me fala em lentidão, aqui na empresa teve uma época que as coisas ficaram complicadas.
  A turma penou pra resolver o problema, mas o duro mesmo, foi que a esquipe de SQL (no caso Microsoft SQL SERVER), colocando a culpa no pessoal de PHP e o pessoal do PHP colocando a culpa na turma de SQL.
  Agora, advinha qual era a acusação do pessoal de PHP pro pessoal do SQL?

  []s
  Toscano

• TaQ qui, 19 de abril de 2007, 08:54:50 -0300

  Shoes,

  Também não tem stored procedures lá. :-)

  Como comecei o projeto em 1999 (um monte de gente achava que Java só prestava para applets naquela época né) fiz basicamente um esquema de criar um protocolo plain entre o cliente e o servidor, onde o servidor que armazena a lógica de cada operação e "conversa" com o cliente Swing, mas sem EJB e coisa do tipo, apesar que já tinha a especificação 1.1 no final de 1999.

  Ele começou como uma GUI em AWT e depois fui para o Swing, rodando rápido (após a carga inicial) até em PII 200mhz na época, e o bichinho continua a funcionar bem nesse mesmo esquema até hoje.

  Aí você pergunta "mas e a manutenção não fica complicada nessa metodologia de desenvolvimento" ... bom, tem eu sozinho cuidando do bicho desde aquela época, um lance sossegado para um sistema que atende mais de 80 agências de venda com vários usuários em cada, usando essas maquininhas modestas para o processamento. Mas esse lance do sistema é outra (e comprida) história. O importante é que peguei o Oracle no pulo. :-)

• Phillip Calcado qui, 19 de abril de 2007, 08:17:36 -0300

  Sei nao, heim... cheirinho de logica de negocios no banco de dados detectado :P

• TaQ qui, 19 de abril de 2007, 08:08:20 -0300

  Tranquilo nada, você tem que ver as brigas de foices que saem entre os gerentes! Reportar somente ao dono seria uma beleza ... :-)

• Aguinelo Pedroso qui, 19 de abril de 2007, 08:01:42 -0300

  Já vi relatos do mesmo problema com o Oracle, um colega da faculdade é DBA e vive comentando sobre problemas que só aparecem depois de um aumento significativo de acessos simultâneos.

  Gerente é complicado mesmo, ainda bem que sou consultor independente e preciso me reportar somente ao dono da empresa. No seu caso é mais tranquilo, é gerente também...hehe

  Abraços TaQ