Bonsoir,
Il reste encore quelques minutes pour vous/nous souhaiter un bon SysAdmin
Day...
Des idées de cadeaux : http://sysadminday.com/about-sysadmin-day/gift-ideas/
Have a lot of Fun :D
--
Cordialement.
Manuel OZAN
Bonjour,
comment améliorer le temps d'affichage d'une page web dynamique (PHP) à
l'autre bout du monde ? (Sans délocalisation de serveurs)
Les CDNs permettent d'améliorer le temps d'affichage des documents
statiques.
Délocaliser des serveurs peut couter cher dans certain pays, et puis dans
ce cas il faut déporter tous les services associés : memcached/redis, DB,
...
Connaissez vous d'autres solutions ?
--
Greg
Merci Vincent pour ces explications et recommandations, que j'ai prise en
compte.
Néanmoins je me demande toujours pourquoi désactiver les TCP timestamps a
un tel impact sur l'établissement des connexions TCP.
Damien> je suis en contact aussi avec eux, mais comme tout CDN ils ne
peuvent rien faire sur le trafic dynamique ;)
Le 23 juillet 2013 12:14, Damien Wetzel <dwetzel(a)nerim.net> a écrit :
> Bonjour Greg,
> On est en contact via cedexis.
> Si l'utilisation du cdn peut soulager vos problemes de perfs n'hesitez pas
> à l'utiliser.
> Cordialement,
>
> Greg writes:
> > Bonjour,
> >
> > je rencontre un problème d'établissement de connexions TCP sur un
> serveur par forte charge, qui se concrétise par des
> > timeouts de connexion. Ce serveur établit de nombreuses connexions :
> > - serveur web NGiNX
> > - fichiers statiques sur NFSv4 (4 connexions TCP)
> > - reverse-proxy sur une 20ène de serveurs web Apache2/PHP, via l'IP
> publique
> > - reverse-proxy sur un cluster XMPP
> >
> > Evidemment il y a quelques axes d'améliorations simple : passer par le
> réseau privé pour limiter les connexions sur
> > l'interface réseau publique, ... mais ce n'est pas le but de ce mail.
> >
> > Sous forte charge, parfois une simple connexion TCP a des difficultés
> pour s'établir. Pour tester, j'écarte des soucis
> > potentiels avec NGiNX et lance un serveur netcat sur le port 8080 :
> > nc -l -k 8080
> >
> > et depuis un poste client sous Linux :
> > while true; do date -R | tee -a /dev/stderr | nc -w 2 perceval.local
> 8080 || echo ERR; sleep 0.2; done
> >
> > Lorsque le problème survient, des "ERR" s'affichent.
> >
> > A ce moment, j'ai tenté plusieurs choses pour tenter de trouver la
> source de ces problèmes de connexions, et aucun ne
> > s'est avéré "payant" :
> > - désactiver le firewall
> > - supprimer et décharger conntrack
> > - changer l'algorythme de congestion TCP de cubic à autre chose
> > - mesurer le nombre de connexions TCP établit ou en FIN_WAIT : à 10k
> total le soucis peut très bien se produire ou pas
> > - modifier plusieurs paramètre de config TCP / Kernel :
> > net.ipv4.tcp_sack = 1
> > net.ipv4.tcp_fack = 1
> > net.ipv4.tcp_window_scaling = 1
> > net.ipv4.tcp_syncookies = 0
> > net.ipv4.tcp_low_latency = 0
> > net.core.netdev_max_backlog = 4000
> > net.ipv4.ip_local_port_range = 1024 65000
> > net.ipv4.tcp_max_syn_backlog = 163840
> > net.ipv4.tcp_synack_retries = 1
> > net.ipv4.tcp_fin_timeout = 10
> > net.ipv4.tcp_no_metrics_save = 1
> > net.ipv4.tcp_max_tw_buckets = 400000
> > net.core.somaxconn = 8192
> > fs.file-max = 1310720
> > net.ipv4.tcp_tw_recycle=1
> > net.ipv4.tcp_tw_reuse=1
> >
> > En vain. Sauf un paramètre qui débloque tout quand il est désactivé :
> > net.ipv4.tcp_timestamps=0
> >
> > C'est très net, si je désactive les timestamps TCP coté serveur (ou
> coté client forcément), je n'ai plus aucun problème
> > d'établissement de connexions TCP.
> >
> > A ce moment commence les recherches sur Google, et tout ce que je
> trouve est ambigu : il vaut mieux activer les
> > timestamps TCP pour des raisons de performances, mais il faut mieux les
> désactiver pour des problèmes de sécurité.
> > Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement
> osef nan ?
> > Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre
> en cas de soucis de congestion TCP...
> >
> > Peut-être qu'avec la quantité de trafic, le kernel n'est pas capable de
> fournir assez de timestamps ? Peut-être que la
> > fréquence du timer Linux a une incidence ?
> > Le kernel utilisé est le 3.5.5 avec les patchs Google d'activé (RPS,
> RFS) et cette config de timer :
> > CONFIG_NO_HZ=y
> > CONFIG_HZ_250=y
> > CONFIG_HZ=250
> >
> > J'essaye avec 1000 HZ : aucune incidence.
> >
> > La désactivation de ce paramètre net.ipv4.tcp_timestamps ne doit pas
> agir que sur les timestamps, peut-être que les
> > algos de congestion TCP, ou certains modules, ou une partie de la stack
> TCP, utilisent les timestamps TCP, et peut-être
> > que c'est un de ces modules qui pose problème ?
> >
> > Avez vous déjà expérimenté ce type de soucis ?
> > Je suis dispo pour faire des tests si vous avez des idées !!
> >
> > --
> > Greg
> >
> >
> > ----------------------------------------------------------------------
> > _______________________________________________
> > Liste de diffusion du FRsAG
> > http://www.frsag.org/
>
> --
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Damien WETZEL (ATANAR TECHNOLOGIES) ("`-/")_.-'"``-._
> http://www.atanar.com . . `; -._ )-;-,_`)
> (v_,)' _ )`-.\ ``-'
> Phone:+33 9 63 05 59 99 _.- _..-_/ / ((.'
> - So much to do, so little time - ((,.-' ((,/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
--
Greg
Bonjour tous le monde,
Pas de répit pour les braves, je vous propose le rendez vous mensuel
pour (presque) Lyonnais et environs.
Cela se passe par ici :
http://framadate.org/studs.php?sondage=musu2ge52b6i1cj7
Au choix le 24 et 25.
Pour le moment le oint de chute est le bar à vin le Tono à Cordelier.
On bloquera la date définitive pour le 20/07
Profitez bien du soleil et de la chaleur en attendant :)
Km
Bonjour,
je rencontre un problème d'établissement de connexions TCP sur un serveur
par forte charge, qui se concrétise par des
timeouts de connexion. Ce serveur établit de nombreuses connexions :
- serveur web NGiNX
- fichiers statiques sur NFSv4 (4 connexions TCP)
- reverse-proxy sur une 20ène de serveurs web Apache2/PHP, via l'IP publique
- reverse-proxy sur un cluster XMPP
Evidemment il y a quelques axes d'améliorations simple : passer par le
réseau privé pour limiter les connexions sur
l'interface réseau publique, ... mais ce n'est pas le but de ce mail.
Sous forte charge, parfois une simple connexion TCP a des difficultés pour
s'établir. Pour tester, j'écarte des soucis
potentiels avec NGiNX et lance un serveur netcat sur le port 8080 :
nc -l -k 8080
et depuis un poste client sous Linux :
while true; do date -R | tee -a /dev/stderr | nc -w 2 perceval.local 8080
|| echo ERR; sleep 0.2; done
Lorsque le problème survient, des "ERR" s'affichent.
A ce moment, j'ai tenté plusieurs choses pour tenter de trouver la source
de ces problèmes de connexions, et aucun ne
s'est avéré "payant" :
- désactiver le firewall
- supprimer et décharger conntrack
- changer l'algorythme de congestion TCP de cubic à autre chose
- mesurer le nombre de connexions TCP établit ou en FIN_WAIT : à 10k total
le soucis peut très bien se produire ou pas
- modifier plusieurs paramètre de config TCP / Kernel :
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_low_latency = 0
net.core.netdev_max_backlog = 4000
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 163840
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_max_tw_buckets = 400000
net.core.somaxconn = 8192
fs.file-max = 1310720
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
En vain. Sauf un paramètre qui débloque tout quand il est désactivé :
net.ipv4.tcp_timestamps=0
C'est très net, si je désactive les timestamps TCP coté serveur (ou coté
client forcément), je n'ai plus aucun problème
d'établissement de connexions TCP.
A ce moment commence les recherches sur Google, et tout ce que je trouve
est ambigu : il vaut mieux activer les
timestamps TCP pour des raisons de performances, mais il faut mieux les
désactiver pour des problèmes de sécurité.
Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement osef
nan ?
Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre en
cas de soucis de congestion TCP...
Peut-être qu'avec la quantité de trafic, le kernel n'est pas capable de
fournir assez de timestamps ? Peut-être que la
fréquence du timer Linux a une incidence ?
Le kernel utilisé est le 3.5.5 avec les patchs Google d'activé (RPS, RFS)
et cette config de timer :
CONFIG_NO_HZ=y
CONFIG_HZ_250=y
CONFIG_HZ=250
J'essaye avec 1000 HZ : aucune incidence.
La désactivation de ce paramètre net.ipv4.tcp_timestamps ne doit pas agir
que sur les timestamps, peut-être que les
algos de congestion TCP, ou certains modules, ou une partie de la stack
TCP, utilisent les timestamps TCP, et peut-être
que c'est un de ces modules qui pose problème ?
Avez vous déjà expérimenté ce type de soucis ?
Je suis dispo pour faire des tests si vous avez des idées !!
--
Greg
Bonjour,
Je travaille actuellement sur une architecture MySQL et cette discutions m'amène a une petite question.
Peu t'ont envisager d'avoir un serveur master en innodb-flush-log-at-trx-commit a 0 et un slave avec cette variable a 1?
Wallace <wallace(a)morkitu.org> a écrit :
Le 18/07/2013 20:12, Etienne Dechamps a écrit :
> On 07/18/2013 05:46 PM, Bégault Luc wrote:
>> Attention, cette méthode si elle fonctionne avec des tables MyIsam peut
>> poser des problèmes avec InnoDB
>> (http://dev.mysql.com/doc/refman/5.5/en/innodb-backup.html => pour un
>> snapshot fichier, mysql dit que le serveur doit etre arrété).
>
> Si c'est vrai, alors ça veut dire que le serveur n'est pas capable de
> résister à une coupure de courant, ce qui me semble peu probable (ça
> briserait d'ailleurs les garanties ACID, plus précisément la garantie
> de durabilité).
>
Pour InnoDB cela dépend de comment il est configuré notamment avec la
variable :
innodb-flush-log-at-trx-commit
à 1 les données sont 100% consistante sur le disque, aucune perte de
donnée possible en cas de coupure.
à 2 possibilité de perdre 1/2 secondes de transaction
à 0 possibilité de corruption de données importante, risque élevé mais
quel gain en performance
les backups dépendent donc notamment de cet élément
Hello !
J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine
de site.
Il y a aussi une vingtaine de bases de données MySQL.
Système sous debian, pas de trucs compliqués, y'a juste apache/php/mysql et
des services alacon dont on se fout ici.
Je cherche une solution fonctionnelle et propre tant qu'à faire pour
sauvegarder mes bases SQL.
J'ai lu autour de mysql dump, mais si j'ai bien compris, ça ne bloque pas
l'accès à la base pendant le dump, donc il peut y avoir des écritures
simultanées et ça met le truc en vrille.
M'enfin j'ai pas tout tout compris, donc je vous demande vos avis :)
J'ai 3,3go de db à sauvegarder (enfin, le dossier /var/lib/mysql fait
3,3go), et je voudrais avoir un ficheir sql par DB, et après j'envoie tout
ça ailleurs avec rsync.
Merci d'avance !!
Gaël
La réponse dépend beaucoup du fait que tu pisse faire une coupure de service ou non.
Sébastien Mureau <sebastien.mureau(a)gmail.com> a écrit :
J'en connais qui ne s'emmerdent pas avec le dump, ils font une copie des
fichiers présent dans le rep ou elles sont et les importes direct ...
On est loin des procédures habituelles ...
Le 18 juillet 2013 17:33, Gaël <gagou9(a)gmail.com> a écrit :
> Hello !
>
>
> J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine
> de site.
> Il y a aussi une vingtaine de bases de données MySQL.
>
> Système sous debian, pas de trucs compliqués, y'a juste apache/php/mysql
> et des services alacon dont on se fout ici.
>
> Je cherche une solution fonctionnelle et propre tant qu'à faire pour
> sauvegarder mes bases SQL.
>
>
> J'ai lu autour de mysql dump, mais si j'ai bien compris, ça ne bloque pas
> l'accès à la base pendant le dump, donc il peut y avoir des écritures
> simultanées et ça met le truc en vrille.
>
> M'enfin j'ai pas tout tout compris, donc je vous demande vos avis :)
>
>
> J'ai 3,3go de db à sauvegarder (enfin, le dossier /var/lib/mysql fait
> 3,3go), et je voudrais avoir un ficheir sql par DB, et après j'envoie tout
> ça ailleurs avec rsync.
>
>
>
>
> Merci d'avance !!
>
> Gaël
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>
>
--
***********************************************************************************************
This message and any attachments are confidential and intended for the
named addressee(s) only.
If you have received this message in error, please notify immediately the
sender, then delete
the message. Any unauthorized modification, edition, use or dissemination
is prohibited.
The sender shall not be liable for this message if it has been modified,
altered, falsified, infected
by a virus or even edited or disseminated without authorization.
***********************************************************************************************
