На моем VDS запущены критически важные приложения. С точки зрения пользователя, мы не наблюдаем никаких видимых задержек. Однако я хочу знать, когда пришло время обновиться. Сетевая нагрузка низкая, и я не верю, что есть дисковый ввод-вывод (это SSD RAID-5) или узкие места в памяти. Это экземпляр KVM с 2 выделенными процессорами (почему Ramnode называет его VDS, а не VPS) и 8 ГБ оперативной памяти под управлением Centos 7 и установленной SugarCRM не более чем с 6 одновременными пользователями и 6 сайтами Wordpress с низким трафиком.
Так что, на мой взгляд, главное, за чем мне нужно следить, - это использование процессора. Ниже приведен заголовок команды top, и я установил событие cron для вывода информации об использовании ЦП каждые 15 минут. Я знаю, что это система с двумя процессорами и выделенным процессором, потому что это VDS на VPS. Вы так же думаете, глядя на использование ЦП с шагом 15 минут ниже, чем загрузка ЦП находится в пределах допуска для текущего экземпляра и не создает каких-либо серьезных проблем? Я склонен сосредотачиваться на втором и третьем числах, показывающих 5-минутное и 15-минутное среднее значение, так как всплеск в 1 минуту не вызывает беспокойства, или вы думаете, что VDS приближается к пределу для ЦП? Я думаю, что если 5-минутные и 15-минутные числа не превышают 3,0, тогда я в порядке? Я знаю, что есть другие инструменты (например, vmstat) и другие, которые я могу использовать, но для простой быстрой проверки достаточно ли этой информации, чтобы просто проверить очевидную перегрузку сервера?
1.81 1.35 1.61 13/448 4598
0.86 1.20 1.33 12/454 10227
3.88 1.65 1.14 11/480 15646
4.40 2.90 1.80 7/460 21584
1.76 1.37 1.49 14/443 27245
2.01 1.42 1.28 12/454 32656
3.98 1.86 1.36 9/465 5890
4.18 2.81 1.86 7/455 11599
2.57 1.68 1.58 7/453 16947
1.59 1.43 1.45 10/443 22651
наверх - 11:54:39 вверх 20 дней, 16:03, 2 пользователя, средняя загрузка: 0,67, 1,12, 1,31 Задачи: всего 156, 3 запущены, 153 спят, 0 остановлено, 0 зомби% ЦП: 41,9 мкс , 6,5 sy, 0,0 ni, 48,4 id, 3,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: всего 8010484, свободно 613228, используется 2096892, 5300364 бафф / кеш Обмен KiB: всего 1048572, бесплатно 72816, используется 975756. 4995584 avail Mem
Определение цель уровня обслуживания будет полезно для обоснования необходимости изменений. Это количественно оценивает ваше утверждение «не наблюдается видимого отставания», независимо от того, как выглядит ваша инфраструктура.
Возможно, вы хотите, чтобы 99,9% загрузки страницы составляли менее 100 мс, чтобы поддерживать восприятие адаптивного сайта. Возможно, вам понадобится точка зрения на стороне клиента, чтобы точно измерить это, например, аналитика скорости страницы.
Планирование мощностей требует некоторого размышления. Кажется, что у этого хозяина сейчас много лишних, но уловка рассчитана на будущее.
Учитывайте планируемый рост организации или ожидаемые скачки нагрузки. Узнайте обо всех ресурсах системы, например о Метод использования. Найдите основную причину событий, при которых не был достигнут целевой уровень обслуживания, и была ли это проблема с мощностью.
При необходимости составьте план по увеличению емкости. Знайте, как масштабировать или увеличивать количество экземпляров, или увеличивать их. Установите балансировщик нагрузки, прежде чем он вам понадобится для повышения производительности, и также получите высокую доступность.
Как правило, метрики уровня хоста системы UNIX / Linux с оставшейся емкостью включают:
Невозможно точно сказать, основываясь только на цифрах времени безотказной работы, но если вы действительно убедились, что диск io не является узким местом (обычно так и есть), то этот сервер работает почти на полную мощность. Я говорю это, потому что LOAD / CPU COUNT близко к 1. На самом деле это означает, что большую часть времени существует почти 1 задание (на процессор), ожидающее ресурса.
Я действительно отмечаю, что ваша система использует изрядное количество SWAP в соответствии с вашим выводом TOP, поэтому я не уверен, что ваша система ограничена процессором, а не памятью / дисковым вводом-выводом.