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

Sun Nov 13 13:30:03 PST 2011

God is dead

2011/11/13 Renato Santos <renato.cron em gmail.com>

> Eden has no god!
>
> brincadeira!!!
>
> @renato_cron
> Em 13/11/2011 18:24, "Stanislaw Pusep" <creaktive em gmail.com> escreveu:
>
> Wallace: boa, fiz o downgrade para e funcionou perfeitamente... Na
>> tentativa e erro, descobri que o *leak* foi introduzido
>> no DBIx-Class-0.08194.
>> Eden: where is your God now?
>>
>> ABS()
>>
>>
>>
>> 2011/11/12 Eden Cardim <edencardim em gmail.com>
>>
>>> >>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> writes:
>>>
>>>    Stanislaw> Trazendo pra cá a conversa com @edenc no Twitter :)
>>>
>>> Exceto que no twitter você não foi tão educado :P
>>>
>>>    Stanislaw> ... (bastante simples) ...
>>>
>>> Deviam banir esse adjetivo do contexto de discussões técnicas.
>>>
>>>    Stanislaw> Consegui isolar o seguinte trecho porcalhão:
>>>
>>>    Stanislaw> my $images = $schema->resultset('Image');
>>>    Stanislaw> ...;
>>>    Stanislaw> while (my $url = <>) {
>>>    Stanislaw>     ...;
>>>    Stanislaw>     $images->find_or_create(
>>>    Stanislaw>         {
>>>    Stanislaw>             sampler_uid => $obj->uid,
>>>    Stanislaw>             url         => $url,
>>>    Stanislaw>         },
>>>    Stanislaw>         { key => 'images_url_idx' }
>>>    Stanislaw>     );
>>>    Stanislaw> }
>>>
>>>    Stanislaw> Curiosamente, posso substituir find_or_create() por apenas
>>> find() e o resultado é o mesmo: acréscimo de
>>>    Stanislaw> alguns KB no processo para cada operação.
>>>    Stanislaw> Como tenho meio milhão de registros, deu no que deu.
>>>
>>> ,----[ test.pl ]
>>> | use strictures 1;
>>> |
>>> | use lib 'lib';
>>> |
>>> | use MyApp::Schema;
>>> | use Devel::Cycle;
>>> |
>>> | my $s = MyApp::Schema->connect('dbi:SQLite:database=test.db');
>>> |
>>> | my $images = $s->resultset('Foo');
>>> | for ( 0 .. 500000 ) {
>>> |   $images->find_or_create(
>>> |     { bar => qq{baz$_}  },
>>> |   );
>>> | }
>>> |
>>> | find_cycle($images);
>>> `----
>>>
>>> Rodei o trecho acima com um schema deduzido (já que você não forneceu o
>>> seu) gerado pelo dbicdump e não consegui reproduzir o "leak". Já tive
>>> problemas de leak com o DBIC há muito tempo atrás e eu mesmo ajudei a
>>> depurar. Mas com o DBIC mais recente (0.08195) e perl 5.14.2, o processo
>>> roda feliz da vida com 15MB, a equipe de core devs do DBIC é bastante
>>> responsiva e trabalha arduamente pra evitar e resolver problemas como
>>> isso. Tudo isso indica que há uma chance do leak ser em alguma
>>> customização sua, pode ser no DBIC também mas sem ver o seu schema na
>>> íntegra não tem como saber o que deu errado.
>>>
>>> A propósito, também testei na cópia de uma base de dados de produção com
>>> cerca de 200M registros ontem, acordei hoje e ainda estava rodando, mas
>>> o processo ainda ocupando cerca de 20MB de memória.
>>>
>>>    Stanislaw> Antes disso, suspeitei que tivesse algo a ver com
>>> AutoCommit e encapsulei com txn_do() a cada 100
>>>    Stanislaw> registros; deu na mesma.
>>>    Stanislaw> Também suspeitei do prepare_cached(), porém isso não faz o
>>> menor sentido, pois o statement é o mesmo para
>>>    Stanislaw> todas as queries.
>>>    Stanislaw> Anyway, tentei limpar $schema->storage->dbh->{CachedKids}
>>> periodicamente e também não
>>>    Stanislaw> adiantou.
>>>
>>> Nada disso faz sentido, e tudo isso que você mencionou acontece
>>>
>>>    Stanislaw> Por fim, tentei ver o que acontece xeretando através do
>>> Devel::Size. De fato, o objeto do ResultSet cresce
>>>    Stanislaw> indefinidamente. Porém todas as minhas tentativas de
>>> serializar o mesmo e descobrir o que está acontecendo
>>>    Stanislaw> via diff foram frustradas :(
>>>
>>> Verificar o tamanho do objeto não é o suficiente pra assertar um "leak"
>>> e como o objeto resultset nunca sai do escopo, não dá pra chamar isso de
>>> "leak". Leak é quando você para de usar um trecho de memória (no caso do
>>> perl, implicitamente, através da destrução de referências) e essa
>>> memória não volta a ficar disponível pro sistema. Uma das coisas que
>>> pode estar acontecendo é você ter configurado caching pros resultsets em
>>> algum outro lugar, nesse caso, é natural que o consumo de memória
>>> aumente sempre que você executar uma query, já que o resultado da query
>>> é armazenado em memória pra evitar uma segunda consulta.
>>>
>>>    Stanislaw> Any ideas?
>>>
>>> Sim, usa o trecho de código acima pra localizar o ciclo dentro do
>>> resultset, se for mesmo um leak, provavelmente vai apontar pra alguma
>>> customização sua.
>>>
>>> --
>>> Eden Cardim
>>> Software Engineer
>>> http://bit.ly/edencardim
>>> http://twitter.com/#!/edenc
>>> +55 73 9986-3963
>>> =begin disclaimer
>>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm em 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 em 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 em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>


-- 
Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
http://www.flickr.com/photos/alexeiz | http://github.com/russoz
"I don't know... fly casual!" -- Han Solo
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111113/4ee8d95c/attachment-0001.html>