VPS сервер под Debian: анализ проблем и оптимизация настроек

Список разделов

• Утилиты и способы диагностики проблем:
  • Нагрузка на процессор,
  • Свободная оперативная память,
  • Использование дискового пространства,
  • Пакет sysstat,
  • Трафик,
  • Логи,
  • Apache:
    • Логи,
    • Время обработки запроса,
    • Страница статуса,
  • Nginx:
    • Логи,
    • Страница статуса,
  • MySQL:
    • Логи,
    • mytop,
    • Mysqltuner,
  • Запись состояния сервера,
  • Отладка скриптов:
    • Медленные запросы MySQL,
    • Время выполнения скриптов PHP,
    • Дебаггинг,
    • Профилирование,
• Проблемные ситуации,
• Описание ситуаций,
• Оптимизация VDS,
• Описание оптимизаций.

К сожалению, при эксплуатации серверов, так же, как и любых других компьютеров, неизбежно возникают проблемы того или иного рода. Особенно это заметно при эксплуатации VDS-серверов, так как зачастую они обладают ограниченными ресурсами. Если не учитывать этот момент в настройке VDS, то могут возникать ситуации при которых один из ресурсов будет исчерпан и сервер перестанет работать так, как должен.

Для начала рассмотрим полезные утилиты и методы диагностики тех или иных проблем. Затем взглянем на возможные проблемные ситуации более детально. Все технические детали относятся к дистрибутиву Debian.

Нагрузка на процессор

Чтобы прикинуть ситуацию на сервере прежде всего стоит воспользоваться утилитой top, или atop, если он установлен.

В top видна информация по аптайму, нагрузке на процессор и использованию оперативной памяти. Также видна статистика по запущенным процессам. Утилита atop более информативна, однако ее нужно предварительно установить.

Быстро узнать LA можно с помощью команды uptime.

LA - параметр характеризующий общую нагрузку на систему. Приблизительно можно считать, что LA равный (или менее) количеству процессорных ядер является нормальным.

Свободная оперативная память

Быстро получить информацию по использованию оперативной памяти можно командой free -m (-m - отображать в мегабайтах):

#free -m
             total       used       free     shared    buffers     cached
Mem:          3439        890       2548          0        181        227
-/+ buffers/cache:        481       2958
Swap:         4729          0       4729

Использование дискового пространства

Статистика по смонтированным файловым системам доступна по команде df -h:

Filesystem                           Size  Used Avail Use% Mounted on
rootfs                                97G  5.0G   87G   6% /
udev                                  10M     0   10M   0% /dev
tmpfs                                344M  6.6M  338M   2% /run
tmpfs                                5.0M     0  5.0M   0% /run/lock

Чтобы узнать сколько занимает директория, нужно перейти в неё и выполнить команду du -hs (s - суммарно). Если же требуется узнать информацию о каждой поддиректории, то используйте следующий вариант: du -h --max-depth=1, где 1 - уровень вложенности.

# du -h --max-depth=1
197M ./bin
129M ./local
22M ./include
354M ./lib
4.0K ./src
6.3M ./lib32
30M ./sbin
379M ./share
1.1G .

Если начать проверку с корневой директории, то можно выявить самые тяжёлые директории.

Также существует утилита ncdu, которая позволяет просканировать все вложенные директории и построить топ по самым тяжёлым с возможностью заходить в них и смотреть информацию по поддиректориям. Очень удобно, но в случае большой вложенности и большого количества файлов для получения результата придётся подождать.

Пакет sysstat

vmstat отображает информацию об использовании памяти, раздела подкачки, дисков, процессора с заданной периодичностью заданное количество раз (опционально).

