wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Nginx test config: Перезапустить nginx, проверка конфигурации nginx

alexxlab
No Comments

Содержание

Перезапустить nginx, проверка конфигурации nginx

После того как конфигурационные файлы веб-сервера отредактированы необходимо перезапустить nginx чтобы произошло их повторное считывание.

 

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

 

Как протестировать конфигурацию и перезапустить nginx

Проверить правильность синтаксиса конфигов можно выполнив следующую команду

 

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

 

При положительном результате в выводе будет приведенное выше сообщение или Syntax OK в зависимости от версии пакета. Если найдены ошибки выведутся названия файлов и строки на которых ошибки обнаружены.

Похожим образом тестируется конфигурация Apache (apache2ctl -t)

 

После тестирования серверу необходимо дать команду на перечитывание конфигов (опция -s обозначает signal, серверу можно отправить множество сигналом, но чаще всего это reload, stop и start)

nginx -s reload

 

Если ошибки все же есть и конфиги предварительно не тестировались nginx -s reload перезапустит nginx только в случае если к остановке веб-сервера это не приведет, т.е. если серьезных ошибок в конфигурации нет

 

Чтобы выполнить полную перезагрузку необходимо выполнить

 

/etc/init.d/nginx restart

 

Конфигурационные файлы при этом не тестируются. Выполнение команды необходимо при внесении каких-либо существенных изменений когда простого reload недостаточно.

 

 

Если Nginx по какой-то причине не останавливается (т.е. после выполнения /etc/init.d/nginx stop в выводе ps aux | grep nginx  остаются процессы) процессы требуется завершить вручную, затем запустить Nginx.

Такое бывает если пакет собирался из исходников и для него не написаны инициализационные скрипты.

 

pkill nginx

 

/etc/init.d/nginx start

 

При работе в нагруженных проектах, обслуживающих сайты с посещаемостью в десятки тысяч человек в сутки и более, NGINX конфигурируют специальным образом, что дает максимальную производительность. Для небольших проектов выполнить такие настройки тоже  может оказаться полезно.

Проверка конфигурации nginx

Nginx не читает конфиги на лету, и их можно спокойно править на действующем сервере. Когда правки закончены, хотелось бы убедиться, что по крайней мере синтаксис команд верен и сервер запустится с новыми настройками.

Для этого в nginx встроен валидатор конфигурации, который можно запустить отдельно с ключом -t.




Если все в порядке, то вы получите соответствующий ответ сервера:


# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful



# nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful


Уже после этого можно выполнить чтение новой конфигурации командой:




или




nginx

Написать комментарий


Данная запись опубликована в 16.04.2018 19:37 и размещена в Программирование.
Вы можете перейти в конец страницы и оставить ваш комментарий.

Мало букафф? Читайте есчо !

Переадресация сайта с www и без www

Январь 26, 2017 г.

Издревле ломают голову сеошники над вопросом. Вопрос ставиться по-гамлетовски : с www или без www? «Быть или не быть, вот в чем вопрос».


Быть или …

Читать

HTTP авторизация для nginx

Декабрь 3, 2019 г.

Задача возникла в контексте SEO, требовалось предотвратить индексацию тестовых сайтов поисковыми системами. На практике видно, что инструкции файла robots.txt …

Читать

Полезные сниппеты для Nginx конфигов / Хабр

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

Готовые конфиги:

Команды Nginx

Основные команды для выполнения базовых операций во время работы Nginx.

  • nginx -V — проверить версию Nginx, его скомпилированные параметры конфигурации и установленные модули.

  • nginx -t — протестировать конфигурационный файл и проверить его расположение.

  • nginx -s reload — перезапустить конфигурационный файл без перезагрузки Nginx.

Location блок на PHP

Простой шаблон для быстрой и легкой установки PHP, FPM или CGI на ваш сайт.

location ~ \.php$ {
  try_files $uri =404;
  client_max_body_size 64m;
  client_body_buffer_size 128k;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass unix:/path/to/php.sock;
}
Rewrite и Redirection

Force www

Корректный способ определить удаленный сервер по домену без www и перенаправить его c www:

server {
    listen 80;
    server_name example.org;
    return 301 $scheme://www.example.org$request_uri;
}

server {
    listen 80;
    server_name www.example.org;
    ...
}

Также работает для HTTPS.

Force no-www

Корректный способ определить удаленный сервер по домену c www и перенаправить его без www:

server {
    listen 80;
    server_name example.org;
}

server {
    listen 80;
    server_name www.example.org;
    return 301 $scheme://example.org$request_uri;
}
Force HTTPS

Способ для переадресации с HTTP на HTTPS:

server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    # let the browsers know that we only accept HTTPS
    add_header Strict-Transport-Security max-age=2592000;

    ...
}
Force Trailing Slash

Данная строка добавляет слэш / в конце каждого URL, только в том случаее если в URL нет точки или параметров. Тоесть после example.com/index.php или example.com/do?some=123 слэш не поставится.

