Hardware: IBM X3650 M3 (2 x Xeon X5680 6C 3.33GHz), 96GB RAM. IBM X3524
with RAID 10 ext4 (noatime,nodiratime,data=writeback,barrier=0) volumes for
pg_xlog / data / indexes.
Software: SLES 11 SP2 3.0.58-0.6.2-default x86_64, PostgreSQL 9.0.4.
max_connections = 1500
shared_buffers = 16GB
work_mem
Hello Mark,
if i was you i would start with making basic benchmarks regarding IO
performance (bonnie++ maybe?) and i would check my sysctl.conf. your
parameters look ok to me.
when these delays occur have you noticed whats causing it ? An output of
vmstat when the delays are happening would also
There's another thread in the list started by Josh Berkus about poor
performance with a similar kernel. I'd look that thread up and see if
you and he have enough in common to work together on this.
On Thu, Feb 21, 2013 at 2:59 AM, Mark Smith smithmark...@gmail.com wrote:
Hardware: IBM X3650 M3
On Thu, Feb 21, 2013 at 1:59 AM, Mark Smith smithmark...@gmail.com wrote:
Software: SLES 11 SP2 3.0.58-0.6.2-default x86_64, PostgreSQL 9.0.4.
[skipped]
Problem: We have been running PostgreSQL 9.0.4 on SLES11 SP1, last kernel in
use was 2.6.32-43-0.4, performance has always been great. Since
(Sorry moderators for any double posts, I keep making subscription errors.
Hopefully this one gets through)
Hi speed freaks,
Can anyone tell me why the bitmap heap scan takes so long to start for this
query? (SQL and EXPLAIN ANALYZE follows).
The big culprit in this appears to be:
- Bitmap
On Thu, Feb 21, 2013 at 8:57 AM, Carlo Stonebanks
stonec.regis...@sympatico.ca wrote:
(Sorry moderators for any double posts, I keep making subscription errors.
Hopefully this one gets through)
Hi speed freaks,
Can anyone tell me why the bitmap heap scan takes so long to start for this
