Merci @Irène Mykhailova pour ces consignes, toujours utiles.

Je ne sais pas si c'est intentionnel de ta part pour garantir que ton article soit lu correctement par la communauté, mais une faute de frappe s'est glissée : %SYSTEM.JSON n'est pas une classe existante dans IRIS.

Ou s'agit-il simplement d'une hallucination non vérifiée, qui prouverait que tu dois appliquer toi-même tes recommandations pour une utilisation optimale de l'IA générative ?

J'opte pour la première option 😊

L'utilisation de multiples namespaces n'induit pas de surconsommation mémoire directe, mais une mauvaise gestion des mappings ou une configuration sous-optimale des caches peut dégrader les performances. Une planification attentive des accès aux données et des paramètres système adaptés (cache global, $ZSTORAGE, huge pages) permet de maintenir une empreinte mémoire efficace.

1. Mécanisme des namespaces et bases de données

• Un namespace est une entité logique sans surcoût mémoire intrinsèque.
• Chaque namespace accède à des bases de données (fichiers IRIS.DAT) via des mappings prédéfinis ou personnalisés.
• La consommation mémoire dépend principalement :
  • Du cache des globals (mémoire partagée pour les données)
  • Du cache des routines (mémoire partagée pour le code)
  • De la configuration des processus individuels ($ZSTORAGE).

2. Impact des accès multi-bases

• Accès concurrents à plusieurs bases :
  • Augmente l'utilisation du cache global si les données sont dispersées.
  • Peut entraîner une fragmentation mémoire si les allocations/désallocations sont fréquentes.
• Mapping intelligent :
  • Des mappings permettent d'optimiser l'accès aux données sans dupliquer les buffers, en partageant des données de référence ou du code entre plusieurs namespaces.

3. Optimisations recommandées

• Configuration du cache global :
  • Allouer 25-30% de la RAM disponible pour les buffers 8KB (valeur par défaut).
  • Utiliser des huge pages Linux pour réduire la surcharge mémoire.
• Limite par processus :
  • Ajuster Maximum Per-Process Memory (KB) via le portal (256KB à 2TB).
  • Surveiller les erreurs <STORE> pour détecter les besoins d'ajustement.
• Stratégie de déploiement :
  • Regrouper les données fréquemment accédées dans une même base ou définir un mapping dans %ALL pour donner un accès à tous les namespaces aux données fréquentes.
  • Utiliser des bases temporaires distinctes pour les opérations transactionnelles lourdes.

4. Comparaison avec les bases en mémoire

InterSystems IRIS évite les écueils des bases purement en mémoire :

• Gestion dynamique : Seules les données actives sont conservées en mémoire via un mécanisme de buffer pool.
• Persistance native : Élimine le besoin de recharger les données après un redémarrage.
• Benchmarks : IRIS est très souvent plus rapide en requêtes SQL que des solutions in-memory pures.

@Corentin Blondeau, c'est la nature des 20 flux qui doit être considérée pour décider du nombre de namespaces.

Si les 20 flux sont tous liés entre eux d'un point de vue métier, un seul namespace est recommandé. 
Si parmi ces 20 flux, une vraie séparation métier existe, il est recommandé de les séparer dans plusieurs namespaces, même si certains d'entre eux ne reçoivent qu'un flux, la séparation offrira plus de souplesse dans l'administration et la gestion opérationnelle. 

L'impact sur la consommation mémoire est marginal ; seuls les processus Ens.Actor, Ens.Alarm, Ens.Alert, Ens.MonitorService, Ens.ProductionMonitorService, Ens.ScheduleHandler seront  dupliqués pour chaque nouveau namespace. 

Chaque instance IRIS pouvant supporter jusqu'à 2048 namespaces, il ne faut pas s'en priver dès l'instant où le bénéfice de l'isolation est au rendez-vous 😉