rewrite ^([^.\?]*[^/])$ $1/ permanent;
Редирект на страницу
server {
    location = /oldpage.html {
        return 301 http://example.org/newpage.html;
    }
}
Редирект на сайт
server {
    server_name old-site.com
    return 301 $scheme://new-site.com$request_uri;
}
Редирект на определенный путь в URI
location /old-site {
    rewrite ^/old-site/(.*) http://example.org/new-site/$1 permanent;
}
Производительность

Кэширование

Навсегда разрешить браузерам кэшировать статические содержимое. Nginx установит оба заголовка: Expires и Cache-Control.

location /static {
    root /data;
    expires max;
}

Запретить кэширование браузерам (например для отслеживания запросов) можно следующим образом:

location = /empty.gif {
    empty_gif;
    expires -1;
}
Gzip сжатие
gzip  on;
gzip_buffers 16 8k;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
    text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
    text/javascript application/javascript application/x-javascript
    text/x-json application/json application/x-web-app-manifest+json
    text/css text/plain text/x-component
    font/opentype application/x-font-ttf application/vnd.ms-fontobject
    image/x-icon;
gzip_disable  "msie6";
Кэш файлов

Если у вас кешируется большое количество статических файлов через Nginx, то кэширование метаданных этих файлов позволит сэкономить время задержки.

open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
SSL кэш

Подключение SSL кэширования позволит возобновлять SSL сессии и сократить время к следующим обращениям к SSL/TLS протоколу.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
Поддержка Upstream

Активация кеширования c использованием Upstream подключений:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    ...
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}
Мониторинг

По умолчанию Stub Status модуль не собирается, его сборку необходимо разрешить с помощью конфигурационного параметра —with-http_stub_status_module и активировать с помощью:

location /status {
    stub_status on;
    access_log off;
}

Данная настройка позволит вам получать статус в обычном текстовом формате по общему количеству запросов и клиентским подключениям (принятым, обработанным, активным).

Более информативный статус от Nginx можно получить с помощью Luameter, который несколько сложнее в установке и требует наличия Nginx Lua модуля. Это предоставит следующие метрики по различным конфигурационным группам в формате JSON:

  • Общее количество запросов/ответов.

  • Общее количество ответов сгруппирированных по статус кодам: 1xx, 2xx, 3xx, 4xx, 5xx.

  • Общее количество байт принятых/отправленных клиенту.

  • Промежуточные отрезки времени для оценки минимума, максимума, медианы, задержек и тд.

  • Среднестатистическое количество запросов для простоты мониторинга и составления прогнозов по нагрузке.

  • И прочее…

Пример дашборда от Luameter.

Также для сбора статистики отлично подходит ngxtop.

Безопасность

Активация базовой аунтификации

Для начала вам потребуется создать пароль и сохранить его в обычной текстовом файле:

имя:пароль

Затем установить найтройки для server/location блока, который необходимо защитить:

auth_basic "This is Protected";
auth_basic_user_file /path/to/password-file;
Открыть только локальный доступ
location /local {
    allow 127.0.0.1;
    deny all;
    ...
}
Защита SSL настроек
  • Отключить SSLv3, если он включен по умолчанию. Это предотвратит POODLE SSL Attack.

  • Шифры, которые наилучшим образом обеспечат защиту. Mozilla Server Side TLS and Nginx.
    # don’t use SSLv3 ref: POODLE CVE-2014-356 - http://nginx.com/blog/nginx-poodle-ssl/
ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  

# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla (Intermediate Set) - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers  on;

Прочее

Подзапросы после завершения

Бывают ситуации, когда вам необходимо передать запрос на другой бэкэнд в дополнении или после его обработки. Первый случай — отслеживать количество завершенных загрузок путем вызова API, после того как пользователь скачал файл. Второй случай -отслеживать запрос, к которому вы бы хотели вернуться как можно быстрее (возможно с пустым .gif) и сделать соответствующие записи в фоновом режиме. post_action, который позволяет вам определить подзапрос и будет отклонен по окончанию текущего запроса — является лучшим решением для обоих вариантов.

location = /empty.gif {
    empty_gif;
    expires -1;
    post_action @track; 
}

location @track {
    internal;
    proxy_pass http://tracking-backend;
}
Распределение ресурсов между источниками

Самый простой и наиболее известный способ кросс-доменного запроса на ваш сервер:

location ~* .(eot|ttf|woff) { 
    add_header Access-Control-Allow-Origin *; 
}
Источники

Большое спасибо всем за внимание!

проверить конфигурацию NGINX перед рестартом

Имеется роль nginx, в которой выполняется его настройка и копирование файлов.

Последней задачей роли выполняется nginx restart.

Проблема заключается в том, что попытка перезапуска NGINX выполняется в любом случае, и если в файле шаблона виртуалхоста есть ошибка — то NGINX не запустится.

