Comment 10 for bug 709575
Revision history for this message
| Raphaël Valyi - http://www.akretion.com (rvalyi) wrote Re: [Bug 709575] Re: [6.0.1][stock] very very slow (22 minutes!!!) to process a large picking | #10 |
Did I tell on Launchpad that I tried to cancel our 315 lines invoice based
on that 315 lines picking? In Brazil, each invoice line has around 6
different line taxes among other bureaucratic stuff,
that also makes 1890 lines to computes global taxes (not OpenERP fault
here)...
Well, after running for 6 hours on the dual core hardware I mentioned, the
invoice was still not cancelled (from the SQL queries, it seems it had no
loop, though I didn't investigate them a lot). I dismissed, as we can
finally have 100+ invoice lines instead of 300, that's okay for now (as time
seems to explode exponentially with the number of lines). But there are
surely things to look at in the perf of the basic functional scope, further
than pickings.
On Mon, Feb 14, 2011 at 2:00 PM, filsys <email address hidden> wrote:
> Hi,
> not only partial picking process is very very slow.
> Paymen invoice (directly from invoice or from
> Accounting/
> inacceptable to wait for 2 min for every payment, whatever i have 200
> invoice unpayed or 10 invoices unpayed.
> I v.5 same workflow works very fine. seems to be from osv_memory?
> Thanks
>
> Pe 14.02.2011 17:48, qdp (OpenERP) a scris:
> > hi,
> >
> > we are currently investigating to find the reason why this part of the
> > process is that slow. Thanks for your patience (it seems really
> > appropriate this time ^^)
> >
> > Quentin
> >
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https:/
>
> Title:
> [6.0.1][stock] very very slow (22 minutes!!!) to process a large
> picking
>
> Status in OpenERP Modules (addons):
> Confirmed
>
> Bug description:
> Hey guys,
>
> <content randomly removed due to foul language, please respect the
> Etiquette!> full description + screenshot here (new bug because different
> concern):
> https:/
>
> During that time, my server CPU usage shows roughly:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 32290 postgres 20 0 54388 38m 32m R 71 1.2 1:47.89 postgres
> 32284 akretion 20 0 186m 113m 23m S 21 3.5 0:49.00 python
>
> So an SQL log analyzer will help us to find if there is some slow
> query. Fortunately here the case is almost daily, so we will be able
> to log the queries. But if you have an idea, be my guest, cause this
> would impact large companies very badly.
>
> BTW, this is our hardware, the rest of the perf is pretty good:
>
> root@audiolivro
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 23
> model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
> stepping : 10
> cpu MHz : 1603.000
> cache size : 3072 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> apicid : 0
> initial apicid : 0
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc
> arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
> cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
> bogomips : 5852.43
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 23
> model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
> stepping : 10
> cpu MHz : 1603.000
> cache size : 3072 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> apicid : 1
> initial apicid : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc
> arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
> cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
> bogomips : 5851.96
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> To unsubscribe from this bug, go to:
> https:/
>