At 10:26 AM 11/22/2005, Guillaume Smet wrote:
Ron,
First of all, thanks for your time.
Happy to help.
As has been noted many times around here, put the WAL on its own
dedicated HD's. You don't want any head movement on those HD's.
Yep, I know that. That's just we supposed it was not so im
Ron,
First of all, thanks for your time.
As has been noted many times around here, put the WAL on its own
dedicated HD's. You don't want any head movement on those HD's.
Yep, I know that. That's just we supposed it was not so important if it
was nearly a readonly database which is wrong acc
At 09:26 AM 11/22/2005, Guillaume Smet wrote:
Ron wrote:
If I understand your HW config correctly, all of the pg stuff is on
the same RAID 10 set?
No, the system and the WAL are on a RAID 1 array and the data on
their own RAID 10 array.
As has been noted many times around here, put the WAL
Claus and Andrew,
Claus Guttesen wrote:
Isn't sort_mem quite high? Remember that sort_mem size is allocated
for each sort, not for each connection. Mine is 4096 (4 MB). My
effective_cache_size is set to 27462.
I tested sort mem from 4096 to 32768 (4096, 8192, 16384, 32768) this
afternoon and
Ron wrote:
If I understand your HW config correctly, all of the pg stuff is on the
same RAID 10 set?
No, the system and the WAL are on a RAID 1 array and the data on their
own RAID 10 array.
As I said earlier, there's only a few writes in the database so I'm not
really sure the WAL can be a l
If I understand your HW config correctly, all of the pg stuff is on
the same RAID 10 set?
If so, give WAL its own dedicated RAID 10 set. This looks like the
old problem of everything stalling while WAL is being committed to HD.
This concept works for other tables as well. If you have a tabl
Qingqing Zhou wrote:
Someone is doing a massive *write* at this time, which makes your query
*read* quite slow. Can you find out which process is doing write?
Indexes should be in memory so I don't expect a massive write to slow
down the select queries. sdb is the RAID10 array dedicated to our
Andrew,
I would be very suspicious of that much memory for sort. Please see
the docs for what that does. That is the amount that _each sort_ can
allocate before spilling to disk.
If some set of your users are
causing complicated queries with, say, four sorts apiece, then each
user is potential
"Guillaume Smet" <[EMAIL PROTECTED]> wrote
> [EMAIL PROTECTED] root]# iostat 10
>
> Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
> sda 7.20 0.0092.00 0920
> sda1 0.00 0.00 0.00 0
> I forgot to give our non default postgresql.conf parameters:
> shared_buffers = 28800
> sort_mem = 32768
> vacuum_mem = 32768
> max_fsm_pages = 35
> max_fsm_relations = 2000
> checkpoint_segments = 16
> effective_cache_size = 27
> random_page_cost = 2
Isn't sort_mem quite high? Remember
Andrew,
Andrew Sullivan wrote:
> Is it exactly half an hour? What changes at the time that happens
> (i.e. what else happens on the machine?). Is this a time, for
> example, when logrotate is killing your I/O with file moves?
No, it's not exactly half an hour. It's just that it slows down for
On Thu, Nov 17, 2005 at 06:47:09PM +0100, Guillaume Smet wrote:
> queries are executed fast even if they are complicated but sometimes and
> for half an hour, we have a general slow down.
Is it exactly half an hour? What changes at the time that happens
(i.e. what else happens on the machine?).
Hi all,
We are operating a 1.5GB postgresql database for a year and we have
problems for nearly a month. Usually everything is OK with the database,
queries are executed fast even if they are complicated but sometimes and
for half an hour, we have a general slow down.
The server is a dedicat
13 matches
Mail list logo
