HAProxy está trocando (Falhas Graves) ao Servir Web Sockets

Question

Eu observei algumas trocas em nossa instância HAProxy que serve sockets da web. A taxa de falha é baixa (0,01 falhas principais / s) atualmente. Usamos o modo nbproc com um processo para o processamento http e 3 outros processos dedicados ao processamento de SSL.

Do Perf, eu pude pegar as seguintes amostras de falhas da instância de processamento 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

Como isso mantém um número razoável de conexões, o uso de memória é bastante alto (~ 16 GB para todas as instâncias (há 4 no total porque estamos executando com nbproc ).

Devo tentar evitar essa falha configurando a troca para zero? Eu acho que isso poderia ser um gerenciamento de memória saudável, mas talvez o haproxy nunca deva realmente estar trocando?

Dados de referência:

Sobrecarga de memória nesta máquina:

[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

Informação da versão:

HA-Proxy version 1.5.2 2014/07/12
Copyright 2000-2014 Willy Tarreau <[email protected]>

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.

Trechos de configuração:

global
    maxconn 300000
    tune.bufsize 16384
    nbproc 4

Memória de todas as instâncias HAProxy (Nota haproxy-t3 é nossa instância do servidor de soquete e é a que está trocando):

[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

    

Answer 1

isso deve ser absolutamente impedido de acontecer! Felizmente você percebeu isso antes que fosse muito sério.

Por favor, verifique o seu maxconn na seção global, verifique se você está usando o "tune.bufsize" na seção global (caso contrário, você pode assumir 16kB) e o número de processos.

A quantidade máxima de memória em uso é sobre (2 * bufsize + 2kB) * maxconn * nbproc) para o próprio haproxy, além de um min de aproximadamente (4 * 4kB * maxconn * nbproc) para os soquetes do lado do kernel.

O problema com o websocket é que as conexões podem durar muito tempo e serem empilhadas juntas, resultando em mais estresse do que quando se faz HTTP, onde as conexões são muito curtas. É possível que suas configurações permitam um uso de memória muito alto e que somente o WebSocket seja capaz de atingir esses limites.

BTW, estou vendo 34 GB de cache nesta máquina, portanto é possível que seja um cache real (caso em que você não deveria se preocupar) ou dados temporários em / dev / shm. Além disso, você poderia verificar o VSZ e RSS de seus processos haproxy?

    

Answer 2

Depois de algumas escavações, aqui está o que eu mostrei:

A caixa definitivamente não estava sob contenção de memória de qualquer tipo. Quase todos os dados em cache consistiam em páginas mapeadas para arquivos de log haproxy. Como esses arquivos estavam sendo constantemente escritos e tendiam a ser bem corpulentos, eles ocupavam uma grande quantidade de páginas em cache.

Quando essas páginas de disco para os logs são mapeadas, elas acabam trocando páginas anônimas antigas do haproxy. Todas as páginas realmente antigas, por acaso, pertenciam aos nossos websockets haproxy, e provavelmente eram espaços de buffer de conexões realmente antigas.

Eu recusei o swap para que ele não trocasse as páginas tão agressivamente. Isso deve resultar no descarte das páginas de logs do haproxy, em vez de trocar páginas anônimas do haproxy.