Назад | Перейти на главную страницу

Сервер ubuntu nginx + apache2 разбился с несколькими сотнями посетителей

У меня есть сервер Linode 768mb RAM на Linode. И у меня есть блог Wordpress. На моем сервере установлены ubuntu, nginx в качестве внешнего интерфейса и apache2 как серверный. И у меня есть модули APC и memcache. Иногда сайт вылетает. Но загрузка процессора сервером ниже критического уровня (максимум 60-70). Однако во время сбоя сайта я могу видеть критические уровни использования ввода-вывода жесткого диска. Я читал, что это может быть связано с неправильными настройками mysql.

Мой nginx.conf:

worker_processes 2;
events {
    worker_connections  1024;
    # multi_accept on;
}
http {
    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  12;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Мой nginx proxy.conf:

proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
client_body_buffer_size 128k;
#client_header_buffer_size 64k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffer_size   16k;
proxy_buffers       32   16k;
proxy_busy_buffers_size 64k;

Конфигурация моего сайта nginx:

server {
        listen   80;
        server_name mysite.org;

        location / {
                proxy_pass  http://127.0.0.1:8080;
                include     /etc/nginx/conf.d/proxy.conf;
                root   /home/mysite/www/;
                index  index.html index.htm index.php;
        }

        location ~* ^.+\.(jpg|jpeg|cur|flv|avi|gif|png|ico|zip|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf)$ {
            root   /home/mysite/www/;
        }

        location ~* ^.+\.(htm|html|js|htc|css|tgz|gz|rar|bz2)$ {
           root   /home/mysite/www/;
           gzip_static on;
       }

My.cnf

#
# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M

Оборудование:

cpu (4x): Intel(R) Xeon(R) CPU L5520  @ 2.27GHz, 2260 MHz 
storage: Xen Virtual Storage 0, Xen Virtual Storage 1
memory: 768mb

Конфигурация Apache:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>
<IfModule mpm_worker_module>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>
<IfModule mpm_event_module>
    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Ссылки на статистику Linode: http://ridna.ua/temp/mysite_io_rate.png и http://ridna.ua/temp/mysite_cpu_rate.png

Как я могу оптимизировать настройки nginx + apache2 + mysql, чтобы избежать сбоев сайта? Спасибо..

У меня были эти проблемы, и я исправил их некоторыми настройками на apache и mysql

Ошибка "тайм-аут восходящего потока" в nginx

или

ИНФОРМАЦИЯ: задача: apache2 (или mysql, или nginx) заблокирована более 120 секунд.

эта проблема возникает, когда ваш ресурс apache используется настолько высоко и недоступен. Если mysql не отвечает быстро и задерживается при ответе на запросы, apache увеличит свои шаги, и ваша память заполнится и ... BoooOOM

ваша основная проблема связана с MYSQL, и один простой способ ее исправить - установить mysqltuner приложение и делать рекомендации, которые

вам также нужно будет настроить свой apache на втором этапе! сначала используйте "top" или что-то подобное (при интенсивном трафике на сервере) и найдите максимальный активный поток размера apache в mb. теперь вы должны передать оставшуюся часть свободной оперативной памяти сервера в apache, настроив MaxClients

например, если ваш RAM равен 12, а ваш mysql использовал 5GB RAM - и ваш максимальный протектор apache, который находит, составляет около 70 МБ, вы должны настроить MaxClients около 70 ~ 80, а остальная часть RAM будет для ОС. Это так важно, чтобы вы сконфигурировали свои службы так, чтобы они не заполняли всю доступную память при интенсивном трафике!

Вам нужно определить реальную причину дискового ввода-вывода, а не просто догадываться о ней. Первый шаг в этом - использовать исторические данные, собранные sar (если вы не установили sysstat на вашем компьютере и настроили его для сбора данных каждую минуту, сделайте это '' 'сейчас' ''). В первую очередь ищите подкачки; как используемый объем, так и входящие / исходящие страницы потенциально полезны.

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

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

Как только вы выяснили, кто преступник, вам нужно исправить это. Если MySQL действительно виноват, то да, вам нужно его настроить. Я не собираюсь вдаваться в подробные статьи о настройке MySQL, поскольку в Интернете (и на этом сайте) их уже полно. Достаточно сказать, что да, параметры MySQL по умолчанию - полная чушь, и вам всегда нужно настраивать свою БД.

Несколько общих моментов по вашей настройке:

  • Запуск nginx и Apache не нужен, расходует память и, следовательно, не поможет ни проблеме подкачки, ни общей проблеме дискового ввода-вывода (поскольку для кэширования диска будет доступно меньше памяти). Избавьтесь от Apache и запустите php-fpm (или старый добрый PHP FCGI) для обслуживания вашего динамического контента.
  • Дисковый ввод-вывод Linode, как правило, довольно плох (мы только что закончили миграцию большого клиента с Linode, отчасти потому, что доступный дисковый ввод-вывод был настолько плох, что вызывал проблемы с производительностью). Если вы действительно собираетесь осуществлять приличный объем трафика, вы должны иметь возможность позволить себе VPS более высокого класса.