HAProxy меняет местами (основные ошибки) при обслуживании веб-сокетов
Я заметил некоторую подкачку в нашем экземпляре HAProxy, который обслуживает веб-сокеты. В настоящее время частота отказов низкая (0,01 основных отказов / с). Мы используем режим nbproc с одним процессом для обработки http и 3 другими процессами, предназначенными для обработки SSL.
Из Perf я смог получить следующие образцы ошибок из экземпляра обработки http:
Samples: 36 of event 'page-faults:u', Event count (approx.): 206
28.64% haproxy-t3 haproxy [.] si_conn_wake_cb
20.87% haproxy-t3 haproxy [.] si_conn_recv_cb
13.11% haproxy-t3 haproxy [.] raw_sock_to_buf
10.68% haproxy-t3 haproxy [.] stream_int_chk_snd_conn
7.28% haproxy-t3 haproxy [.] conn_fd_handler
4.37% haproxy-t3 haproxy [.] http_end_txn
3.88% haproxy-t3 haproxy [.] stream_int_update_conn
3.88% haproxy-t3 haproxy [.] process_session
2.91% haproxy-t3 haproxy [.] eb_delete
2.43% haproxy-t3 haproxy [.] stream_sock_read0
1.94% haproxy-t3 libc-2.12.so [.] __memset_sse2
Поскольку при этом поддерживается изрядное количество одновременных подключений, использование памяти довольно велико (~ 16 ГБ для всех экземпляров (всего их 4, потому что мы работаем с nbproc).
Должен ли я попытаться предотвратить эту ошибку, установив для swapiness значение ноль? Я полагаю, это могло бы быть здоровым управлением памятью, но, может быть, haproxy никогда не должен менять местами?
Справочные данные:
Накладные расходы на память на этом компьютере:
[root@ny-lb06 ~]# free -m
total used free shared buffers cached
Mem: 64375 58876 5499 0 86 34472
-/+ buffers/cache: 24317 40058
Swap: 6015 267 5748
Информация о версии:
HA-Proxy version 1.5.2 2014/07/12
Copyright 2000-2014 Willy Tarreau <w@1wt.eu>
Build options :
TARGET = linux26
CPU = generic
CC = gcc
CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
OPTIONS = USE_GETADDRINFO=1 USE_REGPARM=1 USE_OPENSSL=1 USE_STATIC_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built without zlib support (USE_ZLIB not set)
Compression algorithms supported : identity
Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Фрагменты конфигурации:
global
maxconn 300000
tune.bufsize 16384
nbproc 4
Память всех экземпляров HAProxy (обратите внимание, что haproxy-t3 - это экземпляр нашего сокет-сервера, который выполняет подкачку):
[root@ny-lb06 ~]# ps -A -o cmd,vsz,rss,pid
/opt/haproxy/haproxy-t3 -D 8424224 8299192 30343
/opt/haproxy/haproxy-t3 -D 2259988 2185768 30344
/opt/haproxy/haproxy-t3 -D 3079456 3013344 30345
/opt/haproxy/haproxy-t3 -D 2445524 2380072 30346
/opt/haproxy/haproxy-t4 -D 93332 27780 31606
/opt/haproxy/haproxy-t4 -D 61108 2988 31607
/opt/haproxy/haproxy-t4 -D 61232 3132 31608
/opt/haproxy/haproxy-t4 -D 61288 7464 31609
/opt/haproxy/haproxy-t2 -D 66572 14216 32497
/opt/haproxy/haproxy-t2 -D 63308 12052 32498
/opt/haproxy/haproxy-t2 -D 66400 15696 32499
/opt/haproxy/haproxy-t2 -D 64168 12592 32500
/opt/haproxy/haproxy-t20 -D 57400 5268 33284
/opt/haproxy/haproxy-t20 -D 59620 3864 33285
/opt/haproxy/haproxy-t20 -D 59640 6176 33286
/opt/haproxy/haproxy-t20 -D 59620 3928 33287
/opt/haproxy/haproxy-t1 -D 805556 750948 34693
/opt/haproxy/haproxy-t1 -D 189860 137264 34694
/opt/haproxy/haproxy-t1 -D 196988 144472 34696
/opt/haproxy/haproxy-t1 -D 187136 134524 34697
/opt/haproxy/haproxy-t5 -D 59464 7368 41065
/opt/haproxy/haproxy-t5 -D 59756 1772 41066
/opt/haproxy/haproxy-t5 -D 59984 2136 41067
/opt/haproxy/haproxy-t5 -D 59756 4240 41068
это должно быть исключено! К счастью, вы заметили это до того, как это стало слишком серьезным.
Пожалуйста, проверьте свой maxconn в глобальном разделе, проверьте, используете ли вы "tune.bufsize" в глобальном разделе (в противном случае вы можете принять 16 КБ), и проверьте количество процессов.
Максимальный объем используемой памяти составляет примерно ((2 * bufsize + 2kB) * maxconn * nbproc) для самого haproxy, плюс минимум примерно (4 * 4kB * maxconn * nbproc) для сокетов на стороне ядра.
Проблема с websocket заключается в том, что соединения могут длиться долго и складываться вместе, что приводит к большему стрессу, чем при использовании HTTP, когда соединения очень короткие. Возможно, ваши настройки допускают слишком большое использование памяти и что только WebSocket способен достичь этих пределов.
Кстати, я вижу на этой машине 34 ГБ кеша, поэтому возможно, что это настоящий кеш (в этом случае не стоит беспокоиться) или временные данные в / dev / shm. Также не могли бы вы проверить VSZ и RSS ваших процессов haproxy?
Покопавшись, я обнаружил следующее:
Коробка определенно не вызывала никаких проблем с памятью. Почти все кэшированные данные состояли из страниц, сопоставленных с файлами журнала haproxy. Поскольку эти файлы постоянно записывались и имели тенденцию быть довольно объемными, они занимали огромное количество кешированных страниц.
Когда эти дисковые страницы для журналов будут сопоставлены, они в конечном итоге заменят действительно старые анонимные страницы из haproxy. Все действительно старые страницы принадлежали нашим веб-сокетам haproxy и, скорее всего, были буферными пространствами от действительно старых соединений.
Я отказался от подкачки, чтобы она не меняла страницы так агрессивно. Это должно привести к тому, что страницы журналов haproxy будут отброшены, а не заменены анонимными страницами haproxy.