Як дізнатися, чи має мій nginx гарне здоров'я?

Я запускаю nginx на EC2 (m1.small) для припинення SSL.

I am using 2 workers on Ubuntu, with latest nginx (stable), the network throughput is around 2Mbps and system load average is around 2 to 3.

Мені цікаво, чи є ця система на сьогоднішній день в доброму стані,

напр.

  1. яка довжина черги (я знаю, що nginx може обробляти багато одночасних запитів, але я маю на увазі, перш ніж подається запит, скільки з них потрібно чекати, перш ніж вони подаються)
  2. середній час черги для поданого запиту.

I want to know because if my nginx is cpu bounded (напр.due to SSL), I will need to upgrade to a faster instance.

Мій поточний статус nginx

Active connections: 4076 
server accepts handled requests
 90664283 90664283 104117012 
Reading: 525 Writing: 81 Waiting: 3470 
1
Привіт, iostat -x показують лише використання CPU і Disk, але я думаю, що моє нижнє шия - це мережа.
додано Автор Henning Makholm, джерело
Пряме вивчення використання CPU/IO/RAM може виявитися більш показовим. Розглянемо висновок iostat -x . Якщо у вас є вільна пам'ять, ваша середня величина навантаження повинна визначатися процесором і IO. Якщо ви не маєте високого часу очікування io, то, ймовірно, пов'язані з процесором. (Дивіться також htop або подібне).
додано Автор Tyler Williamson, джерело
M1.small має легко обробляти 2Mbps; і вузьке місце мережі не повинно збільшувати середнє навантаження до такого рівня (m1.small має лише 1 процесор).
додано Автор Tyler Williamson, джерело

6 Відповіді

Налаштуйте плагін статусу nginx і встановіть collectd , щоб зібрати дані про продуктивність системи. Це дуже легкий демон у системних ресурсах, які він потребує. Там є плагін для моніторингу nginx: Плагін: nginx і, звичайно, collectd може контролювати всі інші дані про продуктивність системи.

Наскільки collectd - це тільки збирач даних про продуктивність (зберігає його в БД RRD), потрібний інструмент для відображення даних. Мені дуже подобається CGP ... git версія В ПОРЯДКУ. CGP - це PHP-програма, тому вона з'їсть вас процесором тільки тоді, коли ви подивитеся на графіки.

Example graph: Nginx_connections_and_requests.png

Btw Amazon EC завжди значно повільніше, ніж інші, і особливо для зберігання. Це може бути коренем вищої навантаження.

1
додано

Щоб перевірити важливі процеси введення-виведення, спробуйте встановити iotop :

apt-get install iotop

Вона вимагає підтримки вводу/виводу в ядрі, який присутній в Ubuntu 10.04 або вище.

Якщо ви виявите, що nginx пов'язаний з I/O, спробуйте перевірити, чи дійсно вам потрібна реєстрація доступу (яка може бути вузьким місцем у такій великій кількості запитів). Вимкнення журналу доступу відбувається так само просто, як:

access_log /dev/null crit;

FYI

access_log off;

не зробить (nginx запише у файл з іменем off).

Якщо вам потрібно зареєструватися, введіть політику доставки (наприклад, реєструйте журнали один раз на день і відправляйте повернене до віддаленого місця за допомогою rsync, scp або ще) і спробуйте написати в сховище примірників за замовчуванням встановлений у/mnt). Магазин екземплярів підтримується локальними дисками сервера, які можуть бути більш швидкими (хоча це не гарантовано), але їх дані втрачаються при закритті екземпляра, отже, необхідність політики доставки журналів.

1
додано

Якщо ваш вершина показує, що nginx є єдиним процесом, який споживає процесор і ваш тип екземпляра є m1.small, це, безумовно, означає, що nginx знаходиться в BAD стані. Не забудьте вимкнути стиснення gzip, а також пропоную додати патч SPDY /patches/spdy/README.txt (firefox і chrome підтримує SPDY), що значно збільшить час завантаження сторінок SSL.

0
додано

Як дізнатися, чи працює мій nginx?

Перевірте системні показники, щоб дізнатися, чи виникає вузьке місце в продуктивності, і якщо так; визначити, де вона знаходиться.

2Mbps є, безумовно, повільним для m1.small. Я отримав значно більше, ніж з моїх випадків t1.micro. Перевірте iotop і htop, щоб побачити, що робить ваша система. Схоже, що десь у вашому процесі є неприємні проблеми. Метрики CloudWatch для цього примірника та його томи також можуть допомогти.

Якщо ви запускаєте динамічні сторінки (PHP, Perl, Ruby), то може бути деякий неоптимізований код, який викликає уповільнення.

Якщо ви не бачите процесора або вузьких місць IO на хості, то проблема може бути в іншому ярусі, якщо у вас є інші системи в стеку.

Одна річ, яку слід розглянути, полягає у використанні ELB для припинення SSL (і балансування навантаження) для поширення навантаження. Вони не є надзвичайно дорогими і можуть вистачити достатньо (припускаючи, що винні SSL), щоб допомогти продуктивності дешевше, ніж переміщення вгору за розміром. Вивішування вашого сайту з ELB також дасть вам більшу гнучкість щодо того, як масштабувати та керувати сайтом.

0
додано

Оскільки ви використовуєте ec2 малий, який має тільки 1 обчислювальний блок, loadavg 2 ~ 3 занадто високий. Системні показники надаватимуть набагато більше корисної інформації, ніж ті, які ви надавали від nginx. Натомість ці показники взагалі не допомагають ...

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

https://serverfault.com/search?q=load+average

0
додано

Не відповідаю на запитання, але ...

Проблема з невеликими екземплярами EC2 полягає в тому, що у вас немає доступного 100% процесорного часу, тільки сплески. Після того, як ваш екземпляр почне постійно зайняти процесор, він стає пригніченим.

Ideally, you shouldn't be hitting loads > 2.0. Since small instances have only one CPU, any load above 1.0 means you already have half of your processes waiting for available CPU slices. A medium instance should be enough.

A good article explaining how to measure system load: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

0
додано
m1.small має послідовний amout з доступного процесора, тільки мікро-екземпляри має сплески.
додано Автор Andrei Mikhaltsov, джерело
Ви правильні Андрій, але m1.small мають поганий процесор самостійно. У мене виникли проблеми з роботою на невеликих примірниках, які раніше не використовували 10% на середніх примірниках. Будь ласка, прочитайте: axibase. com/cloud/2010/07/22/& hellip;
додано Автор codescope, джерело