FRsAG

frsag@frsag.org

10 participants
2597 discussions

Serveurs MySQL, binlog, DRBD et perfs IO
by Greg 08 Aug '13

08 Aug '13

Bonjour la liste, je dois remplacer 2 serveurs master MySQL redondés par DRBD. A l'époque j'avais du diminuer les écritures en utilisant le protocole B de DRBD, et en baissant le nombre de sync ... heureusement je n'ai jamais eu de bascule foireuse :) Mais cette fois je voudrais que ça tienne avec la bonne config : sync_binlog=1 innodb_flush_log_at_trx_commit=1 et le protocole C de DRBD. Les serveurs actuels sont équipés de RAID10 6 disques SAS @15krpm et carte raid avec 512Mo de cache. Pour les remplacer, j'hésite entre 2 configs : - 2 RAID10 SAS : 1 pour les datas, 1 pour les binlogs - 1 RAID1 SAS pour les datas, 1 RAID1 SSD pour les binlogs (ou l'inverse...) C'est l'occasion d'utiliser du SSD en production, mais pour l'instant les tests que j'ai pu faire avec du SSD cheap ne sont pas concluants du tout. Avec du pro ça devrait être mieux mais je n'ai pas pu tester. Qu'en pensez vous ? -- Greg

7 10

détecter une tentative de spam sur POSTFIX/DOVECOT (compte mail piraté)
by Antoine Durant 04 Aug '13

04 Aug '13

Bonjour, Je cherche un script/commande qui me permet de savoir qui envoi des messages depuis DOVECOT/POSTFIX. En fait, la semaine dernière j'ai un compte utilisateur qui je pense via une attaque dictionnaire a été utilisé pour envoyer un grand nombre de mail... Je cherche un moyen plus rapide de savoir à un instant T qui utilise le service pour envoyer des mails. Une sorte de compteur d'envoi par compte ou je ne sais quoi afin de pouvoir identifier le ou les comptes qui posent problèmes ! Comment faites-vous, une astuce ou une commande plus ou moins magique ? Merci pour les retours !

10 10

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG