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.