[SP-pm] Tempo (grande!) de liberação de memoria no perl

Renato Santos renato.cron at gmail.com
Tue Sep 28 15:35:47 PDT 2010


Resumindo o e-mail inteiro!
Porque o perl 2 que foi executado pelo perl 1 ainda esta rodando mesmo
depois da ultima linha do perl 2 ter executado?

----------------------
Explicando os fatos;

Esses perls são chamão modulos,
não usa Moose nem nada muito complexo, mas são classes.
Nesses pls tem alguma coisa assim:

use strict;
use Boostrap; -- modulo interno.

my $config = {
  nome => 'aplicacao bla bla bla',
  modulo => 'xpto',
  config => {type=>'json', file => 'app.conf'}
};

my $app = new Boostrap($config);
if($app->load()){
  $app->run();
}
$app->finalize() #manda e-mail  e faz o log 'Fim da aplicacao'


--

Oo

Agora que percebi que mandei coisa a mais....
Essa parte do psql não deveria estar ai!
Acontece o seguinte...
Na empresa q estou,
nao pode usar o gmail,
ai digitei a desgraça do e-mail no kate,
depois fui no https e mandei por la!
como ja tava atrasado nem formatei os codes pra ficarem em monospaced.


Sobre a parte do  -I/projetos/libs
ainda bem que você (Daniel) reparou, pois essa parte é pra rodar na minha
maquina!
Na maquina que esta em produção não existe, então, acho que não vai para por
causa disso. (Afinal, ja rodou a letra 0,1,2,3)

estou em casa agora nao tem como verificar se terminou de rodar, tenho que
ir pra escola!



Solli,
qual seria esse modulo para rodar outros scripts? separei em outro perl
justamente para liberar a memoria quando o mesmo terminasse.

Os selects estão bons, o problema mesmo é na hora de subir (depois da
"letra" F) que eu dropo os index, FK, PK e faço Copy, depois crio de novo
(conforme documentação do postgres )




Segue então o e-mail

Tinha um processo aqui (deduplicação de registros do banco) que rodava com
alguns milhores de registros,
ai acabava acabando a RAM (4 GB, e chora, não vão por mais...),
O processo fazia mais ou menos assim:

Carrega do banco todos as pessoas com a letra A
Sobe em RAM
Loop num outro select nos registros com a lenta A
compara com o com a RAM
"Libera da ram" (undef nas variaveis...)

E assim por diante até o Z


Então, eu resolvi alterar, pois depois do primeiro processamento, a maquina
ja estava sem RAM.
Sei que a RAM não é liberada, mas fica 'reservada' para o proprio perl. Mas
por segunraca, fiz um processamento ficar assim:

Perl contralador:
--> perl filho fazendo processamento da letra A (sobe na ram, processa,
cospe a saida)
perl pai lê a saida e pega algumas variaveis e continua...


O processo esta funcionando (em desenv, rs!)

Mas agora, rodando com os dados Full num banco de homologação na maquina de
producao (rs!)
O processo rodou normalmente até a letra B por exemplo (na verdade é de 0 a
15 hexadecimal) e até a "letra" 4 não há um grande volume.

O perl rodou, eu deu lida no log, e aconteceu isso:

