On Fri, 2005-05-27 at 07:52 -0500, Josh Close wrote:
> > Setting shared buffers above something like 10-30% of memory is counter
> > productive.
>
> What is the reason behind it being counter productive? If shared
> buffers are at 30%, should effective cache size be at 70%? How do
> those two rela
>On 5/31/05, Martin Fandel <[EMAIL PROTECTED]> wrote:
>> In the documentation of
>> http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
>> is the shared_buffers set to 1/3 of the availble RAM.
Well, it says "you should never use more than 1/3 of your available RAM"
which is not quite t
On 5/31/05, Martin Fandel <[EMAIL PROTECTED]> wrote:
> In the documentation of
> http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
> is the shared_buffers set to 1/3 of the availble RAM. You're set
> 5*8/1024=391 MB SHMEM. The effective_cache_size in your
> configuration is 45
Josh Close <[EMAIL PROTECTED]> writes:
> There is 2 gigs of mem in this server. Here are my current settings.
> max_connections = 100
> shared_buffers = 5
> sort_mem = 4096
> vacuum_mem = 32768
> effective_cache_size = 45
> Shared buffers is set to 10% of total mem. Effective cache size i
I didn't see iostat as available to install, but I'm using dstat to see this.
The server has constant disk reads averaging around 50M and quite a
few in the 60M range. This is when selects are being done, which is
almost always. I would think if postgres is grabbing everything from
memory that thi
Hi,
I had some disk io issues recently with NFS, I found the command 'iostat
-x 5' to be a great help when using Linux.
For example here is the output when I do a 10GB file transfer onto hdc
Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
avgrq-sz avgqu-sz await svct
Doing the query
explain
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM adaption.tblBatchHistory_1
WHERE tStamp > ( now() - interval '5 mins' )::text
gives me this:
Aggregate (cost=32138.33..32138.33 rows=1 width=4)
-> Seq Scan on tblbatchhistory_1 (cost=0.00..31996.10 rows=56891 width
> I think you really want that seqscan to be an indexscan, instead.
> I'm betting this is PG 7.4.something? If so, probably the only
> way to make it happen is to simplify the now() expression to a constant:
>
> SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
> FROM adap
Josh Close <[EMAIL PROTECTED]> writes:
> this_sQuery := \'
> SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
> FROM adaption.tblBatchHistory_\' || this_rServerIds.iId || \'
> WHERE tStamp > now() - interval \'\'5 mins\'\';
> \';
> Here is the e
> Few "mandatory" questions:
>
> 1. Do you vacuum your db on regular basis? :)
It's vacuumed once every hour. The table sizes and data are constantly changing.
>
> 2. Perhaps statistics for tables in question are out of date, did you
> try alter table set statistics?
No I haven't. What would
On 5/26/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> > I have some queries that have significan't slowed down in the last
> > couple days. It's gone from 10 seconds to over 2 mins.
> >
> > The cpu has never gone over 35% in the servers lifetime, but the load
> > average is over 8.0 righ
> Setting shared buffers above something like 10-30% of memory is counter
> productive.
What is the reason behind it being counter productive? If shared
buffers are at 30%, should effective cache size be at 70%? How do
those two relate?
>
> Increasing sort_mem can help with various activities, b
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm assuming this is probably due to
disk io.
You sure it's not a severe
On 5/26/05, Josh Close <[EMAIL PROTECTED]> wrote:
> I have some queries that have significan't slowed down in the last
> couple days. It's gone from 10 seconds to over 2 mins.
>
> The cpu has never gone over 35% in the servers lifetime, but the load
> average is over 8.0 right now. I'm assuming th
Josh Close wrote:
>I have some queries that have significan't slowed down in the last
>couple days. It's gone from 10 seconds to over 2 mins.
>
>The cpu has never gone over 35% in the servers lifetime, but the load
>average is over 8.0 right now. I'm assuming this is probably due to
>disk io.
>
>I
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm assuming this is probably due to
disk io.
I need some help setting up
16 matches
Mail list logo
