3 votes

Haproxy a besoin d'un redémarrage toutes les 2 heures

J'ai mis en place deux serveurs haproxy dédiés pour répartir la charge sur trois serveurs d'application. J'ai configuré un équilibrage régulier du port 80 en http, ainsi qu'un spécial pour fonctionner avec les websockets.

Cela fonctionne très bien pendant environ 2 heures, mais après cela cela devient vraiment lent, le temps de chargement d'une page est d'environ 30 secondes. Quand je redémarre haproxy, tout fonctionne à nouveau.

Voici ma configuration. Avez-vous une idée de ce qui pourrait causer cela?

global
  user haproxy
  group haproxy

defaults
  mode http
  timeout connect 5s
  timeout client  5s
  timeout server  60s
  stats enable
  stats auth aa:bb

frontend proxy
   # écouter sur le port 80
  bind 0.0.0.0:80

  # autoriser de nombreuses connexions, avec un timeout long
  maxconn 200000 # total maximum de connexions, vérifier également ulimit
  timeout client 24h

  # par défaut vers le backend webapp
  default_backend webapp

  # est-ce une demande de socket io?
  acl is_websocket hdr_end(host) -i node.domain.com
  use_backend websocket if is_websocket

backend webapp
   balance roundrobin # en supposant que vous n'avez pas besoin de coller
   # permettre aux connexions client de persister pendant 5s
   # mais fermer les requêtes côté serveur pour éviter de conserver des connexions inactives
  option httpchk HEAD /check.txt HTTP/1.0
  option http-server-close
  option forwardfor

  server app1 x.y.149.133:80 cookie app1 weight 10 check
  server app2 x.y.149.134:80 cookie app2 weight 15 check
  server app3 x.y.149.135:80 cookie app3 weight 15 check

backend websocket
  balance source

  # options
  option forwardfor # ajouter X-Forwarded-For

  # Ne pas utiliser httpclose (= les connexions client et serveur sont fermées), car cela fermera les connexions Websockets
 no option httpclose

 # Utilisez "option http-server-close" pour préserver les connexions persistantes côté client tout en gérant chaque demande entrante individuellement, les dispatchant un par un vers les serveurs, en mode fermeture HTTP
 option http-server-close
 option forceclose

 server app1 x.y.149.133:3000 cookie app1 weight 10 check
 server app2 x.y.149.134:3000 cookie app2 weight 15 check
 server app3 x.y.149.135:3000 cookie app3 weight 15 check

1voto

Kyle Brandt Points 81077

Ce qui différencie généralement les websockets du load balancing http quotidien, c'est que vous finissez par avoir un grand nombre de connexions concurrentes par rapport au taux d'arrivée. C'est une distinction importante dans les systèmes, donc si ce n'est pas clair pour vous, jetez un coup d'œil à cette réponse que j'ai donnée.

Donc, quel que soit votre problème, ma supposition est qu'il se produit lorsque vous atteignez un certain seuil de connexions concurrentes. Voici ma meilleure supposition basée sur les informations que vous avez fournies :

Les web sockets côté serveur contiennent 3 serveurs. Le load balancer communique avec eux tous à partir de la même adresse IP. Cela signifie que vous avez un total de plage_de_ports_source * adresses IP de destination. Cela ressemble à quelque chose comme :

[root@ny-kbrandt01 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000
[root@ny-kbrandt01 ~]# echo $(( (61000-32768) * 3 ))
84696

Donc, lorsque vous atteignez environ 84k connexions, vos instances haproxy manquent de ports sources, le CPU augmente alors qu'il effectue quelque chose de similaire à la collecte de déchets pour trouver plus de ports sources.

Si ce n'est pas le cas, je parie que c'est quelque chose dans ce sens, surveillez vos connexions concurrentes en utilisant la page de statistiques de haproxy et surveillez votre CPU pour mieux comprendre ce qui se passe lorsque les choses ralentissent.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X