On Nov 11, 2011, at 11:27 AM, Stanislaw Pusep wrote:
> Any ideas?
Qual a sua versão do DBIC e do perl?
Eu tive problemas de "leak" com o DBIC a partir da versão 0.08190 e perl
5.10.1, pois o dbic-devel-core team re-escreveu a parte transacional do código
nesta versão, assim vejo que você parece
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 tama
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
> Ideia?
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
> Trazendo pra cá a conversa com @edenc no T
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(
