edo1h

Спасибо всем неравнодушным и ответившим по существу проблемы.

Всякое решение плодит новые проблемы.(один из законов Мэрфологии)

Похоже время ответить на вопрос и закрыть тему

Context switch per second (Linux) 1.3млн это много или мало?
Если коротко — это для конфигурации
E5-2699v4 — 2шт
RAM 378Gb
Довольно много, но не предел.
Достигнутый максимум 1.5 млн.
Достигнут был при следующих условиях:
Совет от edo1h,

1. mitigations=off, это снизит стоимость переключения контекста;
2. «Зажал» бы частоту процессора и отключил всякие c3, энергосберегающие опции плохо совместимы с короткими запросами.
processor.max_cstate=1 intel_idle.max_cstate=1 к параметрам ядра, плюс поставить pstate-frequency и запустить pstate-frequency -p max (если помогло, то в systemd включаем pstate-frequency@max)

Дал направление копания, итоговый набор параметров ядра совпал с советом выше.
mitigations=off intel_idle.max_cstate=1 processor.max_cstate=1

Замечания jcmvbkbc, res2001, Everything_is_bad натолкнули на мысль разделить задачи сервера на более-менее автономные блоки и исследовать как по отдельности, так и взаимосвязи между ними.

Результат оказался для меня неожиданным (об этом в п.3)

1. Сеть
Тюнинг сетевой подсистемы дал снижение количества прерываний/сек (не слишком значительное, но это положительным образом сказалось на результатах).
Убрал bonding интерфейсов (выигрыш на уровне погрешностей измерения, но иногда(хоть и крайне редко) при работающем bonding наблюдались всплески interrupts, которые полностью отсутствовали при выключенном bonding в течении 4-х дней)
Максимальный размер буферов на адаптере.
Воспользовался tuned + корректировка параметров sysctl.
Профиль network-latency субъективно подошел лучше всего.

2. Работа nginx-а
Тут дало положительный эффект запуск 2-х независимых серверов на 2-х dummy интерфейсах. Не могу пока предположить с чем связано.

3. Неожиданный эффект — т.к. логирование таки необходимо, довольно много сливалось в rsyslog по unix.socket (сеть не вариант, нагрузка выше заметно)
Вот отказ от заливки логов nginx-а в rsyslog снял 75-76% (С 1.3млн до 0.3млн на пиках нагрузки) количества «Context switch per second».
Буквально «на коленке» на python написал заменитель, вся задача — сообщение из unix.socket записать в файл в нужном формате.

Итог, сервер выполняет те же функций:
«Context switch per second» -- снизился на 50% от исходного.
Нагрузка на CPU — снижение примерно на 25-30%.
При тех нагрузках, при которых ранее появлялись отказы, отказов нет.

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

Нет смысла. Диск сам будет балансировать, если не забит под завязку
Да и 60гб это оч мало для винды
Ну и диск то копеечный... в целом диски это расходник сейчас

Расстояние до роутер ~13 метров и одна железобетонная стена.

Либо стену сносить, либо еще одну точку доступа ставить.

Есть смысл брать более дорогие роутеры, например с AX5400? Или они ни чем не лучше AX1800?

Сигнал затухает на стенах, особенно если речь идет про 5ггц, а уж если стена железобетон....
Роутер не перфоратор, им стены не сверлят.
Если стена мешает - убираем стену, или ставим дополнительную точку доступа. Иначе - миримся с хреновой скоростью.

Потому что время простоя считается суммарно по каждому ядру процесора.
Вот пример - загрузились час назад, ничего не делали все это время.
Аптайм - час. А время простоя для 4-х ядерного процессора - 4 часа.

Почему KVM при свободном ОЗУ так сильно использует SWAP?

Для управления памятью. Какой тогда смысл в SWAP если его не использовать?

Насколько это нормально и что будет при увеличении кол-ва машин (боюсь увидеть 100%)?

Использование SWAP абсолютно нормально.
Ненормально это когда объема ОЗУ не хватает и приходится использовать SWAP вместо ОЗУ.

Дело в том, что '\n' имеет магию только в ЯП. В остальном это просто два символа. По факту на стадии обработки кода '\n' заменяется на символ перевода каретки {по идее он не видимый}. Скорее всего вам нужно обрабатывать строку как-нибудь или пихать в функцию на подобии этой:

def formatter(s):
    return s.replace("\\n", "\n").replace("\\t", "\t")# and etc.

Сначала добавьте новый столбец:

ALTER TABLE items ADD COLUMN item_id VARCHAR (16) DEFAULT NULL;

Затем заполните созданный столбец данными из другой колонки:
UPDATE items SET item_id = item->>'id';

В примере выше items - таблица, а item - столбец типа jsonb

Если новый столбец типа BIGINT:

ALTER TABLE items ADD COLUMN item_id_int BIGINT DEFAULT NULL;
UPDATE items SET item_id_int = (item->>'id')::bigint;

Мне необходимо написать так, что если метод не POST (GET, HEAD), то выдавать не 0.

Т.е. если метод POST, то выдать 0. Иначе выдать 1.

map $request_method $cache_hit {
  "~*post" 0;
  default 1;
}

В $request_method строка всегда в верхнем регистре, так что регулярка не нужна.

map $request_method $cache_hit {
  POST    0;
  default 1;
}

Как выяснилось, исходная задача заключалась в переводе на map таких условий:

set $cache_hit 1;

  # POST requests and urls with a query string should always go to PHP.
  if ($request_method = POST) {
    set $cache_hit 0;
  }

  if ($query_string != "") {
    set $cache_hit 0;
  }
   
  # Don't cache uris containing the following segments.
  if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $cache_hit 0;
  }
   
  # Don't use the cache for logged-in users or recent commenters.
  if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
    set $cache_hit 0;
  }

На map это можно сделать так:

map $query_string $check_query_string {
  ""       0;
  default  1;
}

map $request_uri $check_request_uri {
  "~*(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)"  1;
  default  0;
}

map $http_cookie  $check_cookie {
  "~*comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"  1;
  default  0;
}


map "$request_method:$check_query_string:$check_request_uri:$check_cookie"  $cache_hit {
  "~^POST"    0;
  "~1"        0;
  default     1;
}

У вас открыт portmapper наружу, 111 порт tcp/udp

Косвенно это уязвимость, которая позволяет злоумышленникам пользоваться этим для DDOS аттак.

Обычно он нужен для NFS или RPD, но крайне редко кому-либо нужно это делать прямо через интернет. Через инет чаще делают ssh или уже включают VPN и уже внутри шарят.

Если вы не пользуетесь такими сервисами, просто закройте портмаппер наружу.