Iceforest

Все сервера в директиве upstream резолвятся в IP-адреса и информация об оригинальных именах теряется. Это проблема если на одном IP-адресе существует множество серверов.

Правильным решением было бы поднятие апстримов на уникальных парах IP:port, но есть обходной путь при помощи двойного проксирования.

Примерно так:

# вместо настоящих серверов указываем тут промежуточные,
# которые определены в этом же конфиге ниже
upstream valid {
  server 127.0.10.1:80;
  server 127.0.10.2:80;
}

# промежуточный сервер
server {
  listen 127.0.10.1:80;
  location / {
    proxy_pass http://validator.amd.ru;
    # тут nginx автоматически добавляет proxy_set_header Host validator.amd.ru;
    # (берёт имя домена из proxy_pass)
  }
}
# второй промежуточный сервер
server {
  listen 127.0.10.2:80;
  location / {
    proxy_pass http://validator.bm.ru;
    # тут nginx автоматически добавляет proxy_set_header Host validator.bm.ru;
  }
}

# тут ничего не меняем
server {
  ...
  location /api/valid {
    proxy_pass http://valid/api/validators;
    # теперь запросы проксируются в промежуточные сервера, которые проксируют
    # в настоящие с правильным именем домена
  }
}

max_client_conn в конфиге баунсера - это максимальное число возможных подключений от клиентов к самому баунсеру.
Если у вас max_client_conn стоит, например, 100, а каждый из 20 бекендов попробует открыть по 10 соединений с баунсером - то первая сотня подключений будет успешна, остальные получат ошибку "no more connections allowed (max_client_conn)"
max_client_conn ставится в 10000 и про него надолго забываем. Штука фактически бесплатная, libevent хорошо умеет с таким работать. Но требуется выставить корректный open file limit. Каждый коннект - это файловый дескриптор, если не скорректировать настройки ОС - то будет неприятный сюрприз.

Далее, max_connections базы оставить как есть. Максимум в 100 процессов базы на всего 8 ядер - это и так довольно-таки много, но и урезать смысла нет.
max_user_connections не трогать если нет причин для этого.

pool size 20 на всего лишь 8 ядер CPU может быть чрезмерно. Но далее нужно смотреть уже мониторинг. Сколько реальных процессов базы в работе, очередь ожиданий на баунсере, хватает ли баунсеру процессорного времени (тут скользкий момент, баунсер строго однопоточный и может упираться в производительность одного ядра CPU)

cmp -s <(./test.sh) test && echo 1||echo 0

как все-таки правильно сверить, должно быть 100 процентное совпадение с эталонным файлом в результате команды должна быть 1.

./test.sh | if cmp -s - test ; then echo 1 ; else echo 0 ; fi

result=$(./test.sh)| cmp -s $result test

это почти попытка сравнить текст выводимый test.sh с содержимым файла test, но здесь не нужен конвейер и cmp так не работает.

cmp -s (./test.sh) test

Это почти рабочий вариант для bash, полностью рабочий выглядит так: cmp -s <( ./test.sh ) test. Но из-за того, что конструкция <(…) специфична для bash этот вариант на мой взгляд менее предпочтителен чем вариант ./test.sh | if cmp -s - test.

$http_origin ~ '^https:\/\/example\.org$'

Рисуется сразу потому что в словаре содержатся вызовы (т.е. результаты вызова функции) вместо самих функций.
Нужно изменить словарь и соответственно добавить параметр в вызов функции (как значение из словаря). Также выкинул figures_numbers т.к. смысла в нем тут нет.

point = sd.get_point(300, 300)
figures = {1: triangle, 2: square, 3: pentangle, 4: sixangle}
user_input = input('Введите, пожалуйста, номер фигуры с 1 - 4: ')
number_figure = int(user_input)
# number_figure = 2
if number_figure in figures:
    figures[number_figure](point)
else:
    print('Вы ввели неправильный номер фигуры, введите значение от 1 до 4')

sd.pause()

Полагаю, вы имеете в виду нечто в виде

def func1():
    print('func1')

def func2():
    print('func2')

funcs = {1: func1, 2: func2}

funcs[1]()