Что бы выполнить проверку — nginx -t — добавляем задачу с вызовом модуля shell:

...
- name: Check NGINX configs
  shell: "/usr/sbin/nginx -t"
  register: nginx_config_status
...

Далее добавляем вывод кода в аутпут Ansible — просто для себя:

...
- name: NGINX test status
  debug:
    msg: "{{ nginx_config_status.rc }}"
...

Или всё содержимое, а не только rc (return code):

...
- name: NGINX test status
  debug:
    msg: "{{ nginx_config_status }}"
...

И в последней задаче — добавляем условие when:

...
- name: Service NGINX restart and enable on boot
  systemd:
    name: nginx
    state: restarted
    enabled: yes
    daemon_reload: yes
  when: nginx_config_status.rc == 0
...

Хотя условие тут «условное», т.к. Ansible остановится в любом случае на выполеннии задачи «Check NGINX configs«, если она выполнится с ошибкой.

Теперь полностью всё выглядит так:

...
- name: Check NGINX configs
  shell: "/usr/sbin/nginx -t"
  register: nginx_config_status

- name: NGINX test status
  debug:
    msg: "{{ nginx_config_status }}"

- name: NGINX test status
  debug:
    msg: "{{ nginx_config_status.rc }}"

- name: Service NGINX restart and enable on boot
  systemd:
    name: nginx
    state: restarted
    enabled: yes
    daemon_reload: yes
  when: nginx_config_status.rc == 0

Проверяем.

Добавляем лишнюю фигурную скобку в один из конфигов, вызываем роль nginx:

…

TASK [nginx : Add NGINX RabbitMQ WebUI config] ****

changed: [production.mobilebackend.domain.world]

TASK [nginx : Check NGINX configs] ****

fatal: [production.mobilebackend.domain.world]: FAILED! => {«changed»: true, «cmd»: «/usr/sbin/nginx -t», «delta»: «0:00:00.006300», «end»: «2018-07-11 14:48:31.615100», «msg»: «non-zero return code», «rc»: 1, «start»: «2018-07-11 14:48:31.608800», «stderr»: «nginx: [emerg] unexpected \»}\» in /etc/nginx/conf.d/rabbitadmin-production.domain.world.conf:4\nnginx: configuration file /etc/nginx/nginx.conf test failed», «stderr_lines»: [«nginx: [emerg] unexpected \»}\» in /etc/nginx/conf.d/rabbitadmin-production.domain.world.conf:4″, «nginx: configuration file /etc/nginx/nginx.conf test failed»], «stdout»: «», «stdout_lines»: []}

PLAY RECAP ****

production.mobilebackend.domain.world : ok=4    changed=1    unreachable=0    failed=1

Something went wrong. Exit.

ОК, исправляем ошибку, вызываем Ansible ещё раз:

…

TASK [nginx : Add NGINX RabbitMQ WebUI config] ****

changed: [production.mobilebackend.domain.world]

TASK [nginx : Check NGINX configs] ****

changed: [production.mobilebackend.domain.world]

TASK [nginx : NGINX test status] ****

ok: [production.mobilebackend.domain.world] => {

«msg»: {

«changed»: true,

«cmd»: «/usr/sbin/nginx -t»,

«delta»: «0:00:00.007164»,

«end»: «2018-07-11 14:53:04.623855»,

«failed»: false,

«rc»: 0,

«start»: «2018-07-11 14:53:04.616691»,

«stderr»: «nginx: the configuration file /etc/nginx/nginx.conf syntax is ok\nnginx: configuration file /etc/nginx/nginx.conf test is successful»,

«stderr_lines»: [

«nginx: the configuration file /etc/nginx/nginx.conf syntax is ok»,

«nginx: configuration file /etc/nginx/nginx.conf test is successful»

],

«stdout»: «»,

«stdout_lines»: []

}

}

TASK [nginx : NGINX test status] ****

ok: [production.mobilebackend.domain.world] => {

«msg»: «0»

}

TASK [nginx : Service NGINX restart and enable on boot] ****

changed: [production.mobilebackend.domain.world]

PLAY RECAP ****

production.mobilebackend.domain.world : ok=8    changed=3    unreachable=0    failed=0

Provisioning done.

Готово.

Настройка веб-сервера Nginx для улучшения показателей RPS в HTTP API / Блог компании Timeweb / Хабр

Перед горизонтальным и вертикальным масштабированием инфраструктуры первым делом необходимо убедиться, что ресурсы используются правильно, а конфигурация приложения не создает узких мест для его производительности. Главная цель команды инженеров — обеспечить постоянную, бесперебойную работу любой спроектированной и развернутой системы с помощью минимальных ресурсов.

Мы столкнулись с указанной выше проблемой, когда наша развернутая система ежедневно использовалась миллионом пользователей, которые подключались всплесками время от времени. Это значит, что развертывание нескольких серверов или их масштабирование не будет в данной ситуации оптимальным решением.


Эта статья посвящена настройке Nginx для повышения производительности, то есть для увеличения показателей RPS (Requests Per Second) в HTTP API. Я постарался рассказать об оптимизации, которую мы применили в развернутой системе, чтобы обрабатывать десятки тысяч запросов в секунду без траты огромного количества ресурсов.

План действий: необходимо запустить HTTP API (написанный на Python с использованием flask), проксированный с помощью Nginx; требуется высокая пропускная способность. Содержимое API будет меняться с интервалом в один день.

оптимизация
имя существительное

процесс достижения наилучшего результата; наиболее эффективное использование ситуации или ресурса.

Мы использовали супервизор для запуска WSGI Server со следующими конфигурациями:
Команда для супервизора выглядит так:

gunicorn api:app --workers=5 --worker-
class=meinheld.gmeinheld.MeinheldWorker --bind=unix:api.sock

Мы попробовали оптимизировать конфигурацию Nginx и проверили, что лучше всего сработает для нас.

Для оценки производительности API мы использовали wrk с помощью следующей команды:

wrk -t20 -c200 -d20s http://api.endpoint/resource

Конфигурация по умолчанию

Сначала мы выполнили нагрузочное тестирование API без каких-либо изменений и получили следующую статистику:

Running 20s test @ http://api.endpoint/resource
  20 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   192.48ms  274.78ms   1.97s    87.18%
    Req/Sec    85.57     29.20   202.00     72.83%
  33329 requests in 20.03s, 29.59MB read
  Socket errors: connect 0, read 0, write 0, timeout 85
Requests/sec:   1663.71
Transfer/sec:      1.48MB

Обновление конфигурации по умолчанию

Давайте обновим стандартную конфигурацию Nginx, то есть nginx.conf в /etc/nginx/nginx.conf

worker_processes auto;
#or should be equal to the CPU core, you can use `grep processor /proc/cpuinfo | wc -l` to find; auto does it implicitly.

worker_connections 1024;
# default is 768; find optimum value for your server by `ulimit -n`

access_log off;
# to boost I/O on HDD we can disable access logs
# this prevent nginx from logging every action in a log file named `access.log`.

keepalive_timeout 15;
# default is 65;
# server will close connection after this time (in seconds)

gzip_vary on;
gzip_proxied any;
gzip_comp_level 2;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
# reduces the data that needs to be sent over the network

nginx.conf (/etc/nginx/nginx.conf)

После изменений мы запускаем проверку конфигурации:

sudo nginx -t

Если проверка прошла успешно, можно перезапустить Nginx, чтобы отобразить изменения:

sudo service nginx restart

С такой конфигурацией мы провели нагрузочное тестирование API и получили следующий результат:

Running 20s test @ http://api.endpoint/resource
  20 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   145.80ms  237.97ms   1.95s    89.51%
    Req/Sec   107.99     41.34   202.00     66.09%
  42898 requests in 20.03s, 39.03MB read
  Socket errors: connect 0, read 0, write 0, timeout 46
  Non-2xx or 3xx responses: 2
Requests/sec:   2141.48
Transfer/sec:      1.95MB

Эти конфигурации сократили тайм-ауты и увеличили показатели RPS (количество запросов в секунду), но ненамного.

Добавление кеша Nginx

Поскольку в нашем случае содержимое конечной точки будет обновляться с интервалом в один день, это создает подходящие условия для кеширования ответов API.

Но добавление кеша приводит к его недействительности… это одна из двух трудностей здесь.

В компьютерных науках есть только две сложности: инвалидация кеша и именование вещей. — Фил Карлтон

Мы выбираем простое решение очистки каталога кеша с помощью cronjob после обновления содержимого в нижестоящей системе.

Далее всю тяжелую работу будет выполнять Nginx, но теперь мы должны быть уверены, что Nginx готов на 100%!

Чтобы добавить кеширование в Nginx, нужно прописать несколько директив в файл конфигурации Nginx.

Перед этим нам нужно создать каталог для хранения данных кеша:

sudo mkdir -p /data/nginx/cache

Изменения в конфигурации Nginx:

proxy_cache_path /data/nginx/cache keys_zone=my_zone:10m inactive=1d;
server {
    ...
    location /api-endpoint/ {
        proxy_cache my_zone;
        proxy_cache_key "$host$request_uri$http_authorization";
        proxy_cache_valid 404 302 1m;
        proxy_cache_valid 200 1d;
        add_header X-Cache-Status $upstream_cache_status;
    }
    ...
}

Кеширование проксируемых запросов (конфигурация Nginx)

После этого изменения в конфигурации мы провели нагрузочное тестирование API и получили следующий результат:

Running 20s test @ http://api.endpoint/resource
  20 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.88ms    5.44ms  88.91ms   81.36%
    Req/Sec     1.59k   500.04     2.95k    62.50%
  634405 requests in 20.06s, 589.86MB read
Requests/sec:  31624.93
Transfer/sec:     29.40MB

Таким образом, мы получили почти 19-кратное увеличение производительности за счет добавления кеширования.

Примечание от эксперта Timeweb:

Важно помнить, что кеширование запросов, приводящих к записи в базу данных, приведет к тому, что будет отдаваться закешированный ответ, но запись в базу данных производиться не будет.

Кеш Nginx в RAM (Random Access Memory)

Давайте сделаем еще один шаг вперед! В настоящее время данные нашего кеша хранятся на диске. А если мы сохраним эти данные в RAM? В нашем случае данные ответа ограничены и не имеют большого размера.

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

sudo mkdir -p /data/nginx/ramcache

Чтобы смонтировать созданный каталог в RAM с помощью tmpfs, используйте команду:

sudo mount -t tmpfs -o size=256M tmpfs /data/nginx/ramcache

Это монтирует /data/nginx/ramcache в RAM, выделяя 256 МБ.

Если вы считаете, что хотите отключить RAM-кеш, просто выполните команду:

sudo umount /data/nginx/ramcache

Чтобы автоматически пересоздать каталог кеша в RAM после перезагрузки, нам нужно обновить файл /etc/fstab. Добавьте в него следующую строку:

tmpfs /data/nginx/ramcache tmpfs defaults,size=256M 0 0

Примечание: Также мы должны прописать значение proxy_cache_path с указанием пути до ramcache (/data/nginx/ramcache).

После обновления конфигурации мы снова провели нагрузочное тестирование API и получили следующий результат:

Running 20s test @ http://api.endpoint/resource
  20 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.57ms    5.69ms 277.76ms   92.94%
    Req/Sec     1.98k   403.94     4.55k    71.77%
  789306 requests in 20.04s, 733.89MB read
Requests/sec:  39387.13
Transfer/sec:     36.62MB

Хранение кеша в оперативной памяти привело к значительному улучшению почти в 23 раза.

Журнал буферизованного доступа

Мы храним журнал доступа к проксированным приложениям, но можно сначала сохранить журнал в буфере и только потом записать на диск:

  • если следующая строка лога не помещается в буфер

  • если данные в буфере старше, чем указано в параметре flush.

Эта процедура уменьшит частоту записи, выполняемую с каждым запросом. Для этого нам просто нужно добавить параметры buffer и flush с соответствующим значением в директиве access_log:

location / {
    ...
    access_log /var/log/nginx/fast_api.log combined buffer=256k flush=10s;
    error_log /var/log/nginx/fast_api.err.log;
}

Буферный журнал перед записью на диск

Таким образом, согласно приведенной выше конфигурации, изначально журналы доступа будут записываться в буфер и сохраняться на диск только тогда, когда размер буфера достигнет 256 КБ или буферизованные данные станут старше 10 секунд.

Примечание: Здесь объединено имя log_format.

После повторного нагрузочного тестирования мы получили следующий результат:

Running 20s test @ http://api.endpoint/resource
  20 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.21ms    3.19ms  84.83ms   83.84%
    Req/Sec     2.53k   379.87     6.02k    77.05%
  1009771 requests in 20.03s, 849.31MB read
Requests/sec:  50413.44
Transfer/sec:     42.40MB

Такая конфигурация значительно увеличила количество запросов в секунду, примерно в 30 раз по сравнению с начальным этапом.

Вывод

В этой статье мы обсудили процесс оптимизации конфигурации Nginx для улучшения показателей RPS. Показатели RPS были увеличены с 1663 до ~ 50413 (увеличение примерно в 30 раз), это обеспечивает высокую пропускную способность. Благодаря настройке стандартных параметров можно улучшить производительность системы.

Закончим статью цитатой:

Сначала сделай так, чтобы работало. Потом сделай правильно. Затем оптимизируй. — Кент Бек

Источники

Команды Nginx, которые вы должны знать

Nginx произносится как «engine x» – это бесплатный высокопроизводительный HTTP и обратный прокси-сервер с открытым исходным кодом, отвечающий за загрузку некоторых из крупнейших сайтов в Интернете. Он может использоваться как автономный веб-сервер и как обратный прокси-сервер для Apache и других веб-серверов.

Если вы разработчик или системный администратор, скорее всего, вы имеете дело с Nginx на регулярной основе.

В этой статье мы рассмотрим наиболее важные и часто используемые команды Nginx, включая запуск, остановку и перезапуск Nginx.

 

Все команды должны быть выполнены от имени пользователя sudo или root и должны работать в любом современном дистрибутиве Linux, таком как Ubuntu 18.04 и CentOS 7 и Debian 9.

 

Запуск Nginx довольно прост. Просто запустите следующую команду:

sudo systemctl start nginx

 

В случае успеха команда не выдает никаких результатов.

Если вы используете дистрибутив Linux без systemd для запуска типа Nginx:

sudo service start nginx

 

Вместо того, чтобы вручную запускать службу Nginx, рекомендуется настроить ее на запуск при загрузке системы:

