Я запускаю nginx на EC2 (m1.small) для завершения SSL.
Я использую 2 рабочих на Ubuntu, с последней версией nginx (стабильной), пропускная способность сети около 2 Мбит / с и средняя загрузка системы около 2 к 3.
Мне интересно, здорова ли сейчас эта система,
например
Я хочу знать, потому что если мой nginx ЦП ограничен (например, из-за SSL) мне нужно будет перейти на более быстрый экземпляр.
Мой текущий статус nginx
Active connections: 4076
server accepts handled requests
90664283 90664283 104117012
Reading: 525 Writing: 81 Waiting: 3470
Чтобы проверить тяжелые процессы ввода-вывода, попробуйте установить iotop:
apt-get install iotop
Это требует поддержки учета ввода-вывода внутри ядра, которое присутствует в Ubuntu 10.04 или выше.
Если вы обнаружите, что nginx привязан к вводу-выводу, попробуйте проверить, действительно ли вам нужно вести журнал доступа (что может быть узким местом при таком большом количестве запросов). Отключить журнал доступа очень просто:
access_log /dev/null crit;
К вашему сведению
access_log off;
не будет (nginx запишет в файл с именем off).
если ты необходимость ведение журнала, реализуйте политику доставки (например, logrotate журналов один раз в день и отправьте повернутые журналы в удаленное место через rsync, scp или иначе) и попробуйте записать в хранилище экземпляров (по умолчанию смонтировано в / mnt). Хранилище экземпляров поддерживается локальными дисками сервера, которые могут быть быстрее (хотя это не гарантируется), но их данные теряются при завершении работы экземпляра, отсюда и необходимость в политике доставки журналов.
Настроить nginx плагин статуса и установка собирать для сбора данных о производительности системы. Это очень легкий демон с точки зрения необходимых ему системных ресурсов. Есть плагин для мониторинга nginx: Плагин: nginx и конечно collectd может отслеживать все данные о производительности системы.
Так далеко как collectd является просто сборщиком данных о производительности (хранит их в БД RRD), необходим инструмент для отображения данных. Мне довольно комфортно с CGP... версия git в порядке. CGP это приложение PHP, поэтому оно съест ваш процессор только тогда, когда вы посмотрите на графики.
Пример графика: Nginx_connections_and_requests.png
Кстати, Amazon EC всегда был значительно медленнее, чем другие, и в первую очередь для хранения. Это могло быть причиной более высокой нагрузки.
Не совсем отвечаю на вопрос, но ...
Проблема с небольшими инстансами EC2 заключается в том, что у вас нет 100% доступного процессорного времени, только пакеты. Как только ваш экземпляр начинает постоянно загружать ЦП, он блокируется.
В идеале вы не должны достигать нагрузок> 2,0. Поскольку небольшие экземпляры имеют только один ЦП, любая загрузка выше 1.0 означает, что у вас уже есть половина ваших процессов, ожидающих доступных фрагментов ЦП. Среднего экземпляра должно хватить.
Хорошая статья, объясняющая, как измерить нагрузку на систему: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
Поскольку вы используете ec2 small, который имеет только 1 вычислительный блок, loadavg 2 ~ 3 слишком велик. Системные показатели предоставят много больше полезной информации, чем та, которую вы предоставили из nginx. Скорее, эти показатели совсем не помогают ...
Вам также может быть полезно прочитать другие вопросы, касающиеся средней нагрузки в целом, чтобы лучше понять ее значение и важность.
Как узнать, здоров ли мой nginx?
Проверьте системные метрики, чтобы увидеть, не возникает ли у вас узких мест в производительности и если да; определить, где это.
2 Мбит / с - это определенно медленно для m1.small. Я получил значительно больше от своих экземпляров t1.micro. Проверьте iotop и htop, чтобы узнать, что делает ваша система. Похоже, что где-то в вашем процессе есть неприятное узкое место. Также могут помочь показатели CloudWatch для этого экземпляра и его объемы.
Если вы используете динамические страницы (PHP, Perl, Ruby), может быть неоптимизированный код, который вызывает замедление.
Если вы не видите узких мест ЦП или ввода-вывода на хосте, проблема может быть на другом уровне, если у вас есть другие системы в стеке.
Одна вещь, которую следует учитывать, - это использование ELB для завершения SSL (и балансировки нагрузки тоже) для распределения нагрузки. Они не слишком дороги и могут разгрузить достаточно (при условии, что виноват SSL), чтобы повысить производительность, дешевле, чем увеличение размера инстанса. Отключение вашего сайта от ELB также даст вам больше гибкости в том, как масштабировать сайт и управлять им.
Если ваш топ показывает, что nginx - единственный процесс, потребляющий CPU, а тип вашего экземпляра - m1.small, это наверняка означает, что nginx находится в состоянии BAD. Обязательно отключите сжатие gzip, а также я предлагаю добавить патч SPDY http://nginx.org/patches/spdy/README.txt (Firefox и Chrome поддерживают SPDY), что значительно увеличит время загрузки страниц SSL.
