[SP-pm] "leak" no DBIx::Class?

[Renato Santos]

poxa, não reparei.

bom, gastar 6gb realmente não é confortável!

O DBIC nao foi feito para velocidade, e como você está usando muitas
classes (internamente o find_or_create deve fazer selects que criam mais
objetos gastando mais memoria,
então eu sugiro que, talvez seja melhor:

dependendo do tamanho do banco, use HashRefInflator + select=>[qw/id/] e
depois joge todos os ids na chave de um HASH,
depois faça seu loop no arquivo, caso exista, você joga no arquivo X, se
não existe (é insert) você joga no arquivo Y.

No final, você sobe os dois arquivos, o arquivo Y voce sobe na tabela
final, e o arquivo X você sobe em uma tabela temporária e depois faz o
update com uma consulta diretamente no banco, assim vai ser mais rapido (eu
acho que sim, afinal, subiu os dados via copy em uma transação, depois que
o dado está lá, é só atualizar)

Também é interessante inverter a ordem: faz primeiro o update com base na
tabela temporaria, depois insere os novos, afinal, esses novos só vão
atrasar mais o index do update.



2011/11/11 Stanislaw Pusep <creaktive at gmail.com>

> Sorry Dave, I can't do that :)
> Mandei o código de teste minimamente suficiente para causar o leak. O
> processo em si é um pouco mais elaborado. Aliás, o meu caso é exatamente o
> oposto do que você diz: na MAIORIA dos casos (99.9%), o registro já está lá.
>
> ABS()
>
>
>
>
> 2011/11/11 Renato Santos <renato.cron at gmail.com>
>
>> Ideia?
>> não é melhor gerar um COPY ?
>>
>> Se der erro, remove a linha, tenta novamente... etc..
>>
>> só não faz isso com muitos registros de uma vez (se for provavel ter um
>> erro) pois isso no postgres gera um LOG imenso de dead-rows.
>>
>> 2011/11/11 Stanislaw Pusep <creaktive at gmail.com>
>>
>>>  Trazendo pra cá a conversa com @edenc no Twitter :)
>>> Observei que um script meu (bastante simples) estava torrando 6GB de RAM
>>> mais 5GB de swap...
>>> Consegui isolar o seguinte trecho porcalhão:
>>>
>>> my $images = $schema->resultset('Image');
>>> ...;
>>> while (my $url = <>) {
>>>     ...;
>>>     $images->find_or_create(
>>>         {
>>>             sampler_uid => $obj->uid,
>>>             url         => $url,
>>>         },
>>>         { key => 'images_url_idx' }
>>>     );
>>> }
>>>
>>> Curiosamente, posso substituir find_or_create() por apenas find() e o
>>> resultado é o mesmo: acréscimo de alguns KB no processo para cada operação.
>>> Como tenho meio milhão de registros, deu no que deu.
>>> Tive que trocar por isso daqui e funcionou perfeitamente:
>>>
>>> my $images_insert   = $schema->storage->dbh->prepare(
>>>     'INSERT INTO images (sampler_uid, url) VALUES (?, ?)'
>>> );
>>> ...;
>>> while (my $url = <>) {
>>>     ...;
>>>     eval {
>>>         $images_insert->execute($obj->uid, $url);
>>>     };
>>> }
>>>
>>> Antes disso, suspeitei que tivesse algo a ver com AutoCommit e
>>> encapsulei com txn_do() a cada 100 registros; deu na mesma.
>>> Também suspeitei do prepare_cached(), porém isso não faz o menor
>>> sentido, pois o statement é o mesmo para todas as queries. Anyway, tentei
>>> limpar $schema->storage->dbh->{CachedKids} periodicamente e também não
>>> adiantou.
>>> Por fim, tentei ver o que acontece xeretando através do Devel::Size. De
>>> fato, o objeto do ResultSet cresce indefinidamente. Porém todas as minhas
>>> tentativas de serializar o mesmo e descobrir o que está acontecendo via
>>> diff foram frustradas :(
>>> Any ideas?
>>>
>>> ABS()
>>>
>>>
>>> =begin disclaimer
>>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>>
>>
>>
>> --
>> Saravá,
>> Renato CRON Santos
>>  http://www.renatocron.com/blog/
>> @renato_cron <http://twitter.com/#!/renato_cron>
>>
>>
>>
>> =begin disclaimer
>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>


-- 
Saravá,
Renato CRON Santos
http://www.renatocron.com/blog/
@renato_cron <http://twitter.com/#!/renato_cron>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111111/48a643ba/attachment.html>