FRsAG July 2013

frsag@frsag.org

66 participants
21 discussions

[MISC] SysAdminDay
by Manuel OZAN 26 Jul '13

26 Jul '13

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

1 0

Apero parisien
by Sébastien FOUTREL 26 Jul '13

26 Jul '13

Hello tous. Avec cette chaleur je boirais bien une biere un soir. Des amateurs ?

10 13

Blocage de l'amorçage avec Linux 3.2 + Xen, fonctionne avec Linux 2.6.32 + Xen
by junky 26 Jul '13

26 Jul '13

Bonjour. Nous avons un problème sur plusieurs serveurs Supermicro (je vais inclure plus de détails sur la configuration plus tard): lors du démarrage Linux 3.2 linux-image-3.2.0-4-amd64 (Wheezy) comme DOM0 sur Xen 4.1 (xen-hypervisor-4.1-amd64 de Wheezy), le système se bloque après: [ 3.716174] scsi1 : ata_piix [ 3.722116] scsi2 : ata_piix [ 3.728407] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1860 irq 14 [ 3.742390] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1868 irq 15 Le système démarre correctement lors du démarrage sous Linux 3.2 sans Xen, ou lors du démarrage Linux 2.6.32 (linux-image-2.6.32-5-xen-amd64: Squeeze) sur Xen. J'ai essayé avec Xen 4.0: Squeeze (xen-hypervisor-4.0-amd64) le comportement est le même (il se bloque avec Linux 3.2). Les systèmes possèdent tous des 2 quad-core Xeon (E5320 ou E5405) avec 32 Go à 64 Go de RAM, avec comme cartes mères des Supermicro X7DB8. Voici un lspci sur l'un d'eux: 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1) 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 09:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] (rev 02) 0b:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI ES1000 (rev 02) C'est un serveur de test sur lequel le problème apparaît, alors n'hésitez pas à demander plus d' essais ou des informations qui peuvent être utiles. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (700, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash xen-hypervisor-4.1-amd64 depends on no packages. Versions of packages xen-hypervisor-4.1-amd64 recommends: ii xen-utils-4.1 4.1.4-3+deb7u1 Versions of packages xen-hypervisor-4.1-amd64 suggests: pn xen-docs-4.1 <none> Merci.

3 3

optim page load à l'autre bout du monde
by Greg 23 Jul '13

23 Jul '13

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

7 7

Re: [FRsAG] Incidence des TCP Timestamps sur les connexions
by Greg 23 Jul '13

23 Jul '13

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

1 0

Apéro de Lyon - Juillet
by cam.lafit＠azerttyu.net 23 Jul '13

23 Jul '13

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

2 3

Incidence des TCP Timestamps sur les connexions
by Greg 23 Jul '13

23 Jul '13

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

3 2

Re: [FRsAG] Sauvegarde MySQL
by LEFEVRE Hugo 19 Jul '13

19 Jul '13

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

3 2

Sauvegarde MySQL
by Gaël 19 Jul '13

19 Jul '13

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

13 14

Re: [FRsAG] Sauvegarde MySQL
by LEFEVRE Hugo 18 Jul '13

18 Jul '13

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. ***********************************************************************************************

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG July 2013