VM 영역은 VOS 응용 프로그램에서 신뢰할 수 있는 주소 공간으로 자주 사용됩니다. 이는 여러 프로세스가 동일한 주소 집합에 액세스할 수 있도록 허용하는 매우 효율적인 방법입니다. 주요 단점은 VOS의 가상 메모리 제한으로 인해 공간이 2GB 미만으로 제한되고 이 사용이 다른 용도로 사용할 수 있는 VM으로 줄어듭니다.
주소 공간은 주소를 이진 파일에 매핑하고 파일 I/O 작업을 통해 해당 주소에 액세스하여 파일 시스템을 통해 공유할 수도 있습니다. 이렇게 하면 VM 영역 크기 제한이 제거되고 전용 VM이 해제됩니다. 또한 지역 잠금을 통한 조정을 허용하지만 공유 VM에 직접 액세스하는 것보다 훨씬 더 비쌉습니다.
Posix 응용 프로그램은 때때로 이 목적을 위해 이진 모드에서 스트림 파일을 사용하여 ftruncate를 통해 주소 공간의 원하는 크기를 설정(EOF의 위치를 확장하는 기능에 사용) 다음 데이터가 읽거나 작성된 파일 내 영역으로 배치합니다. 이러한 방식으로 파일은 주소 공간 및 프로세스에 대한 백업 저장소 역할을 하며 fseek/fread/fwrite와 같은 파일 지향 인터페이스를 사용하여 공간을 공유합니다.
64비트 스트림 파일(릴리스 17.2에 도입)이전에는 일반 스트림 파일이 희박할 수 없으며 EOF를 확장하려면 이진 제로블록을 명시적으로 할당하고 작성하는 작업이 포함되므로 VOS에서 매우 비쌀 수 있습니다. 예를 들어 원하는 주소 공간이 2GB라고 하는 경우 VOS는 소량의 저장소만 이진 제로 이외의 값을 포함할 수 있더라도 524,288블록의 디스크 저장소가 필요합니다. 64비트 스트림 파일을 사용하면 VOS에서 이러한 유형의 응용 프로그램을 효율적으로 실행할 수 있으며 실제로 필요한 만큼의 디스크 공간만 필요합니다. Posix 응용 프로그램은 대규모 파일 인식을 위해 빌드될 때 자동으로 64비트 스트림 파일의 이점을 얻습니다. 파일이 2GB 이상으로 증가할 것으로 예상되지 않더라도 이러한 성능 이점을 얻으려면 이 작업을 수행해야 합니다. (자세한 내용은 OpenVOS POSIX.1 참조 설명서, R502, "기존 응용 프로그램을 64비트 스트림 파일 환경으로 이식"을 참조하십시오.
파일 지원 공유 주소 공간의 유사한 사용은 네이티브 VOS 응용 프로그램, 즉 s$ 인터페이스를 사용하는 응용 프로그램에서 가능합니다. VOS는 이 기술을 사용할 때 디스크 I/O를 크게 줄일 수 있는 여러 기능을 제공하므로 CPU 사용량이 기본 비용이 됩니다. 릴리스 17.2에 스파스 64비트 스트림 파일이 도입되어 공유 주소 공간에 대한 접근 방식이 더욱 매력적입니다.
메모리 레지던트 및 RAM 파일
메모리 상주 파일은 set_open_options 명령을 사용하여 식별됩니다. 디스크 캐시의 설정 가능한 부분은 메모리 상주 파일에 대해 예약됩니다. 사용 가능한 실제 메모리 및 캐시의 다른 용도에 따라 최대 9-10GB가 될 수 있습니다. 캐시에 있는 메모리 상주 파일 블록은 총 수가 캐시의 해당 부분을 초과하지 않는 한 후속 디스크 읽기가 발생하지 않습니다. 이 경우 가장 최근에 참조된 블록은 이 점을 유지합니다.
RAM 파일은 비영구 데이터가 포함된 파일이며 응용 프로그램이 데이터를 사용하여 완료될 때 디스크에 커밋할 필요가 없는 데이터가 포함되어 있는 경우에 유용합니다. set_ram_file 명령을 사용할 수 있지만 s$delete_file_on_close 호출되는 모든 파일은 해당 시점부터 RAM 파일로 자동으로 처리됩니다.
메모리 상주 파일은 후속 디스크 읽기가 발생하지 않지만 블록은 여전히 정기적으로 작성되며 캐시에서 허용되는 수정된 블록수는 다른 파일과 마찬가지로 제한됩니다. 수정된 블록 제한은 파일이 닫히거나 플러시될 때 수백만 개의 블록을 작성해야 하는 상황을 방지합니다. 이러한 제한으로 데이터를 기록할 수 있는 것보다 빠르게 수정하는 응용 프로그램의 속도가 느려질 수 있습니다. RAM 파일은 파일이 비활성화된 경우에도 데이터를 디스크에 기록할 필요가 없으므로 이러한 유형의 제한을 피합니다.
메모리 상주 RAM 파일을 사용하면 대부분의 디스크 I/O를 피하는 캐시 메모리의 주소 공간을 제공하며, 캐시 크기로만 제한되는 주소 공간은 가상 메모리가 아닌 사용 가능한 실제 메모리를 기반으로 합니다(캐시 관리자가 실제 메모리에 액세스하기 위해 VM 주소를 공유함). 참고: 단일 파일 기반 주소 공간은 최대 512GB까지 자랄 수 있지만 캐시의 메모리 상주 부분보다 크면 적어도 최근에 참조되지 않은 블록의 경우 I/O 이점이 손실됩니다.
예제
스트림 파일의 내용은 바이트 지향 opcodes와 s$seq_position 사용하여 액세스한 다음 s$read_raw/s$write_raw 사용하여 검사하거나 수정할 수 있습니다. 64비트 스트림 파일은 사용되는 파일의 영역(예: 0이 아닌 영역)을 제외한 중요한 디스크 공간을 요구하지 않고 최대 512GB가 될 수 있습니다.
예를 들어
create_file 스크래치 -조직 스트림64 -extent_size 256
이렇게 하면 DAE-256 파일인 "스크래치"가 만들어집니다.
set_ram_file 스크래치
이렇게 하면 이 파일은 수정된 블록 수와 관련된 제한을 피하고 백그라운드 또는 캐시가 소진되고 다른 목적으로 필요한 경우를 제외하고는 디스크 쓰기를 완전히 피할 수 있습니다. 이 작업은 s$set_ram_file 통해 프로그래밍 방식으로 수행할 수 있습니다. 마지막 오프너가 파일을 닫으면 캐시의 데이터가 삭제되고 디스크 쓰기를 수반하지 않습니다. 이 명령을 사용할 때 파일은 비어 있어야 합니다.
set_open_options 스크래치 -cache_mode memory_resident
이로 인해 이 파일의 블록이 캐시에 무기한 으로 유지됩니다. 실제 숫자는 set_tuning_parameters 명령에서 설정된 캐시 크기와 메모리 거주 비율의 요소입니다.
다음 시퀀스는 프로그래밍 방식 사용의 예를 보여 줍니다(test_system_calls 사용하여 그림)
tSC: s$attach_port p 스크래치
tSC: s$오픈 p-io_type 업데이트
이제 약 512GB의 주소 공간을 제공합니다.
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
데이터를 저장하는 데 사용합니다.
tSC: s$seq_position_x p bwd_by_bytes 3 (연장 후 현재 위치는 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
참고: s$seq_position 절대 바이트 오프셋에 위치하는 opcodes를 지원합니다.
결과는 파일이 디스크에 두 개의 데이터 블록을 차지하는 것처럼 보입니다.
.. dump_file 스크래치 -간략한
%swsle#Raid4>otto>d-3>new>스크래치 15-02-25 16:04:17 est
블록 번호 1
000 53544152 54000000 0000000 00000000 000000 | 시작.........
010 00000000 000000000 000000000 0000000000000000000000000..........................................
=
7D0 00000000 00323030 30000000 00000000000000000000....2000....|
7E0 00000000 000000000 000000000 00000000000000000000000000....................................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 131870736
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
FF0 00000000 000000000 000000000 00454E444 |............END|
참고: 블록 1과 131870736은 캐시에 있으며 일반적으로 디스크 공간이 예약되어 있지만 캐시 리소스가 긴장된 경우 디스크에 기록되지 않습니다. 위의 dump_file 명령은 디스크를 읽지 않고 캐시된 블록을 보고 있습니다.
RAM 파일이 비활성화되면(모든 프로세스에서 더 이상 열리지 않는 경우) VOS는 파일을 트런피하고(수정된 블록을 디스크에 쓰기 피함) 모든 디스크 공간을 해제합니다. 일반적인 상황에서 위의 순서는 두 파일 맵 블록의 쓰기를 제외하고는 디스크 I/O가 전혀 발생하지 않으며 결국 폐기됩니다.
tSC: s$닫기 p
이제 파일이 비어 있고 디스크 공간이 없습니다.
Tsc:.. dump_file 스크래치
%swsle#Raid4>otto>d-3>new>스크래치 15-02-25 16:07:12 est