kortex a écrit 103 commentaires

Merci je regarde demain aussi à ce niveau :)

Par rapport aux paramètres ici : https://unix.stackexchange.com/questions/524295/how-long-does-conntrack-remember-a-connection

On peut essayer de chipoter à des valeurs dans un prochain test et vous donner le résultat :)
Par contre comme dit on a pris l'ensemble de "sysctl -a" de CentOS 7 et on l'a appliqué sur CentOS 8.
Évidemment, si une clef existe sur CentOS 8 et pas sur CentOS 7 alors je suis d'accord : la valeur n'a pas changée et donc ça mérite que l'on s'y intéresse quand même :)

On pense aussi que c'est côté firewall qu'il faut se concentrer bien qu'on puisse jamais être sur à 100%.
En tout cas c'est la meilleure piste que nous avons :)

Le truc c'est qu'on a cherché (peut être pas assez) et on a rien vu qui puisse nous aider.
J'ai oublié de préciser qu'à un moment un collègue a tenté de logger via iptables et idem on a rien trouvé de probant pour nous aider…

Attention par défaut nous sommes sur le frontend iptables pas nft (c'est historique : pour l'instant nous n'avons pas migré).
Demain je pourrais donner un exemple de ce que l'on a en iptables :)

Et effectivement il y a bien une règle pour le ESTABLISHED ;)

Quels sont les postgresql utilisés ? Ce sont ceux de CentOS des deux côtés ?? Et des canaux/dépôts par défaut ? Sur chaque système (7 & 8) on peut installer différentes versions (celle de base, celle via des canaux particuliers centos, voir des canaux externes, ou bien une compilation). Connaitre les versions est un élément important pour une aide éventuelle.

PostgreSQL vient des dépôts PostgreSQL et non ceux de CentOS.
Les versions :
- serveur : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 7 : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 8 : PostgreSQL 10.11 sur CentOS 8.1 puis on a mis à jour en PostgreSQL 10.12 pour essayer (depuis la 10.13 est sortie mais nous n'avons pas essayé)

Avez vous décomposé les phases du scripts pour les faire une à une à la main ? C'est long, OK, mais cela permet de mettre de côté ce script lui même et d'avoir une présomption supplémentaire sur le périmètre exact à l'origine du problème. A moins qu'aucun problème ne surgisse lors de l'exécution à la main des phases essentielles, alors là, il faudra voir le script, mais c'est à priori peu probable, cependant mérite de transformer le peu probable en certitude.

Oui des tests manuels ont été réalisés et nous ont permis d'écarter la piste du script Python : nous avons testé le pg_restore sans les fameux scripts SQL et le problème est le même.
En gros, quand on test un scénario, on se mets dans une boucle de minimum 4 itérations et on lance les pg_restore.

A quel moment exact cela "time out" ? Une durée n'est pas suffisante, il faudrait préciser si cela se produit toujours à la même étape, et quelle est cette étape. Si c'est toujours à la même étape, alors le point précédent peut se concentrer là dessus uniquement.

C'est toujours sur la même table mais les valeurs du "TOC" (Error from TOC entry 31721; 2606 45850 FK CONSTRAINT mytable1 key_1 myowner) que j'ai donné sont pas forcément les même : on est plus ou moins loin dans la table.
Le truc c'est qu'on est toujours plus ou moins au même endroit du restore après un même temps d'exécution car nous avons globalement des performances constantes.

Enfin, toutes les opérations réussissent à tout les coups lorsque le pare-feu de centos8 est désactivé ? Ce point n'est pas bien clair or il semble primordial, car si c'est le cas, les précédents points sont inutiles : il faut se concentrer sur ça et éventuellement le pg_hba. à priori je ne pense pas, car sinon il n'y aurait pas ce long texte, mais n'étant pas sûr d'avoir bien compris ce point je préfère demander

C'est bien ça : avec le pare-feu désactivé, tout est ok.
Niveau pare-feu nous avons essayé :
- en conservant notre iptables historique (ça limitait nos changements déjà au combien nombreux pour ce projet)
- en utilisant le frontend firewalld
- en utilisant le frontend nft
-> même soucis : si un pare-feu est activé sur le CLIENT CentOS 8, alors le pg_restore échoue.

Je vais m'intéresser à cette technologie et voir ce que ça donne merci pour l'info :-)

