Threads - Quase grupo

10 respostas
MarceloNeo

Bom dia Galera GUJ,

Como vocês resolveriam este problema.
Eu tenho um programa que é para fazer migração de “Qualquer Banco” para “Qualquer Banco de dados”

Montei um Thread para ir mais rápido, pois assim vou ter vários Objetos persistindo no banco dados ao mesmo tempo.
Disparo um conjunto de 40 Threads.

Depois disso!
Dispararam-se mais um Conjunto de 40 Threads mas, corro o risco de dar Heap size memory.
Como vocês resolveria esse problema.

Até pensei nessa forma… Colocar mais uma variável controle Thread,
Onde ele aguarde pela 40… Até ela terminar sua execução…

Então é alguma coisa, mas não é a solução… Por que a ultima instanciada no conjunto…
Precisamente não será a ultima terminar sua execução?

Entendem… A suposta a ultima instanciada, dispararia mais 40…

Como vocês resolveria isso?

Já li a respeito de TreadGroup aqui no fórum mesmo…
Mas ainda não vi uma solução para esse meu problema

Vou continuar a busca no Google… mas se algum fera puder me ajudar serei muito grato
Abraços…

10 Respostas

lina

Oi,

40 threads? depois mais 40?

Não deveria “replicar” tabela por tabela? Então pra que 40 threads?

Tchauzin!

MarceloNeo

Isso por que não, qual o espanto pelo numero?

Em si eu tenho uma tabela com quase 1 milhão de registros.
Então cada Thread que seria criada, seria responsabel por persistir 2,5 mil objetos no Banco.
assim teriam 40 frentes persisitindo no banco ao mesmo tempo.

Como resolver isso?
Tentei fazer o que você falou, mas das Heap size mermory.

Então adotei essa estratégia.

O programa esta rodando desde as 16:horas de Ontem.
e ainda não chegou a 200 mil…
quando chegar em 200 mil posso interromper poque vai terminar segunda transação, ai vou adotar essa nova estratégia…
Dessa forma só tenho uma frente pesistindo no banco.

da outra forma terei 40 frentes
mas corro o risco ripe size que comentei antes…
Tenho que terminar todos essas 40 primeira, para depois instaciar mais 40 threads

Entende…
Lina obrigado, pelo seus cometários ajudam a enriquecer o tópico!

lina

Oi,

Se você está com problemas em utilizar 1, imagina 40. Vamos por partes como diria jack.

O que pode estar acontecendo é:

1- Objetos presos na memoria;

2- Você está tentando dar um commit a cada linha inserida na tabela;

3- Utilizando pouco memoria de alocação para o Java;

1- Você pode tentar ler isto: http://www.guj.com.br/java/197990-java-heap-space—encontrar-metodosobjetos-na-memoria-resolvido
para identificar leaks e objetos presos na memoria.

