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

Stanislaw Pusep creaktive at gmail.com
Sun Nov 13 14:19:49 PST 2011


...and no one cares!
If there is a hell
I see you there

ABS()



2011/11/13 Alexei Znamensky <russoz em gmail.com>

> 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
>
> =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
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111113/90cdfdd8/attachment.html>


More information about the SaoPaulo-pm mailing list