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

Renato Santos renato.cron at gmail.com
Tue Sep 28 19:45:01 PDT 2010


Daniel, eu sou deslexo!!

E sim, nao deve ter chego no open ate agora! Isso eu entendi!

So nao sei q diabos o perl tava(ou ta! Nao conferi agpra, depois de 4 hrs se
ta rolando) fazendo depois do log final!

Alguem tem mais experiência com grandes volumes?

Eu estou super aberto a dicas, podem xingar!(afinal neh Marcio, alguem aki
faz isso bem, mas errado )

Tava olhando umas theads, falando sobre o ... como chama... mongodb. Sera q
eh melhor usalo? Pois nao ah necessidade de relaciomento real entre as
tabelas. Se nao existe agora, podera existir daqui algum tempo....
Alias, quem mexeu no banco de prod trocou as gks por indrxes... soh pra
"tentar " drixar mais rapido os milhoes de insert. Troquei pra copy agora
sobe td em segundos....

Vou dormi, abraco pro seis!

Em set 28, 2010 11:36 PM, "Renato Santos" <renato.cron at gmail.com>escreveu:

Entao... começando pelo procedimento do teórico do dedup

Ah cadastros salvos no db, por exemplo nome/email/fone.

100 terceiros te enviam estes dados do seu clientes, ex: financeiro da
eletropaulo, marketing da eletropaulo.

Depois de certos tratamentos (externos, feito em outra hora) eh salvo isso
em outra tabela.

A regra eh: bateu nome/qualquer coisa(tel/mail) eh a msma pessoa.

no $this, $self, ou seja la o nome da.maldita var! Eh populado assim:

$this->{$nm}[(email)]{$email} = id unico desta pessoa/ email

Esse email entre parenteses eh uma const numerica, pra separar o
email,fone,etc..

Depois feito um loop nos novos registros e eh comparado com este Hash.

Foi feito com hash na memoria, pq, em teoria, eh mais rapido ja ter tudo na
ram do que fazer um select por linha lida.

Pensando"ah, eh soum selext...."
Sao 4 tabelas, telefones, emails,enderecos,e a cadastro. 1 pessoa pode ter
55 emails (msmo q hj soh carregue 1 por entrada)
Multiplicando 8milhoes de selects vao gerar mais custo q um com outro where.

Vou ver as respostas novas deste e mail, depois posto de novo

> > Em set 28, 2010 7:59 PM, "Marcio Ferreira" <
marciodesouzaferreira at gmail.com>escreveu: >

> > Resumindo o e-mail inteiro! > Porque o perl 2 que foi executado pelo
perl 1 ainda esta rodando m...

> > Se a aplicação ainda está em desenvolvimento, tente usar o PostgreSQL 9,
o algoritmo de VACCUM ...

> >   > >   > > > > Segue então o e-mail > > Tinha um processo aqui
(deduplicação de registros do b...

> > > > _______________________________________________ > SaoPaulo-pm
mailing list > SaoPaulo-pm at pm...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20100928/c451facd/attachment.html>


More information about the SaoPaulo-pm mailing list