Nanawel a écrit 250 commentaires

Alors pour info, j'ai un Postfix sur mon home-server, mais il ne me sert que pour les services hébergés dessus (donc il envoie beaucoup depuis du noreply), et un peu pour des autres besoins, mais mon "vrai" mail est chez un hébergeur dont je tairai le nom par pudeur.

Mon Postfix est configuré pour utiliser le SMTP d'Orange en relayhost.
J'ai ensuite créé des adresses (on a droit jusqu'à 5 alias) en fonction de mes besoins, et je les utilise dans une sender_canonical_maps qui va bien.

Bien sûr, ça n'est pas comme si c'était réellement envoyé depuis mon serveur, mais ça apparaît notamment sur Gmail comme Envoyé depuis trucmuche@monhomeserver.dyndns.com via orange.fr, ce qui n'est pas si mal.

Tellement trôlle :p

Je n'ai pas voulu non plus aborder ces aspects ni les opinions qu'elles sous-entendent, et qui apparemment n'avaient pas changées depuis 15 ans, hélas. C'était des points qui nous divisaient fortement et que nous prenions soin d'éviter dans nos discussions, lui le premier. À ses yeux je sais que j'étais probablement un hippie insouciant et aveugle des vrais problèmes du Monde, quand lui était aux miens un libertarien pur jus tendance alt-right qu'en d'autres circonstances j'aurais abhorré.

C'était néanmoins un camarade. Nos routes se sont croisées. Elles ne ne feront plus.

J'étais surpris de voir (enfin) un nouvel article de son blog sur mes RSS ce matin, mais la lecture de son message a été une sacrée douche froide.

Nous n'étions pas proches, mais nous avons fait l'IUT à Toulouse ensemble entre 2004 et 2006, et je me souviens d'un camarade - certes un peu nerd - avec beaucoup d'humour, et un membre précieux de notre petit groupe de travail à l'époque.

Il m'a fait découvrir Machinae Supremacy - du temps où le groupe était encore underground et donc "écoutable" par sa personne - et par là-même m'a permis de mettre un pied une oreille dans le metal, et rien que pour ça, je lui en suis éternellement reconnaissant.

Cette nuit j'ai perdu l'accès SSH à mon serveur chez Gandi.

Après un ticket inutile qui a confirmé que le problème était bien de mon côté, j'ai tenté de redémarrer la box.

Et évidemment tout remarche (IGN, Gmail, SSH). Probablement suite au changement d'IP de la box (de 90.76.235.192 à 86.206.2xx.xxx).

Alors impossible de comprendre ce qui a bien pu coincer, mais une chose est quasi-sûre c'est que ça peut recommencer à n'importe quel moment, et c'est bien handicapant.

Tu dis avoir changé l'IP et le nom des clones, mais as-tu changé aussi leur adresse MAC ? (je ne sais pas si avec le système que tu utilises c'est automatique ou non)

Ah un de plus… Maintenant y'a aussi imap.gmail.com en IPv6 qui passe plus (à supposer qu'il passait avant, j'ai pas vérifié).

Ni ping ni connexion TCP.

$ ping imap.gmail.com
PING imap.gmail.com(wr-in-x6d.1e100.net (2a00:1450:400c:c0c::6d)) 56 octets de données
^C

$ mtr -r -c3 -TP993 imap.gmail.com
Start: 2020-10-23T10:59:38+0200
HOST: leto                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a01:cb19:85e4:f800:769d:  0.0%     3    0.4   0.4   0.3   0.5   0.1
  2.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0

En IPv4 toujours aucun problème évidemment.

Je suis dans le flou :\

Effectivement, c'est le minimum.

Bon par contre ça ne change rien, hélas : toujours pas de connexion en IPv4 sur remonterletemps.ign.fr :

$ mtr -4 -r -c3 -T -P443 remonterletemps.ign.fr
Start: 2020-10-22T11:47:07+0200
HOST: leto                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%     3    0.4   0.4   0.4   0.5   0.0
  2.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0
  3.|-- lag-111.nctou101.Toulouse  0.0%     3    1.4   1.6   1.1   2.3   0.6
  4.|-- 193.252.160.9             33.3%     3  3210. 2109. 1008. 3210. 1556.9
  5.|-- ae43-0.nipoi201.Poitiers.  0.0%     3    6.9   9.8   6.9  14.7   4.3
  6.|-- 193.252.137.18             0.0%     3   11.6  14.8  11.6  20.9   5.2
  7.|-- hundredgige0-5-0-22.pastr  0.0%     3  3171. 1066.  13.5 3171. 1823.4
        hundredgige0-2-0-14.pastr4.-.opentransit.net
        hundredgige0-4-0-13.pastr4.-.opentransit.net
  8.|-- zayo-8.gw.opentransit.net  0.0%     3   24.9  28.3  24.9  30.3   3.0
        zayo-9.gw.opentransit.net        
  9.|-- ae4.mpr2.cdg12.fr.zip.zay  0.0%     3   93.8  97.2  93.8 101.8   4.1
 10.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0

