tomcat consumindo muita memoria

[Luiz E. Kowaslki]

bom dia pessoal
tenho um aplicativo web rodando legal no tomcat. o problema é que
quando eu gero muitos boletos pelo jrimum bopepo, o consumo de memoria
do tomcat vai laaa em cima, conforme a imagem

http://i.imgur.com/2fFaN.png

até aqui tudo bem, eu configurei o tomcat pra utilizar até 2gb, o
servidor tem uns 4gb
mas logo após a geração do arquivo e o envio do arquivo ao usuário, o
consumo de memória continua alto.
tentei visualizar o que ta rolando pelo visualvm com um conecto jmx,
mas não consegui
alguem tem outra idéia do que pode ocasionar isso ou como 'limpar'
essa memória?
valeeu

[johnys rabelo]

Duas sugestoes:

Chamar o garbageColetor pelo system = System.gc() Ele e responsavel por limpar a memoria.

Dividir o arquivo dos boletos em arquivos menores, isso diminuirira o consumo de memoria.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "JRimum Community" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para jrimum-c...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para jrimum-communi...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/jrimum-community?hl=pt-BR.

[Luiz E. Kowaslki]

eu chamei o system.gc, mas não funciona

sobre dividir o arquivo, como eu faço isso? tem algum trecho de código
para me ajudar? :D

On 8 set, 10:47, johnys rabelo <jjoh...@gmail.com> wrote:
> Duas sugestoes:
>
> Chamar o garbageColetor pelo system = System.gc() Ele e responsavel por
> limpar a memoria.
>
> Dividir o arquivo dos boletos em arquivos menores, isso diminuirira o
> consumo de memoria.
>
> Em 8 de setembro de 2011 10:44, Luiz E. Kowaslki <

> luizeduardokowal...@gmail.com> escreveu:

[Ricardo JL Rufino]

Realmente isso é um problema.

Um dos problemas é a questão das imagens, cada boleto gerado, cria uma instância e arquivo diferente internamente no PDF.

Existem formas de fazer com que a mesma imagem, seja usada, quando ele se repetir. Infelizmente eu n conseguir fazer isso.

A melhoria, foi colocar as imagens o máximos compactadas, diminuindo uns MB, mas nada muito significativo.

Atenciosamente,

Ricardo JL Rufino

----------------------------------------------------------------------
CriativaSoft - Desenvolvimento de Sistemas com Qualidade
Analista e Engenheiro de Software

Skype: ricardojlrufino

MSN: ricardo....@hotmail.com

[Carleonis Fonseca]

Após fazer o deploy da aplicação, restart o tomcat. Assim ele libera memória.

Em 8 de setembro de 2011 10:44, Luiz E. Kowaslki <luizeduar...@gmail.com> escreveu:

[Luiz E. Kowalski]

acho que o carleonis não entnedeu o problema :)

