Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Alexandre]

Bonjour,

nous utilisons le True-Client-IP, Varnish propage cette variable et
Nginx l'utilise pour avoir des logs intéressant (ne pas voir l'ip des
varnish mais du client final)

Dans notre cas, à part si je me trompe, netstat ne va que me donner
les connections en cours, par la partie data.

J'avais fais un pcap avec tcpdump pour l'analyser. Il faudrait que je
le décortique plus en détail. 

Alex.

On Thu, 06 Oct 2016 14:50:16 +
"Nicolas Steinmetz"  wrote:

> Hello,
> 
> Le 6 octobre 2016 14:58 "Alexandre"  a écrit:
> > Merci d'avoir pris le temps de me répondre. Je vais faire des diff
> > entre 2 netstat. Le problème c'est que je suis derrière Akamai, du
> > coup je ne vois pas les connexions des clients finaux mais les IPs
> > d'Akamai.  
> 
> On utilise Akamai et au niveau de nos Reverse Proxy (Apache +
> mod_proxy), on va chercher la vraie IP du client dans le champ
> HTTP:True-Client-IP en lieu et place de celle d'akamai. Cela nous
> permet de passer nos RPs quand nos sites sont en maintenance.
> 
> Ne peux-tu pas faire pareil pour affiner ton analyse ?
> 
> Mes 2 cents,
> Nicolas
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Jeremie Le Hen]

On Thu, Oct 06, 2016 at 02:44:24PM +0200, Alexandre wrote:
> Merci d'avoir pris le temps de me répondre. Je vais faire des diff
> entre 2 netstat. Le problème c'est que je suis derrière Akamai, du coup
> je ne vois pas les connexions des clients finaux mais les IPs d'Akamai.
> 
> exemple de connexion en close wait par IP : 
> 
> ---
> 106 88.221.82.37
> 109 95.101.182.150
> 129 81.20.72.165
> 133 88.221.82.14
> 147 2.18.244.28
> 150 2.18.244.38
> 297 173.223.10.118
> 311 173.223.10.111
> 533 95.101.182.143
> 539 95.101.182.125
> 775 2.22.112.181
> 840 92.123.226.166
> 845 92.123.226.174
> 927 88.221.113.45
> 997 88.221.112.246
>3455 2.22.112.159
>3573 2.22.112.119
> ---

Il faut prendre le tuple (src ip, dst ip, src port, dst port) pour
identifier la connexion de manière unique.  L'IP remote ne suffit pas.
Si plusieurs connexions s'attardent d'un netstat à l'autre, c'est
problématique.

Si ça vient principalement de certaines IP, ça serait intéressant de
voir ce qu'utilise ce client comme configuration : keep-alive ou pas,
HTTP/2 ?

Si un seul des sites que tu héberges a ce problème, il doit avoir une
caractéristique particulière (HTTP/2 avec pipelining de requêtes ou
streaming par exemple).


> Autre question bête, si j'ai un vrai poblème de latence, qui est tout à
> fait possible, sachant que j'ai plusieurs applications web sur
> différents ports (port 10001 -> application 1, port 10002 ->
> application2 ...) est-ce-que ces close wait apparaitraient sur tous les
> ports, ou que sur le port ou il y a trop de trafic ?

Oui effectivement, mais comme je disais ci-dessus il y a peut-être une
caractéristique qui amplifie ça sur ce site.

Essaie juste de regarder ton requests log et fait un distribution de la
latence en ms sur plusieurs buckets.  Par exemple (à ajuster en fonction
de ce que tu vois) :
[0-50]
[50-100]
[100-500]
[500-1000]
[1000-5000]
[5000-]

Eventuellement le faire par site hébergé.  Regarde les quelques requêtes
avec une grosse latence et essaie de voir s'il elles ont quelque chose
en commun que les autre n'ont pas.  Je pense que ça doit ce voir à ce
niveau, si c'était plus bas dans la stack, ça affecterait problablement
tous tes sites.

-- Jeremie

> Alexandre.
> 
> On Mon, 3 Oct 2016 12:26:24 +0200
> Jeremie Le Hen  wrote:
> 
> > On Tue, Sep 27, 2016 at 05:16:12PM +0200, Alexandre wrote:
> > > Bonjour à tous,
> > > 
> > > je me permets de vous soumettre un petit problème que j'ai avec mes
> > > 2 varnish. (pour info j'ai déjà posé cette question sur la mailing
> > > list de Varnish) 
> > > 
> > > J'ai une architecture très conventionnelle, voici l'ordre des
> > > éléments depuis un internaute.
> > > 
> > >   - akamai 
> > >   - load balancer niveau 4 (LVS)
> > >   - varnish (en direct routing)
> > >   - backend
> > > 
> > > Il y a plusieurs "applications" web tournant sur des ports
> > > différents, mais une d'entre elles pose problème. J'ai des
> > > connexions en "CLOSE_WAIT" qui s'accumulent. 
> > > 
> > > J'ai passé quelques paramètres dans sans mon sysctl.conf pour
> > > essayer d'atténuer ce problème
> > > 
> > > ---
> > > net.ipv4.tcp_keepalive_time = 60
> > > net.ipv4.tcp_keepalive_intvl = 30
> > > net.ipv4.tcp_keepalive_probes = 20
> > > net.ipv4.tcp_tw_recycle = 1
> > > net.ipv4.tcp_tw_reuse = 1
> > > ---
> > > 
> > > En passant ces paramètres, j'ai des optimisations pour mes
> > > "webservices" (voir WEBSERVICE.png) et aucune optimisation pour le
> > > statique (voir IMAGE.png).
> > > 
> > > Qand je fais un netstat, le "close_wait" vient exclusivement
> > > d'akamai. Mais mais autres sites sont aussi sur akamai dans le PM.
> > > 
> > > Si je redémarre Varnish, les connexions se ferment, ca serait
> > > varnish qui ne ferme pas ses connexions, mais en mm temps Varnish
> > > ferme correctement les connections pour les autres sites.
> > > 
> > > Je bloque sur ce problème, auriez-vous une piste ?   
> > 
> > Une connexion TCP n'est pas forcément full-duplex.  En particulier, en
> > HTTP (sans keepalive je pense), le client peut ouvrir une connexion,
> > envoyer sa requête et faire un shutdown(2) dessus pour signifier qu'il
> > n'enverra plus de données via celle-ci.  La connexion est alors
> > half-duplex et peut toujours être utilisée pour recevoir la réponse à
> > la requête, jusqu'à ce que le serveur ferme lui aussi la socket à son
> > tour. Voir le cas 2 de la section 3.5 de la RFC :
> > https://tools.ietf.org/html/rfc793#section-3.5
> > 
> > Si c'est bien la raison pour laquelle tu es en CLOSE_WAIT, le fait
> > qu'elle s'accumule indique tu tu reçois trop de traffic pour ta
> > latence de réponse.
> > 
> > Imaginons que tu reçoives 1000 qps et que chaque requête prend en
> > moyenne 5 ms, ça te fait donc un total de traitement de 5
> > secondes/seconde et en moyenne il y aura 5 requêtes en CLOSE_WAIT à
> > tout instant (concurrence = 5).
> > 
> > Disons que ce soit ta charge maximum.  Je ne 

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Nicolas Steinmetz]

Hello,

Le 6 octobre 2016 14:58 "Alexandre"  a écrit:
> Merci d'avoir pris le temps de me répondre. Je vais faire des diff
> entre 2 netstat. Le problème c'est que je suis derrière Akamai, du coup
> je ne vois pas les connexions des clients finaux mais les IPs d'Akamai.

On utilise Akamai et au niveau de nos Reverse Proxy (Apache + mod_proxy), on va 
chercher la vraie IP du client dans le champ HTTP:True-Client-IP en lieu et 
place de celle d'akamai. Cela nous permet de passer nos RPs quand nos sites 
sont en maintenance.

Ne peux-tu pas faire pareil pour affiner ton analyse ?

Mes 2 cents,
Nicolas
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Alexandre]

