ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[3]: странности в рабо те nginx



On Mon, 25 Apr 2005, Igor Sysoev wrote:

On Mon, 25 Apr 2005, Alexey Bestciokov wrote:

да, именно
waitin on disk io действительно большое, по моему не запредельное .
траффик ~ 80 мб, диски - scsi U320 10 000 RMP
на дисковую подсистему не похоже - на сервере где узким место является
гарантированно именно дисковая подсистема, картина другая.
опять же получаемая картина нелинейна - количество коннектов растёт
скачкообразно.
изначально воркеров было 2 - это в процессе экспериментов увеличилось
до 5-8, так при таком количестве nginx визуально адекватнее отвечал.

странно что появляется задержка при ответе на stub_status -
операции не требующщей чтения с дисков. и почему в выводе стрэйса
задержки ... и то что колиство соединений которое показывает nginx
почти в 2 раза больше чем показывает netstat.

Задержки в обработке запросов, не требующих чтения с диска (например,
stub_status, или файлов, закэшированных ОС) вызвани тем, что процесс,
который accept()нул это соединение, заблокировался после этого на диске,
ещё не получив сам запрос. Хотя, конечно, задержки в секунды - это странно.

Что касается задержек в strace, то они выглядят так:

22:45:32.367043 sendfile64(392, 455, [3182012], 568753) = 13600
22:45:32.367529 sendfile64(282, 205, [5488972], 1611236) = 8760
22:45:32.582824 sendfile64(350, 354, [3224057], 3546631) = 38880
22:45:32.583044 sendfile64(619, 793, [4190198], 1193994) = 8760
22:45:32.583256 sendfile64(253, 525, [2919242], 4549815) = 11680
22:45:32.583370 sendfile64(307, 238, [703136], 2578389) = 17160
22:45:32.583513 sendfile64(365, 383, [196848], 5404432) = 14600
22:45:42.709597 sendfile64(361, 349, [2512803], 2243111) = 10080
22:45:42.710094 sendfile64(613, 625, [3308486], 2620116) = -1 ECONNRESET (Connec

и

22:42:39.632084 sendfile64(305, 326, [4594510], 481317) = 5808
22:42:39.632225 sendfile64(518, 528, [28960], 5428210) = 18824
22:42:39.632423 sendfile64(216, 257, [5715401], 83407) = 11680
22:42:39.632507 sendfile64(408, 432, [4648784], 2323992) = 87352
22:42:58.510398 sendfile64(632, 622, [1030272], 3743616) = 14600
22:42:58.510777 sendfile64(346, 355, [3379459], 1079201) = 30240
22:42:58.511066 sendfile64(506, 507, [3083304], 4862902) = 39420

В обоих случаях nginx не делал системных вызовов в течение 10 и 19 секунд,
несмотря на то, что ему нужно было их делать (то есть, он не просто ждал
новых событий из ядра). Этому факту есть два объяснения:

1) nginx что-то делал внутри себя в течение этих 10 и 19 секунд, что
  непременно должно отразится на использовании процессора.
2) Линукс почему-то не давал возможности выполняться этим ready to run
  процессам в течение 10 и 19 секунд.

Я склоняюсь ко второму варианту, поскольку в обоих случаях задержки
произошли после системного вызова, работающего с файловой системой.


Игорь Сысоев
http://sysoev.ru




 




Copyright © Lexa Software, 1996-2009.