Comment 11 for bug 709575

We trying to deploy OpnERp 6 in a company with a warehouse and 2 point
of sales.
We manage around 2000 of products, most of them with tracking lots.
In warehouse we have to encode around of 5-10 purchases per day with
supplier invoices and incoming picking generated from purchases.
Purchases have 10-20 lines each.
Daily from the warehouse is processed 20-30 of sales with pickings and
invoices generated. The sales have also 10-20 lines each.
Apart those, we have to process 300 lines (50-100 pos orders) in both
point of sales.
Our infrastructure is a cabled network with one server xeon quad with
4GB RAM and with speed disks and clients is dual core, core 2 duo and i3
with 2GB RAM.
In terms of picking delay, because aur picking is not very large, we can
accept a small delay between start process and finalize, but when we
have process payment (in POS or on invoice) we waiting too too much. As
what you see, our customer is a small company, not a big one or banking
and we can't use adequated payment even if we use point of sales, bank
statement, customer/supplier payment/voucer or payment directly from
invoice.
Even if this is not a bug in common sense, we think that is very urgent
to fix this issue BEFORE expand OpenERP 6 on the EVERY kind of market.
Thanks

Pe 14.02.2011 18:20, Raphaël Valyi - http://www.akretion.com a scris:
> 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/Customers/Customer Payment) is very, very, very ... slow. Is
>> 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://bugs.launchpad.net/bugs/709575
>>
>> 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://bugs.launchpad.net/openobject-addons/+bug/709559
>>
>> 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@audiolivroserver:~# cat /proc/cpuinfo
>> 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://bugs.launchpad.net/openobject-addons/+bug/709575/+subscribe
>>