Prêt à installer du cache ZFS L2ARC pour booster les performances du serveur. Il reste de la place pour du ZIL sur barrettes Intel, en attente de leur arrivée.
Test concluant, mon processus hebdomadaire de mise à jour OSM pour https://signal.eu.org/osm/ a pris 6h56 cette nuit au lieu de 8h10 la semaine dernière.
Possiblement également lié à la mise à jour FreeBSD 13.2 vers 14.0 qui est supposée donner de meilleures performances en ZFS, mais je doute que cela explique une telle différence.
@Agonie 64 Go de RAM et 16 To utiles en disque. Contrairement à une croyance qui semble répandue, un peu de RAM ne remplace pas un gros cache disque rapide de toute façon, ne serait-ce que pour accélérer le temps de boot, ou quand il expire pour des outils lancés rarement (cas typique = scripts Python appelant plein de modules).
@pb La croyance, c'est les recommandations de ZFS. L2ARC, même sur un SSD est beaucoup plus lent qu'ARC, et il faut finalement assez peu de ram/TB pour ARC.
Pour optimiser les vitesses de lecture/écriture, tu auras plus de gain en utilisant des SSD (redondés) dédiés au stockage des métadonnées de la pool.
@Agonie de toute façon ici ce n'est pas ARC ou L2ARC, c'est ARC seul ou ARC + L2ARC. Je ne peux pas mettre 500 Go de RAM dans cette machine, par contre je peux facilement y mettre 500 Go de SSD en L2ARC. Après, je ne connais comme possibilités que L2ARC ou SLOG/ZIL, c'est de quoi que tu parles pour les métadonnées ?
@pb L'ajout de L2ARC est connu pour ne pas permettre d'obtenir l'accélération de perfs attendues. Un cache ARC ne se rempli pas non plus comme ca, et l'algo de cache/vidage est assez fin.
A côté, dans une pool ZFS, tu peux faire des volumes dédiés au stockage des meta-données des fichiers, qui sont par défaut stockés dans les mêmes volumes que ceux contenant les données. Ces volumes sont les "special devices". Ces volumes peuvent aussi contenir les petits fichiers (à configurer).
Là où ARC (et L2ARC en dernier recours) ne servent que pour du cache de lecture, donc pour les données les plus utilisées ou récentes, les special devices sur SSD accélèrent les lectures/écriture de l'ensemble de la pool en permettant des accès rapides aux métadonnées qui ne sont pas dans ARC. C'est la principale recommandation pour gagner des perfs avec ZFS.
@Agonie je vois bien une nette accélération de perfs avec du L2ARC sur ma machine de bureau hein... moi ça me va. Le coup du "special device" me semble plus risqué (on doit bousiller et perdre le volume si le special device tombe en rade) et ne couvre que les metadonnées, ce qui ne m'intéresse pas.
@pb With 300 TBW that drive is not really suited for even medium term use for this purpose.There are drives - even in the consumer segment - that perform significantly better. btdt.
@pb been there done that. for the openbsd & co mirrors we run. After brief review of the market I went with seagate firecuda 530. Not great either but more than double TBW of the previously used drives which expired within roughly a year. (due to TBW reached)
@nblr ok... thanks. I'm probably well below OpenBSD mirror levels, but I'll keep a close look on the write rate and reuse that disk on another machine if necessary :)
@pb It will probably be alright for at least a while but it's something to look out for. It caught me by surprise back then. Completely underestimated the load vs. endurance figures being that relevant.
@nblr@pb I have this kind of setup on my home NAS and according to the drives specs, i'm safe for about 10 years. It's true you're playing with fire, but the drive won't wear out in minutes, they're easy to replace, and they'll be even cheaper in the future.
As long as the data stays on spinning disks, that setup seems relatively safe, to me, for my usage.
@zuzur@pb It fails gracefully, indeed. Unless your load figures are high. (which killed the box in our case)
For log not using mirror is suicidal however.
Add comment