Что оптимизировать при большом Load Average?

Тема в разделе "Администрирование серверов", создана пользователем Sunday, 13 фев 2019.

Модераторы: mefish
  1. Sunday

    Sunday

    Регистр.:
    13 дек 2009
    Сообщения:
    799
    Симпатии:
    330
    Вот такой дикий LA у меня:

    [​IMG]

    Давно уже изучил этот вопрос, но ещё раз погуглив, нашёл в двух местах инфу, что дело может быть не только в процессоре, но и в диске и даже в канале сервера.
    Я думал изначально о процессоре, но меня смущает то, что при гигантском LA, процессор чаще всего загружен меньше, чем на 100%.
    Базы данных нет, только мемкеш. Проц больше всего грузит php-fpm, память занята только кешем. Других проектов на сервер нет. Посещалка большая.

    Как понять, что именно оптимизировать? Не хотелось бы покупать сервер втридорого и не использовать его потенциал на 100%. Хочется понять конкретную причину и делать апгрейд в этом направлении.
     
  2. stooper

    stooper

    Регистр.:
    14 апр 2006
    Сообщения:
    566
    Симпатии:
    354
    здесь нужна комплексная оптимизация. высокий LA по большей части связан с нагрузкой на процессор, т.к. создаётся очередь процессов, и чем очередь больше - тем нагрузка выше. iftop может показать утилизацию канала. но если, как вы уже говорили, php-fpm нагружает, то нужен тюнинг и php-fpm и nginx, возможно опкеш тоже поможет. Если цпу не полностью утилизируется, а очереди создаются, то можно попробовать дать больше воркеров энжинску и подкрутить пхп-фпм, и sysctl переменные увеличить, т.к. дефолтные чаще всего не предназначены для высокой нагрузки. Примерные значения, ОС CentOS. Нагрузка на nginx 20к коннектов в онлайне, на пиках до 50к.

    pm = ondemand
    pm.max_children = 10
    pm.process_idle_timeout = 60
    pm.max_requests = 1000

    worker_processes auto;
    timer_resolution 100ms;
    worker_rlimit_nofile 81920;

    use epoll;
    worker_connections 10240;
    multi_accept on;

    tcp_nopush on;
    tcp_nodelay on;
    sendfile on;

    keepalive_timeout 10;
    keepalive_requests 100;
    reset_timedout_connection on;
    client_body_timeout 10;
    send_timeout 10;

    types_hash_max_size 2048;
    client_max_body_size 1024m;
    client_body_buffer_size 128k;
    server_names_hash_bucket_size 128;
    server_names_hash_max_size 10240;

    net.ipv4.ip_forward = 0
    net.ipv4.conf.default.rp_filter = 1
    net.ipv4.conf.default.accept_source_route = 0
    kernel.sysrq = 0
    kernel.core_uses_pid = 1
    net.ipv4.tcp_syncookies = 1
    kernel.msgmnb = 65536
    kernel.msgmax = 65536
    kernel.shmmax = 68719476736
    kernel.shmall = 4294967296
    net.ipv4.tcp_max_syn_backlog = 10240
    net.ipv4.tcp_max_tw_buckets = 400000
    net.ipv4.tcp_max_orphans = 60000
    net.ipv4.tcp_synack_retries = 3
    net.ipv4.tcp_fin_timeout = 3
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.core.rmem_default = 1048576
    net.core.wmem_default = 1048576
    net.core.somaxconn = 16384
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096 65536 16777216
    net.core.netdev_max_backlog = 3000
    #net.ipv4.tcp_congestion_control = htcp #for centos 5
    #net.ipv4.tcp_congestion_control = cubic #for centos 6
    net.ipv4.ip_local_port_range = 1024 65000
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_fin_timeout = 5
    net.ipv4.neigh.default.unres_qlen = 6
    net.ipv4.neigh.default.proxy_qlen = 96
    net.ipv4.ip_nonlocal_bind = 1
    net.ipv4.tcp_keepalive_time = 30
    net.ipv4.tcp_keepalive_probes = 2
    net.ipv4.tcp_keepalive_intvl = 2
    fs.file-max = 360000
    net.ipv4.tcp_window_scaling = 0
    net.ipv4.tcp_sack = 0
    net.ipv4.conf.default.rp_filter = 1
    net.ipv4.conf.default.accept_source_route = 0
     
    Sunday нравится это.
  3. Sunday

    Sunday

    Регистр.:
    13 дек 2009
    Сообщения:
    799
    Симпатии:
    330
    @stooper, спасибо, уже успел найти зависимость. Есть прямая зависимость между нагрузкой на диск и LA. Когда нагрузка падает до нормального уровня, то LA мгновенно также приходит в норму. А когда нагрузка на диск красная, то LA тоже вырастает сильно.

    [​IMG]

    [​IMG]

    nginx больше всего загружает диск, на сколько я понял. Логи пишет или что?
    Посоветуйте, что делать в этом случае? Есть варианты оптимизации какой-то или только замена диска, raid и всё такое? Сейчас просто один HDD и всё.
     
    Последнее редактирование: 14 фев 2019
  4. stooper

    stooper

    Регистр.:
    14 апр 2006
    Сообщения:
    566
    Симпатии:
    354
    а у вас там отдаются какая ни будь статика? если отдаётся, то вынесите её тоже в кеш, в память.
    рейд в любом случае нужен, т.к. если диск умрёт, то это чревато даунтаймом. но обычно дисковая подсистема становится проблемой когда к бд обращения идут и i/o высокие. вряд ли это логи, но можно для теста их вырубить
    access_log off;
    error_log off;
    а там уже смотреть в сторону оптимизации всего стека. как то так.
    если есть возможность, и это виртуальная машина, то попробуйте её на ссд перенести.
     
    Sunday нравится это.
  5. Sunday

    Sunday

    Регистр.:
    13 дек 2009
    Сообщения:
    799
    Симпатии:
    330
    А это они. :eek:
    Ночью отключил, в течение дня всё нормально. LA слегка завышен, но не критично, очереди из процессов нет. Нагрузка на диск нормальная.
    Это конечно круто, но логи же нужны. У меня access_log за сутки разрастается более чем на 1 гиг.
    И шо теперь делать? :) Диск менять? Ставить raid из SSD? Raid в контексте скорости даст плюсы или нет?
     
    stooper нравится это.
  6. stooper

    stooper

    Регистр.:
    14 апр 2006
    Сообщения:
    566
    Симпатии:
    354
    :eek::eek::eek:
    кто бы мог подумать :D
    ага, ну тогда понятно. видимо дисочек всё таки подтормаживает, и системе не хватает пространства для записи.
    ну уже хорошо, что нашли причину :ay:
    а шо делать) тут есть 3 варианта:
    1). вынести хранение логов на другой сервер. для систем, где логи нужны, но их много, а ресурсов под них нет,
    то хорошим решением считается хранение логов на отдельном сервере, как это делают провайдеры.
    2). да, рейд даёт преимущество по скорости чтения и записи, и это даёт больше iops-ов. задача только правильно подобрать рейд)
    3). поменять диск на такой же ssd. можно даже взять PCI-E SSD, там скорости сейчас просто сумасшедшие они выдают, реально лучшая производительность гарантирована. ssd в рейд даёт преимущество, но есть нюансы, такие как пропускная способность рейд-контроллера, а так же шины, по которой он работает. может быть так, что будет стоять обычный контроллер, с пропускной 3gbps по sata - в него втыкаются ssd диски 6gbps, собираются в рейд, а толку 0, т.к. контроллер слабый и максимум 100к iops потянет, тогда туда один ssd ставится, или пара в рейд1, и норм будет. но если на 6-12gbps контроллер взять хороший, то можно играть с рейдом на шустрых ссд и всё будет хорошо, всё будет работать и будет значительный прирост по скорости. это лишь вопрос финансов))
     
    Sunday нравится это.
  7. Sunday

    Sunday

    Регистр.:
    13 дек 2009
    Сообщения:
    799
    Симпатии:
    330
    @stooper
    Как оказалось в итоге, логи были, как дополнительная нагрузка. И их отключение действительно снизило нагрузку. Но я выяснил, кто был реальный виновник торжества.
    Это fastcgi_cache в конфиге nginx. После его отключения, нагрузка вообще снизилась на столько, что даже включив все логи обратно, сервер этого даже не ощущает. И при таком раскладе сервер ещё десяток таких же проектов потянет одновременно :eek:
     
    stooper нравится это.