2010-09-28 11:36:43 - Iniciando aplicacao [Importador Dedup v 1.0]...
2010-09-28 11:36:43 - Lendo arquivo de configuracao: conf/importador.pl.conf
2010-09-28 11:36:43 - Conectando-se no banco de dados
nestle_teste_dedup_novo at yamaha
2010-09-28 11:36:43 - Carregando id_file 1...
2010-09-28 11:36:43 - START: executaQuery.. letras: 4
2010-09-28 11:42:49 - END: executaQuery..
2010-09-28 11:42:49 - START: Loop DBM..
2010-09-28 11:42:49 - 10000
2010-09-28 11:42:50 - 20000
...
2010-09-28 11:55:38 - 2870000
2010-09-28 11:55:52 - END: Loop DBM (READ = 2873193)..782.77837896347
segundos...
2010-09-28 11:57:54 - LoadDatabase: 1271 wallclock secs (235.19 usr + 19.15
sys = 254.34 CPU)
2010-09-28 11:57:54 - Criando arquivo ./tmp//cadastros_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo ./tmp//enderecos_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo ./tmp//cadastros_updated.22493.copy...
2010-09-28 11:57:54 - Criando arquivo
./tmp//telefones_ids_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo
./tmp//enderecos_ids_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo
./tmp//cadastros_ids_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo ./tmp//telefones_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo ./tmp//emails_ids_insert.22493.copy...
2010-09-28 11:57:54 - Criando arquivo ./tmp//emails_insert.22493.copy...
2010-09-28 11:57:55 - Current val for cadastros_ids_seq is 6227684
2010-09-28 11:57:55 - Current val for emails_id_email_seq is 4215242
2010-09-28 11:57:55 - Current val for enderecos_id_endereco_seq is 5205954
2010-09-28 11:57:55 - Current val for telefones_id_telefone_seq is 4908144
2010-09-28 11:57:55 - Obtendo todos os registros da
tb_importa_contato_clean: id_file: 1: letras 4
2010-09-28 11:59:58 - 10000 => id:27346
...
2010-09-28 13:00:50 - 650000 => id:1798654
2010-09-28 13:00:55 - Updating cadastros_ids_seq to 6312829...
2010-09-28 13:00:56 - Updating emails_id_email_seq to 4220223...
2010-09-28 13:00:56 - Updating enderecos_id_endereco_seq to 5212173...
2010-09-28 13:00:56 - Updating telefones_id_telefone_seq to 4914093...
2010-09-28 13:00:57 - 650473 registros comparados. 3738.82161688805
segundos...
2010-09-28 13:04:35 - Dedup Code: 4001 wallclock secs (587.09 usr + 26.34
sys = 613.43 CPU)
2010-09-28 13:04:36 - Gravando arquivo com os updates de cadastro: 41
2010-09-28 13:04:40 - done.
2010-09-28 13:04:40 - Gravando arquivo com os dedups...
2010-09-28 13:06:23 - done.
2010-09-28 13:06:26 - Dedup write files: 111 wallclock secs ( 3.83 usr +
1.03 sys =  4.86 CPU)
Quantidade de erros: 0
Tempo de execucao: 5383 segundos
2010-09-28 13:06:26 - Desconectando-se dos banco de dados...
2010-09-28 13:06:26 - Desconectando-se de dx0
2010-09-28 13:06:27 - Fim da aplicacao


Como mostra o log,
rodou em 5383 segundos, aproximadamente 1:3h

Porém,
o processo ta rodando até agora e o perl não soltou o pai até agora.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
22493 user     20   0 5474m 3.8g  744 D   25 97.3  63:21.11 perl
-I/projetos/libs importador_dedup_lote.pl
 7b2269645f66696c65223a2231222c226c6574726173223a5b2234225d7d



Não quero da um kill nele, pois quero ter certeza que rodou tudin!

Esse perl, como podem ver, chegou a usar toda a RAM, ou seja,
ele esta fazendo free dela até agora.


Como vou embora agora, (pra escola), coloquei nos novos perls um `kill -9
$$` no final, assim os proximos (se sair desse!) se matam no final

Minha questão é:
Demora tanto assim pra liberar a RAM? Já são 17:06 e nada!

O código pra chamar o filho ta assim:

        $rotinas->log("Chamando perl para processar match name com o HEXs "
. (join(', ', @$grp)));
        my $param = {
            id_file => $param->{id_file},
            letras  => $grp
        };
        my $serialize = &ascii_to_hex($rotinas->fastObjToJson($param));

        my $cmd = "perl -I/projetos/libs importador_dedup_lote.pl $serialize
