- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
День добрый,
Сразу скажу, сервер не мой, но аномалия непонятная, Debian.
На сервере стоит Nginx а так же php-cgi. Периодически возникает 502 ошибка, при том на случайных запросах, то CSS файлик не смогли получить, то favicon.ico... то другие запросы.
На машине 16 гиг памяти, при этом 2 еще вообще Free.
Ошибки выглядят вот так:
2013/09/05 12:56:00 [error] 1378#0: *24759881 connect() failed (110: Connection timed out) while connecting to upstream, client: x.x.x.x, server: *******.ru, request: "GET /extends.php?do=ajax&live_activity=1 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "**********.ru", referrer: "*********"
Запуск php-cgi происходит вот таким дивным образом:
export PHP_FCGI_CHILDREN=16
export PHP_FCGI_MAX_REQUESTS=1500
sudo -E -u ftpuser php-cgi -b 127.0.0.1:9000
Конфиг Nginx:
user ftpuser;
worker_processes 8;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
multi_accept on;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;
#tcp_nopush on;
keepalive_timeout 60s;
tcp_nodelay on;
gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_min_length 1000;
gzip_comp_level 9;
gzip_types text/plain image/png image/gif image/jpeg text/xml application/xml application/x-javascript text/javascript text/css text/json text/js;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
client_max_body_size 100m;
}
Настройка самого vhost.
server {
listen 80;
server_name **********.ru;
location / {
index index.php;
root /var/www/**********.ru/;
if (!-e $request_filename) {
rewrite ^(.*) /sef.php last;
}
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/*******.ru/$fastcgi_script_name;
fastcgi_read_timeout 240;
include fastcgi_params;
}
location ~ /\.ht
{
deny all;
}
root /var/www/********.ru;
}
Посещений на сайте не много в районе 10-15 тысяч.
Подскажите, что бы это такое могло быть, куда копать? Процессор на сервере простаивает, память есть свободная по дискам давления никакого нет (стоит munin могу дать графы).
Судя по ошибке Timeout connect to localhost:9000 но как такое может быть? :) Закончились какие-то системные буферы? допустимые лимиты коннектов?
При этом, если сам Nginx логи какие-то дает то php-cgi ничего кроме php error_log, стало быть я вижу ошибки только обработки самого PHP кода, но как бы понять почему TIMEOUT ?
dmesg / messages - тишина...
Заранее всем спасибо.
С Уважением,
Статика же отдается nginx, в этом случае 502 не может быть на статику.
Может быть скрипт обрабатывает больше N времени. И nginx не получив ответ - развешает по таймауту с 502. Думаю стоит - найти закономерность, воспроизвести, отдебажить
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/*******.ru/$fastcgi_script_name;
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
include fastcgi_params;
}
Зачем gzip_comp_level 9; -> достаточно 5~6
worker_connections 1024; -> я бы увеличил хотя бы до 2048, и по stat nginx -> смотрел, сколько юзают и не нужно ли увеличить еще.
keepalive_timeout 60s; -> думаю достаточно 20-30s
fcgi лучше перевести на сокет.
Честно говоря в логах NGINX вообще нету слова "502", там просто есть ошибки, какая из них вызывает 502 как результат клиенту, сложно сказать.... либо я че-то не понимаю где смотреть....
2013/09/05 13:00:01 [error] 1378#0: *24764397 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 178.216.166.1, server: ********.ru, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "********.ru"
Вот почему favicon.ico вообще оттуда читается? Ведь судя по настройкам только .php уходят в php-cgi..... А Ошибка выглядит так как будто php-cgi должен был отдать favicon.ico и не отдал.
Я полагаю, что если бы были в PHP Какие-то таймауты, то об этом было бы известно в php error log ?
Попробуйте увеличить количество процессов fcgi.
А так же заюзать php5-fpm, там есть динамический режим.
---------- Добавлено 05.09.2013 в 23:26 ----------
Я полагаю, что если бы были в PHP Какие-то таймауты, то об этом было бы известно в php error log ?
Да, но если например таймаут на выполнение скрипта 60с для пхп, а для nginx - меньше, то php не запишет ошибку в лог -> если скрипт уложился в отведенное время. Можно сделать небольшой таймаут для php скриптов и посмотреть какие умирают по таймауту.
max_execution_time = 120 это php.
fastcgi_read_timeout 240 это cgi...
Собственно как вы и предлагаете сделать.... Т.е Nginx готов больше ждать нежели PHP.
В логах PHP ничего нет по этому поводу....
Вы уверены, что 502 выдает по fastcgi_read_timeout, то есть через 240 секунд? Пользователи подтвердили, что ждали 4 минуты?
fastcgi_connect_timeout
fastcgi_read_timeout
fastcgi_send_timeout
Увеличьте все 3 параметра. Сделайте больше fcgi процессов. Если стоят кешеры (apc, xcache) - отключите их на время.
Вы уверены, что 502 выдает по fastcgi_read_timeout, то есть через 240 секунд? Пользователи подтвердили, что ждали 4 минуты?
Нет не уверен. Нет пользователи не подтверждали. Это просто все ошибки которые есть в принципе :))) стало быть наверное с ними и связано, а если они не при чем вообще, то других ошибок вовсе нет ..... а 502 есть .... ))))
fastcgi_connect_timeout
fastcgi_read_timeout
fastcgi_send_timeout
Увеличьте все 3 параметра. Сделайте больше fcgi процессов. Если стоят кешеры (apc, xcache) - отключите их на время.
Поставил:
fastcgi_connect_timeout 240;
fastcgi_read_timeout 240;
fastcgi_send_timeout 240;
Увеличил кол-во fcgi с 16 до 32х.
Кешей не обнаружено.
В php5-fpm можно сделать dynamic
http://php.net/manual/ru/install.fpm.configuration.php
Выбор того, как менеджер процессов будет контролировать создание дочерних процессов. Возможные значения: static, ondemand, dynamic. Этот параметр является обязательным.
static - фиксированное число дочерних процессов (pm.max_children).
ondemand - число процессов, порождающихся по требованию (когда появляются запросы, в отличии от опции dynamic, когда стартует определенное количество процессов, равное pm.start_servers, вместе с запуском службы.
dynamic - динамически изменяющееся число дочерних процессов, задается на основании следующих директив: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
---------- Добавлено 05.09.2013 в 23:44 ----------
max_execution_time = 120
это в любом случае дофига, юзер будет ждать 2 минуты?
Поставил одну минуту, все равно мало вероятно , что это связано.
Я че-то подумываю на апач откатиться ..... Не такая уж там и нагрузка что бы php умирало вот так вот... :(
---------- Добавлено 05.09.2013 в 23:05 ----------
Дело в том, что Nginx в пиковой точке за сутки обслуживает около 400 конектов....
А среднее число за сутки.... ~180.....
Не ясно, неужели это так много :D И где ошибки блин !!! ?:)
max_execution_time работает не так, как некоторые ожидают :)
в Unix/Linux он ставит лимит на время, которое скрипт съест у процессора (ITIMER_PROF).
т.е. "обычный" sleep или различные задержки при получении ответа от внешних сервисов не учитываются в этом времени. а это значит, что 502 легко можно словить - nginx просто закроет подключение к бэкенду.
max_execution_time работает не так, как некоторые ожидают :)
в Unix/Linux он ставит лимит на время, которое скрипт съест у процессора (ITIMER_PROF).
т.е. "обычный" sleep или различные задержки при получении ответа от внешних сервисов не учитываются в этом времени. а это значит, что 502 легко можно словить - nginx просто закроет подключение к бэкенду.
Что-то я не совсем уловил суть, max_execution_time настроено в PHP, стало быть PHP процесс лимитируется, если он выходит за лимиты, об этом же должно быть сообщение какое-то :D ?
Nginx логи дает, но они как вы понимаете не многое поясняют :D типа PHP закрыло соединение :D