J'essaie de configurer le SRV mais ça ne fonctionne pas ; j'ai peut être loupé quelque chose.
Voici ma zone exemple :
$TTL 3600
$ORIGIN example.local.

@      IN      SOA      ns1.example.local.             contact.example.local.      (
                                                                        2015090801
                                                                        21600
                                                                        3600
                                                                        604800
                                                                        86400
)

example.local.                                                 IN    NS     ns1.example.local.
example.local.                                                 IN    NS     ns2.example.local.

ns1.example.local.                                             IN    A      192.168.1.3
ns2.example.local.                                             IN    A      192.168.1.4

www1.example.local.                                            IN    A      192.168.1.3
www2.example.local.                                            IN    A      192.168.1.4

_http._tcp.www.example.local.                                  IN  SRV  0         2     80  www1.example.local.
                                                               IN  SRV  0         1     80  www2.example.local

Hors, si je pointe mon PC vers ce serveur DNS :
- www1.example.local résout bien avec nslookup
- www2.example.local résout bien avec nslookup
- www.example.local n'est pas résolu
- une connexion sur http://www.example.local/ avec Firefox ne donne rien

Est-ce qu'il me manque quelque chose dans la zone ?

Désolé pour la réponse tardive je n'ai pas trop eu le temps de me consacrer à ce problème ces derniers jours.

Nous préférons garder la main sur l'infrastructure et ne pas sous-traiter ce genre de service mais merci quand même pour l'info :-)

Non les machines sont toutes installées de la même manière par un script maison qui gère des profils (genre machine SQL / machine de backup / etc). En fonction de ce profil, le script installe tel ou tel paquet et mets en place tel ou tel fichier de configuration.

Les machines sont 100% identiques.

Avant on sauvegardait sur un slave mais en creusant un peu sur le net, nous avons lu plusieurs articles qui expliquent que les slave MySQL ne sont pas toujours consistants (même si 'SHOW SLAVE STATUS' te dit qu'il est à jour). Le Slave est là en cas de dernier recours mais dans la mesure du possible, nous ne lui faisons pas confiance et nous ne l'utilisons pas.
D'ailleurs j'ai écarté la piste du dump en testant sur un slave : la consommation mémoire n'a pas bougée.

Une seule ligne de différence entre notre master et notre slave : "read_only = 1" sur le slave.
Version identique (5.5.40) des deux côtés. Les machines sont identiques mais dans deux datacentres différents.

Il y a environ 1H / 1H15 de sauvegarde pour une base.

Je suis d'accord avec toi mais j'ai deux soucis :
- 1/ c'est une production très très critique : je ne peux pas jouer sans savoir comment ça va réagir
- 2/ comme je n'arrive pas à reproduire le soucis, je ne peux pas le qualifier :(

J'aurais pu désactiver le oom killer pour MySQL également mais si la machine s'effondre le soucis reste le même :-/

Oui alors il y a :
- 2 "grosses" bases de données qui génèrent 99.9% de la charge
- une dizaine de petites DB's mais qui ne sont pas beaucoup sollicitées
- la première base c'est l'applicatif ; 190 Go sur disque ; 603 tables
- la deuxième base c'est les logs ; 259 Go sur disque ; 13 tables
- moteur = InnoDB dans les deux cas

Pour donner une information complémentaire, depuis le redémarrage de MySQL :
- toute la journée je suis resté à 20% de mémoire environ (ps aux)
- la nuit, pendant les sauvegardes, je suis monté à 75%
- le lendemain (donc hier) ça a continué de monté jusqu'à 80%
- cette nuit, on est retombé à 68%

On aurait pu penser qu'il s'agissait d'un soucis avec mysqldump mais j'ai lancé la même sauvegarde sur un des slave : la mémoire utilisée n'a pas bougée.

J'ai revérifié les traitements qui tournaient dans ces heures la : rien de spécial. Et surtout il n'y a aucune modification de code qui pourrait expliquer une telle consommation.

J'ai suivi la piste d'une attaque sur des sites (même s'ils ne sont pas référencés etc) : rien à déclarer.

Du coup je me pose plusieurs questions :
- fuite mémoire de MySQL ?
- problème dans le kernel (3.18.9 hardened - Gentoo) ?
- ma configuration qui n'est pas bonne (d'après toutes les règles de calcul on a de la marge)
- suite logique des briquage de samedi ?

Malheureusement je ne trouve aucune information nul part :-/

Bonjour,

Je te remercie pour la réponse mais en faites, dans l'idéal, j'aimerais comprendre ce qu'il s'est passé et non régler le soucis de l'oom. Il n'est pas logique que la consommation soit montée autant d'un coup :-(

Déjà petit erratum : c'est pas 23H50 mais 2015-06-15T23:50:01,910825+0200 soit, si je ne me trompe pas, 00H50 et la c'est plus logique.

Par contre je ne comprends par pourquoi la sauvegarde aurait tiré autant de RAM.
Si quelqu'un a des informations la dessus je suis preneur.

C'est vraiment bizarre car j'avais trouvé ceci :
http://www.armetiz.info/keepalived-configuration-firewall/?PageSpeed=noscript

On voit bien une configuration iptables pour autoriser la communication. Moi je n'ai rien autorisé et ça fonctionne. Bizarre non ?
Je veux bien ouvrir le protocole vrrp mais pour telle et telle machine source pas plus ;-)

