Hi Hillary,
I'd suggest around 1000 to 2000 shared buffers and bump your max connections
to at least 64.
Make sure you're kernel allowed enough shared memory for the above (2000 *
8k = 16MB)
Chris
- Original Message -
From: "Hilary Forbes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Se
On Tue, 1 Jul 2003 15:02:21 +0200, "Michael Mattox"
<[EMAIL PROTECTED]> wrote:
>I have 1.5 gigs of RAM on my
>server but I'm also running a few other java programs that take up probably
>500 megs total of memory, leaving me 1gig for Postgres. Should I set my
>shared buffers to be 25% of 1gig? Tha
On 1 Jul 2003 at 15:50, Howard Oblowitz wrote:
> The documentation says that Effective Cache Size "sets the optimizer's
> assumption
> about the effective size of the disk cache ( that is, the portion of the
> kernel's disk
> cache that will be used for PostgreSQL data files ).
>
> What then wil
On Tue, 1 Jul 2003 15:50:14 +0200 , Howard Oblowitz
<[EMAIL PROTECTED]> wrote:
>What then will be the effect of setting this too high?
The planner might choose an index scan where a sequential scan would
be faster.
>And too low?
The planner might choose a sequential scan where an index scan woul
I think you're confusing effect_cache_size with shared_buffers.
effective_cache_size tells the planner about how much disk cache the OS is
using for postgresql behind its back, so to speak.
On Tue, 1 Jul 2003, Michael Mattox wrote:
> My understanding is to use as much effect cache as possible,
Good questions. Basically, telling postgresql it has a larger disk cache
makes it favor index operations, smaller makes it favor seq scans.
If your machine has super fast I/O then you may want it to favor seq
scans, whereas if you have more CPU power than I/O bandwidth then you'd
likely want i
On Tue, 1 Jul 2003, Michael Mattox wrote:
> My understanding is to use as much effect cache as possible, so figure out
> how much ram you need for your other applications & OS and then give the
> rest to postgres as effective cache.
>
> What I learned to day is the shared_buffers 25% of RAM guide
Thanks.
Some theoretical questions.
The documentation says that Effective Cache Size "sets the optimizer's
assumption
about the effective size of the disk cache ( that is, the portion of the
kernel's disk
cache that will be used for PostgreSQL data files ).
What then will be the effect of setti
My understanding is to use as much effect cache as possible, so figure out
how much ram you need for your other applications & OS and then give the
rest to postgres as effective cache.
What I learned to day is the shared_buffers 25% of RAM guideline.
Michael
> -Original Message-
> From:
Toby Sargeant <[EMAIL PROTECTED]> writes:
> Merge Join (cost=0.00..448139.41 rows=14786 width=52) (actual
> time=1582.24..125624.92 rows=2140 loops=1)
>Merge Cond: ("outer".seq_text_id = "inner".id)
>-> Index Scan using seq_text_map_seq_text_index on seq_text_map
> (cost=0.00..154974.
The best way to set it is to let the machine run under normal load for a
while, then look at the cache / buffer usage using top (or some other
program, top works fine for this).
My server with 1.5 gig ram shows 862328K cache right now. So, just divide
by page size (usually 8192) and I get ~ 10
What would be the best value range for effective_cache_size
on Postgres 7.3.2, assuming say 1.5 GB of RAM and
shared_buffers set to 8192, and shmmax set to 750mb?
And what are the most important factors one should take
into account in determining the value?
> -Original Message-
> From:
8192 is only 64 megs of RAM, not much, but a good number. Keep in mind
that the kernel tends to be better at buffering huge amounts of disk,
while postgresql is better left to use buffers that are large enough for
the current working set (i.e. not your whole database, just the largest
amount o
> yes, I'd say start with about 25% of RAM, then adjust from there. If 25%
> takes you over your SHMMAX then start at your SHMMAX.
You're the first person I've seen to suggest that many buffers. I've read
that too many can slow down performance. I have 1.5 gigs of RAM on my
server but I'm also r
On Tue, 2003-07-01 at 08:10, Hilary Forbes wrote:
> I'm just trying to improve performance on version 7 before doing some
tests and hopefully upgrading to 7.3.
>
> At the moment we have
> B=64 (no of shared buffers)
> N=32 (no of connections)
> in postmaster.opt which I take it is the equivalen
I have my shared buffers at 8192 and my effective cache at 64000 (which is
500 megs). Depends a lot on how much RAM you have. I have 1.5 gigs and
I've been asking my boss for another 512megs for over a month now. I have
no idea if my buffers are too high/low.
Michael
> -Original Message---
I'm just trying to improve performance on version 7 before doing some tests and
hopefully upgrading to 7.3.
At the moment we have
B=64 (no of shared buffers)
N=32 (no of connections)
in postmaster.opt which I take it is the equivalent of the new postgresql.conf file.
From all that is being w
On Tuesday 01 July 2003 13:40, Juraj Porada wrote:
> shared_buffers = 32
That is 32*8=256KB of memory. I thought default was 64. How much physical
memory you have?
I suggest you set it up something like 256 to start with. That may be too
small as well but you haven't provided enough details to
shared_buffers = 32
I don't have much experience in tuning the database, but I think there is
a problem with a fragmentation of memory or so.
I don't known backgrounds.
Juraj
Shridhar Daithankar schrieb:
On Tuesday 01 July 2003 13:17, Juraj Porada wrote:
I insert data every sec
On Tuesday 01 July 2003 13:17, Juraj Porada wrote:
> I insert data every second in my table. Every minute I delete from the
> table some row to keep max 1 rows in the table.
> At the beginning deletes consume about 20% CPU time. After 24 houts
> every delete needs up tu 100% CPU time (updates t
I insert data every second in my table. Every minute I delete from the
table some row to keep max 1 rows in the table.
At the beginning deletes consume about 20% CPU time. After 24 houts
every delete needs up tu 100% CPU time (updates too).
Vacuuming doesn't help.
After I restart postmaster,
21 matches
Mail list logo
