From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 8.4.8 bringing my website down every evening |
Date: | 2011-05-26 15:12:17 |
Message-ID: | 4DDE6DD1.9070707@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dne 26.5.2011 16:39, Merlin Moncure napsal(a):
> On Thu, May 26, 2011 at 9:01 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>> Dne 26.5.2011 11:41, Alexander Farber napsal(a):
>>> Also I wonder, how's shared memory used by PostgreSQL.
>>> I'm irritated - how it could work with 32MB,
>>> but now I've got suggestion to increase it
>>> to 512MB (and it seems to work too...)
>>
>> Shared buffers are a 'database cache'. When the DB needs a block from a
>> file (because that's where the data are stored), it reads the data into
>> the cache. When the same block is needed again, it may be read from the
>> cache (which is much faster). Unless there's not enough space to hold
>> all the blocks - in that case the block may be removed from the cache
>> and will be read from the disk again.
>
> *or the disk cache*. lowering shared buffers does not lower the
> amount of ram in the system and thus does not lower the availability
> of cache. If I may nitpick this point on your otherwise very
> excellent email, this is exactly the type of thing that drives me
> crazy about advice to raise shared buffers. It suggests you will get
> less disk i/o which may or may not be the case (in fact, it can make
> the i/o problem worse). If it does help i/o, it will probably not be
> for the reasons you suspect. See my thread in -performance on this
> topic.
Yes, you're right. I didn't want to complicate the things further so
I've skipped the part about page cache.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-05-26 15:47:56 | Re: When is commited data available |
Previous Message | Vick Khera | 2011-05-26 15:01:53 | Re: When is commited data available |