Merci d'avoir pris le temps de me répondre. Je vais faire des diff
entre 2 netstat. Le problème c'est que je suis derrière Akamai, du coup
je ne vois pas les connexions des clients finaux mais les IPs d'Akamai.

exemple de connexion en close wait par IP : 

---
106 88.221.82.37
109 95.101.182.150
129 81.20.72.165
133 88.221.82.14
147 2.18.244.28
150 2.18.244.38
297 173.223.10.118
311 173.223.10.111
533 95.101.182.143
539 95.101.182.125
775 2.22.112.181
840 92.123.226.166
845 92.123.226.174
927 88.221.113.45
997 88.221.112.246
   3455 2.22.112.159
   3573 2.22.112.119
---

Autre question bête, si j'ai un vrai poblème de latence, qui est tout à
fait possible, sachant que j'ai plusieurs applications web sur
différents ports (port 10001 -> application 1, port 10002 ->
application2 ...) est-ce-que ces close wait apparaitraient sur tous les
ports, ou que sur le port ou il y a trop de trafic ?

Alexandre.

On Mon, 3 Oct 2016 12:26:24 +0200
Jeremie Le Hen  wrote:

> On Tue, Sep 27, 2016 at 05:16:12PM +0200, Alexandre wrote:
> > Bonjour à tous,
> > 
> > je me permets de vous soumettre un petit problème que j'ai avec mes
> > 2 varnish. (pour info j'ai déjà posé cette question sur la mailing
> > list de Varnish) 
> > 
> > J'ai une architecture très conventionnelle, voici l'ordre des
> > éléments depuis un internaute.
> > 
> >   - akamai 
> >   - load balancer niveau 4 (LVS)
> >   - varnish (en direct routing)
> >   - backend
> > 
> > Il y a plusieurs "applications" web tournant sur des ports
> > différents, mais une d'entre elles pose problème. J'ai des
> > connexions en "CLOSE_WAIT" qui s'accumulent. 
> > 
> > J'ai passé quelques paramètres dans sans mon sysctl.conf pour
> > essayer d'atténuer ce problème
> > 
> > ---
> > net.ipv4.tcp_keepalive_time = 60
> > net.ipv4.tcp_keepalive_intvl = 30
> > net.ipv4.tcp_keepalive_probes = 20
> > net.ipv4.tcp_tw_recycle = 1
> > net.ipv4.tcp_tw_reuse = 1
> > ---
> > 
> > En passant ces paramètres, j'ai des optimisations pour mes
> > "webservices" (voir WEBSERVICE.png) et aucune optimisation pour le
> > statique (voir IMAGE.png).
> > 
> > Qand je fais un netstat, le "close_wait" vient exclusivement
> > d'akamai. Mais mais autres sites sont aussi sur akamai dans le PM.
> > 
> > Si je redémarre Varnish, les connexions se ferment, ca serait
> > varnish qui ne ferme pas ses connexions, mais en mm temps Varnish
> > ferme correctement les connections pour les autres sites.
> > 
> > Je bloque sur ce problème, auriez-vous une piste ?   
> 
> Une connexion TCP n'est pas forcément full-duplex.  En particulier, en
> HTTP (sans keepalive je pense), le client peut ouvrir une connexion,
> envoyer sa requête et faire un shutdown(2) dessus pour signifier qu'il
> n'enverra plus de données via celle-ci.  La connexion est alors
> half-duplex et peut toujours être utilisée pour recevoir la réponse à
> la requête, jusqu'à ce que le serveur ferme lui aussi la socket à son
> tour. Voir le cas 2 de la section 3.5 de la RFC :
> https://tools.ietf.org/html/rfc793#section-3.5
> 
> Si c'est bien la raison pour laquelle tu es en CLOSE_WAIT, le fait
> qu'elle s'accumule indique tu tu reçois trop de traffic pour ta
> latence de réponse.
> 
> Imaginons que tu reçoives 1000 qps et que chaque requête prend en
> moyenne 5 ms, ça te fait donc un total de traitement de 5
> secondes/seconde et en moyenne il y aura 5 requêtes en CLOSE_WAIT à
> tout instant (concurrence = 5).
> 
> Disons que ce soit ta charge maximum.  Je ne sais pas quel est ton
> pattern de traffic, mais ce calcul n'est valable que pour des
> moyennes. Si tu as quelques requêtes qui prennent 100 ms pour une
> raison ou une autre, ça peut te mettre dedans.  Tu auras alors 10
> requêtes par seconde qui te prendront en tout 1 s de traitement.  Il
> reste donc 4 secondes pour gérer les 990 autres.  On peut aisément
> imaginer que ça s'accumule.
> 
> Bref, je te conseille de prendre un netstat toutes les secondes et de
> faire un diff des connexions en CLOSE_WAIT.  Si c'est complètement
> différent, c'est que ton serveur reçoit juste trop de requêtes, essaie
> d'augmenter le temps de caching côté client.  S'il y a des requêtes
> qui restent d'une seconde sur l'autre, à mon avis il faut investiguer
> sur la raison de cette latence
> importante.
> 
> 
> > 
> > Alexandre.
> > 
> > ---
> > tcp1  0 ip_du_lb:7042 2.22.112.119:60697
> > CLOSE_WAIT  28878/varnishd  
> > tcp1  0 ip_du_lb:7042 2.22.112.159:34567
> > CLOSE_WAIT  28878/varnishd  
> > tcp1  0 ip_du_lb:7042 2.22.112.119:61335
> > CLOSE_WAIT  28878/varnishd  
> > tcp1  0 ip_du_lb:7042 2.22.112.159:62058
> > CLOSE_WAIT  28878/varnishd  
> > tcp1  0 ip_du_lb:7042 2.22.112.119:40986
> > CLOSE_WAIT  28878/varnishd  
> > tcp1  0 ip_du_lb:7042 2.22.112.159:51570
> > CLOSE_WAIT  28878/varnishd  
> > tcp1   

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Jeremie Le Hen]

