Медленный http

вырастает load average. Это похоже на атаку медленными http запросами

Нет, не похоже. Какие процессы тратят проц?

Вернула большой список подключений через 127.0.0.1 к апачу

Они все ESTABLISHED? И дели на два сразу, потому что там оба конца соединения показываются, т.е. две строки на каждое.

Ну, если остановить веб сервер то загрузка спадает, а в логах постоянно идут запросы. Из чего я и делаю вывод что оно ходит как утка и крякает как утка.

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

Они все ESTABLISHED?

Уже написав понял что забыл отметить, почти все TIME_WAIT.

Вот типичная картина:

# netstat -nalt | grep :80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8080          127.0.0.1:50652         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50570         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50764         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50906         TIME_WAIT
tcp        0      0 127.0.0.1:50826         127.0.0.1:8080          TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:51108         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50944         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:51040         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50678         TIME_WAIT
tcp        0      0 127.0.0.1:51116         127.0.0.1:8080          TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50884         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50886         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50824         TIME_WAIT
tcp        0      0 127.0.0.1:8080          127.0.0.1:50908         TIME_WAIT

Если ты имел в виду майнер, то это явно не похоже.

ты в первую ояередь ab натрави на локалхосте. мож, проблема в коде?

А что это? Вообще, сайт не мой, я только предоставляю компьютер. Он самописный и у меня в общем есть основания полагать что с ним всё в порядке.

у меня тоже так один cloudflare другой amazon но я их вообще не заказывал

$ netstat -nalt | grep :80
tcp6       0      0 :::80                   :::*                    LISTEN     
$ netstat -nalt | grep :443
tcp        0      0 192.168.43.34:49770     104.16.249.249:443      ESTABLISHED
tcp        0      0 192.168.43.34:42560     52.36.24.174:443        ESTABLISHED
tcp        0      0 192.168.43.34:33248     104.16.249.249:443      ESTABLISHED

man ab. нагрузку дай, может сам сайт и тупит.

Если я спрашиваю значит не знаю о чём речь.

# man ab
Нет справочной страницы для ab
# apt install ab
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
E: Невозможно найти пакет ab

Если гугль меня правильно понял: https://www.google.com/search?q=ab+site и это оно: https://www.optimizely.com/optimization-glossary/ab-testing/ то это для меня совершенно новая сфера в которую придётся входить, но кроме этого случая он мне не понадобится. И вообще работа сайта выглядит хорошо, а постоянные запросы с интервалом 2-3 секунды или чаще, притом что адреса в подавляющем большинстве уникальны, выглядят совершенно неестественно.

Но, независимо от работы сайта у меня вполне конкретный вопрос. Насколько я могу видеть, запросы проходят через nginx и висят на апаче. И насколько я понимаю, смысл nginx в том, чтобы медленно собирать запрос, потом быстренько передать его на бек и быстренько получив ответ так же медленно отдавать. То есть, картина должна быть зеркальной.

Соответственно хотелось бы понять, текущая картина это так и должно быть или, если нет, то как это исправить,

Наверно надо добавить что эта паразитная нагрузка не постоянна и когда этого нет то всё работает отлично.

TIME_WAIT это не нагрузка, это уже закрытые соединения. Здесь нет атаки slow http.

Перед апачем поставлен nginx

Ненужно, удоли. Это ж локалхост обыкновенный, правильно?

Спасибо. Но кто и чего ожидает? Насколько я понимаю, большое количество их съедает какой то ресурс.

Удалить не вопрос. Но мне нужно от проблемы избавиться. Всегда читал что nginx для таких примерно целей и существует.

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

Нет, не так. То что ты наблюдаешь, это просто много запросов. Ни nginx ни апач здесь не роляют. Возьми инструмент ab и сгенери те же запросы что тебе летят локально апачу. если картина не изменится, значит тупит сайт.

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

Но мне нужно от проблемы избавиться. Всегда читал что nginx для таких примерно целей и существует.

