2026 : Mac Mini loué 7×24 — matrice OpenSearch / Elasticsearch : rafraîchissement bulk, threads de fusion, segments et seuils disque
« Sur un Mini Apple Silicon loué, OpenSearch ou Elasticsearch partagent le SSD APFS avec sauvegardes et journaux : sans cadre sur refresh, fusion et seuils disque, l’ingestion bulk passe vite en lecture seule. »
Public : moteur de recherche ou index satellite sur Mac Mini 7×24. Tableau, matrice, JVM mono-nœud, nuit et backoff bulk. Liens : Vector / Loki, tâches longues, accueil, achat sans compte.
Trois freins quand les gabarits cloud heurtent un hôte unique
- Réplication fictive. Les gabarits multi-nœuds supposent des shards étalés ; ici tout tient sur un disque : écriture et recherche partagent la latence.
- Segments. Refresh fréquent et bulk trop petits multiplient les segments ; la fusion ne suit plus.
- Seuils. Le flood stage passe l’index en lecture seule alors que le cluster peut rester jaune ; Time Machine et logs réduisent la marge APFS.
Tableau des paramètres et seuils de départ
Même logique OpenSearch et Elasticsearch ; validez sur votre charge réelle car un mono-nœud loué n’absorbe pas les mêmes pics qu’un cluster multi-racks. Mesurez CPU, I/O et rejets bulk avant de figer les valeurs du tableau.
| Paramètre / indicateur | Seuil de départ | Note Mac Mini |
|---|---|---|
index.refresh_interval |
30 s ou -1 pendant un gros bulk ; revenir à 1 s après la phase batch | Échelonner avec les I/O sauvegarde et expéditeur de logs |
thread_pool.write / bulk |
File ~1000–2000 ; taille selon cœurs ; pause si rejets | Pas de tier chaud distant ; bulk plus gros, moins de fan-out |
index.merge.scheduler.max_thread_count |
Environ la moitié des cœurs logiques ou le plafond éditeur, le plus bas des deux | Augmenter seulement en fenêtre calme en surveillant le p99 recherche |
| Segments par shard | Alerte > ~100 ; d’abord refresh et taille de bulk | Force-merge si charge lecture basse |
cluster.routing.allocation.disk.watermark |
Baseline low 85 %, high 90 %, flood 95 % | Ajouter une marge si instantanés ou Time Machine partagent le disque |
indices.store.throttle.max_bytes_per_sec |
Jour ~64–128 Mo/s ; nuit plus souple | Interaction avec SSD sous charge mixte |
index.translog.durability |
async seulement pour grosses importations ; request après bascule | Limiter l’exposition async prolongée sur mono-nœud |
JVM, tas et hors-tas sur Mac loué
Le tas JVM doit rester nettement sous la moitié de la RAM physique afin de laisser respirer le cache fichiers macOS, les mmap des segments Lucene et les buffers réseau hors tas.
- Direct, mapped et pools Netty sont hors tas mais gonflent le RSS observé par
activity monitor. - Sur Apple Silicon, limitez le nombre de shards pour réduire fichiers ouverts et cycles de fusion.
- Déduisez la mémoire des agents de monitoring avant de fixer
Xmx.
Fenêtres nocturnes et backoff sur échecs
Programmez force-merge, restauration snapshot et retour à un refresh « temps réel » lorsque le trafic applicatif est minimal, en synchronisant avec vos tâches de sauvegarde disque.
- Calquez la fenêtre sur les lots Vector ou Fluent Bit décrits dans l’article journaux lié pour éviter les pics SSD cumulés.
- Sur 429 ou 503 côté bulk, backoff exponentiel entre 1 s et 30 s avec jitter avant toute hausse de débit.
- Ouvrez un disjoncteur applicatif si les rejets persistent : videz la file côté cluster avant d’ajouter des clients.
Matrice de scénarios
Priorité ingestion vs recherche.
| Profil | Refresh et bulk | Posture fusion |
|---|---|---|
| Recherche applicative quasi temps réel | Refresh 1–5 s ; bulk modérés | Threads prudents ; histogramme segments quotidien |
| Réindex journaux de nuit | -1 pendant la charge ; restauration après bascule | Fusion plus agressive seulement dans la fenêtre nuit |
| Lecture analytique dominante | Refresh plus long ; gros bulk avec backoff | Force-merge optionnel vers un segment par shard après arrêt ingestion |
Six étapes pour une indexation 7×24 stable
- Baseline bulk/s et merge ms avant thread pools.
- Refresh par classe d’index ; pas d’interactif + batch sans routing.
- Alerte 15 % libre APFS → watermarks.
- Histogramme segments hebdo ; relief merge si latence monte.
- Nuit + caffeinate / énergie dans le même runbook.
- Trimestre : restore snapshot scratch, mesurer temps au vert.
Repères citables
- 85 / 90 / 95 % : low / high / flood par défaut.
- ~100 segments/shard : ligne jaune mono-nœud.
- Backoff 1–30 s + jitter avant plus de clients bulk.
FAQ
- Mettre refresh_interval à -1 pendant un bulk est-il sans risque ?
- Moins de fusion, documents masqués jusqu’au refresh ; sonde après lot, fenêtre maintenance.
- Les threads de fusion doivent-ils égaler le nombre de cœurs ?
- Non : conflit CPU/disque ; ~moitié des cœurs ; hausse nocturne seulement.
- Pourquoi les écritures se sont-elles arrêtées alors que le disque semblait correct ?
- Flood vers 95 % ; disques partagés → marge plus haute.
Synthèse. Refresh, bulk, fusion et watermarks vont ensemble ; JVM sobre sur Apple Silicon. Accueil, forfaits, aide, louer un Mini — commande sans compte.
Choisissez un nœud Mac pour OpenSearch ou Elasticsearch
Mini Apple Silicon pour l’indexation 7×24. Accueil, tarifs, aide, achat sans compte, blog.
Mac Mini loué pour votre prochain nœud recherche : achat, aide, blog.