VM 영역은 VOS 애플리케이션에서 공유 가능한 주소 공간으로 자주 사용됩니다. 이는 여러 프로세스가 동일한 주소 집합에 접근할 수 있도록 하는 매우 효율적인 방법입니다. 주요 단점은 VOS의 가상 메모리 제한으로 인해 공간이 2GB 미만으로 제한된다는 점이며, 이러한 사용은 다른 용도로 사용 가능한 VM을 차지하게 됩니다.
주소 공간은 파일 시스템에서도 공유될 수 있습니다. 이 경우 주소를 바이너리 파일에 매핑하고 파일 입출력 작업을 통해 해당 주소에 접근합니다. 이는 가상 메모리 영역 크기 제한을 제거하고 전용 가상 메모리를 해제합니다. 또한 영역 잠금을 통한 협조가 가능하지만, 공유 가상 메모리에 대한 직접 접근보다 훨씬 비용이 많이 듭니다. 특히 실제 디스크 입출력이 포함될 경우 더욱 그렇습니다.
Posix 애플리케이션은 때로 이 목적을 위해 스트림 파일을 바이너리 모드로 사용합니다. ftruncate(EOF 위치를 확장하는 기능으로 사용됨)를 통해 원하는 주소 공간 크기를 설정한 후, 파일 내 데이터가 읽히거나 쓰여지는 영역으로 포지션을 이동시킵니다. 이러한 방식으로 파일은 주소 공간의 백업 저장소 역할을 하며, 프로세스는 fseek/fread/fwrite와 같은 파일 지향 인터페이스를 통해 해당 공간을 공유합니다.
64비트 스트림 파일(릴리스 17.2에서 도입됨) 이전에는 일반 스트림 파일이 스파스(sparse)로 처리될 수 없고, EOF(파일 끝) 확장은 이진 0 블록을 명시적으로 할당하고 기록하는 과정을 수반하기 때문에 VOS에서 이 작업은 매우 비용이 많이 들 수 있었습니다. 예를 들어, 원하는 주소 공간이 2GB라고 가정하면, VOS는 524,288개의 디스크 저장 블록을 요구합니다. 비록 그 저장 공간 중 극히 일부만 이진 0 이외의 값을 포함할 수 있음에도 불구하고 말입니다. 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 파일로 처리됩니다.
메모리 상주 파일은 이후 디스크 읽기를 발생시키지 않지만, 블록은 여전히 정기적으로 기록되며 캐시에 허용되는 수정 블록 수는 다른 파일과 마찬가지로 제한됩니다. 수정된 블록 제한은 파일을 닫거나 플러시할 때 수백만 개의 블록을 기록해야 하는 상황을 방지합니다(4GB 파일은 백만 개의 블록을 차지함). 이 제한으로 인해 데이터 수정 속도가 기록 속도를 초과하는 애플리케이션의 성능이 저하될 수 있습니다. RAM 파일은 비활성화된 상태에서도 데이터가 디스크에 기록될 필요가 없으므로 이러한 유형의 속도 제한을 피할 수 있습니다.
메모리 상주 RAM 파일을 사용하면 캐시 메모리 내 주소 공간을 제공하여 대부분의 디스크 I/O를 회피할 수 있으며, 이 주소 공간은 가용 물리 메모리를 기반으로 하는 캐시 크기에만 제한을 받습니다(가상 메모리가 아닌). 캐시 관리자는 물리 메모리에 접근하기 위해 VM 주소를 공유합니다. 참고: 단일 파일 기반 주소 공간은 최대 512GB까지 확장될 수 있지만, 캐시의 메모리 상주 부분보다 클 경우, 특히 최근에 참조되지 않은 블록에 대해서는 I/O 이점을 상실합니다.
예시
스트림 파일의 내용은 바이트 단위 연산 코드와 함께 s$seq_position을 사용하여 접근한 후 s$read_raw/s$write_raw로 검사하거나 수정할 수 있습니다. 64비트 스트림 파일은 사용 중인 영역(즉, 0이 아닌 값으로 설정된 부분)을 제외하면 상당한 디스크 공간을 차지하지 않으면서 최대 512GB까지 저장할 수 있습니다.
예를 들어,
create_file scratch -organization stream64 -extent_size 256
이것은 "scratch"라는 DAE-256 파일을 생성합니다.
set_ram_file 스크래치
이를 통해 해당 파일은 수정된 블록 수와 관련된 스로틀링 없이 캐시에 무제한 접근할 수 있으며, 백그라운드 작업 시나 캐시가 소진되어 다른 용도로 필요할 때를 제외하고는 디스크 쓰기를 완전히 피할 수 있습니다. s$set_ram_file을 통해 프로그래밍 방식으로 설정할 수도 있습니다. 마지막 열기 작업자가 파일을 닫으면 캐시의 데이터는 삭제되며 디스크 쓰기가 발생하지 않습니다. 이 명령을 사용할 때는 파일이 비어 있어야 합니다.
set_open_options 스크래치 -캐시 모드 메모리 상주
이는 해당 파일의 블록이 가능한 한 많이 캐시에 무기한 유지되도록 합니다. 실제 블록 수는 set_tuning_parameters 명령어로 설정된 캐시 크기와 메모리 상주 비율에 따라 결정됩니다.
다음 시퀀스는 프로그래밍 방식 사용 예시를 보여줍니다(test_system_calls를 사용하여 설명됨):
tsc: s$attach_port p 스크래치
tsc: s$open p -io_type update
이제 약 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은 절대 바이트 오프셋으로 위치 지정하는 오퍼코드도 지원합니다.
결과는 다음과 같으며, 해당 파일은 디스크에서 단 두 개의 데이터 블록만을 차지합니다:
..dump_file 임시 -간략
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:04:17 est
블록 번호 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 |…………….|
블록 번호 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
참고: 블록 1과 131870736은 캐시에 존재하며 일반적으로 디스크에 기록되지 않습니다. 다만 캐시 자원이 부족할 경우를 대비해 해당 블록들을 위한 디스크 공간은 예약되어 있습니다. 위의 dump_file 명령어는 디스크를 읽는 것이 아니라 캐시된 블록을 확인하고 있습니다.
RAM 파일이 비활성화되면(어떤 프로세스에서도 더 이상 열려 있지 않음), VOS는 파일을 잘라내고(수정된 블록을 디스크에 쓰지 않음) 모든 디스크 공간을 해제합니다. 일반적인 상황에서는 위의 순서로 인해 두 파일 맵 블록의 쓰기 작업 외에는 디스크 I/O가 전혀 발생하지 않으며, 이 블록들은 결국 폐기됩니다.
tsc: s$close p
이제 파일은 비어 있으며 디스크 공간을 차지하지 않습니다:
tsc: ..dump_file 임시 파일
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:07:12 est