Re: connect -1 errno 36, sendfile -1 errno 35, LA и затыки сервера
cronfy
cronfy на gmail.com
Пн Сен 6 19:46:02 MSD 2010
>> >> В штатном режиме работы между stat и возвратом даже тысячной секунды
>> >> не проходит, а тут сотые. Странно, что gstat при этом весь зеленый -
>> >> нагрузку на диск показывает обычную или даже ниже. А бывает даже так:
>> >> 26333 nginx 14.761612 CALL gettimeofday(0x7fffffffe390,0)
>> >> 26333 nginx 14.818053 RET gettimeofday 0
>> >> Хотелось бы понять, что это может быть, связано ли с nginx и куда
>> >> можно покопать. что еще для диагностики запустить?
>> > Что показывает "top -S" ?
>>
>> Вот top -PS в момент затыка (всего 4 воркера nginx, все в топе):
>>
>> last pid: 79281; load averages: 98.37, 46.06, 20.99
>>
>> up 1+14:20:14 16:46:47
>> 1102 processes:116 running, 959 sleeping, 6 zombie, 20 waiting, 1 lock
>> CPU 0: 8.6 user, 0.0 nice, 91.4 system, 0.0 interrupt, 0.0 idle
>> CPU 1: 11.2 user, 0.0 nice, 88.8 system, 0.0 interrupt, 0.0 idle
>> CPU 2: 12.3 user, 0.0 nice, 87.7 system, 0.0 interrupt, 0.0 idle
>> CPU 3: 7.5 user, 0.0 nice, 92.2 system, 0.0 interrupt, 0.4 idle
>> CPU 4: 10.8 user, 0.0 nice, 89.2 system, 0.0 interrupt, 0.0 idle
>> CPU 5: 8.2 user, 0.0 nice, 91.4 system, 0.0 interrupt, 0.4 idle
>> CPU 6: 8.2 user, 0.0 nice, 91.8 system, 0.0 interrupt, 0.0 idle
>> CPU 7: 7.5 user, 0.0 nice, 92.5 system, 0.0 interrupt, 0.0 idle
>> CPU 8: 15.7 user, 0.0 nice, 82.5 system, 1.9 interrupt, 0.0 idle
>> CPU 9: 17.5 user, 0.0 nice, 82.5 system, 0.0 interrupt, 0.0 idle
>> CPU 10: 14.1% user, 0.4% nice, 85.5% system, 0.0% interrupt, 0.0% idle
>> CPU 11: 18.3% user, 0.0% nice, 81.7% system, 0.0% interrupt, 0.0% idle
>> CPU 12: 11.2% user, 0.4% nice, 88.4% system, 0.0% interrupt, 0.0% idle
>> CPU 13: 17.9% user, 0.0% nice, 82.1% system, 0.0% interrupt, 0.0% idle
>> CPU 14: 14.9% user, 0.0% nice, 84.7% system, 0.0% interrupt, 0.4% idle
>> CPU 15: 10.1% user, 0.0% nice, 89.6% system, 0.0% interrupt, 0.4% idle
>> Mem: 3381M Active, 11G Inact, 2846M Wired, 369M Cache, 1851M Buf, 246M Free
>> Swap: 14G Total, 1376K Used, 14G Free
>>
>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>> 1138 mysql 147 4 0 1513M 1271M sbwait f 5:53 31.93% mysqld
>> 74973 ********** 1 -4 0 159M 69324K RUN 4 0:12 14.89% httpd
>> 76346 www 1 -4 0 54276K 36940K RUN a 0:13 14.70% nginx
>> 77028 ******* 1 -4 0 140M 52796K CPU11 f 0:09 14.36% httpd
>> 76348 www 1 99 0 54276K 36932K RUN 7 0:12 13.87% nginx
>> 76349 www 1 98 0 54276K 36940K RUN f 0:12 13.87% nginx
>> 76347 www 1 -4 0 54276K 36868K ufs e 0:12 13.48% nginx
>> 78733 ********** 1 98 0 136M 49648K RUN 6 0:03 10.89% httpd
>> 77954 ********* 1 -4 0 147M 58316K ufs 1 0:04 10.60% httpd
>> 78145 ********* 1 -4 0 146M 57656K RUN 7 0:04 9.77% httpd
>> 78430 ******* 1 98 0 134M 47484K RUN c 0:03 9.67% httpd
>> 78768 ********** 1 -4 0 131M 45084K RUN 5 0:02 9.57% httpd
>> 78851 diradmin 1 98 0 87648K 20072K RUN e 0:02 9.47% php
>> 78552 diradmin 1 -4 0 90720K 21788K RUN 1 0:02 9.28% php
>> 78850 diradmin 1 -4 0 87648K 19468K RUN f 0:02 8.50% php
>> 78619 ********* 1 97 0 135M 49088K RUN b 0:02 8.06% httpd
>> 78971 diradmin 1 -4 0 85600K 18292K RUN e 0:01 7.96% php
>> 78254 ****** 1 -4 0 149M 59796K RUN 6 0:03 7.86% httpd
>> 95798 ***** 1 54 0 120M 41320K CPU0 0 2:59 7.47% prefork
>> 2010 ********* 1 51 0 115M 34644K select 6 6:47 7.37% prefork
>> 78769 ********* 1 -4 0 133M 47036K RUN b 0:02 7.37% httpd
>> 78897 ******* 1 -4 0 132M 44824K CPU6 6 0:01 7.18% httpd
>> 79140 ****** 1 97 0 133M 46932K RUN f 0:01 7.08% httpd
>> 78731 ********** 1 -4 0 134M 47640K RUN 4 0:02 6.79% httpd
>> 78617 ******* 1 -4 0 142M 53644K RUN 8 0:02 6.69% httpd
>> 78866 ******* 1 97 0 130M 44432K RUN 1 0:01 6.49% httpd
>> 78849 ****** 1 -4 0 136M 49308K CPU1 1 0:01 6.40% httpd
>> 3487 ***** 1 55 0 120M 42348K select b 2:47 6.15% prefork
>> 79051 ********** 1 97 0 132M 46244K RUN c 0:01 6.15% httpd
>> 79089 ********** 1 -4 0 127M 41788K RUN 8 0:01 6.15% httpd
> Похоже на lock contention где-то в ядре на 16 процессорах.
> Судя по тому, что замедляются stat(), возможно, что-то связанное
> с файловой системой (я как-то читал, что там есть проблемы с
А замедление gettimeofday() тоже на это показывает?
> масштабируемостью на много процессоров). Можно попробовать
>
> http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#open_file_cache
Спасибо, сделал так:
open_file_cache max=10000 inactive=120s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
Смотрим пока. errors поставил в off, потому что наличие файлов все
равно проверяется перловыми скриптом, nginx отдает только то, что
реально существует.
Заполнение кеша можно как-то отследить?
--
// cronfy
Подробная информация о списке рассылки nginx-ru