Las regiones de VM se utilizan a menudo como espacios de direcciones compartibles en las aplicaciones de VOS. Esta es una forma muy eficiente de permitir que múltiples procesos accedan al mismo conjunto de direcciones. La principal desventaja es que el espacio está restringido a menos de 2 GB debido a los límites de la memoria virtual del VOS, y este uso corta la VM disponible para otros propósitos.
El espacio de direcciones también puede compartirse a través del sistema de archivos mediante la asignación de direcciones a un archivo binario y el acceso a esas direcciones mediante operaciones de E/S de archivos. Esto elimina las restricciones de tamaño de la región VM y libera a las VM que de otra manera estarían dedicadas. También permite la coordinación a través del bloqueo de regiones, pero es mucho más caro que el acceso directo de VM compartidos, particularmente si la E/S del disco está involucrada.
Las aplicaciones Posix a veces utilizan archivos de flujo en modo binario para este propósito, estableciendo el tamaño deseado del espacio de direcciones mediante el truncamiento (utilizado por su capacidad de extender la ubicación de EOF) y luego se posicionan en áreas dentro del archivo desde las cuales se leen o escriben los datos. De esta manera, el archivo sirve como almacén de respaldo para el espacio de direcciones y los procesos comparten el espacio utilizando interfaces orientadas a archivos como fseek/fread/fwrite.
Antes de los archivos de flujo de 64 bits (introducidos en la versión 17.2), esto podría ser muy caro en VOS porque los archivos de flujo ordinarios no pueden ser escasos, y la ampliación de EOF implica explícitamente la asignación y escritura de bloques de ceros binarios. Por ejemplo, si el espacio de direcciones deseado fuera digamos de 2 GB, entonces la VOS requeriría 524.288 bloques de almacenamiento en disco, aunque sólo una pequeña cantidad de ese almacenamiento podría llegar a contener valores distintos de los ceros binarios. Con los archivos de flujo de 64 bits, este tipo de aplicaciones pueden ahora ejecutarse eficientemente en el VOS, requiriendo sólo tanto espacio de disco como el que realmente se necesita. Las aplicaciones Posix obtienen automáticamente el beneficio de los archivos de flujo de 64 bits cuando se construyen para el conocimiento de archivos grandes; deberías hacer esto para obtener estos beneficios de rendimiento, incluso si no se espera que los archivos crezcan a más de 2 GB. (Véase el manual de referencia de OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment" para más información).
Un uso similar del espacio de direcciones compartido respaldado por archivos es posible en las aplicaciones VOS nativas, es decir, las que utilizan interfaces s$. El VOS proporciona una serie de características que pueden reducir enormemente la E/S del disco cuando se utiliza esta técnica, haciendo esencialmente que el uso de la CPU sea el coste principal. La introducción de los escasos archivos de flujo de 64 bits en la versión 17.2 hace que este enfoque del espacio de direcciones compartido sea aún más atractivo.
Residente de memoria y archivos RAM
Un archivo residente en memoria se identifica con el comando set_open_options. Una parte configurable de la caché del disco se reserva para los archivos residentes en memoria. Según la memoria física disponible y otros usos de la caché, ésta puede ser de hasta 9-10 GB. Los bloques de archivos residentes en memoria una vez en la caché no incurrirán en lecturas posteriores del disco siempre y cuando el número total no exceda esa porción de la caché. Si lo hace, entonces los bloques referidos más recientemente conservan esta ventaja.
Los archivos de RAM son archivos que contienen datos no persistentes y son útiles si el archivo contiene datos que no necesitan ser confirmados en el disco cuando la aplicación termina de utilizarlos. Puede utilizar el comando set_ram_file, pero cualquier archivo para el que se llame s$delete_file_on_close se trata automáticamente como un archivo de RAM a partir de ese momento.
Aunque los archivos residentes en memoria no incurren en lecturas posteriores en el disco, los bloques se siguen escribiendo a intervalos regulares, y el número de bloques modificados permitidos en la caché está limitado como en cualquier otro archivo. Los límites de los bloques modificados evitan la situación en la que puede ser necesario escribir millones de bloques cuando el archivo se cierra o se vacía: un archivo de 4 GB ocupa un millón de bloques. Esta limitación puede ralentizar una aplicación que modifica los datos más rápidamente de lo que se puede escribir. Los archivos de RAM evitan este tipo de estrangulamiento ya que sus datos nunca necesitan ser escritos en el disco, incluso cuando el archivo está desactivado.
El uso de archivos de memoria RAM residente proporciona un espacio de direcciones en la memoria caché que evita la mayoría de las E/S del disco, un espacio de direcciones que sólo está limitado por el tamaño de la caché que, a su vez, se basa en la memoria física disponible, no en la memoria virtual (el administrador de la caché comparte las direcciones de la máquina virtual para acceder a la memoria física). Nota: un único espacio de direcciones basado en archivos puede crecer hasta 512 GB, pero cuando es mayor que la porción de memoria residente en la caché, pierde ventajas de E/S, al menos para aquellos bloques que no han sido referenciados recientemente.
Ejemplo
Se puede acceder al contenido de un archivo de flujo usando s$seq_position con opcodes orientados a bytes y luego se puede examinar o modificar usando s$read_raw/s$write_raw. Los archivos de streaming de 64 bits pueden tener hasta 512 GB sin necesidad de un espacio significativo en el disco, excepto para las regiones del archivo que se utilizan, es decir, que se establecen como no cero.
Por ejemplo,
create_file scratch -organization stream64 -extent_size 256
Esto crea un archivo DAE-256 llamado "scratch"
set_ram_file scratch
Esto permite que este archivo tenga un acceso ilimitado al caché evitando cualquier estrangulamiento relacionado con el número de bloques modificados, y que se eviten totalmente las escrituras de disco excepto en segundo plano o cuando el caché se agote y se necesite para otros fines. Esto puede hacerse también de forma programada mediante el archivo s$set_ram_file. Cuando el último abridor cierra el archivo, los datos de la caché se descartan y nunca se producen escrituras de disco. El archivo debe estar vacío cuando se utiliza este comando.
set_open_options scratch -cache_mode memory_resident
Esto hace que la mayor cantidad posible de los bloques de este archivo se conserven en el caché indefinidamente. El número real es un factor del tamaño de la caché y el porcentaje de residencia de la memoria, como se establece en el comando set_tuning_parameters.
La siguiente secuencia muestra un ejemplo de uso programático (ilustrado mediante llamadas de sistema_de_prueba):
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
Ahora, proporciona un espacio de dirección de alrededor de 512 GB:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
y lo utilizan para almacenar datos:
tsc: s$seq_position_x p bwd_by_bytes 3 (la posición actual después de la extensión es 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
Nota: s$seq_position también soporta opcodes para posicionar a compensaciones de bytes absolutos.
El resultado se ve así, con el archivo ocupando sólo dos bloques de datos en el disco:
...archivo de volcado de raspado - informe
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:04:17 est
Bloque número 1
000 53544152 54000000 00000000 00000000 | COMIENZO................
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
Número de bloque 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |................END|
Nota: los bloques 1 y 131870736 están en caché y normalmente no se habrán escrito en el disco, aunque se reserva espacio en el disco para ellos, en caso de que necesiten estarlo si los recursos de la caché están agotados. El comando dump_file de arriba está viendo los bloques en caché, no leyendo el disco.
Cuando se desactiva un archivo de RAM (ya no se abre en ningún proceso), el VOS trunca el archivo (evitando escribir bloques modificados en el disco) y libera todo el espacio del disco. En circunstancias típicas, la secuencia anterior no daría lugar a ninguna E/S de disco, excepto las escrituras de los dos bloques de mapa de archivos, que finalmente se descartan.
tsc: s$close p
Ahora el archivo está vacío y no ocupa espacio en el disco:
tsc: ...archivo_de_dumpido rascar
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:07:12 est