Les régions VM sont souvent utilisées comme espaces d'adressage partageables dans les applications VOS. C'est un moyen très efficace de permettre à plusieurs processus d'accéder à un 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 la mémoire virtuelle de VOS, et cette utilisation réduit la disponibilité des VM à 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 par des opérations d'E/S de fichiers. Cela permet d'éliminer les restrictions de taille des régions de la VM et de libérer des VM autrement dédiées. Elle permet également la coordination par verrouillage de région, mais elle est beaucoup plus coûteuse que l'accès direct à une VM partagée, en particulier si des E/S de 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 d'EOF) et en se positionnant ensuite sur les zones du fichier à partir desquelles les données sont lues ou écrites. De cette façon, le fichier sert de mémoire de sauvegarde pour l'espace d'adressage et les processus partagent l'espace en utilisant des interfaces orientées fichier telles que fseek/fread/fwrite.
Avant les fichiers de flux 64 bits (introduits dans la version 17.2), cela pouvait être très coûteux sur VOS car les fichiers de flux ordinaires ne peuvent pas être rares, et l'extension d'EOF implique l'attribution explicite et l'écriture de blocs de zéros binaires. Par exemple, si l'espace d'adressage souhaité est de 2 Go, alors VOS nécessiterait 524 288 blocs de stockage sur disque, même si seule une petite partie de ce stockage pourrait contenir des valeurs autres que des zéros binaires. Avec les fichiers de flux 64 bits, ce type d'applications peut maintenant fonctionner efficacement sur VOS, en 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 la prise en compte des fichiers volumineux ; vous devriez faire cela pour bénéficier de ces avantages en termes de performances, même si les fichiers ne devraient pas dépasser 2 Go. (Voir le manuel de référence OpenVOS POSIX.1, R502, "Portage des applications existantes vers l'environnement de fichiers de flux 64 bits" pour plus d'informations).
Une utilisation similaire de l'espace d'adressage partagé sauvegardé par fichier 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 entrées/sorties de disque lors de l'utilisation de cette technique, en faisant essentiellement de l'utilisation du processeur le coût principal. L'introduction de fichiers de flux 64 bits épars dans la version 17.2 rend cette approche de l'espace d'adressage partagé encore plus attrayante.
Mémoire résidente et fichiers RAM
Un fichier résident en mémoire est identifié à l'aide de la commande set_open_options. Une partie paramétrable du cache du 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. Les blocs de fichiers résidant en mémoire une fois dans la mémoire cache n'entraîneront pas de lectures ultérieures du disque tant que le nombre total ne dépasse pas cette partie de la mémoire cache. Si c'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.
Bien que les fichiers résidents en mémoire n'entraînent pas de lectures ultérieures du disque, 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 permettent d'éviter la situation où des millions de blocs doivent ê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 des données plus rapidement qu'elle ne peut être écrite. Les fichiers en mémoire vive évitent ce type d'étranglement puisque 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 permet d'obtenir un espace d'adressage dans la mémoire cache évitant la plupart des entrées/sorties de disque, un espace d'adressage qui n'est limité que par la taille de la mémoire cache qui, à son tour, est basée sur la mémoire physique disponible, et non sur 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 est plus grand que la partie du cache résidant dans la mémoire, il perd les avantages des E/S, du moins pour les blocs qui n'ont pas été référencés récemment.
Exemple
Le contenu d'un fichier de flux peut être consulté en utilisant s$seq_position avec des codes d'opération orientés octet, puis examiné ou modifié en utilisant s$read_raw/s$write_raw. Les fichiers de flux 64 bits peuvent atteindre 512 Go sans nécessiter d'espace disque important, sauf pour les régions du fichier qui sont utilisées, c'est-à-dire définies comme non nulles.
Par exemple,
create_file scratch -organization 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 en évitant tout étranglement lié au nombre de blocs modifiés, et d'éviter complètement les écritures sur 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 ouvreur ferme le fichier, les données en cache sont rejetées et n'entraînent jamais d'écriture sur le disque. Le fichier doit être vide lorsque cette commande est utilisée.
set_open_options scratch -cache_mode memory_resident
Ainsi, le plus grand nombre possible de blocs de ce fichier est conservé indéfiniment dans le cache. Le nombre réel est un facteur de la taille du cache et du pourcentage de résidence en mémoire, tel que défini dans la commande set_tuning_parameters.
La séquence suivante montre un exemple d'utilisation programmatique (illustrée par des appels de système de test) :
tsc : s$attach_port p scratch
tsc : s$open p -io_type update
Maintenant, fournissez un espace d'adresse 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_bytes 3 (la position actuelle après 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_bytes 2000
tsc : s$write_raw p 2000
Remarque : s$seq_position prend également en charge les opcodes à positionner en décalage absolu d'octets.
Le résultat ressemble à ceci, le fichier n'occupant que deux blocs de données sur le disque :
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:04:17 est
Bloc numéro 1
000 53544152 54000000 00000000 00000000 |DÉMARRER...............|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
=
Numéro du bloc 131870736
=
Remarque : les blocs 1 et 131870736 sont en cache et n'auront généralement pas été écrits sur le disque, bien que de l'espace disque leur soit réservé, au cas où ils devraient l'être si les ressources du cache sont sollicitées. La commande dump_file ci-dessus permet de voir les blocs mis en cache, et non de lire le disque.
Lorsqu'un fichier RAM est désactivé (il n'est plus ouvert dans aucun processus), le VOS tronque le fichier (en évitant d'écrire les blocs modifiés sur le disque) et libère tout l'espace disque. Dans des circonstances typiques, la séquence ci-dessus n'entraînerait aucune entrée/sortie sur le disque, à l'exception de l'écriture des deux blocs de la carte de fichiers, qui sont finalement rejetés.
tsc : s$close p
Le fichier est maintenant vide et n'occupe plus d'espace disque :
tsc : ..dump_file scratch
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:07:12 est