Re: Resources

Try "pg_ctl stop" -- you can get the usage and explanation in the idocs:

http://www.postgresql.org/idocs/index.php?app-pg-ctl.html

Mike

-----Original Message-----
From: Wei Weng [mailto:wweng@kencast.com]
Sent: Thursday, January 10, 2002 1:34 PM
To: Stephan Szabo
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] Resources


I have a side question. How do I stop this kind of crazy query to suck up
my CPU power if it is fed by a database driver? (like ODBC, for example)

Since kill -9 postmaster is highly not recommended, can i do a
/sbin/service postgresql stop to force it to shut down? (I am a redhat
user.)

Thank you!

On Thu, 10 Jan 2002 08:12:12 -0800 (PST)
Stephan Szabo <sszabo@megazone23.bigpanda.com> wrote:

> On Thu, 10 Jan 2002, Gurudutt wrote:
> 
> > I have a pentium III server, running on RHL 7.1 with 256 MB RAM,
> >
> > The following is output of the "top" command for query which involves
> > fetch from a table with about MAX of 10,000 rows.
> >
> > -------------------------------------TOP------------------------------
> >   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
> >
> >  3174 postgres  19   0  3328 3328  2672 R    99.0  1.3   0:58
> >  postmaster 1199 nobody     9   0  3728 3728  2704 S     0.5  1.4  
> >  0:03 httpd 3035 root      10   0  1048 1048   840 R     0.3  0.4  
> >  0:15 top   1 root       8   0   544  544   472 S     0.0  0.2   0:04
> >  init   2 root       9   0     0    0     0 SW    0.0  0.0   0:00
> >  keventd   3 root
> >
> >
> > Now, my question is, it takes ages(2 mints) for the query to run
> > (regularly VACUUM ANALYZED Database) and if you look closely at the
> > resources consumed by the postgres, it is almost taking away 100% CPU
> > time.
> >
> > How can we make it faster and to consume less resources ??
> >
> > Can anybody suggest the steps they are taking for time-critical
> > applications to run efficiently.
> 
> An important thing is checking the explain output for the query.  If you
> want to  post the schema, query and explain output, we might be able to
> come up with suggestions on that level.
> 
> You may also want to look at your ram usage.  The default shared buffers
> and sort memory are very low and you'll probably want to raise them.
> You don't want to make them too big because you want to leave memory for
> disk caching, but you can raise them to low thousands and see if that
> helps.
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 


-- 
Wei Weng
Network Software Engineer
KenCast Inc.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly