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

CentOS & PostgreSQL help re: TIME_WAIT

From: "Reggie Euser" <reggie(at)busicast(dot)com>
To: <pgsql-admin(at)postgresql(dot)org>
Subject: CentOS & PostgreSQL help re: TIME_WAIT
Date: 2010-01-28 19:36:32
Message-ID: 00f601caa051$320ba6e0$8bcd1ea8@S0030153310 (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Zombie PostgreSQL processes in a "TIME_WAIT" state are consuming all
available sockets on a web server I'm running. I've Googled & RTFM'ed but am
still stumped.  Sure would appreciate any ideas.

I've recently migrated a PHP-based web app running against PostgreSQL from a
single server running FreeBSD to a cluster consisting of:

-  two virtual machines, both running CentOS 5.4, Linux version
2.6.18-14.10.1.el5 both with 3 Gb RAM allocated, both with two dual-core
Intel processors allocated.

-  the web server is running Apache 2.2.14 & PHP 5.31.

-  the database server is running PostgreSQL 8.4.1, with pg_hba.conf set up
to trust the webserver on port 5432.

-  both Apache & PostgreSQL are set to accept 225 max connections, otherwise
the conf's are pretty much default.

-  web server is running OpenSSL for secure login, but serving general html
pages without https.

-  tcp_keepalive_time in both is default 7200 seconds (which, as I read in
various posts, etc., shouldn't really matter anyway, but...)

Various posts suggest that this could be a PHP programming issues, but as
the problem just surfaced with the migration, I'm inclined to think it's
probably either a PostgreSQL configuration issue or something related to the

A cron job restarting Apache every hour is keeping the webserver alive, but
I'd sure like a better solution...

Any ideas would be greatly appreciated...



pgsql-admin by date

Next:From: Tom LaneDate: 2010-01-28 20:55:33
Subject: Re: CentOS & PostgreSQL help re: TIME_WAIT
Previous:From: Kevin GrittnerDate: 2010-01-28 16:56:27
Subject: Re: Restore database from tablespace

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