eu acredito que ir fazendo como o johnys disse, pode ajudar, mas isso
deveria ser feito internamente pelo bopepo :(
será que não existe outro caminho hehehe?
ricardo, como vc fez pra compactar?

Em 8 de setembro de 2011 10:49, Carleonis Fonseca
<carle...@gmail.com> escreveu:

[Ricardo JL Rufino]

Tipo usa duas Logomarcas.

Compactei usando um programa de edição de imagens (GIMP, etc...). Ajudou um pouco, mas nada significativo.

E para devolver a resposta para o cliente, em vez do PDF, devolvo um ZIP ( mas o processo de zipar pode consumir mais memoria =[ ).

Atenciosamente,

Ricardo JL Rufino

----------------------------------------------------------------------
CriativaSoft - Desenvolvimento de Sistemas com Qualidade
Analista e Engenheiro de Software

Skype: ricardojlrufino

MSN: ricardo....@hotmail.com

[Luiz E. Kowalski]

pois é, mas meu gargalo ta na geração do arquivo mesmo...durante o
envio, a memória ja ta la em cima :(

Em 8 de setembro de 2011 10:59, Ricardo JL Rufino
<ricardo....@gmail.com> escreveu:

[johnys rabelo]

A minha solucao cria arquivos separados, porem eu me debati em outro problema que nao sei solucionar, juntar os arquivos pdf quebrados em um so para enviar.
Sera que existe uma maneira de juntar os pdf de um arquivo em disco em um so?
Se tiver eu emcaminho a minha solução de quebrar os boletos em boletos menores.

[Rômulo Augusto]

Luiz, o problema está na versão da lib do iText que é usada pelo Bopepo hoje. A gente tá trabalhando pra melhorar isso aí.

Falando em versão, qual a versão do Bopepo q vc ta usando?


-------------------------------------------------------------------
Rômulo Augusto
JRimum Developer
www.jrimum.org

P Antes de imprimir, pense em seu compromisso com o meio ambiente

[Luiz E. Kowalski]

blz romulo :P

JRimum-Bopepo-v.0.2.2

[Misael Barreto de Queiroz]

Olá Luiz,

Luiz, utiliza o snapshot mais recente da versão 0.2.3-Hélio:
http://jrimum.org/jrimum/wiki/Projeto/Download
2011/04/15 -  Binary |  Source

Faz o teste aí e nos avisa aí, beleza?

Luiz, só por curiosidade, você tem uma noção de quantos boletos você gera em média por hora? Pergunto isso porque aqui temos um sistema gerenciador de concursos, e no caso ele está gerando guias utilizando o Bopepo normalmente. No caso aqui chegamos a gerar 236 guias por hora, o que dá uma média de 3,9 guias por minutos.

Precisar de algo mais é só falar.
Valeu!




Misael Barreto

--

Misael Barreto de Queiroz
Analista de Sistemas
Squadra Tecnologia
A serviço do:
Departamento de Desenvolvimento de Sistemas
Tribunal de Justiça do Estado do Rio Grande do Norte
e Conselho Nacional De Justiça
+55 (84) 3616.6200 r6415
+55 (84) 3616.6415

[Luiz E. Kowalski]

ok, baixando e fazendo os testes
então cara, aqui é diferente. é uma escola de ingles.
vão ser gerados uma porrada de boletos, um dia no mes só

[johnys rabelo]

Por ex, no meu sistema eu gero 1250 boletos de uma vez so para rodar o faturamento.
Fiz a com que o bopepo gerasse os boletos de  200 em 200, em arquivos separados em pdf. depois eu coloco em um local onde da para baixar via ftp, ja que nao consegui juntar os arquivos de novo.
Alguem tem a solução

--

[Misael Barreto de Queiroz]

Fala Luiz,

Beleza cara. A gente fica no aguardo da resposta dos testes.

Luiz, se não for te dar muito trabalho, depois tu tem como ver essa estatística aí de quantos boletos gerados nesse dia, e tipo o pico por hora? É apenas para servir com benchmark.

Qualquer coisa é só falar.

Valeu!




Misael Barreto
JRimum Developer
www.jrimum.org
P Antes de imprimir, pense em seu compromisso com o meio ambiente

[Misael Barreto de Queiroz]

Luiz, outra coisa: você usa um template próprio para gerar os boletos? Qual seria o tamanho desse template?

Misael Barreto
JRimum Developer
www.jrimum.org
P Antes de imprimir, pense em seu compromisso com o meio ambiente

[Luiz E. Kowalski]

opa misael :P

eu vou dar um jeito aqui de ver isso, de quantos boletos o pessoal tem gerado, sem problemas

cara, eu não uso template proprio não.

[Gilmar P.S.L.]

Olá pessoal,

Gostaria de lembrá-los que já existe a algum tempo uma forma de gerar vários boletos de uma só vez:

http://jrimum.org/bopepo/wiki/Componente/Documentacao/Tutoriais/VariosBoletosEmUmArquivo

Esses métodos trabalham bem melhor pela performance, então gostaria de saber se alguém está utilizando uma dessas maneiras para gerar boletos em lote ou se vocês estão instanciando vários boletos de outra forma?

Atenciosamente

------------------------------------------------------
Gilmar P.S.L.

JRimum Developer
      
http://www.jrimum.org
http://www.blog.jrimum.org
http://twitter.com/jrimum
http://groups.google.com.br/group/jrimum-community

2011/9/8 Luiz E. Kowalski <luizeduar...@gmail.com>

opa misael :P

eu vou dar um jeito aqui de ver isso, de quantos boletos o pessoal tem gerado, sem problemas

cara, eu não uso template proprio não.

--

[Gilmar P.S.L.]

E aí pessoal!?

Nenhuma novidade?

Alguma medição nova de memória? Alias, alguém chegou a ver a memória só na JVM?

Estou perguntando porque estou aproveitando para fazer uma revisão, se alguém tiver alguma observação a fazer seria muito interessante :-)

Atenciosamente

------------------------------------------------------
Gilmar P.S.L.

JRimum Developer
      
http://www.jrimum.org
http://www.blog.jrimum.org
http://twitter.com/jrimum
http://groups.google.com.br/group/jrimum-community

2011/9/15 Gilmar P.S.L. <gilm...@gmail.com>

[Carlos Eduardo]

Chamar o System.gc() não garante que ele seja executado. De qualquer
jeito a JVM é quem escolhe a hora de executar o GC. A chamada do
método é como se você levantasse a mão pra JVM e dissesse:"Ei, JVM,
pode executar o GC", mas quem manda é a JVM.

On Sep 8, 10:48 am, "Luiz E. Kowaslki" <luizeduardokowal...@gmail.com>
wrote:

[johnys rabelo]

Essa questao sobre a memoria e meio complexa.
O consumo de memoria aumenta tanto, e pq o JRimum armazemas todos os boletos(o arquivo pdf) em um array de bytes.
Logo quando fazemos cerca de 500 boletos de uns 100kb cada um, o consumo de memoria sobe muito.
Uma solucao seria criar os boletos em partes ex de 100 em 100, e salvar em um local especifico os arquivos menores (Solucao que uso porem nao acho muito correta, pois nao tem como enviar as partes para o cliente)
Outra: Procurar uma maneira que ao invez de unir os boletos atraves do array de bytes, unilos atravez de arquivos.
Outra: Verificar se tem como se na medidada de que os boletos fossem gerados, parte do pdf gerado fosse guardado em disco, e nao ficasse na memoria, o que aliviaria o gasto de memoria do servidor.

--

Você recebeu esta mensagem porque está inscrito no Grupo "JRimum

Community" nos Grupos do Google.

Para postar neste grupo, envie um e-mail para

jrimum-c...@googlegroups.com
ANTES DE POSTAR... leia:
https://groups.google.com/d/topic/jrimum-community/ULU8QHHgaBs/discussion
Para cancelar a sua inscrição neste grupo, envie um e-mail para
jrimum-communi...@googlegroups.com
Para ver mais opções, visite este grupo em
http://groups.google.com/group/jrimum-community?hl=pt-BR?hl=pt-BR

[Hermes Hostin]

Ola Pessoal,

No meu caso há varias gerações em lote disparadas em paralelo. Cada usuario envia uma seleção de faturas que variam de 100 a mais de 10 000 faturas.
Eu utilizo duas estratégias de geração:

* Monto uma lista com os objetos boleto e utilizo o metodo citado pelo Gilmar (varios boletos em um arquivo)


* Em grandes quantidades eu gero varios arquivos separados, cada arquivo com um grupo de boletos em comum (agrupo de acordo com minhas regras). Ao final, diponibilizo para usuario baixar um arquivo compactado com os arquivos.

Realmente a geração em lote é um processo que aloca bastante memoria, no meu caso o servidor tem que ser "parrudo", ele roda hoje no linux 64 bits com 8 GB.
E um sistema que usado poucas vezes no mês, mais quando é usado acaba demandando um bom desempenho e memoria do servidor, para não tem aquele problema de out of memory.

[Kleber G Soares]

Olá pessoal desenvolvo em java com tomcat e tive muito este problemas, por incrivel que parece isso resolveu meu problema http://www.galaxyz.com.br/sites/gwp/sys/?p=224 não realmente até postei em meu forum porque apos fazer o processo nunca mais obtive este erro, e a aplicação tem milhares de acesso porque é um aplicativo para prefeitura que utiliza o boleto para gerar os tais e depois disso rodou que é uma beleza. Espero que dê certo para vocês também.

 

http://www.galaxyz.com.br/sites/gwp/sys/?p=224

At.
Kleber Gracia Soares
Equipe Galaxyz trabalhando para você
www.galaxyz.com.br
Telefone: |44| 3233-2039
Cel.: |44| 9960-0298 - Tim
Msn: kleber...@hotmail.com
Skype: kleber.gracia
Email: kle...@galaxyz.com.br
"Tudo posso naquele que me fortalece!" (Fl 4,13).

 

[johnys rabelo]

Gostei da ideia de compactar os arquivos, vou refazer a minha solucao para realizar essa tarefa. Muito boa a ideia.
Quanto ao artigo, pelo que entendi, ele aumenta o espaco de memoria que pode ser alocada pelo tomcat. Isso nao soluciona muito o problema, pois nao temos um numero infinito de memoria para alocar.

[Carleonis Fonseca]

ATENÇÃO

Meu antivirus detectou uma possível invasão nesse link citado no email

Em 4 de outubro de 2011 17:06, Kleber G Soares <kleber....@gmail.com> escreveu:

[Misael Barreto de Queiroz]

Fala galera, tudo beleza?

Legal ter esse feedback de vocês quanto a questão de geração de grandes massas de boletos, pois com base no que vocês estão expondo a gente pode procurar formas cada vez mais eficientes, e estamos abertos a sugestões.

Contudo galera, quero fazer apenas algumas ressalvas, no intuito da gente entender como deixar a coisa mais eficiente ainda. No caso aproveito o relato no nosso amigo The Kill (Johnys Rabelo):

Em 04/10/2011 16:08, johnys rabelo escreveu:

Essa questao sobre a memoria e meio complexa.
O consumo de memoria aumenta tanto, e pq o JRimum armazemas todos os boletos(o arquivo pdf) em um array de bytes.
Logo quando fazemos cerca de 500 boletos de uns 100kb cada um, o consumo de memoria sobe muito.

Creio que o problema em si não seja porque o JRimum "armazena todos os boletos boletos(o arquivo pdf) em um array de bytes". O problema em si é que são muitos boletos, e no caso se são 500 boletos de 100kb, não vejo como gerar um arquivo com todos esses boletos sem ter que alocar 500 x 100 Kb de memória.

Uma solucao seria criar os boletos em partes ex de 100 em 100, e salvar em um local especifico os arquivos menores (Solucao que uso porem nao acho muito correta, pois nao tem como enviar as partes para o cliente)
Outra: Procurar uma maneira que ao invez de unir os boletos atraves do array de bytes, unilos atravez de arquivos.

Outra: Verificar se tem como se na medidada de que os boletos fossem gerados, parte do pdf gerado fosse guardado em disco, e nao ficasse na memoria, o que aliviaria o gasto de memoria do servidor.

Na minha visão este processo vai ser "mais caro" ainda. Fazendo um passo a passo seria:
(Passo 1)
100 boletos x 100kb = 10.000 KB (memória alocada e liberada ao final da geração dos 100 boletos. Arquivo criado em disco.)
100 boletos x 100kb = 10.000 KB (memória alocada e liberada ao final da geração dos 100 boletos. Arquivo criado em disco.)
100 boletos x 100kb = 10.000 KB (memória alocada e liberada ao final da geração dos 100 boletos. Arquivo criado em disco.)
100 boletos x 100kb = 10.000 KB (memória alocada e liberada ao final da geração dos 100 boletos. Arquivo criado em disco.)
100 boletos x 100kb = 10.000 KB (memória alocada e liberada ao final da geração dos 100 boletos. Arquivo criado em disco.)

(Passo 2)
Daí na hora de unir os 5 arquivos com 100 boletos cada, os arquivos terão de estar na memória, logo:
5 x 10.000 KB = 50.000 KB (memória alocada e liberada ao final na geração do arquivo unificado. Arquivo criado em disco)

No final não tem pra onde correr. Vão ter que ser alocados 50.000 KB.


Atualmente para evitar o passo 1 a recomendação seria usar o "groupInOnePDF(List<Boleto> boletos)", já recomendando pelo nosso amigo Gilmar.

As considerações que teria a fazer seriam essas. Reitero novamente que estamos abertos à sugestões.

Um abraço.

Misael Barreto
JRimum Developer
www.jrimum.org

P Antes de imprimir, pense em seu compromisso com o meio ambiente

[johnys rabelo]

Beleza Misael.

Eu gostei de suas colocações, porem eu vejo uma maneira para solucionar.
Por exemplo. Gera-se arquivos pdf que contenham 100 boletos cada.
Ao final, podemos zipar os arquivos.
Ai fica um questionamento, a parte de zipar os arquivos levaria o servidor a instanciar todos os arquivos? Ou ele faria em partes como o WinRar faz?

[johnys rabelo]

Opa outra colocação. Nao tem como usar o groupInOnePDF(List<Boleto>) quando a massa de boletos e alta demais. Por ex. eu gero 1250 boletos de uma vez. Meu servidor nao tem memoria suficiente para gerar todos de uma vez, logo eu os faço em partes e coloco os arquivos em um espaco para serem baixados via FTP.
Eu gostei da solucao de zipar os arquivos, espero retorno sobre meu questionamento do email anterior.

[Kleber G Soares]

Depende do servidor, creio que este assunto é realmente problemático para todos nós, mas trabalhamos com uma prefeitura com 350 mil contribuintes e o sistema nunca deu problema, a não ser quando tinhamos duplicidades como citei acima, após acertar foi que foi uma beleza, mas a equipe de servidores é bem chata em relação a CONFIGURAÇÃO.

At.
Kleber Gracia Soares
Equipe Galaxyz trabalhando para você
www.galaxyz.com.br
Telefone: |44| 3233-2039
Cel.: |44| 9960-0298 - Tim
Msn: kleber...@hotmail.com
Skype: kleber.gracia
Email: kle...@galaxyz.com.br
"Tudo posso naquele que me fortalece!" (Fl 4,13).

 

[Misael Barreto de Queiroz]

Fala Jhonnys, tudo beleza?

No caso do método groupInOnePDF(List<Boleto>) eu o recomendei porque ele evita o passo 1 (gerar X arquivos pra depois criar um arquivo só), gerando logo o arquivo final, pois na hora de juntar os arquivos criados separadamente, não tem jeito (pelo menos que eu saiba), todo esse conteúdo terá de estar em memória para então criar o arquivo unificado.

A questão de gerar X arquivos e depois compactar (criar um "zip" da vida) pode ser uma boa saída, achei legal, mas aí talvez fuja um pouco do escopo do Bopepo. No caso acho que fica mais coerente a aplicação cliente definir o que será feito com os boletos gerados, se vão ser ou não compactados, se vai usar .zip, .rar, .7z etc. No teu caso dos 1250 boletos, a aplicação poderia passar ao Bobepo listas com X boletos (poderia ser 100, 200, 500 ..), usando o método groupInOnePDF(List<Boleto>), e aí no final a aplicação faria a compactação desses arquivos ou outro procedimento que achar coerente.

Não estou descartando a possibilidade de se criar um método que fizesse essa compactação 0800, agora de repente isso ficaria mais bem localizado num método utilitário do componente Utilix. Vamos estudar o caso.

Mais uma vez agradeço aí a colaboração,
Quanto mais sugestões tivermos melhor.

Um abraço.



Misael Barreto
JRimum Developer
www.jrimum.org

P Antes de imprimir, pense em seu compromisso com o meio ambiente

Citando o caso dos 1250 boletos, você p

[johnys rabelo]

Opa, Vlw pela comprensao.
Vou ler sobre o Utilix, e aproveito e faco minha solucao de modo que possa ser utilizada por outras pessoas.

[Misael Barreto de Queiroz]

Blz Johnys,

Massa cara, daí tu posta aê, e se for o caso a gente já integra no componente.

Valeu pela colaboração.
Abração.