[technique] DELL R720

Mathieu Goessens (Breizh-Entropy) mathieu at breizh-entropy.org
Sam 26 Sep 22:07:57 CEST 2020



Mathieu Goessens (Breizh-Entropy) via technique:
> 
> 
> Alexandre GUY via technique:
>>> Le 25 sept. 2020 à 20:31, Fabien ADAM via technique <technique at lists.tetaneutral.net> a écrit :
>>> Le 23/09/2020 à 23:34, Alexandre GUY via technique a écrit :
>>>> Matthieu Herrb a passé hier ma VM à 4Go de ram, cette nuit pas de services oom-killés, pas eu à les relancer à la mano ce matin, on verra demain.
>>>
>>>
>>> Tu vois, c'était la RAM, pas le cluster Ceph ;)
>>>
>>> D’ailleurs, tu peux nous dire si le temps de sauvegarde a éventuellement baissé suite à cette opération ?
>>
>> Aujourd’hui le backup s’est terminé à 10h, il a donc mis « que » 7h, au lieu de 10h avant l’augmentation de la ram.
>>
>> Le passage à 4Go de ram a amélioré le temps de sauvegarde, je n’ai pas pris de OOM killer, c’est cool … mais 7h ça continue d’être long, car pendant ce temps, la VM est un peu à la ramasse. Donc ça ne résout pas complètement les problèmes de lenteur pour accéder à pleins de petits fichiers.
> 
> As-tu regardé quelles étapes prenaient du temps ?
> 
> Veux tu partager tes scripts // un aperçu des volumes de données qu'ils
> traitent?
> 
> Les maildirs plein de petits fichiers c'est *jamais* rigolo à backuper,
> mais peut être y a t il des choses à faire pour améliorer leurs
> performances, par exemple,
> 
> - si tu fais tous tes tgz d'un coup, puis les copie, tous d'un coup, les
> copier juste après les avoir générés permettrait d'éviter de les relire
> (et potentiellement de paralléliser)
> 
> - si les fichiers sont gros (trop pour tenir en ram), et changent tous
> les jours, scp à la place d'rsync sera vraisemblablement plus performant
> (pas de comparaison de checksum sources / destinations, d'autant plus
> important si c'est sur des répertoires entiers)
> 
> - je suppose que tu n'utilises pas rsync -z ? Sinon, il ne sert
> vraisemblablement à rien, les fichiers étant déjà compréssés.
> 
> - si tu gzip plusieurs Go à chaque fois, et a plusieurs cores, pigz
> (https://zlib.net/pigz/) devrait etre plus performant que gzip (tu peux
> le ln -s / dpkg --divert à la place de gzip), le gain est quasi linéaire
> par rapport au nombre de cores.
> 
> - gzip, comme pigz permettent de régler le niveau de compression.
> Généralement diminuer celui-ci raisonnablement impacte peu la taille des
> fichiers générés mais énormément les temps d’exécution (et peut être la
> mémoire).
> 
> - la réactivité de ton système s'en ressent elle si tu lances tes
> scripts à coup de nice -n10 ( / -n15 / -n20 ) sans que cela augmente
> trop les temps de backup ?
> 
> - quid de juste rsync sur ton serveur et faire les tgz à l'autre bout
> (tu profiteras ainsi pleinement du coté incrémental d'rsync) ?
> 

+ mount -o remount,noatime sur les partitions qui stockent les mails,
parce que tar/rsync sur des millions de petits fichiers, ça ne pardonne
pas, si tu dois re-écrire la date d'accès à chaque fois fois que les
lis, surtout si c'est répliqué x3.

-- 
Mathieu Goessens
Hackerspace Breizh-Entropy



Plus d'informations sur la liste de diffusion technique