Bonjour,

Je te remercie pour ta réponse.

Je viens de finir quelques tests avec KeepAlived sur 3 nœuds : effectivement il est bien plus simple que Heartbeat ou le couple ( Corosync + Pacemaker) et semble répondre au besoin très simplement.

Par contre, je bloque quand même sur quelque chose de simple : j'ai un pare-feu iptables sur chaque nœud qui autorise toutes les connexions en sortie mais limite les protocoles autorisés en entrée (exemple : http + https).
Je n'ai rien configuré pour KeepAlived et il fonctionne quand même : pourquoi ?
Peut-être que je me trompe mais cela signifie qu'une personne mal intentionnée pourrait, en ayant trouvé le mot de passe, s'incruster dans mon cluster KeepAlived ?!

Bonsoir,

Je te remercie pour ta réponse mais nos deux cas ne m'ont pas l'air comparables et ta solution me parait bien compliquée pour ce que je veux faire :-/

Dans mon cas :

• plusieurs IP publiques sur plusieurs de ces 3 serveurs : une seule machine doit être master à la fois
• plusieurs serveurs qui écoutent la même IP (la solution technique de mon hébergeur ne permet pas ce genre de chose)
• je ne peux rien faire niveau DNS : UNE adresse IP = UN site ou UN service selon ce qui se trouve derrière
• la machine qui reçoit les connexions est déjà un répartiteur de charge donc je n'ai pas besoin de ce type de fonctionnalités

Dans l'idéal, le soft que je cherche dirait :

• telle machine est maître
• telle machine est esclave
• telle machine est esclave
• le maître tombe (non joignable par aucun des deux slaves) : un des esclave est élu maître
• à partir du moment où il est élu maître, il exécute un script

S'il y a en plus une notion de votant uniquement (un peu comme un ReplicaSet MongoDB) c'est encore mieux car je pourrais déclarer 2 ou 3 arbitres supplémentaires pour répartir le risque.

Bonjour,

J'ai résolu le soucis : j'ai commandé la même machine en prenant une option raid hardware.
Pour les chiffres du chargement d'un gros dump :
- ancienne machine (avant première migration) : 8H
- nouvelle machine en raid soft : 14H
- même machine en raid hard : 5H

Merci à tous ;)

Ce sont des secteurs à 512 bytes et les partitions sont alignées

Quand je fais des tests bruts, je gagne en performance.
Il ne s'agit pas de disques SSD effectivement mais bien de disques durs mécaniques.

Comment tu mesurerais ce temps d'accès moyen ?

Est-ce qu'il ne s'agirait pas du paramètre 'async' à mettre dans /etc/fstab ? Quel est le risque en raid software ?

Bonjour,

Je te remercie pour ta réponse ; je ne connaissais pas ces utilitaires.

Voici quelques mesures :

• débit en lecture sur la nouvelle machine (à vide) :

  ioping -RL /dev/md4

  --- /dev/md4 (device 2.7 TiB) ioping statistics ---
  2.0 k requests completed in 3.0 s, 654 iops, 163.5 MiB/s
  min/avg/max/mdev = 33 us / 1.5 ms / 98.6 ms / 2.4 ms

