On Tue, 25 Jan 2005, Andrew Velikoredchanin wrote:
В Линуксе 107 означает ENOTCONN, текст при этом такой:
"Transport endpoint is not connected". Для того, чтобы узнать
почему не выводиться текст, предлагается собрать и запустить вот
такую программку:
-----------
#include <string.h>
int main()
{
char s[1024], *e;
s[0] = '\0';
e = strerror_r(107, s, 1024);
printf("s: \"%s\"\n", s);
printf("e: \"%s\"\n", e);
} -----------
Выдает:
s: ""
e: "Transport endpoint is not connected"
Нда. Тут всё верно. А другие ошибки в логе выводяться с текстом ?
Что касается собственно ошибки, то, судя по всему, это происходит, когда
переполняется listen очередь у сокета. FreeBSD в таких случаях для
connect() возвращает ECONNREFUSED, а Линукс - EINPROGRESS, а затем
возвращает в epoll готовность на запись EPOLLOUT и ошибку EPOLLHUP.
Последущий writev() уже возвращает ENOTCONN.
Лечить можно так:
...
3) перейти на tcp, оно, возможно, более устойчиво.
По тестам tcp работает существенно медленнее.
Тогда пока - только два первых метода.
В планах есть busy lock'и, которые позволят ограничить число одновременных
запросов к апстриму (proxy/fastcgi). Остальные запросы будут ждать в busy
lock'е. В первой реализации busy lock'и будут работать только на уровне
одного процесса, то есть, если у нас 5 рабочих процесса nginx и поставить
ограничение 100, то число будет делаить на число процессов и каждый процесс
может делать не более 100/5=20 одновременных запросов. В последущей
реализации busy lock'и будут разделаться между процессами.
Кстати, а по каким тестам ? И насколько медленее ?
Игорь Сысоев
