Duvida sobre desempenho do mysql

Opa…
Kra, existem alguns itens a ser analizados nessa história;

• O hardware pra comportar um Aplication Server e um Banco de Dados, razoavel, esta TOTALMENTE fora da jogada;
• Analizar como está o desempenho do servidor de aplicação;
• Analizar como está o banco de dados, se não me engano o MySQL tem o MySQL adminstrator que mostra isso.
  Depois da analálise dessas duas coisas, se estivesse tudo normal, eu começaria testando a app e como está o gerenciamento da persistência dela.
  Quanto a utilização de frameworks, vale apena um estudo para migração.

OK ?

Errr… só pra esclarecer:

O servidor está se portando bem… não temos muito problema com ele…

Toda vez que é executado uma consulta pesada, o MySQL demora pra executar a consulta e como a gente usa MyISAM, o Mysql da locked nas tabelas e nas consultas, e não faz mais nada até que a primeira consulta seja executada.

Não existe nenhum framework de persistência… No sistema foi usado JDBC… sql mesmo… rsrs…

Não utilizamos tbm o padrão DAO… os SQLs foram colocados na grande maioria junto com as classes Forms… e algumas mais complexas ( como atualizações em grupos de tabelas, etc ) em um pacote Business…

Minha solução:

Compra um Servidor ‘SERVIDOR MESMO’;

Ai já dava pra juntar a APP + BD se for o caso dos custos;

E Sentaria com o chefe, e falaria como que tá a arquitetura da aplicação, e que ia necessitar repensar no sistema e aplicar os padrões.

OBS: Crerio que deve estar uma beleza pra dar manutenção nos sistemas em ?

bom dia Elison,

Tem uma ferramenta que é o probe lambda, é uma ferramenta de monitoramento e gerenciamento do Tomcat (inclusive o tomcat q. está dentro do jboss)…

Usei ela recentemente para testar se o pool de conexões de um projeto estava estourando…e consegui ver com clareza onde estava o ‘vazamento’.

Com o probe vc consegue monitorar todos as requests e sessions da aplicação ver os atributos de cada…e matar se necessário…

dá uma olhada:
http://www.lambdaprobe.org/d/index.htm;jsessionid=CFB89F6502BE7E16D00AEDDBBE61310C

t+

ok… até ai tudo bem…

mas… e o que é esse ‘SERVIDOR MESMO’ e é realmente melhor 1 servidor mesmo, ou 2 servidores ( 1 pra aplicação e outro pro BD)

outra coisa é a questão dos lockeds no MySQL… pois se continuar assim, não importa o quão bom seja o servidor, sempre vai ficar travando… entende? a tendência do BD é duplicar até ano que vem… e crescer cada vez mais… então se continuar assim daqui uns dias vai precisar de um prédio para os servidores… rsrsrs…

por isso tamos tentando achar uma solução global…

vc nem imagina… ehauehuahe…

valeww…

[]s e t+…

Gostei da idéia do Lambda Probe…

mas uma pergunta…

Pra instalar, como q faz??? rsrsrs… :oops:

kkkkkkkkkkkkkkkk…

nesse link que te passei…
na parte superior da tela tem um botão ‘INSTALLATION’…
ali diz como INSTALAR…

t+

hehehe… blz… vo dar um olhadinha e tentar instalar a ferramenta, acho q vai ajudar a gente aqui sim…

