PHP + Postgres: More than 1000 postmasters produce 70.000 contextswitches

[Gellert, Andre]

Hello,
we installed a new Postgres 7.4.0 on a Suse 9 system.
This is used as a part of an extranet , based on Apache+PHP and has besides
a ldap
server no services running. The system has dual xeon 2ghz and 2GB RAM.
When migrating all applications from 2 other postgres7.2 servers to the new
one,
we had heavy load problems.
At the beginning there where problems with to much allocated shared memory,
as the system was swapping 5-10 mb / sec . So we now reconfigured the
shared_buffers to 2048, which should mean 2mb (linux=buffer each one kb) per
process.
We corrected higher values from sort_mem and vacuum_mem back to sort_mem=512
and
vacuum_mem=8192 , too, to reduce memory usage, although we have
kernel.shmall = 1342177280 and kernel.shmmax = 1342177280 .

Currenty i have limited the max_connections to 800, because every larger
value results in
a system load to 60+ and at least 20.000 context switches.

My problem is, that our apache produces much more than 800 open connections,

because we are using > 15 diff. databases and apache seems to keep
connections to every
database open , the same httpd-process has connected before.
For now i solved it in a very dirty way, i limited the number and the
lifetime
of each httpd process with those values :
MaxKeepAliveReq uests 10
KeepAliveTimeou t 2
MaxClients 100
MaxRequestsPerC hild 300

We use php 4.3.4 and PHP 4.2.3 on the webservers. PHP ini says:
[PostgresSQL]
; Allow or prevent persistent links.
pgsql.allow_per sistent = On
; Maximum number of persistent links. -1 means no limit.
pgsql.max_persi stent = -1
; Maximum number of links (persistent+non persistent). -1 means no limit.
pgsql.max_links = -1

We are now running for days with an extremly unstable database backend...
Are 1.000 processes the natural limit on a linux based postgresql ?
Can we realize a more efficient connection pooling/reusing ?

thanks a lot for help and every idea is welcome,
Andre

BTW: Does anyone know commercial administration trainings in Germany, near
Duesseldorf?


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Richard Huxton]

Re: PHP + Postgres: More than 1000 postmasters produce 70.000 context switches

On Friday 20 February 2004 15:32, Gellert, Andre wrote:[color=blue]
> Hello,
> we installed a new Postgres 7.4.0 on a Suse 9 system.
> This is used as a part of an extranet , based on Apache+PHP and has besides
> a ldap
> server no services running. The system has dual xeon 2ghz and 2GB RAM.
> When migrating all applications from 2 other postgres7.2 servers to the new
> one,
> we had heavy load problems.
> At the beginning there where problems with to much allocated shared memory,
> as the system was swapping 5-10 mb / sec . So we now reconfigured the
> shared_buffers to 2048, which should mean 2mb (linux=buffer each one kb)
> per process.[/color]

Actually it's probably 8kB each = 16MB, but thats between *all* the backends.
You probably want something a fair bit larger than this. Go to

http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

and read the section on performance tuning and on the annotated
postgresql.conf
[color=blue]
> We corrected higher values from sort_mem and vacuum_mem back to
> sort_mem=512 and
> vacuum_mem=8192 , too, to reduce memory usage, although we have
> kernel.shmall = 1342177280 and kernel.shmmax = 1342177280 .[/color]

You can probably put vaccum_mem back up.
[color=blue]
> Currenty i have limited the max_connections to 800, because every larger
> value results in
> a system load to 60+ and at least 20.000 context switches.[/color]

Might be your shared_buffers being too low, but we'll let someone else
comment.
[color=blue]
> My problem is, that our apache produces much more than 800 open
> connections,
>
> because we are using > 15 diff. databases and apache seems to keep
> connections to every
> database open , the same httpd-process has connected before.
> For now i solved it in a very dirty way, i limited the number and the
> lifetime
> of each httpd process with those values :
> MaxKeepAliveReq uests 10
> KeepAliveTimeou t 2
> MaxClients 100
> MaxRequestsPerC hild 300[/color]

You do want to limit the MaxRequestsPerC hild if you're using persistent
connections. The problem seems to be with your PHP though
[color=blue]
> We use php 4.3.4 and PHP 4.2.3 on the webservers. PHP ini says:
> [PostgresSQL]
> ; Allow or prevent persistent links.
> pgsql.allow_per sistent = On
> ; Maximum number of persistent links. -1 means no limit.
> pgsql.max_persi stent = -1
> ; Maximum number of links (persistent+non persistent). -1 means no limit.
> pgsql.max_links = -1[/color]

So - you let PHP open persistent connections to PG and have no limit to the
number of different connections open at any one time?
Turn the persistent connections off - you'll probably find your problems go
away.
[color=blue]
> We are now running for days with an extremly unstable database backend...
> Are 1.000 processes the natural limit on a linux based postgresql ?
> Can we realize a more efficient connection pooling/reusing ?[/color]

You probably can pool your connections better, but difficult to say without
knowing what your PHP is doing.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Csaba Nagy]

Re: PHP + Postgres: More than 1000 postmasters produce

Well, it seems for your application is better to limit php's persistent
connection pool as a quick measure.
Try to set these values to something sensible for you:

; Maximum number of persistent links. -1 means no limit.
pgsql.max_persi stent = 20
; Maximum number of links (persistent+non persistent). -1 means no limit.
pgsql.max_links = 30

Or just disable persistent connections altogether, and see if that is
not resulting in better performance:

; Allow or prevent persistent links.
pgsql.allow_per sistent = Off

In the long term look for some better connection pooling mechanism, I'm
sure you'll find something for PHP too (I'm not using php, maybe
somebody else on the list can help ?).

Cheers,
Csaba.

On Fri, 2004-02-20 at 16:32, Gellert, Andre wrote:[color=blue]
> Hello,
> we installed a new Postgres 7.4.0 on a Suse 9 system.
> This is used as a part of an extranet , based on Apache+PHP and has besides
> a ldap
> server no services running. The system has dual xeon 2ghz and 2GB RAM.
> When migrating all applications from 2 other postgres7.2 servers to the new
> one,
> we had heavy load problems.
> At the beginning there where problems with to much allocated shared memory,
> as the system was swapping 5-10 mb / sec . So we now reconfigured the
> shared_buffers to 2048, which should mean 2mb (linux=buffer each one kb) per
> process.
> We corrected higher values from sort_mem and vacuum_mem back to sort_mem=512
> and
> vacuum_mem=8192 , too, to reduce memory usage, although we have
> kernel.shmall = 1342177280 and kernel.shmmax = 1342177280 .
>
> Currenty i have limited the max_connections to 800, because every larger
> value results in
> a system load to 60+ and at least 20.000 context switches.
>
> My problem is, that our apache produces much more than 800 open connections,
>
> because we are using > 15 diff. databases and apache seems to keep
> connections to every
> database open , the same httpd-process has connected before.
> For now i solved it in a very dirty way, i limited the number and the
> lifetime
> of each httpd process with those values :
> MaxKeepAliveReq uests 10
> KeepAliveTimeou t 2
> MaxClients 100
> MaxRequestsPerC hild 300
>
> We use php 4.3.4 and PHP 4.2.3 on the webservers. PHP ini says:
> [PostgresSQL]
> ; Allow or prevent persistent links.
> pgsql.allow_per sistent = On
> ; Maximum number of persistent links. -1 means no limit.
> pgsql.max_persi stent = -1
> ; Maximum number of links (persistent+non persistent). -1 means no limit.
> pgsql.max_links = -1
>
> We are now running for days with an extremly unstable database backend...
> Are 1.000 processes the natural limit on a linux based postgresql ?
> Can we realize a more efficient connection pooling/reusing ?
>
> thanks a lot for help and every idea is welcome,
> Andre
>
> BTW: Does anyone know commercial administration trainings in Germany, near
> Duesseldorf?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org[/color]


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[scott.marlowe]

Re: PHP + Postgres: More than 1000 postmasters produce


Have you tested it with regular pg_connects instead of pg_pconnect? while
many people expect pconnects to be faster, often, when they result in the
database having lots of open idle connections, they actually make the
system slower than just using plain connects.

You might want to look into some of the connection pooling options out
there that work with PHP, as persistant connections work well only for a
smaller number of hard working threads, and not so well for a large number
of connections of which only a few are actually hitting the db at the
same time. The becomes especially bad in your situation, where it sounds
like you have multiple databases to connect to, so php is keeping multiple
backends alive for each front end thread.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[scott.marlowe]

Re: PHP + Postgres: More than 1000 postmasters produce

On 20 Feb 2004, Csaba Nagy wrote:
[color=blue]
> Well, it seems for your application is better to limit php's persistent
> connection pool as a quick measure.
> Try to set these values to something sensible for you:
>
> ; Maximum number of persistent links. -1 means no limit.
> pgsql.max_persi stent = 20[/color]

Please note that pgsql.max_persi stant is PER apache / php backend process.

http://www.php.net/manual/en/ref.pgsql.php

QUOTE:
pgsql.max_persi stent integer

The maximum number of persistent Postgres connections per process.
UNQUOTE:
[color=blue]
> ; Maximum number of links (persistent+non persistent). -1 means no limit.
> pgsql.max_links = 30[/color]

This one too is per process
[color=blue]
> Or just disable persistent connections altogether, and see if that is
> not resulting in better performance:[/color]

My recommendation.



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org