sudo systemctl enable nginx

 

Stop Nginx быстро остановит все рабочие процессы Nginx, даже если есть открытые соединения.

Чтобы остановить Nginx, выполните одну из следующих команд:

sudo systemctl stop nginx
sudo service stop nginx

 

Параметр restart – это быстрый способ остановить и запустить сервер Nginx.

Используйте одну из следующих команд для перезапуска Nginx:

sudo systemctl restart nginx
sudo service restart nginx

 

Это команда, которую вы, вероятно, будете использовать чаще всего.

 

Вам необходимо перезапустить Nginx всякий раз, когда вы вносите изменения в его конфигурацию.

Опция перезагрузки загрузит новую конфигурацию, запустит новые рабочие процессы с новой конфигурацией и корректно завершит работу старых рабочих процессов.

Чтобы перезагрузить Nginx, используйте одну из следующих команд:

sudo systemctl reload nginx
sudo service reload nginx

 

Всякий раз, когда вы вносите изменения в файл конфигурации сервера Nginx, рекомендуется проверить конфигурацию перед перезапуском или перезагрузкой службы.

Используйте следующую команду для проверки конфигурации Nginx на наличие любых синтаксических или системных ошибок:

sudo nginx -t

 

Вывод будет выглядеть примерно так.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

 

Если есть какие-либо ошибки, команда напечатает подробное сообщение.

 

Чтобы проверить состояние службы Nginx, используйте следующую команду:

sudo systemctl status nginx

 

Вывод будет выглядеть примерно так:

 * nginx.service - nginx - high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)                                                                        
  Drop-In: /etc/systemd/system/nginx.service.d                                                                                                                
           `-nofile.conf                                                                                                                                      
   Active: active (running) since Mon 2019-04-22 10:21:22 MSK; 10h ago
     Docs: http://nginx.org/en/docs/                                                                                                                          
  Process: 1113 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)                                                            
 Main PID: 1183 (nginx)                                                                                                                                       
    Tasks: 4                                                                                                                                                  
   Memory: 63.1M                                                                                                                                              
      CPU: 3min 31.529s                                                                                                                                       
   CGroup: /system.slice/nginx.service                                                                                                                        
           |-1183 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con                                                                               
           |-1184 nginx: worker process                                                                                                                       
           |-1185 nginx: worker process                                                                                                                       
           `-1186 nginx: worker processs

 

Иногда вам может понадобиться узнать версию вашего Nginx, чтобы вы могли отладить проблему или определить, доступна ли определенная функция.

Вы можете проверить свою версию Nginx, запустив:

sudo nginx -v
nginx version: nginx/1.14.0 (Ubuntu)

 

Вариант -V будет выводить версию Nginx вместе с возможностью конфигурирования.

sudo nginx -V

 

В этой статье мы показали вам некоторые из наиболее важных команд Nginx. Если вы хотите узнать больше о командной строке Nginx, посетите документацию Nginx

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Настройка nginx / Хабр

Тема правильной настройки nginx очень велика, и, боюсь, в рамки одной статьи на хабре никак не помещается. В этом тексте я постарался рассказать про общую структуру конфига, более интересные мелочи и частности, возможно, будут позже. 🙂

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html. Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. 🙂


Начнём с общих настроек. Сначала укажем пользователя, от имени которого будет работать nginx (от рута работать плохо, все знают 🙂 )

user nobody;


Теперь скажем nginx-у, какое количество рабочих процессов породить. Обычно, хорошим выбором бывает число процессов, равное числу процессорных ядер в вашем сервере, но с этой настройкой имеет смысл поэкспериментировать. Если ожидается высокая нагрузка на жёсткий диск, можно сделать по процессу на каждый физический жёсткий диск, поскольку вся работа будет всё-равно ограничена его производительностью.

worker_processes 2;


Уточним, куда писать логи ошибок. Потом, для отдельных виртуальных серверов, этот параметр можно переопределить, так что в этот лог будут сыпаться только «глобальные» ошибки, например, связанные со стартом сервера.

error_log /spool/logs/nginx/nginx.error_log notice; # уровень уведомлений "notice", конечно, можно менять


Теперь идёт очень интересная секция «events». В ней можно задать максимальное количество соединений, которые одновременно будет обрабатывать один процесс-воркер, и метод, который будет использоваться для получения асинхронных уведомлений о событиях в ОС. Конечно же, можно выбрать только те методы, которые доступны на вашей ОС и были включены при компиляции.

Эти параметры могут оказать значительное влияние на производительность вашего сервера. Их надо подбирать индивидуально, в зависимости от ОС и железа. Я могу привести только несколько общих правил.

Модули работы с событиями:

— select и poll обычно медленнее и довольно сильно нагружают процессор, зато доступны практически везде, и работают практически всегда;

— kqueue и epoll — более эффективны, но доступны только во FreeBSD и Linux 2.6, соответственно;

