ПРОЕКТЫ 


  АРХИВ 


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[2]: nginx есть проц



Там еще штуки три вдс. Слабоактивных.
wa == iowait? Он вырастает, когда много транзакций к диску. Примерно,
когда больше 80 в сек - начинает расти.

И да, если это важно - раз в 5-10 минут делается релоад с целью
переоткрытия конфигов, потому что там стоит самописная панелька,
которая изначально делалась под шаред хостинг.

vmstat 5 я показывал до отключения буферизации. Сейчас поменялось не
принципиально,
 vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- 
-----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0    528  91312  81792 773232    0    0     2    50    5    5 22  5 64  9  0
 7  3    528  67624  81872 774536    0    0     0   694 2330  751 38 10 34 18  0
 0  0    528  84108  82084 775396    0    0     0   361 2064  955 34 13 24 29  0
 4  0    528  83944  82144 775624    0    0     0     0 1974  606 36  6 56  2  0
 4  0    528  83640  82240 776508    0    0     0     0 2270  670 23  6 67  4  0
 7  0    528  77692  82296 777360    0    0     0     0 2372  992 44  8 46  3  0
 7  0    528  70216  82384 778632    0    0     0     0 2395  949 30  8 52 11  0
 1  0    528  68876  82492 779836    0    0     0     0 2291 1311 49  8 38  5  0
 0  0    528  63360  82588 781028    0    0     0     1 2134 1129 33  7 56  5  0
 0  3    528  62628  82652 781404    0    0     0   530 1714  520 32  5 40 23  0



Tuesday, November 13, 2007, 8:36:53 PM, you wrote:
>  Честно говоря странным является только значение столбца wa. Что за ввод 
> вывод неясно.
>  Но как мне кажется (могу быть не прав) то что выключение
> буфферизации увеличило нагрузку на процессор,
>  если при этом уменьшился wa, то проблема как раз в вводе выводе.
>  
>  Топу не доверяю ниразу, это что то типа средней температуры по палате.
>  Хорошо показывает только процессы в состоянии 100% загрузки.
>  Чтоб так сильно камень жрало - тож невижу, если допустить что у
> Вас 1025 открытых соединений по которым чего  то тянут, то имхо все неплохо.
>  
>  Для сравнения примерно тож самое от меня, но это не виртуал:
>  
>  [root@server4 logs]# netstat -a -n | grep .42:80 | grep ESTAB | wc -l
>  103
>  [root@server4 logs]# netstat -a -n | grep .42:443 | grep ESTAB | wc -l
>  1178
>  [root@server4 logs]# vmstat 5
>  procs -----------memory---------- ---swap-- -----io---- --system-- 
> ----cpu----
>   r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id 
> wa
>   0  0   1912 472232   4688 717328    0    0    11    74   18     4 14  3 82  
> 1
>   0  0   1912 471848   4696 717580    0    0     0   117 6613  5451 17  4 78  
> 1
>   1  0   1912 471336   4704 718092    0    0     0   114 6358  5248 16  5 79  > 0
>   0  0   1912 470888   4712 718604    0    0     0   190 6512  5392 16  4 80  
> 1
>   1  0   1912 470376   4720 719116    0    0     0    58 6484  5375 16  5 79  > 0
>  
>  Топ кажет впринципе хрень какйюто...
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  #C   TIME 
> WCHAN     COMMAND
>   1771 nobody    16   0  166m 138m 9620 R   28  6.8 219:45.36  0
> 219:45 -         nginx: worker process
>   1772 nobody    16   0  140m 124m 9600 S   14  6.1 213:50.06  0
> 213:50 -         nginx: worker process
>  .....
>  
>  Nick S. Knutov wrote: 
>   
> netstat -n -a | wc -l
> 1025

> Что именно там должно быть? С виду - ничего необычного
> vmstat 5 на вдс ничего не даст, но если брать его с ноды -

> procs -----------memory---------- ---swap-- -----io---- --system-- 
> -----cpu------
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa 
> st
>  2  0    528  95572  62552 852684    0    0     2    50    1    4 22  5 64  9 
>  0
>  0  1    528  91248  62660 856372    0    0     0     0 2817  907 20  7 66  7 
>  0
>  1  0    528  80776  62736 853480    0    0     0   100 2793  746 17  7 66 11 
>  0
>  0  0    528  94220  62832 852388    0    0     0     0 2848  661  8  5 77 10 
>  0
>  0  0    528  84564  63132 859444    0    0     0     0 2588  848  8  6 75 11 
>  0
>  0  0    528  83504  63316 860796    0    0     0     0 2259  609  3  4 74 20 
>  0
>  0  2    528  81848  63364 860876    0    0     0  1427 1620  388  2  1 22 74 
>  0
>  0  1    528  84820  63512 861272    0    0     0   368 2086  659  8  8 33 51 
>  0
>  0  0    528  85280  63892 860920    0    0     0     0 2751  824 12  5 62 21 
>  0

> proxy_buffering off;
> вроде подняло загрузку проца, если смотреть в top.



> Tuesday, November 13, 2007, 7:42:56 PM, you wrote: 
>   
>   
> А можно еще
> netstat -n -a
> vmstat 5 
>   
>   
>  
>   
>   
> как совет:
> попробовать
>         proxy_buffering off;
> если файлы большие, то ngnix ,будет перекладывать контент в буфер в 
> памяти, когда закончится на диск, и только когда примет от бекенда все
> тогда начнет выплевывать. 
>   
>   
>  
>   
>   
> Nick S. Knutov wrote: 
>   
>   
>  
>   
>   
>   
> Приветствую, 
>   
>   
>   
>  
>   
>   
>   
> Есть вдс, ей дано очень много ресурсов. nginx ест проц. 
>
>   
> OpenVZ, 2.6.18-8.1.8.el5.028stab039.1, failcnt нету, памяти, проца - 
> достаточно. 
>   
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 31986 nobody    17   0  4904 3472  692 R   40  0.2   4:50.57 nginx
> 13398 nobody    17   0  4840 3400  692 R   39  0.2   1:19.98 nginx 
>
> Было на 0.5.31, не исчезло после обновления до 0.5.33. 
>   
>
> Вероятнее всего в это время nginx отдает проксированные ответы апача, 
> который получает их от пхп скрипта. Пхп скрипт, вероятнее всего, 
> отдает 3х мегабайтные файлы с диска. Про интернал редиректы я в курсе,
> но скрипты не мои и править нельзя. Да и nginx независимо от, по моему
> мнению, не должен есть столько проца, скорее его должны бы есть те 
> скрипты, но с нагрузкой в два потока, по идее, не должны и они. 
>   


-- 
Best regards,
 Nick                            mailto:mail@xxxxxxxxxx




 




Copyright © Lexa Software, 1996-2009.