$ curl -v https://remonterletemps.ign.fr
*   Trying 185.113.40.99:443...
^C

Et la connexion en IPv4 vers le SMTP de Gmail fonctionne toujours - comme attendu - mais toujours pas en IPv6 puisque… ben je l'ai désactivé.

Oui j'avais pensé à désactiver l'IPv6 puis mes tests semblaient démontrer que le problème n'était - au moins uniquement - limité à cet aspect, donc j'ai préféré le laisser car pour certains cas d'usage c'est pratique.

Le test Gmail en IPv6 fonctionne parfaitement depuis une autre connexion que celle de chez moi, donc non a priori le service est ouvert et opérationnel (le contraire serait étonnant de la part de Google).

Effectivement le test de ping est un simple complément au reste. Ça permet surtout de valider la partie IP sans la partie TCP.

Hello,
Très intéressé pour remplacer mon vieux (mais néanmoins vaillant) portable de 2008.
Une adresse mail ou autre pour te contacter ?

C'est effectivement une très bonne remarque. Cette idée m'avait traversé l'esprit mais j'ai pensé que c'était plutôt réservé à des HDD de plus grosses capacités, en oubliant que justement les constructeurs s'étaient fait pincer récemment à omettre ces informations sciemment sur certains modèles…

Merci pour les docs, effectivement c'est une erreur de ma part en choisissant les disques. J'ai un peu trop joué sur le côté Inexpensive du RAID en prenant des disques d'entrée de gamme. Je note de remplacer le Barracuda qui n'est pas adapté à l'usage.

Oui pardon, j'avais bien compris le principe du NCQ pour les disques et de sa pertinence pour améliorer les perfs, mais presque tous les articles que j'ai vus qui parlaient de solutions concernant la lenteur d'un reshape de RAID5 disaient de le désactiver (càd de passer à 1).

Or chez moi ça a exactement l'effet inverse et baisse considérablement les débits. Alors que le laisser à 32 permet de revenir à des performances acceptables.

Ah, et passer /sys/block/$dev/device/queue_depth de 8 à 16 permet de gagner encore 5 Mo/s (soit environ 23 Mo/s).

Je l'avais abaissé à 8 en supposant qu'il s'agissait d'un bon compromis entre 1 (les conseils lus à droite et à gauche) et 32, la valeur par défaut.

Le repasser à 32 m'a encore permis de remonter à 27 Mo/s. Je comprends vraiment pas ces conseils.

Et le truc qui sauve vraiment, c'est le write cache des disques. C'est souvent désactivé par défaut parce qu'en cas de coupure brusque, ça fait de gros dégats dans le FS. Mais ça accélère vraiment sur des I/O un peu intenses.

Ah oué c'est radical oO

Je passe instantanément (ok non en quelques minutes) à 18 Mo/s.

Le serveur étant sur un onduleur avec 30mn d'autonomie et une extinction automatique propre on va dire que c'est plutôt safe. Dans tous les cas, c'est principalement des backups donc pas de question de vie ou de mort en cas de perte des données.

Merci !

Bon, après 5mn pas de changement notable malgré les "optimisations" apportées :(

Je déconseille par contre fortement dans une situation similaire de suivre les conseils indiquant qu'il faut désactiver le NCQ sur les disques : en faisant ça le débit a chuté chez moi en 1mn à ~500 ko/s ! (j'avais déjà testé ça en début de semaine avec le même résultat)

Ouais je crois que c'est ce qui fait toute la différence ici. Il faudrait (aurait fallu) que j'augmente la taille des chunks en passant du RAID1 à RAID5.

A priori c'est possible de le faire a posteriori, mais encore faut-il que le reshape se termine d'abord…

