Apr_socket_connect(): Operation not permitted (1)?

Question

[AntonioK]

Делаю бенчмарк сервера, раздающего статику (работает на lighttpd/1.4.30). Бенчмаркаю с соседнего сервера с помощью ab (Apache HTTP server benchmarking tool). Выглядит это примерно так:

# ab -n10000 -c50 -t60 -r <a href="http://domain.tld/image.gif">domain.tld/image.gif</a><br/>
This is ApacheBench, Version 2.3 &lt;$Revision: 655654 $&gt;<br/>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, <a href="http://www.zeustech.net/">www.zeustech.net/</a><br/>
Licensed to The Apache Software Foundation, <a href="http://www.apache.org/">www.apache.org/</a><br/>
<br/>
Benchmarking domain.tld (be patient)<br/>
Completed 5000 requests<br/>
<br/>
Test aborted after 10 failures<br/>
<br/>
apr_socket_connect(): Operation not permitted (1)<br/>
Total of 7943 requests completed

Ситуация стабильно воспроизводится, число Total of N requests completed плавает вокруг цифры 7500.


Что такое apr_socket_connect(): Operation not permitted (1)? Хотя бы на чьей стороне ошибка — не проверямом хосте, или на проверяющем? Гугл что-то не радует меня большой толпой братьев по несчастью.

Comments

[AntonioK]

«Проверяемый» хост — # uname -a
FreeBSD domain.tld 8.3-RELEASE FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 [e-mail]:/usr/obj/usr/src/sys/GENERIC amd64

«Проверяющий» хост — FreeBSD 8.0-RELEASE-p6 amd64

[AntonioK]

Идентично на «проверяющем» и «проверяемом» серверах:

# ulimit -a
socket buffer size (bytes, -b) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) 33554432
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 200000
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 524288
cpu time (seconds, -t) unlimited
max user processes (-u) 65535
virtual memory (kbytes, -v) unlimited
swap size (kbytes, -w) unlimited

[AntonioK]

Когда ab отваливается, не успев выполнить все запросы, на «проверяемом» сервере сразу смотрю количество открытых tcp-соединений:

# netstat -an | grep tcp4 | grep -v LISTEN | wc -l
5201

Значит, tcp-коннекты не закрываются после успешной отработки HTTP-запроса. Возможно, виноват keep-alive, по умолчанию включенный в lighttpd. Лезу в настройки — там по умолчанию server.max-keep-alive-idle = 5, то есть сервер держит коннект открытым 5 секунд в ожидании keep-alive запроса. Уменьшаю значение до 1, бенчмаркаю снова с теми же ключами (для верности ребутнув предварительно подопытный сервер). Не помогло, та же картина. Отключаю вообще поддержку keep-alive: server.max-keep-alive-requests = 0. Тот же результат!

Раз сходу не получилось, пробуем разобраться. Что это за 5200 повиснувших коннектов? Смотрю netstat -an | grep tcp4 — видно, что коннекты в состоянии TIME_WAIT. Становится понятно, почему независимо от того, на каком значении Total of N requests completed отваливается ab на “проверяющем” хосте, на “проверяемом” видно около 5200 висящих коннектов — дело в sysctl net.inet.tcp.maxtcptw. Во FreeBSD он (она? оно?) по умолчанию равен 5120. Повышение значения этого параметра до 40960, как завещал г-н Сысоев, впрочем, никак не меняет ситуацию (ab продолжает отваливаться с такой же ошибкой) кроме того обстоятельства, что после отработки бенчмарка на “проверяемом” хосте остается примерно столько висящих TIME_WAIT коннектов (чуть больше), сколько успешных HTTP-запросов успел провернуть бенчмарк (а не тупо 5120 с гаком, как ранее).

[AntonioK]

Уменьшение concurrency тоже не спасает:

# ab -n10000 -c25 -r domain.tld/image.gif
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Licensed to The Apache Software Foundation, www.apache.org/

Benchmarking domain.tld (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests

Test aborted after 10 failures

apr_socket_connect(): Operation not permitted (1)
Total of 8064 requests completed

-c10, -c2, -c250, или вообще без многопоточности — дают одинаковые результаты, ошибка на 6~8 тысяче запросов.

[tsabir]

httperf пробовали вместо ab?