хотел написать success story но не получилось:(
пришлось писать багрепорт
1) помницца такая (подобная ?) ошибка была в 0.13
сейчас время от времени проявляется в 0.15 - по крайней мере для
одного хоста:
005/01/25 08:04:33 [alert] 27134#0: *95250 zero size buf in sendfile while
sending to client, client: 195.210.128.54, URL: /pop/download.php?id=430,
upstream: fastcgi://127.0.0.1:9001/pop/download.php?id=430
либо, если без fcgi то:
2005/01/22 13:15:55 [alert] 17908#0: *213689 zero size buf in sendfile, client:
195.210.128.54, URL: "/pop/download.php?id=426"
оно бы всё и ничего, но когда проявляется, то записывается в лог со
скоростью порядка 1 Gb / минуту до того момента пока не заканчивается
место на диске. Лечится перезапуском nginx - ну или отключением
вывода error_log :)
Для того, чтобы процесс с "zero size buf" не ел процессор и не писал
в лог, нужно в основном разделе конфига поставить
debug_points abort;
В этом случае такой процесс сразу же выйдет по сигналу SIGABORT.
Возможно с коркой.
"zero size buf" - это ужасная для меня проблема. У меня её долго не было,
но на днях один процесс упал с такой коркой. В общем, на днях я серьёзно
займусь этой ошибкой.
2) время от времени один (иногда больше) из дочерних процессов nginx
начинает активно отжирать процессор - от 20 до 50 процентов, и
подвисает в таком состоянии до перезапуска nginx
пример вывода ps
PID PPID USER %CPU VSZ WCHAN COMMAND
13149 1 root 0.0 2180 rt_sig nginx: master process
/usr/local/sbin/nginx
25112 13149 www-data 23.0 5760 - nginx: worker process
30908 13149 www-data 0.7 7780 - nginx: worker process
31205 13149 www-data 0.5 5884 - nginx: worker process
31571 13149 www-data 0.1 2948 - nginx: worker process
31576 13149 www-data 0.6 6240 - nginx: worker process
31604 13149 www-data 0.1 3548 - nginx: worker process
31757 13149 www-data 0.7 5160 - nginx: worker process
31772 13149 www-data 0.1 3320 - nginx: worker process
31799 13149 www-data 0.4 4268 - nginx: worker process
31966 13149 www-data 0.5 3844 - nginx: worker process
кстати - если в нормальном состоянии послать мастр процессу -HUP, то
большая часть воркеров умирает очень долго - больше часа, дольше не
ждал, при этом опять же начинает отжирать процессорное время - судя по выводу
top
больше (20-30 %), по ps - меньше, порядка 10 %
лечится опять же перезапуском.
Если процесс начинает есть процессор, то нужно или посмотреть, что
он делает с помощью truss, strace, а ещё хорошо бы с gdb.
Воркеры могут умирать долго, если они передают большие файлы. Если же нет,
то имеет место бага.
3) не уверен что это проблема nginx, может быть пхп, но время от времени nginx
перестает общацца с remotу fcgi - пишет
Gateway time out, хотя процессы пхп живут и слушают сокет. можно ли как либо
включить отладочную информацию именно для этой ситуации ?
Именно для этой - нет. Но можно задать другой лог уровень debug только
для определённого location:
error_log error.log error;
http {
...
location / {
fastcgi_pass localhost:8000;
error_log error1.log debug;
}
Кстати, а fastcgi что использует - tcp или unix sockets ?
Игорь Сысоев