— rtsig — довольно эффективный метод, и поддерживается даже очень старыми линуксами, но может вызывать проблемы при большом числе подключений;

— /dev/poll — насколько мне известно, работает в несколько более экзотических системах, типа соляриса, и в нём довольно эффективен;

Параметр worker_connections:

— Общее максимальное количество обслуживаемых клиентов будет равно worker_processes * worker_connections;

— Иногда могут сработать в положительную сторону даже самые экстремальные значения, вроде 128 процессов, по 128 коннектов на процесс, или 1 процесса, но с параметром worker_connections=16384. В последнем случае, впрочем, скорее всего понадобится тюнить ОС.

events {

worker_connections 2048;

use kqueue; # У нас BSD :)

}


Следующая секция — самая большая, и содержит самое интересное. Это описание виртуальных серверов, и некоторых параметров, общих для них всех. Я опущу стандартные настройки, которые есть в каждом конфиге, типа путей к логам.

http {

# Весь код ниже будет внутри этой секции %)

# ...

}


Внутри этой секции могут находиться несколько довольно интересных параметров.

Системный вызов sendfile появился в Linux относительно недавно. Он позволяет отправить данные в сеть, минуя этап их копирования в адресное пространство приложения. Во многих случаях это существенно повышает производительность сервера, так что параметр sendfile лучше всегда включать.

sendfile on;


Параметр keepalive_timeout отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Обдумайте, как именно на вашем сайте посылаются запросы, и исправьте этот параметр. Для сайтов, активно использующих AJAX, соединение лучше держать подольше, для статических страничек, которые пользователи будут долго читать, соединение лучше разрывать пораньше. Учтите, что поддерживая неактивное keepalive-соединение, вы занимаете коннекшн, который мог бы использоваться по-другому. 🙂

keepalive_timeout 15;


Отдельно стоит выделить настройки проксирования nginx. Чаще всего, nginx используется именно как сервер-прокси, соответственно они имеют довольно большое значение. В частности, размер буфера для проксируемых запросов имеет смысл устанавливать не менее, чем ожидаемый размер ответа от сервера-бэкенда. При медленных (или, наоборот, очень быстрых) бэкендах, имеет смысл изменить таймауты ожидания ответа от бэкенда. Помните, чем больше эти таймауты, тем дольше будут ждать ответа ваши пользователе, при тормозах бэкенда.

proxy_buffers 8 64k;

proxy_intercept_errors on;

proxy_connect_timeout 1s;

proxy_read_timeout 3s;

proxy_send_timeout 3s;


Небольшой трюк. В случае, если nginx обслуживает более чем один виртуальный хост, имеет смысл создать «виртуальный хост по-умолчанию», который будет обрабатывать запросы в тех случаях, когда сервер не сможет найти другой альтернативы по заголовку Host в запросе клиента.

# default virtual host

server {

listen 80 default;

server_name localhost;

deny all;

}


Далее может следовать одна (или несколько) секций «server». В каждой из них описывается виртуальный хост (чаще всего, name-based). Для владельцев множества сайтов на одном хостинге, или для хостеров здесь может быть что-то, типа директивы

