Решил переехать на Nginx (почему только сейчас - так уж вышло). За время экспериментов появилось несколько вопросов. OS - CentOS 6. Компоненты такие: 1) сам Nginx, 2) Lighttpd (на него проксируются старые сайты чтобы не переносить все разом), 3) PHP-FPM (для новых), 4) Игровой сервер, работающий по websockets, трафик на который так же проксируется через Nginx. 5) Боты, играющие на сервере, соединяющиеся через Nginx. Всего параллельно 1600 ботов. К одним вопросам это все имеет отношение, к другим - нет. Итак, вопросы: 1. nginx.conf, keepalive_timeout Как работает keepalive_timeout? Доки и гуглеж что-то не дали внятного ответа, что же именно считается таймаутом, и что именно его сбрасывает. Полноценный HTTP-запрос-ответ? Или любой отправленный байт в любую сторону? 2. Первое время в логах было много таких записей: 1024 worker_connections are not enough При этом в конфиге: worker_processes 16; Средняя игровая сессия бота - наверно порядка 1 минуты. После геймовера бот закрывает сокет, соединятся повторно, и играет снова. netstat показал, что количество established и time_wait соединений примерно одинаковое. Может ли это быть связано с keepalive_timeout 65? Удаляется ли соединение из пула по закрытию сокета, или только по keepalive_timeout? Уменьшил keepalive_timeout до 15, увеличил worker_connections до 2048, пока что эта запись больше не появлялась. Но все-таки хочется понять в чем было дело. Вот тут (https://serverfault.com/questions/2...-in-time-wait-state-server-is-slow-ipconntrac) чувак сказал что в /etc/sysctl.conf надо добавить: net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_tw_recycle=1 Этого у меня не было, тоже добавил. Может дело было в реюзе? 3. Еще в логах было много вот такого: an upstream response is buffered to a temporary file Одни чуваки (https://serverfault.com/questions/587386/an-upstream-response-is-buffered-to-a-temporary-file) посоветовали добавить: proxy_buffers 16 16k; proxy_buffer_size 16k; Другие (https://codebeer.ru/nginx-an-upstream-response-is-buffered-to-a-temporary-file/) - добавить: fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; Понятно, что цифры для примера и могут быть увеличины (памяти на сервере достаточно). Правильно ли я понимаю, что первый случай нужен тогда, когда Nginx работает как HTTP прокси, а второй - когда сам работает с PHP через FastCGI, то есть это все разные буферы, хотя ошибка (а точнее - предупреждение) в логе будет одна и та же? На сервере 32 Гб ОЗУ. Есть ли смысл дать этим буфферам гораздо больше, чем в примерах? Например по 16 метров? 4. В редких случаях при попытке открыть файл через FastCGI (то есть через "свой" сайт, а не проксируемый через Lighttpd), была HTTP 500 и запись в логе Nginx: Resource temporarily unavailable Гуглеж показал, что проблема на стороне PHP-FPM (например https://serverfault.com/questions/8...temporarily-unavailable-while-connecting-to-u), и посмотрев несколько вариантов ответов, я просто увеличил pm.max_children c пары десятков до 1024 - вроде бы пока что все ок, но опять же, хотелось бы разобраться. Сейчас в FPM-конфиге у меня так: pm = dynamic pm.max_children = 1024 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 35 ;pm.max_requests = 500 - закомментировано, то есть 0, то есть ограничителя нет Помогите кто чем может, а то сами мы не местные Спасибо
Вот тут советуется еще одна настройка: https://devmems.wordpress.com/2014/...le-на-связке-nginx-php-fpm-через-unix-socket/ --- Сообщение объединено, Mar 19, 2019 --- Сегодня эта ошибка начала появляться снова. Я обратил внимание что в примере по ссылке выше Nginx ходит на FastCGI по UNIX-сокету, а у меня был IP:Port. Заменил на UNIX-сокет, посмотрим что из этого выйдет.
_DEN_, если хочешь сильно разобраться в тонкостях настроек, качай сорцы и смотри акь нужные тебе опции пережёвываются прогой. а ещё не помешает собрать эту крень с дебагом.
FastCGI использует свой сервер так что причём тут Nginix не понятно. В HTTP протоколе есть команда keepalive. Вот только с повсеместным появлением HTTPS абсолютно бесполезна.
UbIvItS, именно такой совет я от тебя и ждал Pavia, не совсем понял, при чем тут HTTPS? Трафик либо идет, либо нет, вне зависимости от того, зашифрован он или нет. Или я чего-то не знаю? Minzdrav, нет, все ровно наоборот. --- Сообщение объединено, Mar 20, 2019 --- И снова здравствуйте. Вылез еще один момент. Не критично, но все-таки хочется разобраться. Итак, рассмотрим ситуацию, когда Nginx отдает статический файл напрямую (то есть без похода на прокси, PHP-FPM или куда-то еще). Если сохранить этот файл самба-сервером, а потом в течение 2-3 секунд попытаться открыть браузером (через Nginx), то опять же будет HTTP 500 и запись в лог "Resource temporarily unavailable". При этом в точно такой же ситуации Lighttpd отдаст файл без ошибок. Его можно скачать даже параллельно с сохранением - файл может оказаться кривым, да, но ошибки не будет, и Lighttpd выдаст хотя бы что-то. Все это выглядит так, будто Nginx при отдаче статических файлов открывает их на чтение эксклюзивно, и эта попытка фейлится, если самба еще не успела закрыть хэндл. А Lighttpd - не эксклюзивно, и читает то, что удалось прочитать. Гуглеж по ключевым словам результата не дал. Может быть кто в теме и по этому вопросу?
всегда есть простой Вопрос == ЧТО В ЛОГАХ????????????? могу дать и второй хороший совет == заплати этим ребятам https://www.nginx.com/services/ и они тебе настроят + раcскажут тонкости сих опций
Когда Lighttpd отдает файл, в который сейчас пишет самба - ошибки нет, и поэтому в логах ничего. Когда Nginx не может отдать файл, в который сейчас пишет самба, он пишет в лог ошибку: Code (Text): 2019/03/20 11:17:21 [crit] 22762#22762: *2327031 open() "/var/www/html/.../game.js" failed (11: Resource temporarily unavailable), client: ... И выдает в респонс HTTP 500, Internal Server Error. То есть - не смог открыть файл. Почему приложение не может открыть файл, в который сейчас кто-то пишет (а другие при этом могут)? Единственный вариант, который приходит на ум - приложение пытается открыть файл эксклюзивно. Может быть на это могут быть еще какие-то причины?
Файл действительно создан другим пользователем, но права на чтение для этого файла есть у всех. Тот же Lighttpd его читает (точно так же не будучи владельцем файла). Пока писал, нашел решение: https://stackoverflow.com/questions...e-temporarily-unavailable-using-a-samba-share (похоже работает)
привет Да не так-то это просто (для меня) - вот так взять и заменить одну систему на другую И мне все-таки нужен HTTP-сервер, поскольку за Nginx-ом у меня и сам сайт сидит, и игровой сервер. Это чтобы игровой сервер был доступен по тем же 80/443, что и сайт. У ряда юзеров все кроме HTTP(S) бережно зафаерволено Но спасибо, я посмотрю что это такое.
Денисочка. Мне трудно понять в чём конкретно состоит проблема. Но может надо разделить физически, сайт и игровой сервер. И они перестанут лагать. Или перевалить на маршрутизатор проблему одного IP адреса. Подключить к нему два провода. Я во всяком случае когда не могу докрасноглазить, то так и действую. Через виртуалки, через аппаратуру. А ещё, если поставить на другую ОС, или на другое ядро той же ОС, то часто ситуация меняется. --- Сообщение объединено, Apr 4, 2019 --- Если 32 ГБ ОЗУ можно и на виртуалке запустить сайт. --- Сообщение объединено, Apr 4, 2019 --- Говорят на виртуалке ещё быстрее работает чем на основном железе. Сайты в интернете.