# vmstat 2 5 -S M
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so bi bo   in   cs us sy id wa
0  0   0      2081    271    357    0    0  1 10   45    4  3  1 95  0
0  0   0      2081    271    357    0    0  0  0  458  307  5  1 94  0
0  0   0      2081    271    357    0    0  0  0  625  346 19  9 73  0
0  0   0      2081    271    357    0    0  0 30  542  309  5  1 93  1
0  0   0      2081    271    357    0    0  0  0  447  280  4  1 95  0

В команде первая цифра задаёт периодичность, вторая - количество проверок. Параметр -S позволяет задать в каких единицах отображать информацию об использовании памяти, в данном случае - в мегабайтах.

mpstat позволяет просмотреть информацию по использованию процессора как суммарно, так и для отдельных процессоров (ядер), как с заданной периодичностью, так и единожды.

# mpstat 2 2 -P ALL
Linux 3.2.0-4-amd64 (debgate)     10/30/2013     _x86_64_    (2 CPU)

10:02:25 AM  CPU %usr   %nice %sys %iowait %irq   %soft  %steal  %guest   %idle
10:02:27 AM  all 5.30    0.00 0.51    0.00 0.00    0.00    0.00    0.00   94.19
10:02:27 AM    0 8.59    0.00 1.01    0.00 0.00    0.51    0.00    0.00   89.90
10:02:27 AM    1 2.00    0.00 0.00    0.00 0.00    0.00    0.00    0.00   98.00

10:02:27 AM  CPU %usr   %nice %sys %iowait %irq   %soft  %steal  %guest   %idle
10:02:29 AM  all 4.02    0.00 0.25    0.75 0.00    0.25    0.00    0.00   94.72
10:02:29 AM    0 6.63    0.00 0.51    1.02 0.00    0.00    0.00    0.00   91.84
10:02:29 AM    1 1.01    0.00 0.00    0.00 0.00    0.00    0.00    0.00   98.99

Average:  CPU %usr   %nice %sys %iowait %irq   %soft  %steal  %guest   %idle
Average:  all 4.66    0.00 0.38    0.38 0.00    0.13    0.00    0.00   94.46
Average:    0 7.61    0.00 0.76    0.51 0.00    0.25    0.00    0.00   90.86
Average:    1 1.51    0.00 0.00    0.00 0.00    0.00    0.00    0.00   98.49

Параметр -P ALL как бы намекает, что нужно отображать информацию по процессорам (ядрам) в отдельности, иначе будут показаны только суммарные значения. В случае, если не задать периодичность, то информация отобразится только один раз.

iostat - утилита для мониторинга использования дисков. Отображает информацию о том, сколько данных было передано и с какой скоростью идёт считывание. Первая строка отображает данные с момента перезапуска системы, остальные - с момента вывода предыдущей строки.

# iostat 2 5 -dhkz
Linux 3.2.0-4-amd64 (debgate)   01.11.2013   _x86_64_     (2 CPU)

Device:         tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda
               0,81      3,58      5,91  276896  457728

Device:         tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda
               0,50      0,00      2,00       0       4

Параметр -d позволяет выводить только данные по дисковой подсистеме, иначе выводится также информация по процессору. -h - позволяет отображать данные в человекопонятном виде, -k - значения будут выведены в килобайтах, -z - ничего не отображать, если ничего не изменилось.

pidstat позволяет узнать большое количество информации по запущенному процессу, такой как утилизация процессора, потребление памяти, использование диска и прочую. Можно получать информацию как об одном, так и о нескольких процессах:

# pidstat 1 -p 24219 -p 24130
Linux 3.2.0-4-amd64 (debgate)  07/26/2014  _x86_64_ (2 CPU)

03:48:40 AM       PID    %usr %system  %guest    %CPU   CPU  Command
03:48:41 AM     24219    2.00    0.00    0.00    2.00     1  apache2
03:48:41 AM     24130    0.00    0.00    0.00    0.00     0  apache2

В данном случае отображается информация об использовании процессора двумя указанными процессами раз в секунду. Можно задать количество и периодичность запросов для каждого процесса в отдельности.