include /spool/users/nginx/*.conf;


Остальные, скорее всего опишут свой виртуальный хост прямо в основном конфиге.

server {

listen 80;

# Обратите внимание, в директиве server_name можно указать несколько имён одновременно.

server_name myserver.ru myserver.com;

access_log /spool/logs/nginx/myserver.access_log timed;

error_log /spool/logs/nginx/myserver.error_log warn;

# …

Установим кодировку для отдачи по-умолчанию.

charset utf-8;


И скажем, что мы не хотим принимать от клиентов запросы, длиной более чем 1 мегабайт.

client_max_body_size 1m;


Включим для сервера SSI и попросим для SSI-переменных резервировать не более 1 килобайта.

ssi on;

ssi_value_length 1024;


И, наконец, опишем два локейшна, один из которых будет вести на бэкенд, к апачу, запущенному на порту 9999, а второй отдавать статические картинки с локальной файловой системы. Для двух локейшнов это малоосмысленно, но для большего их числа имеет смысл также сразу определить переменную, в которой будет храниться корневой каталог сервера, и потом использовать её в описаниях локаций.

set $www_root "/data/myserver/root";

location / {

proxy_pass 127.0.0.1:9999;

proxy_set_header X-Real-IP $remote_addr;

proxy_intercept_errors off;

proxy_read_timeout 5s; # Обратите внимание, здесь мы переопределили глобальную настройку, заданную выше

proxy_send_timeout 3s;

# …

Отдельный блок в корневом локейшне посвящён компрессии получаемого результата в gzip. Это позволит вам, и вашим пользователям сэкономить на трафике. Nginx можно указать, какие типы файлов (или, в нашем случае, ответов от бэкенда) стоит сжимать, и каким должен быть минимальный размер файла для того, чтобы использовать сжатие.

# ...

gzip on;

gzip_min_length 1024;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain application/xml;

}

location /i/ {

root $www_root/static/;

}

}

Всем спасибо за внимание. И, сорри, что пост получился довольно длинным.

тестовый файл конфигурации Nginx с использованием реального nginx.conf

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

.

vagrant — nginx: файл конфигурации /etc/nginx/nginx.conf не прошел тест (хост не найден в восходящем потоке)

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

.

9 популярных команд Nginx, которые вы должны знать

Обновлено 4 октября 2018 г.

Nginx — один из самых популярных веб-серверов в мире. Так что независимо от того, используете вы его в настоящее время или нет, скорее всего, если вы веб-разработчик, скорее всего, вы в какой-то момент столкнетесь с ним. Поэтому есть несколько важных команд Nginx, о которых вы должны знать, чтобы познакомиться с основами этого веб-сервера.

В этом руководстве мы рассмотрим, что такое эти популярные команды Nginx, как их использовать и что делает каждая из них.

Популярные команды Nginx

Обратитесь к следующему списку популярных команд, если вам когда-нибудь понадобится быстрое напоминание о том, как использовать определенную команду или что она делает. Помните, что если вы не являетесь пользователем root, вам потребуется sudo для каждой команды, чтобы они работали правильно.

Запустить Nginx

Запустить Nginx очень просто. Просто используйте следующую команду:

  service nginx start

Если вы используете версию на базе systemd, например Ubuntu Linux 16.04 LTS и выше, используйте systemctl в команде, например:

  systemctl start nginx

Пример ответа: 

  Запуск сервера nginx ...

Остановить Nginx

Остановка Nginx быстро завершит работу всех системных процессов. Это завершит работу Nginx, даже если есть открытые соединения. Для этого выполните одну из следующих команд:

  service nginx stop
systemctl остановить nginx

Пример ответа: 

  Остановка сервера nginx...

Однако эта команда может занять некоторое время на загруженных серверах. Поэтому, если вы хотите, чтобы Nginx останавливался еще быстрее, вы также можете использовать:

  killall -9 nginx

Выйти из Nginx

Выход из Nginx очень похож на его остановку, но делает это аккуратно, что означает, что он завершит обслуживание открытых соединений перед завершением работы. Чтобы выйти из Nginx, используйте одну из следующих команд:

  service nginx quit
systemctl выйти из nginx

Перезапуск Nginx

Перезапуск Nginx в основном выполняет остановку, а затем запуск.Используйте одну из следующих команд для перезапуска Nginx:

  service nginx restart
systemctl перезапустить nginx

Пример ответа: 

  Остановка сервера nginx ... [OK]
Запуск сервера nginx ... [OK]

Reload Nginx

Reload немного отличается от перезагрузки тем, что, опять же, более изящно. Согласно Nginx, перезагрузка определяется как «запуск нового рабочего процесса с новой конфигурацией, корректное завершение работы старых рабочих процессов.». Вы можете перезагрузить Nginx, используя одну из следующих команд:

  service nginx reload
systemctl перезагрузить nginx

Пример ответа: 

  Перезагрузка сервера nginx ... [OK]

Просмотр статуса сервера

Проверьте текущий статус вашего веб-сервера Nginx с помощью одной из следующих команд:

  service nginx status
systemctl статус nginx

Пример ответа: 

  nginx работает

Тестовая конфигурация Nginx

Вы можете протестировать файл конфигурации вашего сервера Nginx перед его перезапуском или полной перезагрузкой.Это помогает предотвратить любые непредвиденные ошибки, которые могут привести к ухудшению работы вашего сайта. Для этого можно использовать две отдельные команды, обе возвращают одинаковую информацию:

  nginx -t

Или используйте одно из следующих:

  service nginx configtest
systemctl config nginx

Пример ответа: 

  nginx: синтаксис файла конфигурации /etc/nginx-sp/nginx.conf в порядке
nginx: файл конфигурации / etc / nginx-sp / nginx.conf тест прошел успешно

Проверить версию Nginx

Есть также два разных способа проверить версию Nginx. Оба они довольно похожи, но один показывает немного больше информации, чем другой. Используйте одну из следующих команд Nginx для печати версии Nginx:

  service nginx -v
systemctl -v nginx

Используйте следующую команду, чтобы распечатать версию Nginx, версию компилятора и настроить параметры.

  сервис nginx -V
systemctl -V nginx

Показать справку по командам

Если вы хотите получить краткое справочное руководство по командам, доступным непосредственно из терминала, используйте одну из следующих команд справки:

  service nginx -h
systemctl -h nginx

Или:

  service nginx -?
systemctl -? nginx

Резюме

Эти команды Nginx, показанные в этой статье, являются одними из самых популярных.Есть еще несколько параметров, но они почти не используются. Обращайтесь к этому руководству всякий раз, когда вы застряли в команде Nginx, и, надеюсь, вы найдете ту, которая вам нужна.

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *