Skip site navigation (1) Skip section navigation (2)

Re: Capping CPU usage?

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Capping CPU usage?
Date: 2002-12-12 17:57:57
Message-ID: 1039715877.1261.101.camel@haggis (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 2002-12-12 at 11:43, Josh Berkus wrote:
> Tom,
> 
> > If the issue is to prevent Postgres *as a whole* from hogging CPU
> > usage,
> > I would think that nice-ing the postmaster at launch would work
> > beautifully.  Requests like "I want Postgres to use no more than 30%
> > of CPU" make no sense to me: if the CPU is otherwise idle, why should
> > you insist on reserving 70% of it for the idle loop?
> 
> <grin>  That's what I asked the person who asked me.  Apparently, they
> want to do real-time operations without forking out for a real-time OS.
>   My response was "you can nice the postmaster, and simplify your
> queries, but that's about it".

Maybe, even with processes niced down low, the current Linux scheduler
"drop down" a currently schueduled/executing process. 

Maybe that would change with the low-latency patches, or with the
O(1) scheduler in kernel 2.6.

-- 
+---------------------------------------------------------------+
| Ron Johnson, Jr.        mailto:ron(dot)l(dot)johnson(at)cox(dot)net          |
| Jefferson, LA  USA      http://members.cox.net/ron.l.johnson  |
|                                                               |
| "My advice to you is to get married: If you find a good wife, |
| you will be happy; if not, you will become a philosopher."    |
|    Socrates                                                   |
+---------------------------------------------------------------+


In response to

pgsql-performance by date

Next:From: Lincoln YeohDate: 2002-12-12 21:02:28
Subject: Re: Docs: GIST
Previous:From: Josh BerkusDate: 2002-12-12 17:49:08
Subject: Re: Time to commit a change

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group