"Max Zorloff" <zorloff@xxxxxxxxx> writes:
> ... The problem is that after the number of concurrent users rises to
> 100, CPU becomes almost 100% loaded. How do I find out what's hogging the
> CPU?
> 'top' shows demon using 8% cpu on top, and some amount of postgres
> processes each using 2% cpu with some apache processes occassionally
> rising with 2% cpu also. Often the writer process is at the top using 10%
> cpu.
IOW there's nothing particular hogging the CPU? Maybe you need more
hardware than you've got, or maybe you could fix it by trying to
optimize your most common queries. It doesn't sound like there'll be
any quick single-point fix though.
> And the second question is that over time demon and writer processes use
> more and more shared memory - is it normal?
This is probably an artifact. Many versions of "top" report a process
as having used as many pages of shared memory as it's actually touched
in its lifetime. So if you have lots of shared buffers, then any one
Postgres process will show growth of reported memory usage as it
randomly happens to access one buffer or another, eventually maxing out
at whatever you've got the PG shared memory segment size set to.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
