shared_buffers = 12000 will use 12000*8192 bytes (i.e about 96Mb). It is
shared, so no matter how many connections you have it will only use 96M.
Now I use the figure of 27853
Will the increasing in effective cache size to arround 20 make a little
bit
improvement ? Do you think so?
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on my
8GB Opteron server and 10K seems to be the best setting.
also effective cache is the sum of kernel buffers + shared_buffers so it
should be
William Yu wrote:
[EMAIL PROTECTED] wrote:
Yes , vacuumdb daily.
Do you vacuum table by table or the entire DB? I find over time, the
system tables can get very bloated and cause a lot of slowdowns just due
to schema queries/updates. You might want to try a VACUUM FULL ANALYZE
just on the
Amrit --
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Mon 1/3/2005 12:18 AM
To:Mark Kirkwood
Cc:PGsql-performance
Subject: Re: [PERFORM] Low Performance for big hospital server ..
shared_buffers = 12000 will use 12000*8192 bytes (i.e about
Decrease the sort mem too much [8196] make the performance much slower
so I use
sort_mem = 16384
and leave effective cache to the same value , the result is quite better
but I
should wait for tomorrow morning [official hour] to see the end result.
You could also profile your queries to see
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on
my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not using opterons which can access physical
Amrit,
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
I would seriously consider upgrading, if at all possible.
A few more hints.
Random page cost is quite conservative if you have reasonably fast
amrit wrote:
I try to adjust my server for a couple of weeks with some sucess but
it
still
slow when the server has stress in the moring from many connection . I
used
postgresql 7.3.2-1 with RH 9 on a mechine of 2 Xeon 3.0 Ghz and ram of
4
Gb.
Since 1 1/2 yr. when I started to use the
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
There are a little bit incompatibility between 7.3 -8 , so rather difficult to
change.
I would seriously consider upgrading, if at all possible.
A few more
Hi,
are there any plans for rewriting queries to preexisting materialized
views? I mean, rewrite a query (within the optimizer) to use a
materialized view instead of the originating table?
Regards,
Yann
---(end of broadcast)---
TIP 6: Have you
On Monday 03 January 2005 10:40, [EMAIL PROTECTED] wrote:
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
There are a little bit incompatibility between 7.3 -8 , so rather difficult
to change.
Sure, but
On Mon, 13 Dec 2004 09:23:13 -0800, Joshua D. Drake
[EMAIL PROTECTED] wrote:
RAID 10 will typically always outperform RAID 5 with the same HD config.
Isn't RAID10 just RAID5 mirrored? How does that speed up performance?
Or am I missing something?
-- Mitch
---(end of
Mitch Pirtle wrote:
On Mon, 13 Dec 2004 09:23:13 -0800, Joshua D. Drake
[EMAIL PROTECTED] wrote:
RAID 10 will typically always outperform RAID 5 with the same HD config.
Isn't RAID10 just RAID5 mirrored? How does that speed up performance?
Or am I missing something?
-- Mitch
Hi Mitch,
Nope,
Dave Cramer wrote:
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings on
my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not using opterons which
Madison Kelly wrote:
Nope, Raid 10 (one zero) is a mirror is stripes, no parity. with r10
Woops, that should be mirror of stripes.
By the way, what you are thinking of is possible, it would be 51 (five
one; a raid 5 built on mirrors) or 15 (a mirror of raid 5 arrays).
Always be careful, 10
Madison Kelly [EMAIL PROTECTED] writes:
Without it, specially in a failure state, the performance can collapse as
the CPU performs all that extra math.
It's really not the math that makes raid 5 hurt. It's that in order to
calculate the checksum block the raid controller needs to read in the
You are right, I now remember that setup was originally called RAID
10 plus 1, and I believe is was an incorrect statement from an
overzealous salesman ;-)
Thanks for the clarification!
- Mitch
On Mon, 03 Jan 2005 15:19:04 -0500, Madison Kelly [EMAIL PROTECTED] wrote:
Madison Kelly wrote:
I've got a table using a data type that I have
created as the type for its primary key. I (hope) I have the type set up
properly - it seems okay, and does not have any problem creating a b-tree index
for the type. The problem I am having is that the index seems to never be
chosen for use. I
Well, it's not quite that simple
the rule of thumb is 6-10% of available memory before postgres loads is
allocated to shared_buffers.
then effective cache is set to the SUM of shared_buffers + kernel buffers
Then you have to look at individual slow queries to determine why they
are slow,
Besides the tables pg_stat_xxx, are there any stronger tools for
PostgreSQL as the counterpart of Oracle's Statspack? Is it possible at
all to trace and log the cpu and io cost for each committed
transaction?
Thanks a lot! -Stan
__
Do You Yahoo!?
Merlin Moncure [EMAIL PROTECTED] writes:
Tom Lane wrote:
Add a small cost factor to ensure we
prefer materializing the smaller input. This changes several
regression test plans, but with any luck we will now have more
stability across platforms.
No. The planner is not a factor.
You are
[EMAIL PROTECTED] wrote:
I realize you may be stuck with 7.3.x but you should be aware that 7.4
is considerably faster, and 8.0 appears to be even faster yet.
There are a little bit incompatibility between 7.3 -8 , so rather difficult
to
change.
I would seriously consider upgrading, if
William Yu wrote:
Dave Cramer wrote:
William Yu wrote:
[EMAIL PROTECTED] wrote:
I will try to reduce shared buffer to 1536 [1.87 Mb].
1536 is probaby too low. I've tested a bunch of different settings
on my 8GB Opteron server and 10K seems to be the best setting.
Be careful here, he is not
...and on Mon, Jan 03, 2005 at 03:44:44PM -0500, Mitch Pirtle used the keyboard:
You are right, I now remember that setup was originally called RAID
10 plus 1, and I believe is was an incorrect statement from an
overzealous salesman ;-)
Just an afterthought - that could well be the
On Mon, Jan 03, 2005 at 01:44:27PM -0800, Adam Palmblad wrote:
I've got a table using a data type that I have created as the type for
its primary key. I (hope) I have the type set up properly - it seems
okay, and does not have any problem creating a b-tree index for the
type. The problem I
25 matches
Mail list logo