Дополнительную информацию можно получить на сайте разработчика: http://sebastien.godard.pagesperso-orange.fr/documentation.html

Трафик

Для мониторинга соединений в режиме реального времени можно использовать утилиту iftop (устанавливается отдельно). Чтобы отключить преобразование адресов в доменные имена нужно нажать n, чтобы включить отображение портов - p. Также отображается скорость передачи.

Вторым инструментом является утилита iptraf с псевдографическим интерфейсом (также ставится отдельно). Позволяет  в более наглядной форме просмотреть скорость соединения, а также целый набор прочей информации о сетевых соединениях.

Стоит также упомянуть о довольно простой утилите bwm-ng, которая позволяет в режиме реального времени отслеживать использование канала. iptraf и iftop также предоставляют данную информацию, но в менее наглядной форме и с бОльшим количеством подробностей.

Логи

По умолчанию в Debian логи (журналы работы) расположены в директории /var/log. Основные файлы логов:

auth.log - содержит в себе записи об авторизациях в различных системах: FTP, SSH, cron.
cron.log - информация обо всех выполненных заданиях.
daemon.log - сюда демоны пишут служебные сообщения.
debug - сюда пишутся системные сообщения и сообщения от приложений, для которых выбран уровень лога debug.
dmesg -  в этот лог пишутся сообщения выдаваемые при загрузке системы.
dpkg.log - тут собрана информация о последних установках ПО с помощью apt-get и aptitude.
kern.log - содержит сообщения выдаваемые ядром. Информация может пригодиться в случае проблем с новым, самостоятельно собранным, ядром.
messages - здесь можно найти сообщения от системных служб и приложений, которые ведут лог на уровне info. Часть информации может дублироваться с другими логами.
syslog - системный лог, может содержать информацию, которой нет в других логах.

В зависимости от ситуации можно смотреть различные логи. Хотите узнать, не пытаются ли подобрать пароль к сервису или думаете, что уже подобрали? Вам в auth.log. Что-либо не запустилось при перезапуске системы? Добро пожаловать в dmesg. Требуется определить что и когда было установлено? Обратитесь к dpkg.log. Неудачно собрали ядро и система на нем не запускается? Посмотрите содержимое kern.log. И так далее. Не забывайте, что в директории /var/log обычно содержатся файлы логов одного типа за некоторый период времени.

Apache

Логи

Логи веб-сервера Apache по умолчанию пишутся в директорию /var/log/apache2. В директории создается два файла: access.log - содержит логи доступа и error.log - содержит информацию об ошибках в работе веб-сервера и сайтов.

Логи можно проанализировать с помощью простого просмотра или конвейера из консольных команд. К примеру, мы можем построить топ IP-адресов генерирующих определённый код ответа:

cd /var/log/apache2
tail -n1000 access.log | grep " 302 " | awk '{print $1}' | sort | uniq -c | sort -g

Результат:

      1 77.66.215.97
      1 82.145.220.175
      2 207.241.226.231
      8 199.192.207.146
     29 178.154.160.29
    751 37.140.141.35

То есть мы взяли последнюю 1000 строк лог-файла access.log, выбрали строки с определенным кодом, из них вырезали только IP-адреса с которых идут запросы, отсортировали, посчитали количество уникальных адресов идущих подряд, отсортировали по количеству вхождений.

Время обработки запроса

Также полезным может оказаться запись в лог времени обработки запроса, что можно сделать создав собственный формат лога и добавив в него параметр %T. К примеру, в случае базовой установки Apache в Debian, в файле /etc/apache2/apache2.conf нужно найти строку начинающуюся с LogFormat и заканчивающуюся на combined, скопировать её в новую строку внести изменения:

• Переименовать combined в combined-time
• Перед последней кавычкой добавить следующее: CPU_TIME: %T

В результате должно получиться:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" CPU_TIME: %T" combined-time

Теперь правим файл какого-либо виртуального хоста в директории /etc/apache2/sites-available, корректируя (добавив) строку начинающуюся с CustomLog, в которой указываем путь до файла лога и указывая наш новый формат. В итоге получается строка вида:

CustomLog /var/www/logs/domain.tld-access.log combined-time

Теперь в лог будет записываться время обработки запроса в секундах. К примеру:

81.95.28.26 - - [26/Dec/2013:12:01:31 +0400] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 850 "http://gesu.su/wp-admin/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" CPU_TIME: 9

Страница статуса

Включить страницу статуса Apache можно с помощью следующих директив в конфигурационном файле:

<Location /server-status>
        AllowOverride All
        SetHandler server-status
        Order allow,deny
        Allow from 12.34.56.78 127.0.0.1
        Satisfy any
</Location>

В данном случае доступ ограничен с локального хоста и адреса 12.34.56.78, который следует заменить на используемый вами внешний IP-адрес.

На странице видна общая информация по работе веб-сервера и по обслуживаемым в настоящий момент запросам. Страницей статуса стоит пользоваться для анализа текущей ситуации на сервере.

Nginx

Логи

По умолчанию, ведётся два лога error.log и access.log в директории /var/log/nginx. Приёмы анализа аналогичны тем, которые применяются для анализа логов Apache.

Страница статуса

Nginx также позволяет получить информацию о текущем состоянии, однако более простую, чем для Apache. Фактически выводится информация только о количестве соединений.

Чтобы включить вывод данной информации необходимо внутри контекста server добавить строки:

location /nginx_status {
  stub_status on;
  access_log off;
  allow 12.34.56.78;
  deny all;
}

Где 12.34.56.78 - IP-адрес с которого разрешён доступ к статистике.

Расшифровка показателей в статистике:

• Reading - получение заголовков запросов,
• Writing - чтение тел запросов, обработка запросов и выдача результатов,
• Waiting - активных keep-alive соединений (reading + writing).

MySQL

Логи

По умолчанию, после установки MySQL в Debian информация пишется в лог /var/log/syslog

Можно задать путь до лога ошибок добавив файл /etc/mysql/my.cnf строки:

log_error = /var/log/mysql/mysql.err
log_warnings = 1

mytop

В Debian установить mytop можно командой

aptitude install mytop

Далее потребуется создать конфигурационный файл, чтобы не указывать каждый раз данные для подключения вручную. Файл создается для каждого пользователя в отдельности (~/.mytop). Содержимое файла:

user=root
pass=XXX
host=localhost
db=
delay=2
port=3306
socket=
batchmode=0
header=1
color=1
idle=1

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

Обратите внимание, что пароль пользователя root сервера баз данных указывается в открытом виде, поэтому стоит озаботиться настройкой прав, чтобы остальные пользователи не смогли прочесть содержимое файла.

Mytop позволяет посмотреть нагрузку в текущий момент, активные запросы, их состояние. Кроме того, можно убить процессы, посмотреть подробности (explain) и так далее. Информация, выдаваемая с помощью explain может пригодиться при создании индексов и совершенствовании запросов к базам.

Mysqltuner

Mysqltuner - скрипт на perl, который анализирует показатели работе MySQL-сервера, накопленные за период времени и выдаёт статистическую информацию и рекомендации по оптимизации настроек.

Получить скрипт можно командой:

wget https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl

При использовании под Debian какие-либо настройки не требуется, при использовании, к примеру, в CentOS, может понадобиться указать данные для доступа к MySQL.

Пример вывода:

# perl mysqltuner.pl

>>  MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
>>  Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.33-0+wheezy1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1M (Tables: 82)
[--] Data in InnoDB tables: 96K (Tables: 6)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 6

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 22h 56m 26s (674K q [8.169 qps], 83K conn, TX: 483M, RX: 65M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 480.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 885.8M (25% of installed RAM)
[OK] Slow queries: 0% (0/674K)
[OK] Highest usage of available connections: 3% (6/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/640.0K
[OK] Key buffer hit rate: 99.2% (46K cached / 364 reads)
[OK] Query cache efficiency: 91.7% (311K cached / 340K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 12K sorts)
[OK] Temporary tables created on disk: 7% (118 on disk / 1K total)
[OK] Thread cache hit rate: 99% (6 created / 83K connections)
[!!] Table cache hit rate: 19% (129 open / 655 opened)
[OK] Open file limit used: 8% (212/2K)
[OK] Table locks acquired immediately: 100% (27K immediate / 27K locks)
[OK] InnoDB data size / buffer pool: 96.0K/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 1200)

Далее остается подправить конфиг MySQL (/etc/mysql/my.cnf) и перезапустить его. Затем подождать около суток, снова запустить скрипт и следуя рекомендациям внести очередные коррективы в конфигурационный файл. Следует следить за максимальным значением, которое может использовать сервер баз данных, так как большинство изменений приводит к его увеличению.

Запись состояния сервера

atop - утилита, похожая на утилиту top, но с значительно расширенным функционалом. Отображает больше различных параметров и делает это более подробно. Однако наиболее интересной функцией является возможность записи состояния сервера с определённой периодичностью, что позволяет восстановить ситуацию на сервере перед, во время и после аварии. И вообще отслеживать ситуацию на сервере.

Установка классическая:

aptitude install atop

Задать путь до директории, в которой будут храниться логи и периодичность, с которой будет записываться состояние системы, можно прямо в стартовом скрипте /etc/init.d/atop.

Просмотреть содержимое лога можно командой вида:

atop -r /var/log/atop/atop_20131231

Перемещаться по шкале времени можно с помощью t и T (shift+t).

Отладка скриптов

Медленные запросы MySQL

MySQL: индексы, EXPLAIN, прфилирование

Время выполнения скриптов php

Узнать время выполнения скрипта php можно узнать либо из лога Apache при включённом логировании времени обработки запроса, либо выполнив скрипт из консоли и воспользовавшись командой time. К примеру, команда:

time php test.php

Выдаст результат работы скрипта, после чего покажет время затраченное на его выполнение:

real 0m0.114s
user 0m0.040s
sys  0m0.036s

Если вы используете php-fpm, то можно включить лог медленных запросов по аналогии с MySQL:

slowlog = /var/log/php5/slow.log
request_slowlog_timeout = 10s

Дебаггинг

Это уже для программистов на php. Xdebug устанавливается легко:

aptitude install php5-xdebug

После чего может понадобиться дополнительная настройка в конфиге. Подробнее: http://romych.com.ua/ru_RU/blog/view/post/19

Xdebug позволяет использовать точки останова, менять значения переменных на лету, осуществлять удалённую отладку и так далее.

Профилирование

XHProf и xDebug - профилирование кода PHP

Проблемные ситуации

Конечно, все проблемы, возникающие на VDS серверах, уникальны. Однако зачастую они попадают в одну из следующих категорий:

1. Место на диске кончилось,
2. Закончилось свободное место в оперативной памяти,
3. Крайне высокая нагрузка на процессор,
4. Скачки посещаемости,
5. Спам с сервера,
6. Сервер взломали,
7. Забился канал (DoS),
8. Эксплуатация ошибок в настройках сервисов,
9. Проблемы с файловой системой.

Прочие:

1. Лёгкий пароль рута.
2. Обновление ядра пользователем.

Описание ситуаций

1. Недостаток свободного места на диске мешает нормальной работе программ. Зачастую в первую очередь перестаёт работать MySQL. Сразу увидеть проблему позволяет утилита df. Затем требуется определить какие конкретно файлы и директории занимают больше всего места. Для поиска наиболее объёмных директорий можно использовать утилиты du и ncdu. Затем для поиска наиболее крупных файлов в директории можно использовать команду ls -lS | head.

Далее требуется очистить некоторое количество места и принять меры для того, чтобы ситуация не повторилась. К примеру, настроить ротацию логов. Для восстановления нормального функционирования системы может понадобиться перезагрузка сервера.

2. В случае, если возникает недостаток оперативной памяти, то начинает использоваться swap, который находится на диске, который работает значительно медленнее и сервер начинает тормозить. В случае же острой нехватки ОП начинает работать OOM Killer (Out Of Memory Killer), который убивает наиболее тяжёлые, по его мнению, процессы, что может привести к неработоспособности программ и трудностям с их перезапуском, так как в случае их экстренного завершения на диске может оставаться pid-файл. В отдельных случаях возможно зависание сервера вследствие паники ядра.

Посмотреть информацию по ОП можно с помощью утилиты free. Узнать, был ли задействован OOM Killer, можно проанализировав лог syslog. Вообще, достаточно универсальным способом найти информацию является команда:

egrep -i 'killed process' /var/log/*

Часто проблемы с наличием свободной оперативной памяти возникают в случае активного размножения процессов веб-сервера Apache. Чтобы не допустить этого стоит чётко рассчитать сколько процессов выдержит ваш VDS и внести коррективы в настройки апача. С помощью top или ps aux узнаем сколько занимает один процесс и делим общее количество ОП (за вычетом 20% на прочие программы) на полученное значение. В итоге узнаем количество процессов и прописываем его в конфигурационном файле.

3. Проблемы с нагрузкой на процессор могут возникать, к примеру, в случае, если кто-то ведёт перебор паролей для доступа в административную часть сайта или панели управления сервером. В этом случае используется как веб-сервер, так и интерпретатор скриптов, а также сервер баз данных. Что суммарно может создавать высокую нагрузку. Информацию по использованию процессора можно получить с помощью утилит top или atop. Затем необходимо анализировать логи соответствующих программ и блокировать плохишей.

4. В случае скачков посещаемости сайтов могут наблюдаться проблемы как с нагрузкой на процессор, свободной оперативной памятью, так и с нагрузкой на дисковую подсистему и интернет-канал. То есть создаётся суммарная нагрузка. Выявить, кто генерирует нагрузку можно проанализировав логи веб-серверов. В случае, если нагрузка полезная, то необходимо экстренно предпринимать соответствующие меры. Если нагрузка полезная и запланированная, то стоит заранее провести соответствующие оптимизации. В качестве таких оптимизаций может выступать кэширование, переход на более мощный сервер, отказ от apache и прочие действия.

В случае, если скачек посещаемости вызван бесполезными ботами или DoS-атакой с небольшого количества IP-адресов, то доступ с них можно закрыть либо на файрволе, либо с помощью блокировки на уровне веб-сервера nginx. Nginx можно свободно использовать в качестве веб-файрвола, так как он достаточно легковесен и способен выдерживать значительные нагрузки.

5. Если вы по глупости все ещё используете Joomla 1.5 и ваш сайт взломали и начали использовать для рассылки спама с него, то SMTP-сервер также может генерировать значительную нагрузку, в зависимости от его настроек. Отследить это можно по очереди почтового сервера либо с помощью мониторинга утилитой atop. В логе будут видны моменты, когда было слишком много одновременных процессов SMTP-сервера.

6. Если ваш сервер взломали, то это можно увидеть по логу авторизаций - есть успешные подключения по ssh со сторонних  IP-адресов. Кроме того, при просмотре запущенных процессов можно увидеть подозрительные и непонятные, которые вы не запускали. Можно попробовать просканировать сервер с помощью clamav и rkhanter. Найденные гадости удалить. Однако наилучшим вариантом будет полная переустановка операционной системы. В любом случае требуется изменить пароль пользователя root.

Никогда не ставьте слишком лёгкий пароль пользователя root. Был случай, когда для пользователя root был установлен пароль root. Не делайте так никогда.

7. Если ваш сервер DDoS-ят так сильно, что к нему не подключиться, то, скорее всего, провайдер заблокирует ваш IP-адрес до момента окончания атаки. В любом случае что-то можно сделать только в обход основного интеренет-канала, то есть с помощью VNC-подключения к консоли. В данной ситуации обратитесь за помощью к вашему хостинг-провайдеру.

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

8. Как показывает практика, злоумышленники могут эксплуатировать не правильно настроенные программы, установленные на VPS-серверах. В том числе, это могут быть и предустановленные программы. Особо стоит выделить DNS и NTP - серверы. Если вы не планируете использовать собственные DNS-серверы, то соответствующее ПО лучше отключить совсем или даже удалить. В случае, если вы используете свои DNS-серверы, то отключите возможность рекурсивных ответов или установите ПО, которое их не поддерживает.

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

9. Ещё одной проблемой могут быть неполадки в работе файловой системы. Они могут как накапливаться, так и возникать в случае экстренного отключения вашего VDS, к примеру, в случае неполадок в работе головного сервера или проблем с электричеством в дата-центре. Некоторые проблемы могут быть обнаружены при анализе лога kernel.log. Другие - экспериментальным путём, например, в случае, если ваш сервер не загружается после перезагрузки VPS. Если у вас нет VNC-доступа, то в подобной ситуации стоит обратиться в техническую поддержку хостинга.

Оптимизация VDS

Часто VDS-серверы предоставляются с базовыми настройками, которые далеки от оптимальных. К примеру, установлен только Apache с некими стандартными настройками. В таком случае может возникать избыточная нагрузка на процессор и на оперативную память, которую можно избежать.

Общие предложения для оптимизации настроек:

1. Установка проксирующего веб-сервера Nginx,
2. Установка opcode-кэшера для php,
3. Оптимизация настроек Apache,
4. Оптимизация настроек MySQL.

Дополнительно:

1. Настройка связки Nginx + php-fpm и удаление Apache,
2. Использование различных уровней кэширования: на уровне движка сайта, opcode-кэшера, веб-сервера nginx,
3. Настройка собственных скоростных DNS-серверов,
4. Оптимизация запросов к базе данных,
5. Оптимизация кода сайта.

Описание оптимизаций

1. Установка Nginx и соответствующая настройка позволяет снизить количество обращений к Apache, тем самым снизив потребление оперативной памяти и нагрузку на процессор. То есть настраивать следует так, чтобы Nginx выдавал статику самостоятельно, в то время как к Apache поступали запросы только на обработку скриптов.

2. Рекомендуется использовать OPCache для кэширования php-скриптов и APCu для пользовательского кэширования. Либо можно установить xCache, который может и то, и другое. Кэширование опкода позволяет не компилировать повторно одни и те же скрипты, что значительно повышает скорость их выполнения при повторном обращении.

Чтобы установить OPCache и APCu в Debian вам понадобиться модуль php-pear:

aptitude install php-pear

После чего можно будет установить необходимые модули с помощью команд:

aptitude install libpcre3-dev
pecl install zendopcache-7.0.3 apcu-4.0.6

3. Оптимизация настроек Apache заключается, в основном, в отключении не нужных модулей, которые дополнительно потребляют ОП в расчёте на один процесс, а также установка лимита на максимально возможное количество параллельных процессов, что позволяет не допустить недостатка оперативной памяти в случае скачков посещаемости.

4. Дополнительный тюнинг настроек MySQL позволяет как оптимизировать потребление оперативной памяти, так и ощутимо повысить производительность. Для этого можно использовать MySQLTuner, речь о котором уже шла выше.

Про дополнительные оптимизации здесь говорить не будем, так как каждая из них требует отдельной статьи.

Если у вас возникли вопросы или дополнения, добро пожаловать в комментарии.

Наверх

Опубликовано 22 August 2014