On Tue, Sep 27, 2016 at 05:16:12PM +0200, Alexandre wrote:
> Bonjour à tous,
> 
> je me permets de vous soumettre un petit problème que j'ai avec mes 2
> varnish. (pour info j'ai déjà posé cette question sur la mailing list
> de Varnish) 
> 
> J'ai une architecture très conventionnelle, voici l'ordre des éléments
> depuis un internaute.
> 
>   - akamai 
>   - load balancer niveau 4 (LVS)
>   - varnish (en direct routing)
>   - backend
> 
> Il y a plusieurs "applications" web tournant sur des ports différents,
> mais une d'entre elles pose problème. J'ai des connexions en
> "CLOSE_WAIT" qui s'accumulent. 
> 
> J'ai passé quelques paramètres dans sans mon sysctl.conf pour essayer
> d'atténuer ce problème
> 
> ---
> net.ipv4.tcp_keepalive_time = 60
> net.ipv4.tcp_keepalive_intvl = 30
> net.ipv4.tcp_keepalive_probes = 20
> net.ipv4.tcp_tw_recycle = 1
> net.ipv4.tcp_tw_reuse = 1
> ---
> 
> En passant ces paramètres, j'ai des optimisations pour mes
> "webservices" (voir WEBSERVICE.png) et aucune optimisation pour le
> statique (voir IMAGE.png).
> 
> Qand je fais un netstat, le "close_wait" vient exclusivement d'akamai.
> Mais mais autres sites sont aussi sur akamai dans le PM.
> 
> Si je redémarre Varnish, les connexions se ferment, ca serait varnish
> qui ne ferme pas ses connexions, mais en mm temps Varnish ferme
> correctement les connections pour les autres sites.
> 
> Je bloque sur ce problème, auriez-vous une piste ? 

Une connexion TCP n'est pas forcément full-duplex.  En particulier, en
HTTP (sans keepalive je pense), le client peut ouvrir une connexion,
envoyer sa requête et faire un shutdown(2) dessus pour signifier qu'il
n'enverra plus de données via celle-ci.  La connexion est alors
half-duplex et peut toujours être utilisée pour recevoir la réponse à la
requête, jusqu'à ce que le serveur ferme lui aussi la socket à son tour.
Voir le cas 2 de la section 3.5 de la RFC :
https://tools.ietf.org/html/rfc793#section-3.5

