Какая производительность действительно нужна вашему облачному серверу?
Большинство облачных провайдеров делят свои предложения по количеству ядер ЦП и объему оперативной памяти. Вам нужен большой многоядерный сервер или их целый парк? Вот как можно измерить реальную производительность вашего сервера.
Нужно ли вашему приложению «масштабироваться»?
Технологические стартапы очень часто привлекает «масштабируемая» архитектура, то есть построение серверной архитектуры таким образом, чтобы каждый ее компонент мог масштабироваться для удовлетворения любых потребностей.
Это здорово и все такое, но если вы не сталкиваетесь с таким объемом трафика в реальном мире, создание масштабируемой архитектуры с целью масштабирования до миллиона пользователей может оказаться излишним (и более дорогим), если вы только управляете несколько тысяч.
Вы захотите отдать предпочтение созданию хорошего приложения, а не созданию исключительной инфраструктуры. Большинство приложений работают на удивление хорошо, имея лишь несколько простых в управлении стандартных серверов. И, если ваше приложение когда-либо станет большим, ваш рост, скорее всего, произойдет в течение нескольких месяцев, что даст вам достаточно времени (и денег) для работы над вашей инфраструктурой.
Тем не менее, масштабируемая архитектура по-прежнему полезна, особенно в таких сервисах, как AWS, где автомасштабирование можно использовать для уменьшения масштаба и экономии денег в непиковые часы.
Вы должны планировать пиковую нагрузку
Самое важное, о чем следует помнить, это то, что вы планируете не среднюю нагрузку, а пиковую нагрузку. Если ваши серверы не справляются с пиковой нагрузкой в полдень, они не выполнили свою задачу. Вам нужно убедиться, что вы измеряете и понимаете нагрузку вашего сервера с течением времени, а не просто смотрите на использование ЦП в один момент.
Здесь пригодится масштабируемая архитектура. Возможность быстро развернуть спотовый инстанс (что часто намного дешевле) для снятия части нагрузки с ваших основных серверов — очень хорошая парадигма проектирования, позволяющая значительно сократить расходы. В конце концов, если вам нужно всего два сервера на несколько часов в день, зачем платить за их работу в течение ночи?
У большинства крупных облачных провайдеров также есть масштабируемые решения для контейнеров, таких как Docker, которые позволяют автоматически масштабировать вещи, поскольку вашу инфраструктуру легче дублировать.
Какую производительность дает ваш сервер?
Трудно ответить точно; приложения и веб-сайты у всех разные, и серверный хостинг у всех разный. Мы не можем дать вам точный ответ, какой сервер лучше всего подходит для вашего варианта использования.
Что мы можем сделать, так это рассказать вам, как самостоятельно экспериментировать, чтобы найти то, что лучше всего подходит для вашего конкретного приложения. Это включает в себя запуск вашего приложения в реальных условиях и измерение определенных факторов, чтобы определить, перегружены ли вы или недогружены.
Если ваше приложение перегружено, вы можете запустить второй сервер и использовать балансировщик нагрузки для балансировки трафика между ними, например Elastic Load Balancer от AWS или сервис Fastly Load Balancing. Если он значительно недогружен, вы можете сэкономить несколько долларов, арендовав более дешевый сервер.
Использование процессора
Использование ЦП, вероятно, является наиболее полезной метрикой для рассмотрения. Это дает вам общее представление о том, насколько перегружен ваш сервер; если использование ЦП слишком велико, операции сервера могут остановиться.
Загрузка ЦП отображается в top, а также средние значения нагрузки за последние 1, 5 и 15 минут. Он получает эти данные из /proc/loadavg/, так что вы можете записать их в CSV-файл и при желании отобразить в Excel.
Однако у большинства облачных провайдеров для этого есть гораздо лучший график. У AWS есть CloudWatch, который отображает использование ЦП для каждого экземпляра по метрикам EC2:
Google Cloud Platform показывает хороший график на вкладке «Мониторинг» в информации об экземпляре:
На обоих графиках вы можете настроить временные шкалы для отображения загрузки ЦП с течением времени. Если этот график постоянно достигает 100%, вы можете рассмотреть возможность обновления.
Имейте в виду, однако, что если ваш сервер имеет несколько ядер, загрузка ЦП все равно может быть «перегружена», а график далеко не равен 100%. Если загрузка ЦП держится на уровне около 50 %, а у вас двухъядерный сервер, вполне вероятно, что ваше приложение в основном однопоточное и не дает никаких преимуществ в производительности.
Использование оперативной памяти
Использование ОЗУ с меньшей вероятностью будет сильно колебаться, так как в основном это вопрос того, достаточно ли у вас ее для выполнения определенной задачи.
Вы можете быстро просмотреть использование памяти в top, где отображается текущая выделенная память для каждого процесса в столбце «RES», а также отображение использования в процентах от общего объема памяти в столбце «%MEM». .
Вы можете нажать Shift + M для сортировки по %MEM, в котором перечислены процессы, наиболее интенсивно использующие память.
Обратите внимание, что скорость памяти в определенной степени влияет на скорость ЦП, но, скорее всего, не является ограничивающим фактором, если только вы не запускаете приложение, требующее «голого железа» и максимально возможной скорости.
Место для хранения
Если на вашем сервере заканчивается свободное место, это может привести к сбою определенных процессов. Вы можете проверить использование диска с помощью:
df -H
Это отображает список всех устройств, подключенных к вашему экземпляру, некоторые из которых могут быть вам бесполезны. Найдите самый большой из них (вероятно, /dev/sda1/), и вы увидите, сколько ресурсов в настоящее время используется.
Вам необходимо эффективно использовать ротацию журналов и следить за тем, чтобы в вашей системе не создавались лишние файлы. Если есть, вы можете ограничить его хранением только нескольких последних файлов. Вы можете удалить старые файлы с помощью find с параметрами времени, прикрепленными к заданию cron, которое запускается один раз в час:
0 * * * * find ~/backups/ -type f -mmin +90 -exec rm -f {} ;Этот скрипт удаляет все файлы в папке ~/backups/ старше 90 минут (используется для сервера Minecraft, который делал резервные копии размером более 1 ГБ каждые 15 минут, заполняя 16 ГБ SSD). Вы также можете использовать logrotate, который достигает того же эффекта более элегантно, чем эта наспех написанная команда.
Если вы храните массу файлов, возможно, вы захотите рассмотреть возможность их перемещения в службу управляемого хранилища, такую как S3. Это будет дешевле, чем подключение дисков к вашему экземпляру.
Скорость сети
Нет хорошего способа отслеживать это изначально, поэтому, если вы хотите получить хороший вывод командной строки, установите sar из sysstat:
sudo apt-get install sysstat
Включите его, отредактировав /etc/default/sysstat и установив для параметра ENABLED значение true.
Это отслеживает вашу систему и генерирует отчет каждые 10 минут, чередуя их один раз в день. Вы можете изменить это поведение, отредактировав crontab sysstat в /etc/cron.d/sysstat.
Вы можете собирать среднее значение сетевого трафика с помощью флага -n :
sar -n DEV 1 6
Передайте его в tail для более приятного вывода:
sar -n DEV 1 6 | tail -n3
Он отображает среднее количество пакетов и килобайт, отправленных в секунду на каждом сетевом интерфейсе.
Однако для этого проще использовать графический интерфейс; CloudWatch имеет статистику «NetworkIn» и «NetworkOut» для каждого экземпляра:
Вы можете добавить динамическую метку с помощью функции СУММ, которая отображает общий объем сети в байтах за заданный период времени.
Трудно судить, перегружаете ли вы свою сеть; в большинстве случаев вы ограничены другими вещами, например, может ли ваш сервер справляться с запросами, прежде чем беспокоиться об использовании полосы пропускания.
Если вы действительно беспокоитесь о трафике или хотите обслуживать большие файлы, вам следует подумать о приобретении CDN. CDN может снять некоторую нагрузку с вашего сервера и позволить вам очень эффективно обслуживать статические носители.