On Mon, Mar 5, 2012 at 7:33 AM, <php-list@xxxxxxxxxxxxxxxxx> wrote: >> > I have a MySQL server A, a server B with PHP 5.3.8 and a server C with >> > PHP 5.3.3. I'm connecting to the MySQL server on A via TCP from B and C >> > using an internal network. Server B and C use the same PHP application. >> > There are also same PHP scripts that get data from the database and then >> > calculate up to 30 minutes. I close all database connection before doing >> > the calculation to save connections (and ports) using: >> > $thread_id = mysqli_thread_id( $this->handle ); >> > mysqli_kill( $this->handle, $thread_id ); >> > mysqli_close( $this->handle ); >> > >> > During a review on our servers I discovered that server B has a lot of >> > network connection in the state "CLOSE_WAIT". Server C running the same >> > PHP application has not. I see the difference that server B is using >> > mysqlnd and server C not. >> > >> > serverB# netstat -an | grep 3306 >> > tcp 1 0 10.8.0.58:47455 10.8.0.1:3306 >> > CLOSE_WAIT >> > >> > serverA# cat firewall >> > Feb 17 16:21:49 www kernel: [6587053.325075] SFW2-OUT-ERROR IN= OUT=tun0 >> > SRC=10.8.0.1 DST=10.8.0.58 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF >> > PROTO=TCP SPT=3306 DPT=47455 WINDOW=0 RES=0x00 RST URGP=0 >> > >> > Does anybody have an idea why this happens? How can I avoid this or >> > investigate in this? Is this a know issue? >> >> Is the underlying OS for servers B & C exactly the same? Down to >> kernel version (if Linux/Unix), NICs and driver version, >> configurations, etc.? It would help if specify OS type and kernel >> version. > > No, client B and C have different OS versions. You are right this can be a > reason too. Do you have any hints how I can trace that down? > > Details client B (newer OS with CLOSE_WAIT problems): > $ uname -a > Linux www3 3.1.9-1.4-default #1 SMP Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) > x86_64 x86_64 x86_64 GNU/Linux > $ mysql --version > mysql Ver 14.14 Distrib 5.5.16, for Linux (x86_64) using readline 6.2 > $ ethtool -i eth0 > driver: r8169 > version: 2.3LK-NAPI > firmware-version: rtl_nic/rtl8168e-2.fw > bus-info: 0000:04:00.0 > supports-statistics: yes > supports-test: no > supports-eeprom-access: no > supports-register-dump: yes > > Details client C: > $ uname -a > Linux www13 2.6.34.10-0.4-default #1 SMP 2011-10-19 22:16:41 +0200 x86_64 > x86_64 x86_64 GNU/Linux > $ mysql --version > mysql Ver 14.14 Distrib 5.1.57, for suse-linux-gnu (x86_64) using readline > 6.1 > $ ethtool -i eth0 > driver: r8169 > version: 2.3LK-NAPI > firmware-version: > bus-info: 0000:04:00.0 > > Server A: > Linux www 3.1.9-1.4-default #1 SMP Fri Jan 27 08:55:10 UTC 2012 (efb5ff4) > x86_64 x86_64 x86_64 GNU/Linux > $ mysql --version > mysql Ver 14.14 Distrib 5.5.16, for Linux (x86_64) using readline 6.2 > $ ethtool -i eth0 > driver: r8169 > version: 2.3LK-NAPI > firmware-version: rtl_nic/rtl8168e-2.fw > bus-info: 0000:04:00.0 > supports-statistics: yes > supports-test: no > supports-eeprom-access: no > supports-register-dump: yes > > I also have set wait_timeout 45 in my.cnf on server A and mysqli.reconnect On > on client B and C in php.ini. Troubleshooting that much variances will take a lot of time. Do you have root access? Was the OS installed via standard distribution? Did someone reconfigured and recompiled the kernel and system? I'd suggest you start compiling from source of the following: * MySQL client - same version (preferred) or newer than server (make sure config is the same on both boxes for PHP) * compile PHP thereafter Then you'll know if it's the OS related or not (ie: configuration, kernel version, etc.) Also, your kernel versions doesn't seem to be stable per [1]. You might want to check each flavor's distributor. Just out of curiosity, are both boxes (B & C) are the same Linux flavor? Best regards, Tommy [1]http://www.kernel.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
