Les régions VM sont souvent utilisées comme espaces d'adressage partageables dans les applications VOS. Il s'agit d'un moyen très efficace de permettre à plusieurs processus d'accéder au même ensemble d'adresses. Le principal inconvénient est que l'espace est limité à bien moins de 2 Go en raison des limites de mémoire virtuelle de VOS, et cette utilisation réduit la VM disponible à d'autres fins.
L'espace d'adressage peut également être partagé via le système de fichiers en mappant les adresses sur un fichier binaire et en accédant à ces adresses via des opérations d'E/S de fichiers. Cela élimine les restrictions de taille de la région VM et libère la VM autrement dédiée. Cela permet également la coordination via le verrouillage de région, mais est beaucoup plus coûteux que l'accès direct à la VM partagée, en particulier si des E/S disque réelles sont impliquées.
Les applications Posix utilisent parfois des fichiers de flux en mode binaire à cette fin, en établissant la taille souhaitée de l'espace d'adressage via ftruncate (utilisé pour sa capacité à étendre l'emplacement de EOF), puis en se positionnant sur les zones du fichier à partir desquelles les données sont lues ou écrites. De cette manière, le fichier sert de mémoire de sauvegarde pour l'espace d'adressage et les processus partagent l'espace à l'aide d'interfaces orientées fichier telles que fseek/fread/fwrite.
Avant les fichiers de flux 64 bits (introduits dans la version 17.2), cela pouvait s'avérer très coûteux sur VOS, car les fichiers de flux ordinaires ne peuvent pas être clairsemés, et l'extension EOF implique l'allocation et l'écriture explicites de blocs de zéros binaires. Par exemple, si l'espace d'adressage souhaité était de 2 Go, VOS aurait besoin de 524 288 blocs de stockage sur disque, même si seule une petite partie de ce stockage pouvait contenir des valeurs autres que des zéros binaires. Avec les fichiers de flux 64 bits, ce type d'applications peut désormais fonctionner efficacement sur VOS, ne nécessitant que l'espace disque réellement nécessaire. Les applications Posix bénéficient automatiquement des avantages des fichiers de flux 64 bits lorsqu'elles sont conçues pour prendre en charge les fichiers volumineux. Vous devez procéder ainsi pour bénéficier de ces avantages en termes de performances, même si les fichiers ne devraient pas dépasser 2 Go. (Pour plus d'informations, consultez le manuel de référence OpenVOS POSIX.1, R502, « Portage d'applications existantes vers l'environnement de fichiers de flux 64 bits »).
Une utilisation similaire de l'espace d'adressage partagé soutenu par des fichiers est possible dans les applications VOS natives, c'est-à-dire celles qui utilisent des interfaces s$. VOS offre un certain nombre de fonctionnalités qui peuvent réduire considérablement les E/S disque lors de l'utilisation de cette technique, faisant essentiellement de l'utilisation du processeur le principal coût. L'introduction des fichiers de flux 64 bits clairsemés dans la version 17.2 rend cette approche de l'espace d'adressage partagé encore plus attrayante.
Fichiers résidents en mémoire et fichiers RAM
Un fichier résident en mémoire est identifié à l'aide de la commande set_open_options. Une partie configurable du cache disque est réservée aux fichiers résidents en mémoire. En fonction de la mémoire physique disponible et des autres utilisations du cache, cette partie peut atteindre 9 à 10 Go. Une fois dans le cache, les blocs de fichiers résidents en mémoire ne nécessitent plus de lectures sur le disque tant que leur nombre total ne dépasse pas cette partie du cache. Si tel est le cas, les blocs les plus récemment référencés conservent cet avantage.
Les fichiers RAM sont des fichiers contenant des données non persistantes et sont utiles si le fichier contient des données qui n'ont pas besoin d'être enregistrées sur le disque lorsque l'application a fini de les utiliser. Vous pouvez utiliser la commande set_ram_file, mais tout fichier pour lequel s$delete_file_on_close est appelé est automatiquement traité comme un fichier RAM à partir de ce moment-là.
Bien que les fichiers résidant en mémoire n'entraînent pas de lectures disque ultérieures, les blocs sont toujours écrits à intervalles réguliers, et le nombre de blocs modifiés autorisés dans le cache est limité, comme pour tout autre fichier. Les limites de blocs modifiés empêchent la situation où des millions de blocs pourraient devoir être écrits lorsque le fichier est fermé ou vidé – un fichier de 4 Go occupe un million de blocs. Cette limitation peut ralentir une application qui modifie les données plus rapidement qu'elles ne peuvent être écrites. Les fichiers RAM évitent ce type de ralentissement, car leurs données n'ont jamais besoin d'être écrites sur le disque, même lorsque le fichier est désactivé.
L'utilisation de fichiers RAM résidents en mémoire fournit un espace d'adressage dans la mémoire cache qui évite la plupart des E/S disque, un espace d'adressage qui n'est limité que par la taille du cache, laquelle dépend à son tour de la mémoire physique disponible, et non de la mémoire virtuelle (le gestionnaire de cache partage les adresses VM pour accéder à la mémoire physique). Remarque : un espace d'adressage basé sur un seul fichier peut atteindre 512 Go, mais lorsqu'il dépasse la partie résidente en mémoire du cache, il perd ses avantages en termes d'E/S, du moins pour les blocs qui n'ont pas été récemment référencés.
Exemple
Le contenu d'un fichier flux peut être consulté à l'aide de s$seq_position avec des opcodes orientés octet, puis examiné ou modifié à l'aide de s$read_raw/s$write_raw. Les fichiers flux 64 bits peuvent atteindre 512 Go sans nécessiter d'espace disque important, à l'exception des régions du fichier qui sont utilisées, c'est-à-dire définies comme non nulles.
Par exemple,
create_file scratch -organisation stream64 -extent_size 256
Cela crée un fichier DAE-256 appelé « scratch ».
set_ram_file scratch
Cela permet à ce fichier d'avoir un accès illimité au cache, évitant ainsi toute limitation liée au nombre de blocs modifiés, et d'éviter complètement les écritures sur le disque, sauf en arrière-plan ou lorsque le cache est épuisé et nécessaire à d'autres fins. Cela peut également être fait par programmation via s$set_ram_file. Lorsque le dernier utilisateur ferme le fichier, les données du cache sont supprimées et n'entraînent jamais d'écritures sur le disque. Le fichier doit être vide lorsque cette commande est utilisée.
set_open_options scratch -cache_mode memory_resident
Cela permet de conserver indéfiniment dans le cache autant de blocs que possible de ce fichier. Le nombre réel dépend de la taille du cache et du pourcentage de résidence en mémoire, tels que définis dans la commande set_tuning_parameters.
La séquence suivante montre un exemple d'utilisation programmatique (illustré à l'aide de test_system_calls) :
tsc : s$attach_port p scratch
tsc : s$open p -io_type update
Maintenant, fournissez un espace d'adressage d'environ 512 Go :
tsc : extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
et l'utiliser pour stocker des données :
tsc : s$seq_position_x p bwd_by_bytes 3 (la position actuelle après l'extension est EOF)
tsc : s$write_raw p END
tsc : s$seq_position_x p bof
tsc : s$write_raw p START
tsc : s$seq_position_x p fwd_by_bytes 2000
tsc : s$write_raw p 2000
Remarque : s$seq_position prend également en charge les codes d'opération permettant de positionner des décalages absolus en octets.
Le résultat ressemble à ceci, le fichier n'occupant que deux blocs de données sur le disque :
..dump_file scratch -bref
%swsle#Raid4>otto>d-3>nouveau>scratch 15-02-25 16:04:17 est
Bloc numéro 1
000 53544152 54000000 00000000 00000000 |START………..|
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
Numéro de bloc 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
Remarque : les blocs 1 et 131870736 sont en cache et ne sont généralement pas écrits sur le disque, bien que de l'espace disque leur soit réservé au cas où cela serait nécessaire si les ressources du cache étaient saturées. La commande dump_file ci-dessus affiche les blocs mis en cache, sans lire le disque.
Lorsqu'un fichier RAM est désactivé (il n'est plus ouvert dans aucun processus), VOS tronque le fichier (évitant ainsi d'écrire les blocs modifiés sur le disque) et libère tout l'espace disque. Dans des circonstances normales, la séquence ci-dessus n'entraînerait aucune opération d'E/S disque, à l'exception de l'écriture des deux blocs de la carte de fichiers, qui sont finalement supprimés.
tsc : s$close p
Le fichier est désormais vide et n'occupe plus d'espace disque :
tsc : ..fichier_de_vidage scratch
%swsle#Raid4>otto>d-3>nouveau>scratch 15-02-25 16:07:12 est