Si c'est bien la raison pour laquelle tu es en CLOSE_WAIT, le fait
qu'elle s'accumule indique tu tu reçois trop de traffic pour ta latence
de réponse.

Imaginons que tu reçoives 1000 qps et que chaque requête prend en
moyenne 5 ms, ça te fait donc un total de traitement de 5
secondes/seconde et en moyenne il y aura 5 requêtes en CLOSE_WAIT à tout
instant (concurrence = 5).

Disons que ce soit ta charge maximum.  Je ne sais pas quel est ton
pattern de traffic, mais ce calcul n'est valable que pour des moyennes.
Si tu as quelques requêtes qui prennent 100 ms pour une raison ou une
autre, ça peut te mettre dedans.  Tu auras alors 10 requêtes par seconde
qui te prendront en tout 1 s de traitement.  Il reste donc 4 secondes
pour gérer les 990 autres.  On peut aisément imaginer que ça s'accumule.

Bref, je te conseille de prendre un netstat toutes les secondes et de
faire un diff des connexions en CLOSE_WAIT.  Si c'est complètement
différent, c'est que ton serveur reçoit juste trop de requêtes, essaie
d'augmenter le temps de caching côté client.  S'il y a des requêtes qui
restent d'une seconde sur l'autre, à mon avis il faut investiguer sur la
raison de cette latence
importante.


> 
> Alexandre.
> 
> ---
> tcp1  0 ip_du_lb:7042 2.22.112.119:60697
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.159:34567
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.119:61335
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.159:62058
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.119:40986
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.159:51570
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 88.221.113.45:54955
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 92.123.224.151:61522
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 95.101.182.125:34379
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.181:38540
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 88.221.112.246:55492
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.119:60806
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 173.223.10.118:59989
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 81.20.72.214:44728
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 5.178.43.14:49587
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 88.221.112.246:34017
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 2.22.112.159:47600
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 173.223.10.111:45591
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 ip_du_lb:7042 95.101.182.143:60799
> CLOSE_WAIT  28878/varnishd  
> tcp1  0 

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Alexandre]

Aucune amélioration, mais ce qui me semble étrange c'est que Varnish ne
semble pas fermer les connections ...

Je vais contacter le support Akamai.

On Tue, 27 Sep 2016 17:51:59 +0200 (CEST)
Xavier Beaudouin  wrote:

> Hello,
> 
> Est-que que par hasard il y aurais un firewall entre akamai et ton
> varnish ? ou un machin qui filtre l'icmp ? Si oui, essayes de faire
> un allow any any en icmp.
> 
> Si c'est le LB est qu'il est en ... DSR bah... y a p'tet un truc
> quelque part...
> 
> > Pas trop d'idée, a priori. Mais... tu as essayé de contacter le
> > support d'Akamai ?  
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Xavier Beaudouin]

Hello,

Est-que que par hasard il y aurais un firewall entre akamai et ton varnish ? ou 
un machin qui filtre l'icmp ? Si oui, essayes de faire un allow any any en icmp.

Si c'est le LB est qu'il est en ... DSR bah... y a p'tet un truc quelque part...

> Pas trop d'idée, a priori. Mais... tu as essayé de contacter le support
> d'Akamai ?
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Beaucoup de connexion en "CLOSE_WAIT"

[Dominique Rousseau]

Le Tue, Sep 27, 2016 at 05:16:12PM +0200, Alexandre [in...@opendoc.net] a écrit:
[...]
> 
> Qand je fais un netstat, le "close_wait" vient exclusivement d'akamai.
> Mais mais autres sites sont aussi sur akamai dans le PM.

Pas trop d'idée, a priori. Mais... tu as essayé de contacter le support
d'Akamai ?


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
___
Liste de diffusion du FRsAG
http://www.frsag.org/