...and no one cares! If there is a hell I see you there ABS()
2011/11/13 Alexei Znamensky <[email protected]> > God is dead > > > 2011/11/13 Renato Santos <[email protected]> > >> 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 >> >> > > > -- > 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: [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
