Как правильно оптимизировать nginx и php?

[magicrobot]

Взял vds для одного сайта на Wordpress с характеристиками 8 Гб оперативки, 1 Гб swap, SSD диск, на борту: Debian, ispmanager5, Apache MPM-ITK, nginx и PHP-FPM FastCGI.

Водрузил сайт (трёхъязычный, овер 10 000 записей, 30 000 изображений, не считая уменьшенных, мегажрущий плагин WPML)

При редактировании постов - сайт начал вылетать в ошибку 504 nginx
При этом - смотрю в панели на нагрузку на систему, не вижу там критических ситуаций:

То есть, мне что то подсказывает, что сервер не используется "на полную", скорее всего имеются какие то программные ограничения на использования ресурсов. Скорее всего это ограничения php, nginx, apache

Скажите пожалуйста, какие я могу "поднять" параметры, чтобы искусственно не ограничивать выполнения тех или иных скриптов, например.

 

[nejtr0n]

Слишком мало информации.
Вариантов, почему такое возможно, много.
Для начала посмотрите логи php, есть ли там что нибудь интересное.
Потом можно увеличить proxy_read_timeout для nginx.
Так же, если это редактирование - возможно max_upload_filesize.
Ещё можно включить slow_query_log в mysql и посмотреть, что в нём будет.

 

[Proline29]

Если отваливается nginx смотрите его логи в первую очередь на что ругается, как правило нормальная настройка кэширования.
И Proxy лимитов должна решить 90% типовых задач. Остлаьное без логов не как.

 

[latteo]

Я 504 ловлю при проблемах с php.
Фиксы:
Поднимать повыше fastcgi_read_timeout - время ожидания ответа от php. Некотоые страницы wp под нагрузкой у меня отрабатывались до 5 минут, если у вас тоже есть такие монстры то ставить значение 300. В основном ставлю 180:

location ~ \.php$ {
  ...
  fastcgi_read_timeout 180;
}

Поднимать побольше процессов для PHP-FPM FastCGI. При таком количестве оперативки, запросто можно поднимать 50-100. Следить чтобы они не дохли - у меня при тестовой ddos нагрузке почти все поотваливались.
Как именно следить так и не нашел решения. На словах - сделать проверку через крон на количество процессов и если стало меньше 80% от начального значения перезапускать, но там наверняка есть нюансы, особенно при необходимости непрерывной работы...

 

[nejtr0n]

Как именно следить так и не нашел решения.

Самое простое решение имхо - докер контейнер с директивой restart=always.
Можно накостылить с supervisor (numprocs=5 например). Но тогда нужно биндить каждый фпм на свой порт и балансить nginx'ом.

 

[magicrobot]

Слишком мало информации.
Вариантов, почему такое возможно, много.
Для начала посмотрите логи php, есть ли там что нибудь интересное.
Потом можно увеличить proxy_read_timeout для nginx.
Так же, если это редактирование - возможно max_upload_filesize.
Ещё можно включить slow_query_log в mysql и посмотреть, что в нём будет.

Вот что вижу в логах nginx (множественно

2016/12/07 08:55:09 [warn] 4567#4567: *3024 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/6/38/0000000386 while reading upstream, client: 217.69.134.39, server: congress.org, request: "GET /sitemap-pt-post-2014-02.xml HTTP/1.1", upstream: "fastcgi://unix:/var/www/php-fpm/congress.sock:", host: "congress.org"

а так же вот такое, тоеж много где:

2016/12/07 08:56:53 [error] 4567#4567: *3072 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 217.69.134.15, server: congress.org, request: "GET /sitemap-pt-post-2014-07.xml HTTP/1.1", upstream: "fastcgi://unix:/var/www/php-fpm/congress.sock", host: "congress.org"

но я заметил, что сервак падает в момент новой записи или редактирвоания из вордпресс, бриблизительно вот такой код тоже множественно:

2016/12/07 23:21:18 [warn] 9113#9113: *4865 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/5/75/0000000755 while reading upstream, client: 178.205.110.240, server: congress.org, request: "GET /wp-admin/post.php?post=61109&action=edit&lang=ru&message=6 HTTP/1.1", upstream: "fastcgi://unix:/var/www/php-fpm/congress.sock:", host: "congress.org", referrer: "http://congress.org/wp-admin/post-new.php?wp-post-new-reload=true"

вот тут у меня знания заканчиваются, даже понять не могу в какую сторону рыть. Понятное дело, что есть за что зацепиться, за некий fastcgi://unix:/var/www/php-fpm/congress.sock
А вот куда дальше копать - ума не приложу.

 

[nejtr0n]

2016/12/07 08:55:09 [warn] 4567#4567: *3024 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/6/38/0000000386 while reading upstream, client: 217.69.134.39, server: congress.org, request: "GET /sitemap-pt-post-2014-02.xml HTTP/1.1", upstream: "fastcgi://unix:/var/www/php-fpm/congress.sock:", host: "congress.org"

То что данные буферизуются, это не критично. Просто размер буфера nginx меньше буферизуемых данных, и он их сбрасывает на диск. В идеале - увеличить размер буфера. Но это не критично.
Вот это уже больше похоже на правду

2016/12/07 08:56:53 [error] 4567#4567: *3072 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 217.69.134.15, server: congress.org, request: "GET /sitemap-pt-post-2014-07.xml HTTP/1.1", upstream: "fastcgi://unix:/var/www/php-fpm/congress.sock", host: "congress.org"

Возсожно не правильно прописан сокет?
может unix:/var/www/php-fpm/congress.sock ?

 

[Proline29]

Покажите Ваш конфиг лучше