| 2011-01-29 00:55:15 |
Raphaël Valyi - http://www.akretion.com |
bug |
|
|
added bug |
| 2011-01-29 09:49:32 |
xrg |
marked as duplicate |
|
709559 |
|
| 2011-01-29 09:50:28 |
xrg |
description |
Hey guys,
very happy to learn that v6 is such a major perf leap. Cause here in production on 6.0.1, we have 41 000 stock moves in the DB. That I try to validate a 315 lines moves picking and it takes 22 minutes to complete (yes just 22 fucking whole minutes), 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: |
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: |
|
| 2011-01-30 03:19:24 |
snook |
bug |
|
|
added subscriber snook |
| 2011-01-31 09:56:27 |
Olivier Dony (Odoo) |
changed duplicate marker |
709559 |
555271 |
|
| 2011-01-31 09:57:04 |
Olivier Dony (Odoo) |
removed duplicate marker |
555271 |
|
|
| 2011-01-31 10:03:09 |
Olivier Dony (Odoo) |
openobject-addons: importance |
Undecided |
Medium |
|
| 2011-01-31 10:03:09 |
Olivier Dony (Odoo) |
openobject-addons: status |
New |
Confirmed |
|
| 2011-01-31 10:03:09 |
Olivier Dony (Odoo) |
openobject-addons: assignee |
|
OpenERP R&D Addons Team 2 (openerp-dev-addons2) |
|
| 2011-01-31 10:08:17 |
Olivier Dony (Odoo) |
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: |
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
Screenshot for reference: https://bugs.launchpad.net/openobject-addons/+bug/709559/+attachment/1813508/+files/large_picking.png
Example of one of many 150+ms SQL queries executed during these 20 mins: http://launchpadlibrarian.net/63120073/stock_logs.txt
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:
|
|
| 2011-01-31 12:54:36 |
Raphaël Valyi - http://www.akretion.com |
attachment added |
|
postgresql-2011-01-29_230423.log https://bugs.launchpad.net/openobject-addons/+bug/709575/+attachment/1819616/+files/postgresql-2011-01-29_230423.log |
|
| 2011-01-31 12:57:48 |
Raphaël Valyi - http://www.akretion.com |
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
Screenshot for reference: https://bugs.launchpad.net/openobject-addons/+bug/709559/+attachment/1813508/+files/large_picking.png
Example of one of many 150+ms SQL queries executed during these 20 mins: http://launchpadlibrarian.net/63120073/stock_logs.txt
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:
|
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:
|
|
| 2011-01-31 13:00:01 |
Raphaël Valyi - http://www.akretion.com |
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:
|
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
Screenshot for reference: https://bugs.launchpad.net/openobject-addons/+bug/709559/+attachment/1813508/+files/large_picking.png
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:
|
|
| 2011-01-31 13:00:50 |
Raphaël Valyi - http://www.akretion.com |
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
Screenshot for reference: https://bugs.launchpad.net/openobject-addons/+bug/709559/+attachment/1813508/+files/large_picking.png
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:
|
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:
|
|
| 2011-02-22 10:48:40 |
xrg |
attachment added |
|
0001-stock-improve-speed-for-action_done-with-many-moves-.patch https://bugs.launchpad.net/bugs/709575/+attachment/1865267/+files/0001-stock-improve-speed-for-action_done-with-many-moves-.patch |
|
| 2011-02-22 14:19:41 |
qdp (OpenERP) |
openobject-addons: status |
Confirmed |
Fix Released |
|
