Соединения не закрываются с рабочим MPM Apache и mod_php

Во-первых, я знаю, что это сомнительная установка, но производительность fastcgi или fcgid заставила меня попробовать. Проблема в том, что мое нагрузочное тестирование никогда не завершается из-за того, что соединения не закрываются. Когда я нажимаю только на 40 одновременных подключений, все идет наперекосяк — соединения находятся в установленном состоянии в течение нескольких минут:

netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
      1 CLOSE_WAIT
     72 ESTABLISHED
      8 LISTEN

Затем через несколько минут они разделились на смесь CLOSE_WAIT и ESTABLISHED:

netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
     41 CLOSE_WAIT
     32 ESTABLISHED
      8 LISTEN

И спустя еще 10 минут это не изменилось. Это комбинация клиента для веб-сервера и веб-сервера для сервера mysql. Если я тестирую php-страницу, которая не устанавливает соединение с mysql, все работает нормально.

Я самостоятельно скомпилировал PHP (настройте ниже) и установил apache-mpm-worker через apt-get (Ubuntu 10.04). Я пытался скомпилировать PHP как с msyql_config, так и с mysqlnd для модулей mysql, mysqli и pdo. Может ли это быть просто непоточно-безопасной библиотекой, поднимающей свою уродливую голову?

./configure --prefix=/usr/local --with-apxs2=/usr/bin/apxs2 --disable-cgi --with-layout=GNU --with-config-file-path=/etc/php5/apache2 --with-config-file-scan-dir=/etc/php5/apache2/conf.d --disable-ipv6 --without-kerberos --with-pcre-regex=/usr --with-zlib --with-zlib-dir=/usr --enable-bcmath --with-bz2 --enable-calendar --enable-ctype --with-curl=shared,/usr --without-qdbm --without-gdbm --with-db4 --with-libxml-dir=/usr --enable-exif --disable-ftp --with-gd=shared,/usr --enable-gd-native-ttf --with-gmp=shared,/usr --with-jpeg-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-gettext --with-mhash=shared,/usr --with-ldap=shared,/usr --with-ldap-sasl=/usr --with-mcrypt=shared,/usr --enable-mbstring --without-msql --without-mssql --with-pspell=shared,/usr --without-mm --disable-shmop --enable-soap --enable-sockets --with-regex=php --disable-sysvshm --disable-wddx --with-xmlrpc=shared --with-iconv --with-xsl=shared,/usr --enable-zip --with-pear=/usr/share/php --with-tsrm-pthreads --enable-maintainer-zts --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=myslqnd --with-libdir=lib64


php apache worker
person David Urig    schedule 05.06.2012    source источник
comment
Можете ли вы добавить вывод из файла httpd.conf, в частности, конфигурацию MPM?   -  person Mike Mackintosh    schedule 05.06.2012
comment
На данный момент это значение по умолчанию: ‹IfModule mpm_worker_module› StartServers 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadLimit 64 ThreadsPerChild 25 MaxClients 150 MaxRequestsPerChild 0 ‹/IfModule›   -  person David Urig    schedule 05.06.2012

Ответы (1)


arrow_upward
0
arrow_downward

Одно решение, которое сработало для меня, состояло в том, чтобы добавить следующий флаг в настройку apache (я не использую репо):

export CFLAGS=-DNO_LINGCLOSE
./configure ...

Затем это заставило apache закрыть сокет, когда от узла был получен пакет FIN.

По умолчанию Apache помещает сокет в close_wait после того, как партнер отправит FIN. В это время сокет считается наполовину закрытым в ожидании FIN от локального партнера, что обычно делается путем завершения приложения. Apache по умолчанию разрешает это время ожидания, обычно 2-5 минут в зависимости от настройки.

person Mike Mackintosh    schedule 05.06.2012
comment
Это самое странное — вот я почти 30 минут спустя, а подключения не изменились (и не изменятся, пока я не перезапущу Apache, который также не принимает новые подключения): netstat -an|awk '/tcp/ {print $6 }'|sort|uniq -c 41 CLOSE_WAIT 38 ESTABLISHED 8 LISTEN - person David Urig; 05.06.2012
comment
Извините, хотел добавить, что CLOSE_WAIT - это порт 80 от клиента, ESTABLISHED - это соединения с сервером mysql. Таким образом, он не закрывает соединение с БД, как должно. - person David Urig; 05.06.2012
comment
Вы используете IPTables или какую-то службу безопасности брандмауэра? - person Mike Mackintosh; 15.06.2012
comment
Это не значит, что мы больше не сталкиваемся с проблемой, но нам пришлось перейти к другой конфигурации. Я все еще хотел бы вернуться к этому и попробовать еще раз. - person David Urig; 18.06.2012