As regiões VM são freqüentemente usadas como espaços de endereços compartilháveis em aplicações VOS. Esta é uma maneira muito eficiente de permitir que múltiplos processos acessem o mesmo conjunto de endereços. A principal desvantagem é que o espaço é restrito a menos de 2 GB devido aos limites de memória virtual do VOS, e esta utilização corta a VM disponível para outros fins.
O espaço de endereços também pode ser compartilhado através do sistema de arquivo mapeando endereços em um arquivo binário e acessando esses endereços através de operações de E/S do arquivo. Isto elimina as restrições de tamanho da região da VM e libera a VM dedicada a outros fins. Também permite a coordenação via bloqueio de região, mas é muito mais caro do que o acesso direto de uma VM compartilhada, particularmente se a E/S de disco real estiver envolvida.
As aplicações Posix às vezes usam arquivos stream em modo binário para esta finalidade, estabelecendo o tamanho desejado do espaço de endereços via ftruncote (usado para sua capacidade de estender a localização do EOF) e depois posicionar em áreas dentro do arquivo a partir do qual os dados são lidos ou escritos. Desta forma, o arquivo serve como armazenamento de suporte para o espaço de endereços e os processos compartilham o espaço usando interfaces orientadas a arquivos, tais como fseek/fread/fwrite.
Antes dos arquivos de 64 bits (introduzidos no Release 17.2), isto poderia ser muito caro no VOS porque os arquivos de fluxo comum não podem ser esparsos, e a extensão do EOF envolve explicitamente a alocação e a escrita de blocos de zeros binários. Por exemplo, se o espaço de endereço desejado fosse de 2 GB, então o VOS exigiria 524.288 blocos de armazenamento em disco, mesmo que apenas uma pequena quantidade desse armazenamento pudesse conter outros valores além de zeros binários. Com arquivos de 64 bits, estes tipos de aplicações podem agora rodar eficientemente no VOS, exigindo apenas o espaço em disco que é realmente necessário. As aplicações Posix obtêm automaticamente o benefício de arquivos de fluxo de 64 bits quando construídas para a visualização de arquivos grandes; você deve fazer isso para obter esses benefícios de desempenho, mesmo que não se espere que os arquivos cresçam para mais de 2 GB. (Veja OpenVOS POSIX.1 Manual de Referência, R502, "Porting Existing Applications to the 64-bit Stream File Environment" para mais informações).
O uso semelhante de espaço de endereços compartilhado com suporte de arquivo é possível em aplicações VOS nativas, ou seja, aquelas que utilizam interfaces s$. O VOS fornece uma série de recursos que podem reduzir muito a E/S em disco ao usar esta técnica, essencialmente fazendo do uso da CPU o custo primário. A introdução de arquivos de 64 bits esparsos no Release 17.2 torna esta abordagem do espaço de endereços compartilhado ainda mais atraente.
Memória Residente e arquivos RAM
Um arquivo residente na memória é identificado usando o comando set_open_options. Uma parte do cache de disco ajustável é reservada para arquivos residentes na memória. Dependendo da memória física disponível e de outros usos do cache, este pode ser de até 9-10 GB. Blocos de arquivos residentes na memória uma vez no cache não incorrerão em leituras subseqüentes em disco, desde que o número total não exceda essa porção do cache. Se isso acontecer, então os blocos referenciados mais recentemente mantêm esta vantagem.
Os arquivos RAM são arquivos que contêm dados não persistentes e são úteis se o arquivo contiver dados que não precisam ser comprometidos com o disco quando a aplicação é feita usando-o. Você pode usar o comando set_ram_file, mas qualquer arquivo para o qual s$delete_file_on_close é chamado é automaticamente tratado como um arquivo RAM a partir desse ponto.
Enquanto os arquivos residentes na memória não incorrem em leituras subseqüentes em disco, os blocos ainda são escritos em intervalos regulares, e o número de blocos modificados permitido no cache é limitado, como em qualquer outro arquivo. Os limites de blocos modificados impedem que milhões de blocos precisem ser escritos quando o arquivo é fechado ou lavado - um arquivo de 4 GB ocupa um milhão de blocos. Esta limitação pode atrasar uma aplicação que modifica os dados mais rapidamente do que pode ser escrito. Os arquivos RAM evitam este tipo de estrangulamento, já que seus dados nunca precisam ser gravados em disco, mesmo quando o arquivo é desativado.
O uso de arquivos RAM residentes na memória RAM fornece um espaço de endereço na memória cache evitando a maioria das E/S em disco, um espaço de endereço que é limitado apenas pelo tamanho do cache que, por sua vez, é baseado na memória física disponível, não na memória virtual (o gerenciador de cache compartilha endereços VM para acessar a memória física). Nota: um único espaço de endereço baseado em arquivo pode crescer até 512 GB, mas quando maior que a porção residente da memória do cache, perde vantagens de E/S, pelo menos para aqueles blocos que não foram referenciados recentemente.
Exemplo
O conteúdo de um arquivo stream pode ser acessado usando s$seq_position com opcodes orientados por bytes e depois examinados ou modificados usando s$read_raw/s$write_raw. Os arquivos de fluxo de 64 bits podem ter até 512 GB sem requerer nenhum espaço significativo em disco, exceto para as regiões do arquivo que são utilizadas, ou seja, definidas como não zero.
Por exemplo,
create_file scratch -organization stream64 -extent_size 256
Isto cria um arquivo DAE-256 chamado "scratch".
set_ram_file scratch
Isto permite que este arquivo tenha acesso ilimitado ao cache, evitando qualquer estrangulamento relacionado ao número de blocos modificados, e para evitar a gravação em disco, exceto em segundo plano ou quando o cache estiver esgotado e for necessário para outros propósitos. Isto também pode ser feito programmaticamente através de s$set_ram_file. Quando o último abridor fecha o arquivo, os dados no cache são descartados e nunca implicam em gravação em disco. O arquivo deve estar vazio quando este comando for utilizado.
set_open_options scratch -cache_mode memory_resident
Isto faz com que o maior número possível de blocos deste arquivo seja retido em cache indefinidamente. O número real é um fator do tamanho do cache e da porcentagem de residência da memória, conforme definido no comando set_tuning_parameters.
A seqüência seguinte mostra um exemplo de uso programático (ilustrado usando test_system_calls):
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
Agora, forneça um espaço de endereços de cerca de 512 GB:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
e usá-lo para armazenar dados:
tsc: s$seq_position_x p bwd_by_bytes 3 (posição atual após extensão é EOF)
tsc: s$write_raw p END
tsc: s$seq_position_x p bof
tsc: s$write_raw p INICIAR
tsc: s$seq_position_x p fwd_by_bytes 2000
tsc: s$write_raw p 2000
Nota: s$seq_position suporta opcodes para posicionar também para offsets de bytes absolutos.
O resultado é assim, com o arquivo ocupando apenas dois blocos de dados em disco:
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>novo>scratch 15-02-25 16:04:17 est
Bloco número 1
000 53544152 54000000 00000000 00000000 00000000 |START...........|
010 00000000 00000000 00000000 00000000 |…………….|
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Bloco número 131870736
000 00000000 00000000 00000000 00000000 |…………….|
FF0 00000000 00000000 00000000 00454E44 |.............END|
Nota: os blocos 1 e 131870736 estão em cache e tipicamente não terão sido gravados em disco, embora o espaço em disco seja reservado para eles, caso seja necessário se os recursos de cache estiverem tensos. O comando dump_file acima está vendo os blocos em cache, não lendo o disco.
Quando um arquivo RAM é desativado (não está mais aberto em nenhum processo), o VOS truncata o arquivo (evitando gravar blocos modificados em disco) e libera todo o espaço em disco. Sob circunstâncias típicas, a seqüência acima não resultaria em nenhuma E/S em disco, exceto gravações dos dois blocos de mapa de arquivo, que eventualmente são descartados.
tsc: s$close p
Agora o arquivo está vazio e não ocupa espaço em disco:
tsc: ..dump_file scratch
%swsle#Raid4>otto>d-3>novo>scratch 15-02-25 16:07:12 est