(et j'imagine que cette action va aussi prendre des plombes pour les mêmes raisons)

Très juste, j'avais oublié de mettre la sortie de mdadm --detail /dev/md0, j'ai corrigé ça.

Normalement ça permet de dire que j'utilise déjà un internal bitmap. C'est bien le but de ta première commande ?

Pour les commandes suivantes voici l'état actuel :

# cat /proc/sys/dev/raid/speed_limit_max
200000

# cat /sys/block/sd[a-d]/queue/read_ahead_kb
128
128
128
128

# cat /sys/block/sd[a-d]/queue/nr_requests
64
64
64
64

# for dev in $(echo /dev/sd[a-d]); do echo -n "$dev: "; blockdev --getra $dev; done
/dev/sda: 256
/dev/sdb: 256
/dev/sdc: 256
/dev/sdd: 256

# blockdev --getra /dev/md0
65536

# cat /sys/block/md0/md/stripe_cache_size
8192

# cat /sys/block/md0/md/stripe_cache_active
12041

Bon clairement y'a des choses à ajuster. Je m'en vais tenter ça de suite. Merci !

Autres sources trouvées à ce sujet en passant, avec des valeurs égales ou similaires :
- https://wtf.roflcopter.fr/links/pogo/?nICtQw
- http://wiki.alessandro.delgallo.net/wiki/index.php/RAID

Quand j'ai vu ces perfs j'ai cherché une explication dans les logs, et notamment des erreurs SATA (par expérience…). Mais là rien du tout, les logs systèmes sont cleans, rien à redire.

Si le problème était lié au débit es interfaces, je pense que les tests hdparm l'auraient révélé.

Quelle est la taille des chunks sur ta grappe ?

J'y ai pensé aussi, mais quand je regarde le load je vois surtout beaucoup d'iowait et pas beaucoup de temps kernel ou user (80% d'iowait contre 10% max de kernel+user). À mon sens ça devrait pourtant se traduire par une occupation forte de ces états.

La sortie de mon dmesg :

[    4.470732] raid6: sse2x1   gen()  2107 MB/s
[    4.538717] raid6: sse2x1   xor()  2003 MB/s
[    4.606728] raid6: sse2x2   gen()  3375 MB/s
[    4.674719] raid6: sse2x2   xor()  3409 MB/s
[    4.742733] raid6: sse2x4   gen()  4054 MB/s
[    4.810714] raid6: sse2x4   xor()  2175 MB/s
[    4.810717] raid6: using algorithm sse2x4 gen() 4054 MB/s
[    4.810718] raid6: .... xor() 2175 MB/s, rmw enabled
[    4.810720] raid6: using intx1 recovery algorithm

Pas top certes, mais pas trop dégueu non plus je pense, non ?

Oh OK merci :)

En effet ça semble logique. Mais où vois-tu cette valeur de ~75 IOPS dans les sorties des commandes ? Je suis curieux je n'y vois que des valeurs en ko/s.

Je ne sais pas comment faire pour augmenter la quantité de données lues à chaque "tour", je pensais que la commande blockdev --setra servait à ça, mais apparemment mdadm ne semble pas trop y voir de différence.

Si j'avais une solution qui impliquait d'augmenter sensiblement la RAM occupée pour ce travail (en travaillant sur de plus gros lots de données) ça ne me dérangerait pas, j'ai encore presque 3 Go libres, mais je ne trouve rien qui permette ça.

Et je plussoie également pour borg, avec tous les avantages décrits par les précédentes réponses.

Je suis également tombé sur un service de sauvegarde que j'ai failli prendre¹ et qui allie simplicité et faible coût : https://www.rsync.net/products/borg.html
En gros, il s'agit simplement d'un serveur de stockage utilisable avec rsync… et borg évidemment. Ça revient à $12.50 par mois pour 500 Go de stockage, ce qui me semble pas mal.

---

¹ Finalement j'en suis resté pour l'instant à de l'auto-hébergement à ce niveau, mais je n'exclue pas d'y souscrire à terme.

En effet, ça confirme mes doutes sur la faisabilité.

Je ne sais pas si tu as testé car tu ne le mentionnes pas, mais as-tu essayé la virtualisation ?
Pour une application 3D je n'aurais pas trop d'espoir malheureusement, mais il semble y avoir un peu de doc qui traîne et qui semble faire penser que c'est possible : https://all3dp.com/2/fusion-360-for-linux-how-to-install-it/

Idem quand je clique sur un lien extérieur à Twitter. Par contre une fois la page d'erreur affichée, forcer le rafraîchissement (Ctrl+Shift+R) permet d'accéder à la page voulu, alors qu'un simple rafraîchissement ne fait rien de plus.