Ошибки при использовании 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