Re: Рост количества подключений в состоянии writing

kpoxa kpoxa на kpoxa.net
Пн Июл 31 11:43:46 UTC 2017


Есть одно подозрение, не знаю, может ли об этого зависеть, но статистика
получилась такая -  проблема началась синхронного на 3 полностью
независимых серверах примерно за 18 дней до окончания истечения ssl
сертификата, и решилась синхронно с его продлением.

25 июля 2017 г., 15:38 пользователь kpoxa <kpoxa at kpoxa.net> написал:

> буферизация включена.
> приложение - отдача статики с ссд, причем вся отдаваемая статика это 1гб,
> а на сервере 16гб, так что она всегда в кеше дисковом.
> деградации каналов не было.
> На одном канале таких серверов 3 (раунд-робин днс распределяет нагрузку),
> повышение количества writing коннектов не синхронное, возникает
> спорадически. Если бы были пробелемы на канале, то проблемы были бы
> синхронные
>
> 24 июля 2017 г., 18:28 пользователь Илья Шипицин <chipitsine at gmail.com>
> написал:
>
>> буферизация включена? (по умолчанию - включена).
>> деградация каналов в сторону пользователей была? деградация приложения?
>>
>> 24 июля 2017 г., 19:41 пользователь kpoxa <kpoxa at kpoxa.net> написал:
>>
>>> Добрый день.
>>>
>>> Запросы в статусу writing спонтанно пришло и спонтанно ушли, пикаких
>>> пиковых нагрузок не было.
>>>
>>> [image: Встроенное изображение 1]
>>>
>>> 24 июля 2017 г., 14:51 пользователь kpoxa <kpoxa at kpoxa.net> написал:
>>>
>>>> Добрый день.
>>>>
>>>> Та же проблема:
>>>> Active connections: 9995
>>>> server accepts handled requests
>>>>  213171 213171 1185236
>>>> Reading: 0 Writing: 8835 Waiting: 8702
>>>>
>>>>
>>>> На сервере нагрузка не менялась, нагрузка на проц 2-3%, памяти свободно
>>>> 10гб из 16гб, диск не нагружен вообще. Сеть нагружена на 7-10%.
>>>> Абсолютно в непредсказуемые моменты бывает сильно вырастают "Writing"
>>>> коннекты и сервер начинает тупить.
>>>>
>>>> nginx version: nginx/1.13.3
>>>> debian jessy
>>>>
>>>>         listen 443 default_server backlog=32768 rcvbuf=4194304
>>>> sndbuf=16777216 reuseport ssl;# http2;
>>>> пробовал и с http2 и без, в обоих случаях writing большой.
>>>>
>>>>
>>>> 2 апреля 2017 г., 8:41 пользователь DK <kohaner at gmail.com> написал:
>>>>
>>>>> Добрый день,
>>>>>
>>>>> Касательно этой проблемы, в логах тишина
>>>>>
>>>>> есть только ошибки от роботов
>>>>>
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/PMA2012/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/PMA2012/ HTTP/1.1", host: "x.x.x.x"
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/pma2012/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/pma2012/ HTTP/1.1", host: "x.x.x.x"
>>>>> 2017/04/02 07:50:37 [error] 8434#8434: *76017536
>>>>> "/etc/nginx/html/PMA2011/index.html" is not found (2: No such file or
>>>>> directory), client: 131.103.139.131, server: , request: "HEAD
>>>>> http://x.x.x.x:80/PMA2011/ HTTP/1.1", host: "x.x.x.x"
>>>>>
>>>>>
>>>>> и иногда возникают ошибки, что нет возможности переименовать файл
>>>>> (использую proxy_store)
>>>>>
>>>>> 2017/04/02 11:24:27 [crit] 8433#8433: *76159901 rename()
>>>>> "/var/www/virtual/xxxxx.ru/temp/0000330774" to "/var/www/virtual/
>>>>> xxxxx.ru/images/250s/lh3.googleusercontent
>>>>> .com/vy9kyUGvT6j3KlUNO1IsJbaFEYrvDGf7pWIe_VLHGci8IQ1vYgtXrU3
>>>>> X2HvGhzZMzmjYL0615aPpnqqA4NTKTKiag_hGmK0yO4Em0NHwQqRikcM07uh
>>>>> 89KASsLLq9W2XFoOHyg9KsZYbjsAPmzSMUoem2VuI02bWwUF71sJn3v2uBnj
>>>>> -aRu843Fxh0E7iokVNXyoiEesIQfIlAGeN8Fe6nRtY5GFcpyjV1brXuTvW-7lpEd"
>>>>> failed (36: File name too long) while reading upstream, client:
>>>>> x.x.203.204, server: xxxxxxx,
>>>>>
>>>>>
>>>>> но обе эти ошибки были и на предыдущей версии nginx (точно не помню,
>>>>> но была версия в районе 0.9.8 ).
>>>>>
>>>>> Проблемная инсталяция работает как кеширующий сервер для раздачи
>>>>> статики. При обращении к нему он смотрит есть такой файл или нет, если
>>>>> файла нет то забирает файл с главного сервера и сохраняет его себе
>>>>> (proxy_store).
>>>>>
>>>>> У инсталяции (на другом сервере) которая работает как обычный
>>>>> фронт-энд перед апачем, такой проблемы нет. Версия ОС, настройки ОС и
>>>>> версии nginx везде одинаковые.
>>>>>
>>>>>
>>>>> PS: По глупости подписался в режиме дайджеста (уже изменил), поэтому
>>>>> не могу ответить на индивидуальные письма, поэтому отвечаю сам себе
>>>>>
>>>>>
>>>>>
>>>>> 1 апреля 2017 г., 11:36 пользователь DK <kohaner at gmail.com> написал:
>>>>>
>>>>>> Добрый день,
>>>>>>
>>>>>> В начале марта обновил nginx до версии nginx-1.11.10-1.el7.ngx.x86_64
>>>>>> и заметил, что постепенно растет количество подключений в состоянии writing
>>>>>>
>>>>>> http://take.ms/p541u
>>>>>>
>>>>>> Куда смотреть, чтобы найти причину такого роста?
>>>>>>
>>>>>> PS: Падение количества подключения - это последствия добавление
>>>>>> второго сервера в качестве фронтенда и балансировки трафика через DNS.
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nginx-ru mailing list
>>>>> nginx-ru at nginx.org
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170731/83659ab6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 36448 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170731/83659ab6/attachment-0001.png>


Подробная информация о списке рассылки nginx-ru