Eden has no god! brincadeira!!!
@renato_cron Em 13/11/2011 18:24, "Stanislaw Pusep" <[email protected]> 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 <[email protected]> > >> >>>>> "Stanislaw" == Stanislaw Pusep <[email protected]> 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: [email protected] >> 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: [email protected] > 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
