That's a good thought, maybe the stats are old and you have bad
plans? It could also be major updates to the data too (as opposed to
growth).
we have made checks for number of dead tuples etc recently, but looks
ok. and as "everything" in the database seems to be very slow atm, I
guess th
That's why I love dstat, just do this
$ dstat -C 0,1,2,3,4,5,6,7
and you know all you need.
dstat looks like a very nice tool, results below ..
(now the system load seems a bit lower then before when generating
results for vmstat and iostat)
Good catch, thanks Scott.
Yes, good catch.
Sti
hi,
What does a "normal load" mean? Does that mean a time when the queries are
slow?
yes, we are have slow queries (according to postgresql.log) with such load
Are you sure the machine really has 48GB of RAM? Because from the vmstat
output it seems like there's just 32GB.
procs ---me
Thanks a lot to everybody for their helpful hints!!!
I am running all these benchmarks while the VMs are up .. with the
system under something like "typical" loads ..
The RAID is hardware based. On of my colleagues will check if there is
any hardware problem on the RAID (the disks) today, but
hi,
thanks a lot for your help!
Dear list,
we are encountering serious performance problems with our database.
Queries which took around 100ms or less last week now take several
seconds.
The database runs on Ubuntu Server 10.4.3 (kernel: 2.6.32-33) on
hardware as follows:
8-core Intel Xeon CP
hi,
thanks a lot for your help!
Dear list,
we are encountering serious performance problems with our database.
Queries which took around 100ms or less last week now take several
seconds.
The database runs on Ubuntu Server 10.4.3 (kernel: 2.6.32-33) on
hardware as follows:
8-core Intel Xeon CP
On 09/05/2011 03:51 PM, Andy Colson wrote:
On 09/05/2011 02:48 AM, Tomas Vondra wrote:
On 3 Září 2011, 9:26, Gerhard Wohlgenannt wrote:
Dear list,
we are encountering serious performance problems with our database.
Queries which took around 100ms or less last week now take several
seconds
Dear list,
we are encountering serious performance problems with our database.
Queries which took around 100ms or less last week now take several seconds.
The database runs on Ubuntu Server 10.4.3 (kernel: 2.6.32-33) on
hardware as follows:
8-core Intel Xeon CPU with 2.83GHz
48 GB RAM
RAID 5