Каких «таких примерно»? Мы пока не поняли, какие примерно у тебя проблемы. Сайт жрет ресурсы при обращениях, вот тоже мне аномалия.

В общем, проблема в том, что на сервере растёт la. Настолько, что использовать его становится практически невозможно. Проблема появляется и исчезает.

При этом в логах сайта много обращений, и подавляющее большинство ip адресов в логах встречаются один раз. Мне трудно представить себе использование сайта одним запросом, поэтому я делаю вывод что это трафик паразитный. И если паразитный трафик вызывает отказ в обслуживании то это выглядит естественным, для этого он и создаётся, его задача жрать ресурсы больше положенного не затрачивая своих.

А апач сзади голую статику отдает, или там может mod_php например?

Так это и не 80, а 8080, на который ты очевидно повесил апач.

nginx принимает запрос на 80, отдает апачу на 8080 и ждет ответ по своему таймауту. Апач за это время ответ не успел отдать, nginx ждать перестал, вот и висит TIME_WAIT. Чем больше такого копится, тем в итоге и хуже, со временем.

Если и правда php, то переехал бы на php-fpm и сузил поиск.

Насколько я понял, nginx передаёт соединение и затем закрывает по таймауту, но у апача это соединение продолжает висеть. Правильно ли это и если да то как можно обучить nginx говорить апачу что соединение нужно закрыть?

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

Сайт жрет ресурсы при обращениях

Выше уже ответили.

Да, там конечно php, там довольно сложный сайт. Переводить его на nginx задачи в принципе нет. Да и я к нему отношения не имею.

Он раньше слушал 443, но чтобы закрыть его (рассчитывая на улучшение) переставил на 127.0.0.1:8080, извне его не видно. Извне отвечает nginx, по 80 порту: «спасибо, извините, до свиданья», а по 443 и по доменному имени передаёт внутрь.

Тогда ответ может быть только один - разбирайтесь с бекендом на php. Веб-сервер тут ситуацию не исправит.

Ты конечно можешь потюнить апач, чтоб он приложение прибивал, если оно долго работает, но это очень неправильно (хз, что там это приложение делает, может данные потерять и прочее).

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

Удалить надо не nginx а апач. Но к проблеме это не относится думаю.

Нет, я имел ввиду что медленные запросы load average не создают.

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

Посмотри iotop. Это нагрузка на диски скорее всего.

Да, там конечно php, там довольно сложный сайт. Переводить его на nginx задачи в принципе нет. Да и я к нему отношения не имею.

Что значит «переводить на nginx»? Сайт так и остаётся на php. nginx это демон, который принимает http-запросы от клиентов. Апач делает то же самое, второй раз.

Nginx этого не исправит. По крайней мере, пока ты не попросишь его резать клиентов по какому-то критерию, геолокации например.
Может у сайта морда генерируется с таким трудом, что обычные боты, обращающиеся к / в количестве 20 штук в минуту, успешно складывают твой сервак пополам. «Большое количество обращений» это неинформативно, смотри кто откуда приходит и чего хочет, что в реферерах у него.
Может тебя вообще поломали уже.

Во многих случаях mod_php бывает выгоднее php-fpm, но спорить с тобой не собираюсь, ты в каждом треде фанатично топишь за «Удалить надо не nginx а апач».

И я обычно с тобой согласен, но категоричность не работает, пока все детали не выяснили.

Во многих случаях

Приведи хоть один, кроме привязки к какому-то легаси.

фанатично топишь

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

Как писал выше, спорить с тобой не собираюсь. С другими людьми с удовольствием.

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

И если что, я сам апач с mod_php сейчас не использую, но только потому что для моих задач он бесполезен.

Да и вообще, ты перепутал фанатичность с агром на очередное нубство.

Хуюбство. Ты в каждом треде про апач пишешь, что он не нужен. Это фанатизм.

Можем еще метриками померяться, но ты админ локалхоста.