2- Executar um commit de 100 em 100 linhas ou 200/200;
3- Utilizar as propriedades VM’s para alocação de memoria: -Xms1024m -Xmx1024m ou -Xms1024m -Xmx2048m (Vai depender de sua maquina.

Isso foi desnecessário.

Tchauzin!

MarceloNeo

Obrigado Lina,
Vou falar o meu problema e controlar o conjunto de threads,

Matematica não.
Estou com problema que é buscar uma lista com quase 1 milhão de registros e persistir,

Então o que eu fiz, dividi de 100 em 100 mil a busca por lista…
esta funcionadooooooooo!

Agora estou dividindo esse 100 mil por 40, que seria 40 lista de 2,5 mil registros
Não 1 milhão, nem 100 mil.

Com 100 mil já esta dando certo!
Acontece que só existe uma linha de execução salvando no banco, e se continuar nesse ritimo vai demorar uns 2 ou 3 dias.
Da forma que falei seria 40 linhas de execução ao mesmo tempo.

Uma pergunta você entende mesmo de Thread ou esta só querendo fazer sarcasmo comigo.
Porque até agora o que você falou não foi nada de util para mim.
Se não pode contribuir … é melhor não falar nada.

Abraços…

lina

Oi,

Acho que você não leu até o final meu post anterior. Estou tentando ajuda-lo a identificar o possível Heap size memory.
Não é correto mudar de estratégia porque não conseguiu resolver 1 problema. E sim tentar descobrir o real motivo do problema.

Se você não sabe aceitar opiniões dos outros, porque procurou o fórum ?

“…Um guerreiro deixa de ser um guerreiro quando tem medo de enfrentar desafios. Um programador deixa de ser um programador, quando começa a ter medo de escrever códigos…”

Tchauzin!

MarceloNeo

lina:
Heap size memory.
Não é correto mudar de estratégia porque não conseguiu resolver 1 problema. E sim tentar descobrir o real motivo do problema.

Eu sei o motivo do Heap size até porque a mensagem é bem sugestiva,
Estou jogando muitos objetos ná memória,

Se você se assustou com 40 Threads imagina

vou colocar todos o zeros agora.

[color=blue] 1.000.000 esse é numero de objetos que retorna da lista![/color]
Se você não dispõe de recurso você deve contorna-los…

Geralmente as Threads ajudam neste tipo de controle… além disso tem como objetivo execução de multiplas linhas.

Opiniões são diferentes de besteiras…
Procureir o Fórum porque acredito que aqui tem pessoas muito boas, que podem ajudar.
e que no futuro o meu problema pode ser uma solução para outra pessoa da comunidade GUJ ou Java mesmo.

Abraços…

bruno.fantin

Na maioria dos bancos de dados, nesse seu caso, utilizar uma unica thread é mais rapido.

A sensação de ter 4 thread trabalhando é ilusória nesse caso. O banco vai perder mais tempo controlando a concorrência do que inserindo os registros.

Faça com uma unica thread mesmo e faça inserts em blocos. Ou seja, inicia uma transação, faz varios inserts e depois comita tudo. Quantos seriam esses inserts? Ai depende de maquina, de banco, de tabela e varios outros fatores.

Falou.

doravan

Cara, faz um ThreadPoolManager ou baixa o Quartz, limita a quantidade de Threads a um máximo de 4 por vez, uma para cada coisa ao seu tempo.

Já tive um problema parecido com o seu, só que no meu caso eu tinha que converter 36 XML em tabelas de banco de dados.
Total geral de registros 26.540.000,00.
Tempo total de leitura dos XML para a memória ~6minutos (~68gb em arquivo)
Tempo total de tratamento dos dados, ~2:30 horas
Tempo total de persistência após o tratamento, ~25minutos

Tempo total de execução 3:01 horas.

Analisa teu código aí, pq não é possível que isso esteja levando tanto tempo.

Hoje mesmo persisti dados XML pra um banco MySQL, com tratamento, total de 996.000,00 registros, e levou pouco menos de 15minutos, e também não torrou a memória.

ViniGodoy

No lugar do Quartz, você pode usar a classe ExecutorService do Java:
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html

A classe Executors permite a criação fácil de um ExecutorService:
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html

Ali você pode configurar um ThreadPool dinamico, com apenas 4 (ou 40) threads. Tenha certeza também que seu banco irá fazer as transações simultaneas, e não serializa-las. O banco geralmente também tem seus limites máximos.

MarceloNeo

Não foi a melhor solução ainda…

Mas quando precisar fazer outro trabalho semelhate vou usar as dicas do
ThreadPoolManager.

Iniciei 35 threds executand por vez, cada uma persisindo um conjunto de 5000 registros.
persistiu 175.000 registros em 40 minutos

Equanto da outra forma levei 28 horas para persistir 200.000 registros.

Threads são multiplas linhas de execção ao mesmo tempo.
O que ainda não consegui ainda muito bem é otimizar o uso do processador ele só opera em 26% da sua capacidade
contando o sistema opecional…
E para JVM coloquei Maximo 1GB de Mémória.

Não sei se isso conta em si
Processador i5,
4BG memória DDR3

acredito deveria ser mais rápido…
mas vou aperfeiçoando as tecnicas por aqui para tirar o maximo de proveito dos recuros de
máquima e não consumir além do planejado.

Novidades eu posto ai.
Muito gratos pelos comentários.

Criado 23 de março de 2011
Ultima resposta 24 de mar. de 2011
Respostas 10
Participantes 5