Sou programador a 8 anos, mas no Java tenho apenas 3 meses de
prática; aqui na empresa temos um servidor (Core 2 Duo 6300, 2GB RAM,
HD SATAII, Debian-Linux), que roda um site (com cerca de 1.000 acessos
ao dia) todo em Servlet/JSP e alguns robôs. Estes bots varrem outros
sites da internet em busca de informações que são atualizadas em nosso
banco de dados para depois repassarmos aos nossos clientes pelo site.
O problema é que, em alguns momentos, as atualizações do banco de
dados (MYSQL) estão consumindo 100% da CPU. Isso derruba o site e os
robôs que estão em outras Threads. Uso o driver mais novo do MYSQL
para JDBC e acesso o banco por Pool de Conexões, DataSources… (tudo
no TomCat 5.5.25)
Alguém vê onde pode haver algum erro no código, alguma forma de
limitar o uso da CPU… ou a solução é pôr o banco em outra máquina mesmo?
Sendo necessária a utilização de um servidor dedicado ao banco de
dados, qual seria a melhor tecnologia? Passo a usar Entity Beans
(EJB3)? Ou mantenho no JDBC? Hibernate ajuda?
Enfim, acho que dá p/ notar que estou meio perdido. Se alguém puder,
me dê uma luz, mesmo que seja indicando um bom material sobre o assunto.
Que tipos de atualizações? É uma consulta (select) que está varrendo toda a tabela (full table scan)? Uma inserção de grande quantidade de dados de uma vez (batch)?
Geralmente o problema ocorre durante um Insert ou, principalmente, Update de vários registros.
O sistema monta uma String com os comandos SQL gerados pelos bots e a cada 50 registros (para Insert ou Update) abre-se uma transação com o banco e são executadas as instruções. Quando desenvolveram o sistema essa foi a melhor forma encontrada, devido às threads que disparam os bots. Não sei se foi uma boa idéia… mas é como funciona.
Thingol,
Acho que agora entendi o que você já havia perguntado antes sobre o batch, respondendo às perguntas:
1 - Não usa o Batch update. Ele faz um ArrayList com as instruções, depois abre a Connection e percorre a lista atribuindo as instruções SQL a um PreparedStatement.
2 - Só há dois índices: Chave Primária e um Ascendente simples por um campo Varchar (45).
No seu caso um batch update poderia ajudar um pouco. Você não precisa mudar o seu “PreparedStatement” já que um PreparedStatement é um Statement, portanto esses métodos também fazem parte de PreparedStatement.
Eu normalmente como técnico recomendária que você usasse um computador somente para o seu banco de dados, afinal de acordo com você são mais de 1000 acessos diarios, quanto mais livre de outros processos estiver a máquina do DB mais rápida vai ficar, já implantei várias vezes este tipo de solução para servidores de empresas, e quando voce circula dados e DB na mesma maquina mesmo com processadores de dois núcleos ainda há lentidão, isso se torna mais problema do hardware do que do software ao meu ver.
duas soluções:
Ou uma maquina realmente Bi Processada, com dois processadores
Ou duas maquinas gêmeas ou uma mais parruda pro banco de dados, falo isto por que trabalhava numa prefeitura e lá para 140 pc’s que usavam um banco de dados tinhamos uma porrada de servidores, uma média de 15, não psso divulgar as configs mais eram parrudos, monte a solução de duas maquinas separadas, voce vai ver como a performance almenta.
Tem horas que por melhor que seja o desenvolvimento do software a coisa aperta no hardware.
se poder informar a versão do seu kernel fica mais facil compreender algumas coisas…mais se for o 2.6 não vejo que possa ser problemas com o sistema operacional…mesmo não sendo um programador experiênte neste ponto tenho muitas noções rsrsrs