1>$serialize.log 2>&1";
        print ">>> $cmd\n\n";
        `$cmd`;
        open(X, '<', "$serialize.log");
        my @logs = ();
        while (<X>){
            print "\t$_";
            push(@logs, $_);
        }
        close(X);
        print "\n";


Tenho certeza que não chegou no "open"


2010/9/28 Marcio Ferreira <marciodesouzaferreira at gmail.com>

> Renato,
>
> leia:
> http://sao-paulo.pm.org/equinocio/2010/set/20
> http://sao-paulo.pm.org/equinocio/2010/set/10
>
> Eu recomendaria você começar a usar Moose para encapsular melhor as coisas
> e esquecer o code guidelines legado da empresa.
>
> OBS**posso falar isso porque já trabalhei nessa empresa e sei bem como as
> coisas funcionam.
>
> []s,
>
> @webgenes
> Marcio Ferreira
>
> "Perl lives as the 'toolbox for Unix' "
>
>
>
> 2010/9/28 Solli Honorio <shonorio at gmail.com>
>
>> O meu email comeu algum pedaço do email dele ? Pois não ví nem mesmo este
>> código !
>>
>>
>> Solli M. Honório
>>
>> Em 28 de setembro de 2010 18:03, Daniel de Oliveira Mantovani <
>> daniel.oliveira.mantovani at gmail.com> escreveu:
>>
>> 2010/9/28 Renato Santos <renato.cron at gmail.com>:
>>> > O código pra chamar o filho ta assim:
>>> >
>>> >         $rotinas->log("Chamando perl para processar match name com o
>>> HEXs "
>>> > . (join(', ', @$grp)));
>>> >         my $param = {
>>> >             id_file => $param->{id_file},
>>> >             letras  => $grp
>>> >         };
>>> >         my $serialize = &ascii_to_hex($rotinas->fastObjToJson($param));
>>> >
>>> >         my $cmd = "perl -I/projetos/libs importador_dedup_lote.pl$serialize
>>> > 1>$serialize.log 2>&1";
>>> >         print ">>> $cmd\n\n";
>>> >         `$cmd`;
>>> >         open(X, '<', "$serialize.log");
>>> >         my @logs = ();
>>> >         while (<X>){
>>> >             print "\t$_";
>>> >             push(@logs, $_);
>>> >         }
>>> >         close(X);
>>> >         print "\n";
>>> >
>>> >
>>> > Tenho certeza que não chegou no "open"
>>> >
>>>
>>> Esse foi o único pedaço do seu e-mail que eu entendi alguma coisa. Se
>>> você tem certeza que não está chegando no open
>>> é porque o `$cmd` não está terminando a execução. Cara, porque você
>>> não usa módulos ao invés de fazer isso ?
>>>
>>> >
>>> >
>>> > Alguma sugestão?
>>> >
>>> > --
>>> > Renato Santos
>>> > http://www.renatocron.com/blog/
>>> >
>>> > _______________________________________________
>>> > SaoPaulo-pm mailing list
>>> > SaoPaulo-pm at pm.org
>>> > http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>> >
>>>
>>>
>>>
>>> --
>>> http://www.danielmantovani.com
>>>
>>> "If you’ve never written anything thoughtful, then you’ve never had
>>> any difficult, important, or interesting thoughts. That’s the secret:
>>> people who don’t write, are people who don’t think."
>>> _______________________________________________
>>> SaoPaulo-pm mailing list
>>> SaoPaulo-pm at pm.org
>>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>>
>>>
>>
>>
>> --
>> "o animal satisfeito dorme". - Guimarães Rosa
>>
>> _______________________________________________
>> SaoPaulo-pm mailing list
>> SaoPaulo-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>
>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm at pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>



-- 
Renato Santos
http://www.renatocron.com/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20100928/d3e48ad3/attachment-0001.html>


More information about the SaoPaulo-pm mailing list