mas, como disse agora pouco, ainda tem a questão dos lockeds no MySQL… =[

só q aí foge um pouco do contexto da aplicação…
por isso perguntei se alguém já passou por algo parecido…

valewwss…

[]s e t+…

Quantos micros/filiais que utilizam o banco de dados dessas aplicaçao?

Kra… tipo, hoje nós temos umas 60 pessoas que acessam esse sistema o dia inteiro ( horário comercial 08:00 às 18:00 ).

fora isso, temos estudantes/empresas/Instituições de Ensino, que juntos somam umas 1500 visitas por dia…

Mais uma coisinha…

São ao todo 7 filiais da empresa… sendo que mais duas estão pra abrir…

Assim, a tendência é aumentar ainda mais o fluxo de dados…

valewss…

bom, vamos la ver se eu consigo ajudar, apenas conhecendo o q foi postado aqui…

eu acho a ideia de juntar o container e o sgbd equivocada…por uma serie de motivos, incluindo segurança, performance, etc…

vamos a solução do mundo ideial:

1 - ter um Servidor de verdade pro banco, esquece windows.
2 - ter um sgbd de verdade, o Oracle seria a melhor opção.
3 - fazer um trabalho de analise na arquitetura do sistema, e verificar a possibilidade de migração. Uma arquitetura J2EE de verdade pode ser uma possibilidade, aumentando a necessidade de um servidor melhor pro container.
4 - analisar o modelo do banco, verificar se ele esta ajudando na performance, poucas tabelas muito maiores q o resto me cheiram a desnormalização.

na real muito mais coisa tem q ser analizada…tem q ver ate q ponto isso esta realmnte prejudicando a empresa…pra poder convencer quem cuida da grana…q essas mudanças são necessárias…

espero ter ajudado…

flw

O servidor nosso é linux…

A gente ta cogitando a idéia de migrar pra postgres…
mas ainda não é algo 100% certo… talvez a alternativa seja oracle mesmo…

3 - fazer um trabalho de analise na arquitetura do sistema, e verificar a possibilidade de migração. Uma arquitetura J2EE de verdade pode ser uma possibilidade, aumentando a necessidade de um servidor melhor pro container.

essa é a parte mais complicada…
porque pra gente fazer isso, nós pelo menos teríamos que ter o sistema “funcionando”, para que fosse possível ficarmos apenas voltados para desenvolver esse novo projeto…
e como o sistema é enorme, e surge coisas novas a serem feitas a cada dia, infelizmente creio q essa alternativa está longe pra acontecer…

mas é fato que uma hora a coisa vai tudo pro ar, a bomba estoura ai vai ter q ser feito por bem ou por mau… ( e quem cuida da grana não vai poder dizer que não foi avisado)

4 - analisar o modelo do banco, verificar se ele esta ajudando na performance, poucas tabelas muito maiores q o resto me cheiram a desnormalização.

isso tbm é preocupante, mas teremos que fazer tbm…
uma boa hora seria na migração do sgbd…

as alternativas que você passou foram ótimas grande…
tinhamos pensado algo parecido e tal há um tempo, mas fomos travados por uma série de motivos e serviços a serem feitos…

e mesmo agora o que querem da gente é arrumar uma solução “momentânea”… :???:
mas é bom estar ouvindo de você isso q a gente já tanto discutiu aqui…

é triste… mas é a vida… =\

valewss…

Pedro, eu também acho a solução de juntar o BD + App num só, mas concordo contigo pela parte da segunrança.
Mas agora vamos ver pela realidade da empresa…

• Pra empresa ter uma arquitetura dessas ai que o usuário está apresentando, você acha que eles “diretoria” tem interesse de documentar e estudar o que vai ser implementado?

• Moro aqui na região, e geralmente quando chegam as DEMANDAS, (nem solicitação de alteração no projeto é) os clientes querem tudo pra ontem, e os patrões só repassam as pendências para os programadores e falam… isso é pra ontem…

• Mas voltando a história da solução ideial…
  Se a empresa não quis investir num Oracle, DB2, SQL Server da vida… e muito raro que eles vao querer investir agora, pq na mentalidade deles… “ta funcionando… entao ta bom”;
• E pra finalizar nossa infeliz realidade…
  – E por isso que cada dia mais os sistemas estao cada vez mais inseguros e lentos…

concordas ?

eh Cassolato…eu concordo contigo sim…

por isso q no meu post, a “solução” q eu propus, foi a do mundo ideal, por isso tb q no final eu disse q as reais necessidades da empresa teriam q ser avaliadas…

mas sendo um pouco mais realista, se hj eles ja tem 2 maquinas…a compra de um “servidor de verdade” na minha opinião, deveria ser feita apenas para abrigar o sgbd…SE eles mantivemrem o Tomcat, a maquina q ele descreveu no inicio suporta…

eh complicado esse tipo de situação, tentar equalizar as necessidades tecnicas com o budget disponivel, e ate conseguir convencer os executivos da necessidade do invenstimento em tecnologia…q tb tem q ser feito com muito cuidado…

agora meu caro Elison…acho q mudar para o PostgreSQL nao vai mudar muita coisa nao…dentro das dificuldades q vc passou…acho q a primeira melhoria, seria uma analise em cima do modelo do banco…tunning do modelo mesmo…talvez ate a contratação de um especialista seria indicada…depois disso, a aquisição de um bom servidor e do Oracle, acredito eu ser o próximo passo…por causa do cenario atual q pelo visto ja eh critico, e tb pela previsão de crescimento…

isso ja deve ajudar, mas a melhoria e modernização do sistema tb deve ser levado em conta…como vc mesmo disse, eh constante a manutenção desse sistema atual…um sistema com uma arquitetura consistente e atual, com certeza iria diminuir isso, baixando os custos…

bom, espero ter ajudado mais uma vez…

flw

pedrobusko

agora conseguimos nos entender…
Esse é um problema sério e precisa ser conversado muito bem conversado com a diretoria… quanto ao tomcat… 60 acessos concorrentes eu acho tranquilo pra um P4 segurar…
Mas… acho que o estado d urgencia seria a app que teria que passar por uma reforma total, sendo testada de modulo em modulo ao processo de reorganização…

beleza gente…

com certeza ajudou e muito esse bate-papo… o difícil agora é acertar a coisa toda…

mas valew pela ajuda…

mas tenho uma outra perguntinha ( não sei se vem ao caso ou se aqui é o lugar ideal)… rsrsrs…

tipo, no caso do BD em MyISAM, se for convertido pra InnoDB ( que segundo andei pesquisando é bem melhor) há o risco de perda de dados, ou incompatibilidade de tipos??

:???:

valewwss…

Creio eu que não… na verdade o MyISAM é uma estrutura otimizada para consultas, e InnoDB é pra o CRUD em geral, vai vc tem que ver como vai ficar as coisas ai, e adequar

também acredito que não haverá problemas…porém como qq processo de mudança deve ser feito com muito cuidado…com o banco parado, backup completo, etc…

na própria instalação do mySQL existe a opção de instalação, myISAM eh utilizado quando o mySQL eh usado como um datawarehouse…para aplicações de BI q efetuam praticamente só consultas pesadas…no seu caso a melhor opção eh innoDB mesmo…

flw

Soh um comentário, as vezes, idependente do servidor, o problema pode estar nas suas consultas, uma tabela com 1 milhão de registros, se vc não fizer consultas utilizando algum indice ou se sempre fizer uma consulta na tabela inteira, não vai haver banco ou maquina que ajude… trabalhei 2 anos mexendo com bases de 100Gb, tabelas realmente enormes (não era java e o banco não era MySQL tb hehe)… programar alguma consulta sem usar um indice, o teu programa não chegava nem a ter a logica de negócio testada… corrigi vários problemas de performasse, e sempre o problema era na forma como foi programado…

meu conselho é vc ver certinho onde esta o erro, sera de maquina?! ou sera nas suas consultas e na definição do banco de dados?! se vc etstar no banco de dados os sql’s que a aplicação executa, demora muito tb?! não vou dizer com 100% certeza porque não conheço tantos BD, mas pesquisas com like ‘%…%’ ou propriedades que não tenham nenhum indice, geralmente vão ler a tabela toda, e ler tabelas grandes da problema idependente do banco…

outra coisa é utilizar paginação para fazer suas consultas… só que da maneira como esta sua aplicação, sem utilzar um framework de persistencia, sem seguir padrões… alterar tudo para suportar paginação e testar da um bom trabalho…

enfim, boa sorte

Kra… realmente, há um tempo atraz essa questão não era muito pensada aqui, mas conforme foi crescendo o sistema, começamos a verificar consultas pesadas, e a partir daí a estruturar melhor nossas consultas…

Quando vamos fazer uma pesquisa agora, trazemos apenas os campos realmente necessários, e estamos evitando também usar OR… LIKE ‘%%’, etc…
começamos também a usar otimização de sql em algumas consultas, e
temos indices no BD geralmente nos campos que usamos como parâmetros de consulta, mas mesmo assim, quando pesquisamos uma consulta grande diretamente no BD, a resposta é um pouco demorada… =\

O que percebemos é que qdo uma consulta é feita em várias tabelas, o MyISAM do mysql da um locked na tabela inteira… ai ela não pode ser acessada por outra consulta, atualização, etc…

Agora… paginação realmente temos poucas… ( da um trabalho danado fazer tudo na mão… rsrsrs… )

Mas se for o caso, creio que não vamos ter escapatória… hehehe…

Valew grande!

abração…

• ps. eu te add no msn… =]

Gostei deste tópico, estou trabalhando numa aplicação com porte parecido, e uma menor, mas tenho duvidas quanto ao pool de conexões, vou aproveitar este tópico para ver se alguem pode dar umas dicas.

Estou usando Struts e a persistencia atraves de DAO (acessando SQL Server 2005) com uma classe conectando atraves de um pool JNDI configurado no tomcat 5.0.28

A aplicação tem cerca de 40 usuarios conectados ao mesmo tempo (às vezes lendo informacoes, as vezes acessando o BD), mas acessando o banco de dados ao mesmo tempo talvez uns 10 no máximo.

Às vezes a aplicação “trava” no pool, excedendo o limite. Não faço idéia de qual a melhor forma de configurar.

So server.xml configurei a conexão com:
maxActive=50
maxIdle=10
maxWait=120000

estou no caminho ou tem coisa “feia” feita ai?

obs: Comecei a usar o Lambda Probe hoje, ainda não suguei nada de informação da aplicação.