gremlintv2
@gremlintv2

Где могли быть допущены ошибки в архитектуре проекта?

В чем может заключатся проблема на ваш взгляд:
5a9e686659fb4638936920.png

S1 NGINX+PHP_FPM+POSTGRES
S2 NGINX+PHP_FPM

S1 проксирует соединения на S2
В опеределенный момент количество установленых соединений резко возростает, по этой причине S2 создает дополнительные запросы к базе на S1 с которыми S1 не справляется

sysctl.conf (на обеих серверах)
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.ip_local_port_range=1024 65535
net.netfilter.nf_conntrack_max = 562144
net.nf_conntrack_max = 562144
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.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 0
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_tw_buckets_ub = 26536
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
fs.file-max = 999999
fs.suid_dumpable = 0
kernel.core_pattern = /dev/null
net.netfilter.nf_conntrack_max = 2048576
net.nf_conntrack_max = 2048576
net.ipv4.tcp_max_syn_backlog = 100000
net.core.somaxconn = 100000
net.core.netdev_max_backlog = 100000</blockquote>
/etc/security/limits
* soft nofile 100000
* hard nofile 100000
root soft nofile 100000
root hard nofile 100000

/etc/1111/limits (nginx, postgres, pgbouncer)
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             514588               514588               processes 
Max open files            100000               100000               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       514588               514588               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us
pgbouncer
[databases]
* = host=111.111.111.111 port=5432

[pgbouncer]
logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid
listen_addr = *
listen_port = 6432

;Настройки аутентификации:
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

;доступ 
admin_users = postgres
server_reset_query = DISCARD ALL

;Чаще всего значение имеет смысл заменить на transaction. В этом случае соединение будет возвращаться в общий пул после завершения транзакции. 
;pool_mode = transaction
pool_mode = session
;Настройки размера пула:
max_client_conn = 10000
default_pool_size = 30

;Не логировать подключения/отключения
log_connections = 0
log_disconnections = 0



Понимаю, что описание "ниочем" но может быть у вас найдеться пара советов для новичка.
Пробовал настроить haproxy вместо nginx не помогло, пробовал перед обращением к базе пулить запросы через pgbouncer не помогло. Пробовал на отдельном сервер настроить балансер, та же история.
Перерыл логи nginx, php-fpm, journalctl,messages, pgbouncer, postgres. Нигде ни намека почему так происходит.

1)Какие еще, есть варианты для решения нагрузки по установленым соединениям?
2)В чем может быть затык(кривой конфиг, неправильное размещение элементов проекта)?
3)Решит ли задачу вынос БД на отдельный сервер?

ЗЫ: Как говориться: не святые горшки лепили. Все мы учимся. И зачастую на собственных ошибках.
  • Вопрос задан
  • 117 просмотров
Пригласить эксперта
Ответы на вопрос 2
VoidVolker
@VoidVolker
Ошибки в архитектуре могли быть допущены где угодно. Анализируйте узкие места и ищите причины. Кстати, вы спрашиваете об ошибках архитектуры без предоставления самой архитектуры и какой-либо информации о системе и надеетесь получить какой-то ответ, который решит ваши проблемы?
Ответ написан
vman
@vman
Вас не досят? сделайте лимит по запросам в nginx nginx.org/ru/docs/http/ngx_http_limit_req_module.html
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы