Package: mysql-server-4.1 Version: 4.1.11a-4 Severity: important I am connecting to the server with Apache + PHP, using "persistent connections". Using this feature, PHP does not disconnect from the server after every request served, but keeps the connections for future requests. When not used, these connections are in a "sleep" state, as can be seen with "mysqladmin processlist".
Usually, the mysql server will kill such processes if their idle time (the "Time" value in the processlist) exceeds the value of wait_timeout. On my machine, wait_timeout is set to 15 seconds, as can be confirmed with "mysqladmin variables". As expected, connections disappear from the processlist after this time. Now from time to time, mysqld stops shutting down these idle processes. They keep hanging around in the processlist, and after a short period of time, the available max_connections are used up. Clients trying to connect will get a "too many connections" error message. At that point, the processlist will show connections with "Time" values of up to several hundred seconds. [Probably that would further increase if I would not have to restart mysqld.] Maybe there's a problem with the way PHP handles/reuses the connections, but that is not the point here - mysqld should shut down these connections no matter how the "client" plans to re-use them. The problem occurs only under load, currently the server is handling about 40 queries / sec. If everything works well, there are not more than a dozen (or two) persistent connections at the same time, with a wait_timeout as above. After restarting the server, it may take from minutes to about one or two hours for the problem to occur again. I cannot make out anything special that triggers this. I investigated the mysql query log but found nothing special. Even when the problem occurs, new connections and queries are served correctly until the max_connections count has been reached. I just moved my databases from a woody system to this machine, running sarge (upgraded from woody, if that matters). The problem occured right from the start, not related to some speficic upgrade or the like. The machine is a dual XEON with hyperthreading enabled. (Actually, this is my first Debian bug report. Sorry if anything important is missing.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11.8 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mysql-server-4.1 depends on: ii adduser 3.63 Add and remove users and groups ii debconf 1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdbi-perl 1.46-6 Perl5 database interface by Tim Bu ii libgcc1 1:3.4.3-13 GCC support library ii libmysqlclient14 4.1.11a-4 mysql database client library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libreadline4 4.3-11 GNU readline and history libraries ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3 ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii mailx 1:8.1.2-0.20040524cvs-4 A simple mail user agent ii mysql-client-4.1 4.1.11a-4 mysql database client binaries ii mysql-common-4.1 4.1.11a-4 mysql database common files (e.g. ii passwd 1:4.0.3-31sarge5 change and administer password and ii perl 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.5-1 Utilities that use the proc filesy ii zlib1g 1:1.2.2-4.sarge.1 compression library - runtime -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
