c2c-oerpscenario team mailing list archive

[filsys <office@xxxxxxxxxxxx>]

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<office@xxxxxxxxxxxx>  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
>>

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
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: