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

[Sunday]

Вот такой дикий LA у меня:

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

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

 

[stooper]

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

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

Спойлер: для php-fpm:

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

Спойлер: для nginx:

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;

Спойлер: для sysctl:

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]

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

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

 

[stooper]

Посоветуйте, что делать в этом случае? Есть варианты оптимизации какой-то или только замена диска, raid и всё такое? Сейчас просто один HDD и всё.

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

 

[Sunday]

вряд ли это логи

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

 

[stooper]

А это они.

кто бы мог подумать

Это конечно круто, но логи же нужны. У меня access_log за сутки разрастается более чем на 1 гиг.

ага, ну тогда понятно. видимо дисочек всё таки подтормаживает, и системе не хватает пространства для записи.
ну уже хорошо, что нашли причину

И шо теперь делать? Диск менять? Ставить raid из SSD? Raid в контексте скорости даст плюсы или нет?

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

 

[Sunday]

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