Ошибки при использовании fastcgi
Igor Sysoev
is at rambler-co.ru
Tue Jan 25 19:37:53 MSK 2005
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'и будут разделаться между процессами.
Кстати, а по каким тестам ? И насколько медленее ?
Игорь Сысоев
http://sysoev.ru
More information about the nginx-ru
mailing list