• iops en lecture sur la nouvelle machine (à vide) :

  ioping -R /dev/md4

  --- /dev/md4 (device 2.7 TiB) ioping statistics ---
  253 requests completed in 3.0 s, 84 iops, 336.0 KiB/s
  min/avg/max/mdev = 2.9 ms / 11.9 ms / 41.1 ms / 4.0 ms

• débit en lecture sur l'ancienne machine (à vide) :

  ioping -RL /dev/sda3

  --- /dev/sda3 (device 2.7 TiB) ioping statistics ---
  1.9 k requests completed in 3.0 s, 652 iops, 163.2 MiB/s
  min/avg/max/mdev = 70 us / 1.5 ms / 17.9 ms / 459 us

• iops en lecture sur la nouvelle machine (à vide) :

  ioping -R /dev/sda3

--- /dev/sda3 (device 2.7 TiB) ioping statistics ---
226 requests completed in 3.0 s, 75 iops, 301.8 KiB/s
min/avg/max/mdev = 171 us / 13.3 ms / 41.7 ms / 4.4 ms

Pour iozone, copier le contenu ici était compliqué alors j'ai placé le contenu sur pastebin :

• nouvelle machine : Pastebin
• ancienne machine : Pastebin

J'ai forcé la taille du fichier à 64 KB pour avoir une première mesure. Je ne sais pas spécialement comment interpréter les résultats mais la conclusion est la même qu'avec MySQL : les performances sont meilleures sur l'ancienne machine. Qu'en penses-tu ?

Pour le déplacement de MySQL, non ; pas sans réinstaller la machine. Ce sera mon dernier recours si vraiment je n'ai pas le choix.

Pour 'innodb_flush_method' je suis sur la valeur par défaut (donc 'fsync'). La documentation de MySQL dit quand même de faire son choix selon si tu es sur raid hard, san, etc. Du coup, soit je me trompe complètement, soit jouer avec ce paramètre revient à jouer avec le 'barrier' : c'est juste bon le temps d'un test.

Oui innodb-file-per-table est activé (sur les deux machines ; l'ancienne et la nouvelle).

J'ai eu exactement le même soucis sur une machine de prod un jour ; c'était un contrôleur raid matériel. Le soucis venait du cache qui était à 'WriteThrough' au lieu de 'WriteBack' (défaillance de la batterie = désactivation du cache). Les symptômes étaient les même : journalisation en top liste.
Du coup je me demande vraiment s'il n'y a pas un soucis au niveau de mdadm ; un réglage ; un "cache" à activer / désactiver. Si tu connais quelque chose à ce niveau je suis preneur.

Bonjour,

Je vais surement tester le barrier = 0 mais il faut le prendre avec des pincettes celui-ci. Comme je n'ai pas de système de cache avec batterie, c'est relativement risqué non ?

Sinon entre 'noatime' et 'data=ordered' je suis bon quoi :-/

Il y un détail que je remarque :
- sur la nouvelle machine qui est lente, iotop pendant le chargement du dump :
1/ jbd2/md4-8 (entre 60 et 80%)
2/ mysqld (3%)
3/ mysqld (1,5%)

• sur l'ancienne machine qui est rapide, iotop pendant le chargement du dump : 1/ mysqld 2/ mysqld 3/ jbd2/md4-8

Les débits restent similaire (une trentaine de Mo/s) pendant la restauration ; je pense donc que c'est "normal".
Par contre c'est bizarre que dans un cas la journalisation soit le plus gros consommateur est pas dans l'autre.

Effectivement ça peut être des pistes mais temporaires.
Le problème est apparu en changeant de machine et ne s'est jamais posé avec une machine bien moins puissante. Il y a donc un soucis de fond et c'est celui-ci que j'essaie de résoudre.

Je reste persuadé qu'il y a quelque chose à faire au niveau /etc/fstab ou mdadm mais je sèche :-/

Alors mysqltuner ne retourne rien de probant (sauf que mon cache n'est pas utilisé mais ça c'est pas un scoop pour moi).
Par contre, c'est bien ce que je pensais, les résultats de ce script sont à prendre avec des pincettes :
[…]
[--] Data in InnoDB tables: 411G (Tables: 1599)
[…]
Variables to adjust:
long_query_time (<= 10)
query_cache_limit (> 128M, or use smaller result sets)
innodb_buffer_pool_size (>= 411G)

Je vais regarder dès que j'arrive au bureau en espérant que ça me donne une bonne piste ; je te tiens au courant.