2026 : Mac Mini loué 7×24 — matrice Valkey (compatible Redis) : AOF, fragmentation et seuils disque
« Valkey hérite des mêmes compromis que Redis sur un Mac Mini Apple Silicon loué : la réécriture AOF et le fork (selon configuration) peuvent coûter I/O et RAM pendant que vos workers croient être seuls sur la machine. Une matrice de seuils évite de découvrir la fragmentation ou la ligne d’eau disque un vendredi 22 h. »
Public : équipes qui utilisent Valkey comme cache, courtier ou backend compatible Redis sur un nœud 7×24. Livrable : table de décision, quatre piliers (persistance, éviction, sauvegarde, coexistence), seuils actionnables, FAQ et parcours d’achat. Pour la base Redis classique, voir la matrice AOF/RDB Redis ; pour Sidekiq et files, la matrice Sidekiq ; pour APFS et espace libre, la FAQ ligne d’eau disque.
Matrice de décision rapide
Choisissez une ligne selon le rôle principal ; ajustez avec les seuils du tableau suivant.
| Profil | AOF / RDB | appendfsync (repère) | Fenêtre réécriture |
|---|---|---|---|
| Cache reconstituable | AOF everysec ou RDB léger |
everysec |
Nuit / creux file ; pas de BGSAVE lourd même heure |
| File / broker (données sensibles) | AOF prioritaire ; RDB optionnel orchestré | everysec sauf audit always |
Après vidage partiel ; surveiller aof_rewrite_in_progress |
| Colocation forte (batch + cache) | Une voie dominante + copies externes | Éviter always sans SSD dédié |
Créneau 02h–05h local, throttle producteurs si jaune disque |
Rappel. Paramètres auto-aof-rewrite-percentage (souvent 100) et auto-aof-rewrite-min-size (quelques centaines de Mo selon débit) cadrent le déclenchement automatique ; le calendrier humain évite les collisions avec vos jobs.
Stratégie de persistance (AOF)
Sur un Mini loué, la persistance est autant une question de fenêtre temporelle que de syntaxe de fichier. L’AOF grossit avec le churn ; la réécriture compacte le journal mais exige espace libre (souvent de l’ordre de ≥ 2× la taille AOF pendant l’opération, à confirmer sur votre volume) et augmente momentanément la pression disque.
- appendfsync everysec reste le défaut raisonnable lorsque des batchs écrivent déjà sur le même SSD ; always n’est pas « gratuit » en latence et fsync.
- En dual-stack AOF+RDB, décalez les save automatiques et les BGREWRITEAOF : deux forks ou pics séquentiels valent mieux qu’un carambolage sur les p99 des workers.
- Surveillez
INFO persistence: durée anormale de réécriture, aof_delayed_fsync en hausse, ou croissance d’aof_current_size après réécriture (signe de churn extrême).
maxmemory et éviction
Sans plafond explicite, Valkey croit pouvoir occuper toute la RAM ; sur macOS, la marge se rétracte quand arrivent compression mémoire et voisins processus. Fixez maxmemory à RAM physique moins OS, agents, workers et marge 15–25 % (ordre de grandeur ; mesurez sur votre charge).
| Politique | Quand l’utiliser |
|---|---|
allkeys-lru |
Caches entièrement reconstituables ; accepte perte silencieuse de clés froides |
volatile-lru / volatile-ttl |
Données métier avec TTL ; priorité temps pour files sensibles à l’échéance |
noeviction |
Aucune perte silencieuse tolérée : les écritures échouent si plein — couplez à files externes et monitoring |
Fragmentation. Comparez used_memory et used_memory_rss via mem_fragmentation_ratio : un écart durable explique pourquoi le plafond « logique » semble respecté alors que le système suffoque (voir seuils ci-dessous).
Fenêtre de sauvegarde
La sauvegarde n’est pas seulement copier appendonly.aof ou dump.rdb : c’est éviter que la copie ne coïncide avec une réécriture AOF, un snapshot APFS ou un import batch qui saturera le contrôleur SSD.
- Avant copie : vérifier espace libre et absence de
aof_rewrite_in_progress; optionLASTSAVE/ journal applicatif pour cohérence métier. - Pendant : copie vers stockage externe ou compartiment objet ; checksum ; au moins deux générations conservées.
- Après : exercice de restauration trimestriel sur bac à sable ; mesurer RTO réel, pas celui du tableau.
Tâches marathon et cache partagé
Quand un même Mac héberge Valkey et des workers longue durée (rendu, ETL, builds), la ressource rare est souvent la latence disque unifiée, pas le GHz annoncé. Trois principes suffisent souvent à éviter les incidents :
- Isoler les chemins : répertoire ou volume dédié aux AOF et RDB pour ne pas partager la même arborescence que les artefacts batch géants.
- Désynchroniser les pics :
nice,launchdThrottleInterval et files métier pour empêcher enqueue maximal pendant réécriture. - Séparer les rôles logiques : deux instances Valkey (ports distincts) ou bases séparées pour éviter qu’une politique LRU sur cache ne purge des structures censées durer côté courtier.
Seuils exécutables
Reliez chaque métrique à une action ; ajustez les pourcentages si votre fournisseur impose un disque plus petit.
| Signal | Jaune (planifier) | Rouge (agir) | Action type |
|---|---|---|---|
mem_fragmentation_ratio |
> 1,5 pendant > 30 min | > 2,0 ou RSS au plafond | Analyser churn et gros objets ; défrag active si dispo ; fenêtre redémarrage ; éviter always jusqu’à stabilisation |
| Espace libre volume données | < 25 % libre ou < 50 Go absolus (petit SSD) | < 12–15 % libre | Reporter réécriture AOF ; purge logs/containers ; extension ou migration ; pause enqueue non critique |
Plafond maxmemory |
> 80 % du cap quelques minutes | > 90 % soutenu ou évictions massives inattendues | Monter RAM ou réduire cap applicatif ; vérifier politique ; isoler instance « hot » |
| Réécriture AOF | Durée > 2× médiane habituelle | Bloquée + disque qui fond | Stopper producteurs bruyants ; vérifier double réécriture ; espace libre ; dupliquer charge sur second nœud |
FAQ
- Valkey change-t-il la donne vs Redis pour AOF sur Mac ?
- Les commandes et la sémantique « Redis-like » restent proches ; l’optimisation gagne seulement si vous suivez les notes de version du moteur et testez réécriture + fork sur votre build Apple Silicon.
- Faut-il un disque dédié ?
- Pas obligatoire, mais un chemin ou volume séparé réduit la corrélation des pics I/O avec les répertoires batch ; c’est souvent le meilleur ROI sur Mini loué.
- Comment valider les seuils ?
- En charge de synthèse : enregistrez médiane et p95 de durée de réécriture, ratio de fragmentation et Go libres pendant une semaine ; figez ensuite jaune/rouge dans votre observabilité.
Guide d’achat
Dimensionnez la location pour que maxmemory + marge RSS fragmentation + workers tienne en RAM, et le SSD pour AOF, RDB, snapshots et journaux sans approcher la ligne rouge disque en une seule nuit de batch.
- Privilégiez nœuds avec marge stockage interne NVMe plutôt que dépendre d’un montage réseau pour la persistance temps réel.
- Parcours public : achat sans compte puis alignez unités launchd sur les créneaux de réécriture et de backup ci-dessus.
Synthèse. Valkey stable en 7×24 sur Mini loué repose sur trois garde-fous : fenêtre AOF maîtrisée, ratio de fragmentation surveillé, disque tenu au-delà des seuils jaune/rouge. Pour passer à l’action : accueil, forfaits, aide, achat.
Louez un Mac Mini pour Valkey 7×24
Apple Silicon, persistance locale et tâches longues sur un seul hôte : accueil, tarifs, centre d’aide, achat, blog.