Смотрите в сторону более высокоуровневых языков, в C нет даже массивов в вашем привычном понимании, сложные структуры данных делаются только руками, а «массив» здесь это просто область памяти размером n * sizeof(type), о которой надо думать именно как о блоке байтов, а не о контейнере, в котором уже есть операции типа «добавить» и т.д.
Да, уже прочитал… Вхост всегда был умолчальным, а левый трафик просто раньше не замечали, я думаю.
В общем, браузер открывает соединения, которые не использует, а nginx закрывает их спустя некоторое время, отправляя ошибку 400. Хост подставляется умолчальный по той простой причине, что браузер не прислал заголовок Host. Если всё так, то это ничего страшного.
Спасибо всем за быстрый ответ :)
Дефолтным он действительно является.
С общим трафиком на сервере данный примерно одного порядка.
И да, спасибо за дельный совет, все IP-шники, «попавшиеся» за несколько секунд просмотра лога, действительно совершали и нормальные запросы. Эти запросы шли на поддомен рассматриваемого. Возможно ли так, что браузер порождает какие-то запросы на домен верхнего (по отношению к данному) уровня?
Чисто ради интереса пытаюсь воспроизвести ситуацию, просматривая сайт, к которому идут нормальные запросы, пока что не удаётся.
limit_req, ограничивающий число запросов в секунду с одного IP, в данный момент на рассматриваемых вирт.узлах, отключён. И даже будь он включён, статус ответа был бы 503, а не 400… Так что в данном случае, я думаю, это не совсем нормально. Может, попробовать временно сделать proxy_pass на какое-нибудь приложение-заглушку, просто слушающее порт и пишущее в лог весь трафик?
PHP, к слову, даже не получится на отдельном сервере завести, так как ему всё равно нужен доступ по ФС к самому скрипту. То есть по FastCGI работает сам интерпретатор, а не скрипт. Можно, конечно, извратиться и сделать NFS-доступ, но в целом именно так.
Ну, как я уже написал выше, львиная доля памяти уходит на сжатие (zlib, да и TLS, если GnuTLS собрано со встроенным сжатием) и на MUC. MUC ест вообще порядка половины всей памяти. В остальном причина такого агрессивного потребления — сама архитектура erlang-машины (следствие избыточности внутреннего представления строк). Но как-то специально тюнить действительно не пытались, так как есть и запас по ресурсам, и возможность добавить ноду.
Если взглянуть на Prosody, у него накладные расходы значительно меньше, но при этом меньше и нагрузочная способность. Такой вот порочный круг с этими XMPP-серверами выходит.
Сказать с уверенностью, к сожалению, нельзя. Например, если большинство пользователей будут с «узкими» каналами, то станзы, идущие к ним, будут массово буферизоваться, в результате на одного пользователя будет расходоваться больше памяти.
В данный момент у процесса beam.smp VIRT = 22.6G, RES = 11.6G, число онлайнов — 17 килочеловек.
График потребления памяти (VIRT) выглядит так:
А график пользователей, соответственно, такой (артефакты на изображении вызваны характером аудитории, а не проблемами с сервером).
