As regiões VM são frequentemente utilizadas como espaços de endereçamento compartilháveis em aplicações VOS. Esta é uma forma muito eficiente de permitir que vários processos acessem o mesmo conjunto de endereços. A principal desvantagem é que o espaço é restrito a bem menos de 2 GB devido aos limites de memória virtual do VOS, e esse uso reduz a VM disponível para outros fins.
O espaço de endereço também pode ser compartilhado por meio do sistema de arquivos, mapeando endereços em um arquivo binário e acessando esses endereços por meio de operações de E/S de arquivo. Isso elimina as restrições de tamanho da região da VM e libera a VM que, de outra forma, seria dedicada. Também permite a coordenação por meio do bloqueio de região, mas é muito mais caro do que o acesso direto à VM compartilhada, especialmente se houver E/S de disco real envolvida.
Os aplicativos Posix às vezes usam arquivos de fluxo no modo binário para essa finalidade, estabelecendo o tamanho desejado do espaço de endereço por meio do ftruncate (usado por sua capacidade de estender a localização do EOF) e, em seguida, posicionando-se em áreas dentro do arquivo a partir das quais os dados são lidos ou gravados. Dessa forma, o arquivo serve como armazenamento de backup para o espaço de endereço e os processos compartilham o espaço usando interfaces orientadas a arquivos, como fseek/fread/fwrite.
Antes dos arquivos de fluxo de 64 bits (introduzidos na versão 17.2), isso poderia ser muito caro no VOS, pois os arquivos de fluxo comuns não podem ser esparsos, e estender o EOF envolve alocar e gravar explicitamente blocos de zeros binários. Por exemplo, se o espaço de endereço desejado fosse, digamos, 2 GB, o VOS exigiria 524.288 blocos de armazenamento em disco, mesmo que apenas uma pequena parte desse armazenamento pudesse conter valores diferentes de zeros binários. Com os arquivos de fluxo de 64 bits, esses tipos de aplicativos agora podem ser executados com eficiência no VOS, exigindo apenas o espaço em disco realmente necessário. Os aplicativos Posix obtêm automaticamente o benefício dos arquivos de fluxo de 64 bits quando criados para reconhecimento 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. (Consulte o manual de referência OpenVOS POSIX.1, R502, “Portando aplicativos existentes para o ambiente de arquivos de fluxo de 64 bits” para obter mais informações).
É possível utilizar de forma semelhante o espaço de endereço compartilhado baseado em arquivos em aplicativos VOS nativos, ou seja, aqueles que utilizam interfaces s$. O VOS oferece vários recursos que podem reduzir significativamente a E/S do disco ao utilizar essa técnica, tornando o uso da CPU o principal custo. A introdução de arquivos de fluxo esparsos de 64 bits na versão 17.2 torna essa abordagem ao espaço de endereço compartilhado ainda mais atraente.
Arquivos residentes na memória e na RAM
Um arquivo residente na memória é identificado usando o comando set_open_options. Uma parte configurável do cache do disco é reservada para arquivos residentes na memória. Dependendo da memória física disponível e de outros usos do cache, isso pode chegar a 9-10 GB. Os blocos de arquivos residentes na memória, uma vez no cache, não incorrerão em leituras subsequentes do disco, desde que o número total não exceda essa parte do cache. Se isso acontecer, os blocos referenciados mais recentemente mantêm essa 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 gravados no disco quando o aplicativo terminar de usá-los. Você pode usar o comando set_ram_file, mas qualquer arquivo para o qual s$delete_file_on_close seja chamado será automaticamente tratado como um arquivo RAM a partir desse ponto.
Embora os arquivos residentes na memória não incorram em leituras subsequentes do disco, os blocos ainda são gravados em intervalos regulares, e o número de blocos modificados permitidos no cache é limitado, assim como em qualquer outro arquivo. Os limites de blocos modificados evitam a situação em que milhões de blocos podem precisar ser gravados quando o arquivo é fechado ou liberado – um arquivo de 4 GB ocupa um milhão de blocos. Essa limitação pode tornar mais lenta uma aplicação que modifica dados mais rapidamente do que eles podem ser gravados. Os arquivos RAM evitam esse tipo de limitação, pois seus dados nunca precisam ser gravados em disco, mesmo quando o arquivo é desativado.
O uso de arquivos RAM residentes na memória fornece um espaço de endereço na memória cache, evitando a maior parte da E/S do 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). Observação: um único espaço de endereço baseado em arquivo pode crescer até 512 GB, mas quando maior do que a parte residente na memória do cache, ele perde as vantagens de E/S, pelo menos para os blocos que não foram referenciados recentemente.
Exemplo
O conteúdo de um arquivo de fluxo pode ser acessado usando s$seq_position com opcodes orientados por byte e, em seguida, examinado ou modificado usando s$read_raw/s$write_raw. Arquivos de fluxo de 64 bits podem ter até 512 GB sem exigir espaço significativo em disco, exceto para regiões no arquivo que são usadas, ou seja, definidas como diferentes de zero.
Por exemplo,
criar_arquivo scratch -organização stream64 -tamanho_extensão 256
Isso cria um arquivo DAE-256 chamado “scratch”.
definir_arquivo_de_RAM scratch
Isso permite que esse arquivo tenha acesso ilimitado ao cache, evitando qualquer limitação relacionada ao número de blocos modificados e evitando gravações em disco, exceto em segundo plano ou quando o cache estiver esgotado e for necessário para outros fins. Isso também pode ser feito programaticamente por meio de s$set_ram_file. Quando o último usuário fecha o arquivo, os dados no cache são descartados e nunca implicam gravações em disco. O arquivo deve estar vazio quando esse comando for usado.
definir_opções_de_abertura scratch -modo_cache residente_na_memória
Isso faz com que o maior número possível de blocos desse arquivo seja mantido no cache indefinidamente. O número real é um fator do tamanho do cache e da porcentagem de residência na memória, conforme definido no comando set_tuning_parameters.
A sequência a seguir 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ço de cerca de 512 GB:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
e use-o para armazenar dados:
tsc: s$seq_position_x p bwd_by_bytes 3 (posição atual após a extensão é 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
Observação: s$seq_position também suporta códigos de operação para posicionar em deslocamentos absolutos de bytes.
O resultado é semelhante ao seguinte, com o arquivo ocupando apenas dois blocos de dados no disco:
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>novo>rascunho 25/02/15 16:04:17 est
Bloco número 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 |…………….|
Número do bloco 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
Observação: os blocos 1 e 131870736 estão no cache e normalmente não serão gravados no disco, embora o espaço em disco seja reservado para eles, caso seja necessário, se os recursos do cache estiverem sobrecarregados. O comando dump_file acima está visualizando os blocos em cache, não lendo o disco.
Quando um arquivo RAM é desativado (não está mais aberto em nenhum processo), o VOS trunca o arquivo (evitando gravar blocos modificados no disco) e libera todo o espaço em disco. Em circunstâncias normais, a sequência acima não resultaria em nenhuma E/S de disco, exceto gravações dos dois blocos do mapa de arquivos, que acabam sendo descartados.
tsc: fechar p
Agora o arquivo está vazio e não ocupa espaço em disco:
tsc: ..arquivo de despejo scratch
%swsle#Raid4>otto>d-3>novo>rascunho 25/02/15 16:07:12 est