Проверяем текущие показатели
Проверять текущие показатели советуем в моменты отсутствия пиковых нагрузок. Если показатели выходят за пределы нормы, то, возможно, необходимо увеличить ресурсы сервера или поменять настройки.
1. Анализируем нагрузку на процессор (CPU)
Используем утилиту top.
Набираем команду top. Получаем примерно такие значения:
Анализируем значения load average и %CPU, us, id, wa.
1. load average - состоит из трёх чисел и демонстрирует усреднённую загрузку сервера за 1, 5 и 15 минут. Чем ниже значения, тем лучше.
Простое правило: значения не должны быть больше количества процессоров.
2. %CPU - какие процессы сколько процессорных ресурсов потребляют. Значение с us в моменты отсутствия серьёзной нагрузки не должно превышать 20%, в моменты пиковой не превышать 50%. Значения выше приводят к замедлению работы сервера.
3. id - Процент времени бездействия процессора должен быть высоким, в норме - от 80.
4. wa - Ожидание операций ввода/вывода, чем ниже, тем лучше (иначе процессор слишком долго ждёт ответы от диска или сети). Значение должно быть 0 или не выше 0,2.
2. Анализируем нагрузку на память
Набираем команду free -h
Получаем примерно такие значения:
· total - общее количество памяти
· used - реально использующая и зарезервированная системой память
· free - cвободная память (total - used)
· shared - разделяемая память (быстрое средство обмена данными между процессами)
· buff/cache - буферы в памяти (страницы памяти, зарезервированные системой для выделения их процессам, когда они потребуют этого, также известна как heap-memory)
· аvailable - доступная для использования память
Для высоконагруженных серверов при отсутствии пиковой нагрузки должно быть свободно не менее 70% памяти. Стабильное превышение используемой памяти на 30% от всего обьёма свидетельствует об угрозе перегрузки сервера.
Для слабонагруженных серверов (без вероятности пиковых нагрузок) позволительно иметь стабильно низкий объём свободной памяти.
3. Проверяем пиковые нагрузки на сервер
Необходимо поставить систему мониторинга нагрузки. Рекомендуем Munin, Cacti, Zabbix.
Интерфейс Munin
Если пиковое потребление ресурсов (более 50% памяти, 60% и выше CPU) сервера стабильно возникает не менее раза в сутки, то, значит, есть угроза перегрузки или замедления работы.
В этом случае, возможно, нужно увеличить ресурсы или поменять настройки сервера.
Тестируем производительность сервера
Необходимо поставить инструмент для измерения. Мы рекомендуем sysbench (github.com/akopytov/sysbench).
Если показатели выходят за пределы рекомендуемых значений, то, возможно, необходимо увеличить ресурсы сервера или поменять настройки.
1. Проверка производительности CPU+RAM
Для этого запускаем вычисление двадцати тысяч простых чисел.
$ sysbench --test=cpu --cpu-max-prime=20000 run
Смотрим значения параметра total time.
Мы рекомендуем следующие значения:
1. Для серверов для 1С, CRM с высокой нагрузкой – не более 10 секунд.
2. Для почтовых, файловых и т.д. серверов – не более 20 секунд.
3. Для веб-серверов с высокой нагрузкой – не более 15 секунд.
Если значения выше этих, то, возможно, стоить увеличить ресурсы или поменять настройки сервера.
2. Тестируем дисковую подсистему
Необходимо:
- Создать набор тестовых файлов.
- Выполнить тестирование, снять показатели.
- Удалить тестовые файлы.
Подготовка тестовых файлов:
$ sysbench --test=fileio --file-total-size=70G prepare
Команда создаст набор файлов общим размером на 70 гигабайт. Размер должен заметно превосходить объем оперативной памяти, чтобы на результат тестирования не влиял кэш операционной системы.
Выполнение теста:
$ sysbench --test=fileio --file-total-size=70G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
Будет произведен тест в режиме случайного чтения (rndw) в течение 300 секунд, после чего будут показаны итоги.
В качестве меры производительности дисковой подсистемы можно использовать значение средней скорости передачи данных. Этот параметр должен быть в интервале от 1.5 до 2 Mb/sec.
3. Тестируем производительность баз данных
К сожалению, в рамках одного чек-листа нецелесообразно расписывать тесты для всех баз данных. Покажем, как можно протестировать MySQL.
Подготовка к тестированию:
$ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=pass prepare
Запуск теста:
$ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=pass --max-time=60 --oltp-read-only=off --max-requests=0 --num-threads=8 run
Смотрим параметр количество транзакций в секунду (transactions per sec). Для высоконагруженных серверов он должен составлять более 400 транзакций.
4. Проверяем сетевой канал
Доступную ширину канала может показать утилита iftop, запущенный с ключом -m 100M.
На скриншоте видна белая полоса — это доступная ширина канала. Не менее 50% канала должно быть доступно. Превышение на 70% уже говорит о перегрузке.
Тест сервера на распространенные ошибки
1. Программная часть регулярно обновляется? Наличие обновлений проверяются вручную?
Для корректной работы сервера обновления очень важны (убирают «дыры» в безопасности, устраняют различные ошибки в работе). Автоматические обновления не всегда устанавливаются, поэтому необходимо время от времени проверять вручную.
2. Для повседневных задач не используется пользователь root?
Использование учетной записи пользователя root для повседневной работы полностью противоречит классической модели безопасности Linux.
3. Выполняется плановое сканирование сервера на вирусы?
Это позволяет обнаружить проникновение злоумышленников.
4. Резервное копирование корректно работает? Периодически проверяете создание резервных копий?
Сбои происходят везде, даже в системе резервного копирования. Чтобы точно знать, что в запасе есть рабочая копия, регулярно проверяйте, делаются ли копии, правильно ли сохраняются, в нужном ли объеме.
5. Резервные копии хранятся в облаке или другом сервере?
Если резервные копии данных хранятся не отдельно от основных данных, то при полной потери сервере не получится ничего восстановить.
6. Кто-то регулярно просматривает ошибки по журналу логов?
Без мониторинга журнала логов можно даже не узнать о наличии каких-то проблем.
7. Действует служба мониторинга сервера?
Без службы мониторинга можно даже не знать, что временами сервер «падает». Например, при создании «бекапов».
8. Ключевые порты (SSH, FTP) изменены на нестандартные? Все лишние порты закрыты?
Хорошая защита от взлома – изменить стандартный ключевой порт.
Все неиспользуемые порты надо закрыть (найти их можно через утилиту nmap, а закрыть с помощью iptables).
9. Не используйте приложения для очистки системы или дефрагментации файловых систем?
Воспользовавшись приложениями для очистки системы, такими как Bleachbit или deborphan, вы можете удалить гораздо больше необходимых файлов, чем предполагаете.
10. Все неиспользуемые сервисы выключены?
Активные неиспользуемые сервисы забирают ресурсы сервера, повышают вероятность взлома.
11. Не используйте установочные сценарии для Linux Mint и Ubuntu?
Использование всех без исключения сторонних установочных сценариев связано с различными опасностями: некоторые из них особо опасны, другие — менее опасны.
12. Смешиваете компоненты окружения рабочего стола KDE с компонентами других рабочих столов?
В Linux Mint, Ubuntu и Fedora Workstation вы можете установить окружение рабочего стола KDE рядом с уже установленным окружением рабочего стола (таким, как Mate, Cinnamon, Unity, Xfce, LXDE или GNOME), безнадежно смешав компоненты обоих окружений рабочих столов. В результате этого резко упадет производительность и стабильность работы вашей системы.
Если вы хотите получить полноценный IT-аудит с разбором состояния вашей инфраструктуры и нашими рекомендациями, то запишитесь на бесплатную диагностическую встречу по ссылке https://ininsys.ru/audit-it-infrastruktury/.
