When Caching Systems Meet Emerging Storage Devices: A Case Study
HotStorage 2023
Zhen Lin, University of New York at Binghamton;
Lianjie Cao, Faraz Ahmed, Hewlett Packard Labs;
Hui Lu, State University of New York at Binghamton;
Puneet Sharma, Hewlett Packard Labs
Link : https://www.hotstorage.org/2023/program.html
Paper : https://huilucs.github.io/pubs/shruti.pdf
첫 포스팅에서는 논문을 개괄적으로 요약했고 https://dev-charlotte.tistory.com/178
두 번째 포스팅에서는 논문에 포함된 자료를 간략하게 분석했으며 https://dev-charlotte.tistory.com/180
이번 포스팅에서 논문 전문을 자세하게 분석할 예정
첨부한 이미지는 논문 원문을 캡처한 것
일반 폰트는 논문 원문을 한국어로 번역한 것
괄호 내용은 논문에 없으나 이해를 위해 추가한 것
0. ABSTRACT
1. Introduction
2. BACKGROUND AND RELATED WORK
2-1. Fast storage and interconnect
새로운 스토리지 기술 덕분에 NVMe SSD의 대역폭은 더 높아지고 지연시간은 더 낮아졌다.
(고성능 스토리지 디바이스인 NVMe SSD가 이용하는 PCIe bus는 컴퓨터와 고속 주변 장치를 연결하는 고속 데이터 전송 규격으로 NVMe SSD를 CPU에 연결하는 통로 역할, 고속 전송과 낮은 지연시간이 특징)
기존 스토리지 장치는 블록 단위의 접근 방식이라 특정 바이트 수정을 위해서는 해당 바이트가 포함된 블록 전체를 읽고 수정한 후 저장해야했고, 그 때문에 속도가 느렸었다. 새로운 스토리지 기술 덕분에 바이트 주소 지정이 가능한 비휘발성 메모리가 시장에 출시되었다.
그래서 프로그램이 cpu에서 load와 store 명령어로 비휘발성 메모리의 데이터에 직접 접근할 수 있게 되었다.
(NVMe SSD는 기존의 비휘발성 메모리라 블록 단위 접근 방식을 사용하고 PCIe 버스를 통해서 CPU와 연결된다. DRAM은 휘발성 메모리로 메모리 버스를 통해 cpu와 연결되고 cpu가 주 메모리로 사용한다. pmem은 새로운 스토리지 기술의 등장으로 바이트 주소 지정이 가능해진 비휘발성 메모리로 메모리 버스를 사용해서 cpu가 dram을 사용하듯 메모리처럼 빠르게 접근할 수 있다. )
pmem은 dram보다 더 큰 용량에 비슷한 성능을 제공한다.
인텔이 옵테인 제품을 최근에 단종시켰지만 스토리지 분야는 고속 cpu 디바이스 인터커넥트 즉 cxl을 연구하는 방향이다. 여기서 말하는 cxl은 compute express link 의 약어로 dram이나 pcie처럼 다양한 스토리지 장치를 cpu와 직접적으로 연결하기 위한 통합된 인터페이스를 제공한다. 또한 작은 수정으로 PCIe 스토리지의 블록 인터페이스를 메모리처럼 바이트 주소 지정 인터페이스로 수정할 수 있을 것으로 보고 있다.
스토리지가 점점 빨라지고 점점 더 높은 대역폭을 제공하고 저점 더 낮은 지연시간을 제공하며 메모리처럼 바이트 주소 지정이 가능하게 될 것으로 예상된다. 해당 논문은 메모리 버스로 연결되는 pmem을 위주로 다루지만 cxl을 활용한 빠른 바이트 주소 지정이 가능한 스토리지에도 적용할 수 있을 것이다.
2-2. Block-level caching systems
블록 레벨의 캐싱 시스템
스토리지를 인식하는 캐싱 시스템은 dram, pmem, ssd, hdd 등 여러 레이어의 스토리지 디바이스로 구성된다. 빠른 디바이스일수록 비용이 많이 들고, 느린 디바이스보다 빠른 디바이스가 높은 계층에서 사용된다.
멀티 티어 계싱 (다계층 캐싱)에서 고성능 디바이스와 관련해서 스토리지 스택의 서로 다른 계층을 타겟팅하는 연구가 있었다. ex. open CAS, NVCache, orthusCAS 모두 로컬 호스트의 고성능 블록 디바이스를 느린 블록 디바이스의 캐시로 사용하는 블록 레벨에서 구현된 캐시 가속화 프레임워크이다.
(멀티 티어 캐싱 시스템은 속도와 비용이 다른 다양한 스토리지 디바이스가 계층적으로 배치되는 것이다. 빠르고 비싼 디바이스는 상위 레이어에, 느리고 저렴한 디바이스는 하위 레이어에 위치하는 방식이다. 이런 계층 구조를 통해서 자주 사용되는 데이터는 빠른 장치에, 덜 사용되는 데이터는 느린 장치에 저장해서 대용량 데이터를 비용 효율적으로 빠르게 처리하는 최적화를 이룰 수 있다.)
(openCAS, orthusCAS, nvCache는 모두 멀티 티어 캐싱 시스템을 가속화하기 위한 블록 레이어 캐싱 프레임워크인데 각각 다른 계층을 타켓팅해서 다양한 환경에서 최적화 성능을 제공한다)
(Open CAS (Open Cache Acceleration Software) 주로 상위 레이어 스토리지 디바이스(ex SSD)를 사용하여 하위 레이어 (ex HDD)의 느린 I/O 성능 개선. 상위 계층을 캐시로 활용하여 R W 속도를 향상시켜 전체 성능 향상)
(OrthusCAS = Open CAS처럼 고성능 블록 장치를 캐시로 사용 + 부하가 큰 상황에서 캐싱 레이어에서 capacity 레이어(HDD 처럼 느린 디바이스)으로 I/O를 오프로드하는 기능. 주로 부하가 극심할 때 성능 저하를 방지)
(NVCache = PMem(비휘발성 메모리) 같은 고속 디바이스를 활용하여 메모리와 디스크 사이의 중간 레이어 형성. 자주 액세스하는 데이터를 PMem에 저장하여 메모리 접근 속도와 비슷한 성능 제공 + 용량은 더 큼)
orthusCAS는 부하가 클 때 캐싱 레이어에서 주요 데이터를 저장하는 capacity 레이어로 excessive (과도한) 입출력을 오프로드 할 수 있다. 약간의 수정만으로도 openCAS와 통합될 수 있어서 논문 대부분의 연구 결과는 orthusCAS에도 적용할 수 있다.
mapperX는 리눅스 커널의 dm-캐시 구성 요소의 확장판이라 dm-캐시의 비동기 메타 데이터 업데이트의 단점을 해결해서 crash recovery 시간을 개선한다. (충돌 복구 시간)
(dm-cache = device mapper cache. 리눅스 커널의 디스크 캐싱 기능. 느린 디스크의 데이터 접근 속도를 빠른 디스크를 통해 가속화할 수 있음. 빠른 디바이스로 느린 디바이스의 성능을 향상시킴.)
(dm-cache는 데이터를 캐싱할 때 메타데이터 업데이트를 비동기 방식으로 처리 데이터를 캐시에 저장한 후에 메타데이터 업데이트를 따로 처리해서 업데이트가 제대로 되지 않았을 수 있다는 문제가 있음. 이럴 때 더 빠르고 안정적으로 시스템을 복구하게 하는 것이 mapperX)
(mapperX는 메타데이터 동기화를 특정 간격마다 수행하거나 캐시에 중요한 데이터 변경이 있을 때 우선적으로 기록하거나 업데이트 정보를 기록하는 저널링 방법을 사용하거나 주기적으로 일관상태로 저장하고 체크포인트를 생성한다 -> 논문에서는 체크포인트 방식을 언급하였으나 나머지는 확인이 필요함)
First Responder는 vfs (가상파일시스템)에 구현된 캐싱 프레임워크로 EX4 같은 기존의 파일 시스템을 위한 버퍼로 빠른 pmem을 사용한다.
strata는 pmem을 포함한 멀티 티어 스토리지와 함께 작동하는 로컬 파일 시스템으로 유저 스페이스와 커널 스페이스 모두에 캐싱을 적용한 파일 시스템을 구현한다.
assies는 pmem을 빠르고 지속적인 클라이언트 로컬 캐싱 디바이스로 사용하는 분산 파일 시스템이다.
2-3. open CAS
open cache acceleration software의 약어 open CAS는 백엔드 장치로 쓰이는 HDD의 성능을 개선하기 위해 설계된 블록 레벨 캐싱 솔루션. SSD에 데이터를 캐싱하여 성능을 향상시키는 솔루션. 산업 솔루션과 연구 프로젝트 모두에서 널리 사용되고 연구된다.
open CAS에는 두 가지 구현방식에는 SPDK, open CAS Linux가 있고 논문은 open CAS linux에 포커스를 두고 있다. 리눅스 커널 파일 시스템인 ext4, xfs, btrfs 등에서 작동하는 커널 모듈이며, 상위 레이어 파일 시스템으로부터 io요청을 받고 cas 가상 블록 디바이스로 하위 스토리지 디바이스에 io 요청을 전달해서 캐시 작업을 수행한다.
캐시 작업을 수행하기 위해 사용하는 캐시 모드는 총 6가지를 지원하는데 논문에서는 페이지 제한으로 인해 가장 제너럴하게 이용되는 캐시 모드인 write back WB 모드만 다룬다.
3. MEASUREMENT STUDY
intel optane persistent memory를 캐시로 사용하는 open CAS에 대한 종합적인 성능을 연구하고 분석한 챕터이다. 하나의 사례 연구로 사용해서 다양한 조건과 구성에서 최신 캐싱 시스템에서 새로운 스토리지 디바이스의 성능을 이해하기 위함이었다. 성능 결과를 바탕으로 새로운 스토리지 디바이스를 최적화하기 위한 기존 캐싱 시스템의 재설계나 최적화를 위한 인사이트를 다룬다. 읽기보다 더 복잡하고 시스템 병목을 유발하기 때문에 주로 쓰기 성능 평가에 집중한다.
3-1. Experimental Configurations
HPE ProLiant DL380 Gen10 Plus 서버에서 Intel Xeon Silver 4314 프로세서 1개, 4 × 32GB DDR4 3200MHz 메모리, 그리고 4 × 256GB Intel Optane 200 Persistent Memory가 장착해서 실험했고 비교를 위해 서버에는 1 × 400GB Intel Optane NVMe SSD P5800X, 1 × 960GB Samsung NVMe SSD PM9A3, 1 × 960GB Samsung SATA SSD PM863도 추가로 장착했다. Ubuntu Server 20.04.6 LTS가 설치되어 있으며, Linux 커널 버전은 5.4.0-144-generic이고 파일 시스템은 Ext4(저널링 비활성화 상태)로 설정했다.
쓰기 워크로드를 생성하기 위해 FIO(버전 3.34-13)를 싱글 스레드 모드에서 사용하였으며, 페이지 캐시를 우회하기 위해 direct I/O(direct=1)를 사용했고, 동기식 데이터 I/O(sync=dsync)를 사용했고, Open CAS는 SSD와 HDD를 지원하도록 설계되어 있어서 Optane PMem은 일반 블록 장치로만 사용할 수 있으며 직접 접근(DAX) 모드는 지원되지 않는다.
실험을 수행하기 전에 데이터 업데이트에 초점을 맞추기 위해 쓰기 작업 중 파일 시스템 메타데이터 업데이트가 발생하는 것을 방지하기 위해 8GB의 테스트 파일을 미리 생성하고 이를 백엔드 장치에 기록해 두었다.
실험은 다양한 시나리오를 포괄할 수 있도록 신중하게 설계되었다. 캐시 장치의 용량은 4GB로 설정되었으며, FIO는 2GB에서 6GB까지의 다양한 크기의 파일을 Open CAS 가상 블록 장치에 쓰는 데 사용되었다. 다양한 요인이 미치는 영향을 체크하기 위해 캐시 라인 크기(CL = 4KB, 16KB, 64KB), 단일 쓰기 크기(WS = 4KB에서 1024KB), 동일 파일에 대한 여러 번의 접근을 테스트했다.
3-2. Raw Performance of Storage Devices
openCAS 없이 FIO를 사용해서 다양한 크기의 쓰기 작업 요청을 생성하고 모든 스토리지 디바이스의 쓰기 대역폭을 벤치 마크했다. (벤치마크 = 성능을 측정하고 비교했다) 그 결과를 open CAS와 비교할 때 기준선으로 사용했다.
도표에서 볼 수 있듯이 pmem은 특히 작은 크기의 쓰기 작업에서 모든 종류의 ssd 성능을 크게 능가했다.
(pmem은 파란색, 그 외 빨간색 노란색 초록색은 모두 ssd)
동일한 3d xpoint 기술을 사용하는 p5800x와 비교해도 pmem은 모든 쓰기에서 높은 쓰기 대역폭을 일관되게 보여준다.
pmem과 p5800x 모두 인텔 옵테인 메모리를 사용하지만 pmem은 dimm 패키지로 제공되고 dram 버스에서 동작하지만 p5800x ssd는 pcie 버스 상의 표준 nand 패키지 모델로 제공되고 nvme 프로토콜을 사용해서 동작하기 때문이다.
논문의 레퍼런스인 Izraelevitz, J., Yang, J., Zhang, L., Kim, J., Liu, X., Memaripour, A., Soh, Y. J., Wang, Z., Xu, Y., Dulloor, S. R., et al. Basic performance measurements of the intel optane dc persistent memory module. arXiv preprint arXiv:1903.05714 (2019) 의 3.2 section에서 다른 장치와 비교했을 때 일관되게 우수한 결과가 논문과 일치한다.
(하단 이미지 참고)
이런 결과들은 pmem이 높은 성능 덕분에 캐시 장치에 적합함을 설명한다.
3-3. Open CAS Performance
open cas의 write back WB모드에 포커스를 두고 open cas의 성능을 측정한다. WB모드의 주요 구성 요소인 WB 엔진은 데이터를 백엔드 장치에 쓰기 전에 먼저 캐시 장치의 하나 이상의 캐시 라인에 데이터를 쓰고 애플리케이션에 캐시 작업을 했다고 알려준다. 캐시 라인은 open cas가 관리할 수 있는 가장 작은 데이터 단위이다.
모든 사용 중인 캐시 라인은 백엔드 장치의 특정 코어라인과 연결되어 있고 캐시 라인은 코어라인으로 쓰여진다. (코어 라인은 백엔드 장치의 저장소에 해당하는 최종 저장 위치, 캐시에서 임시로 저장된 데이터가 최종적으로 기록될 백엔드 장치의 특정 위치)
(캐시라인에 저장된 데이터가 최종 백엔드 특정 위치인 코어 라인에 저장된다는 거, 처음에는 빠른 임시 저장하고 캐시 full처럼 특정 조건이 만족돠면 백엔드 장치로 옮기는 것)
open cas는 4~64kb에 이르는 캐시 라인 크기를 지원하고 가상 블록 디바이스가 초기화되면 캐시 라인 크기는 변경할 수 없다. (캐시 라인 크기 = 데이터를 나눠서 한 번에 캐시에 저장할 크기) (성능을 일정하게 유지하고 관리를 단순하게 하기 위해 변경 불가)
캐시 디바이스에 있는 더티 데이터는 백그라운드에서 주기적으로 클리너로 백엔드 장치에 플러시한다.
(더티 데이터 = 캐시에 임시 저장되었지만 백엔드에 저장하지 않은 상태인 것)
(백그라운드 플러시 = 바쁘지 않은 bg에서 더티 데이터를 백엔드에 옮겨서 저장하는 것)
데이터가 이미 사용 중인 캐시라인에 쓰이면 캐시 히트, 그렇지 않으면 캐시 미스이다.
캐시 장치가 가득 차면 사용 중인 캐시 라인 일부를 비우기 위해 기본적인 LRU (least recently used) 제거 정책을 기반으로 캐시 제거 eviction가 트리거 된다.
복잡한 캐시 히트와 캐시 제거 시나리오에서 open cas 성능을 측정하기 위해서 동일한 파일에 두 번 연속 접근한다. 첫 번째 접근과 두 번째 접근의 캐시 라인 크기는 4kb에 64kb로 다르고 파일 크기는 2gb에서 6gb로 다르다. 결합해서 캐시 장치 용량이 4gb일 때 수행되도록 한다.
(즉, open cas의 성능을 다양한 상황에서 테스트하기 위해 동일한 파일을 두 번 연속 접근하면서 다른 캐시 라인 크기와 파일 크기 조합을 사용해서 실험한다는 것)
(같은 파일을 두 번 접근하는 이유는 첫 번째 접근과 두 번째 접근에서 캐시를 어떻게 사용하는지 캐시 히트와 미스 발생이 어떻게 일어나는지 확인하기 위함 >> 첫 번째 접근은 데이터가 캐시에 없으니 캐시 미스가 발생할 것, 두 번째 접근에서는 데이터가 이미 캐시에 있을 확률이 높다)
(캐시 라인 크기는 캐시에 데이터를 저장할 때 사용하는 블록 단위의 크기이고 4kb는 작아서 세부적으로 관리할 수 있지만 관리 오버헤드가 발생하고 64kb는 관리 오버헤드는 줄일 수 있지만 작은 데이터 처리에 비효율적이다)
(캐시에 저장하고자 하는 파일 전체의 크기는 2gb, 6gb를 사용하는데 2일 경우 파일 크기가 작아서 캐시 용량이 충분할 수 있지만 파일이 6으로 클 경우 캐시에 모두 저장할 수 없어 캐시 제거 작업이 발생할 수 있다)
(캐시 디바이스 용량을 4gb로 설정하면 캐시에 4gb만큼 데이터를 담을 수 있는데 파일 크기가 4gb 이하면 캐시 용량이 충분하니 모두 저장할 수 있지만 그 이상인 경우 캐시 용량이 부족해서 일부 데이터를 캐시에서 제거해야한다)
집중해서 분석할 경우 네 가지는 다음과 같다.
- 첫 번째 접근 시 파일 크기(FS)가 캐시 용량(CC)보다 작은 경우 (FS < CC)
캐시에 해당 데이터가 처음 들어가므로 캐시 미스 발생
하지만 캐시 용량이 충분하므로 캐시 제거는 발생하지 않는다
- 첫 번째 접근 시 파일 크기(FS)가 캐시 용량(CC)보다 크거나 같은 경우 (FS ≥ CC)
파일의 크기가 캐시 용량을 초과하기 때문에 캐시 미스 발생
일부 데이터를 캐시에서 제거해야 하기 때문에 캐시 제거 발생
- 두 번째 접근 시 파일 크기(FS)가 캐시 용량(CC)보다 작은 경우 (FS < CC)
첫 번째 접근에서 이미 데이터를 캐시에 저장했기 때문에 캐시 히트 발생
캐시 용량이 충분하므로 캐시 제거는 필요하지 않다
- 두 번째 접근 시 파일 크기(FS)가 캐시 용량(CC)보다 크거나 같은 경우 (FS ≥ CC)
첫 번째 접근에서 일부 데이터는 캐시에서 제거되었을 수 있으므로 캐시 미스 발생 가능성 있다
전체 파일에 대해 캐시 제거가 발생할 수 있다
3-3-1. Metadata Overhead
observation
ws = cl 일 때의 쓰기 대역폭 변화를 보여주는 그림3 그래프
각 쓰기 요청이 정확히 하나의 캐시 라인에 접근할 때 쓰기 대역폭의 변화
fs < cc 두 번째 접근보다 첫 번째 접근의 대역폭이 낮지만 cl과 ws가 커지면서 두 접근 간 대역폭 차이가 줄어든다.
pmem + pm9a3 조합에서 대역폭 차이가 4kb일 때 40%, 16kb일 때 25%, 64kb일 때 14%로 점점 감소한다.
캐시 라인 크기가 커지면서 첫 번째 접근에서 발생하는 메타데이터 오버헤드가 상쇄하기 때문이다.
(첫 번째 접근에는 저장된 캐시 데이터가 없으니 데이터 쓰기 전에 추가적으로 메타데이터를 갱신하고 저장하는 작업이 필요하고 그 때문에 속도가 느려지는 메타데이터 오버헤드가 발생한다. 캐시 라인이 작으면 더 많은 접근이 필요해서 더 많이 갱신하니까 메타데이터 오버헤드가 적게 발생하지만 캐시 라인이 커질수록 데이터를 한 번에 더 큰 덩어리를 읽고 쓸 수 있으니 한 번의 메타데이터 갱신으로 더 많은 데이터를 처리할 수 있어서 오버헤드가 적게 발생한다. )
analysis
첫 번째 접근에서 캐시 미스가 발생하니까 open cas의 메타데이터를 업데이트하고 캐시 디바이스로 플러시해야한다. (캐시에 없으니 캐시로 넘겨주기 위해 플러시가 필요하다)
두 번째 접근에서 캐시 히트가 발생하여 추가적인 메타데이터 작업은 필요하지 않다.
그림2
open cas는 여러 유형의 메타데이터를 저장하는데 그 중에서 collision 충돌 세그먼트가 성능에 가장 큰 영향을 미친다.
(충돌 세그먼트는 캐시 시스템에서 데이터 위치를 추적하고 관리하는 메타데이터의 일부, 캐시에서 저장하는 데이터가 어디에 위치하는지 매핑하는 역할, 특정 데이터를 찾을 때 충돌 세그먼트를 이용해서 정확하게 찾을 수 있기 때문에 성능에 영향)
충돌 섹션에는 dram 내에 저장된 4kb 메타데이터 블록 세트가 포함되어 있고 각 블록은 여러 개의 12바이트 청크들로 구성되어있다. 그 청크들은 각각 cl 캐시 메모리가 한 번에 처리할 수 있는 데이터 단위 4kb, 16kb, 64kb에 대해 12, 18, 42바이트에 해당하는 부분들은 캐시 라인과 코어 라인의 매핑 정보와 상태 비트(유효상태, 업데이트여부)를 저장한다.
첫 번째 접근에서의 각 쓰기 요청은 12바이트의 충돌 블록을 업데이트 하고 12바이트의 충돌 블록을 업데이트하고 충돌 메타데이터 청크가 위치한 4kb 메타데이터 블록을 덮어 쓰고 그 4kb 메타데이터 블록을 캐시 장치로 플러시해야한다.
첫 번째 접근에서 단일 쓰기 작업에 대해 캐시 장치에 기록되는 총 바이트 수는 4kb의 메타 데이터 + 캐시 라인 사이즈의 데이터이다.
cl이 4kb인 경우 첫 번째 접근에서는 캐시 장치에 2 x FS (파일 크기)가 기록된다.
(메타 데이터와 실제 데이터를 모두 기록해야하기 때문이다)
4kb일 때 pmem과 p5800x에서 첫 번째와 두 번째 접근 간의 쓰기 대역폭 차이는 각각 40%, 48%이다.
첫 번째 접근에서 발생ㅇ하는 추가 메타데이터 쓰기의 영향은 cl이 증가함에 따라 상쇄된다. 대역폭 차이가 점점 줄어들게 되는 것이다.
table1. cpu usage breakdown
표1은 fs < cc일 때 (파일 사이즈가 캐시 용량보다 작을 때) fio 기본 성능 첫 번째 두 번째 접근에 대한 cpu 사용률 분포를 나타낸다. open cas는 첫 번째 접근 45%과 두 번째 접근 38% 모두에서 메타데이터와 데이터 작업을 포함하여 cpu 시간을 상당히 소비한다. 메타데이터 작업으로 인해 발생하는 부분을 정확하게 측정하기는 어렵지만 추정에 따르면 첫 번째 접근에서 open cas가 소비하는 cpu 사용량의 최대 50%가 메타데이터에 할당됨을 알 수 있다.
takeaway #1
open CAS의 메타데이터 업데이트는 추가적인 캐시 장치 대역폭을 사용한다. 동시에 open CAS의 소프트웨어 스택은 상당한 cpu 자원을 소모한다.
3-3-2. Cache eviction overhead
observation
그림3은 파일 사이즈가 캐시 용량보다 크거나 같은 경우 파일 크기가 증가함에 따라 첫 번째 접근의 대역폭은 서서히 줄어들지만 두 번째 접근의 대역폭은 파일 사이즈가 캐시 용량보다 작을 때보다 비교하면 급격히 떨어진 후에 파일 크기가 커져도 대역폭이 거의 일정하게 유지된다.
이와 같은 패턴은 실험에서 사용된 모든 캐시와 백엔드 장치 조합에서 나타났다. 하지만 백엔드 장치를 pm9a3 이라는 nvme ssd에서 pm863이라는 sata ssd로 바꾸면 확연한 차이가 나타나고 cl 캐시 메모리가 한 번에 처리할 수 있는 데이터 단위와 ws 쓰기 크기가 커질수록 더 큰 차이가 나타난다.
analysis
파일 크기가 캐시 용량보다 클 때 주된 차이점은 캐시에서 데이터를 제거해야한다는 것이다.
첫 번째 접근에서는 기본 LRU 제거 정책에 따라 파일의 마지막 부분을 쓰기 위해 가장 오래된 캐시 라인을 비워야 한다.
두 번째 접근에서는 첫 번째 접근 중에 캐시에 써있던 모든 데이터를 제거해야하니 각 쓰기 요청마다 모두 캐시 제거가 발생하게 된다.
예를 들어서 캐시 용량이 4gb일 때 파일 크기가 5gb일 때 첫 번째 접근에서는 첫 1gb를 제거하고 마지막 1gb를 써야 한다.
두 번째 접근이 시작될 때는 첫 번째 1gb 데이터가 (이미 첫 번째 접근할 때 파일 후반부의 1gb를 쓰기 위해서) 제거 되었기 때문에 두 번째 접근할 때는 (1gb가 없어서) 캐시 히트가 발생하지 않는다.
파일의 두 번째 1gb 데이터도 LRU 정책으로 제거되고 이 모든 과정은 두 번째 접근 과정 전체에 걸쳐 반복된다. 결국 첫 번째와 두 번째 접근 간 쓰기 대역폭 차이는 차별화된 캐시 제거 동작에서 비롯된다.
open cas에서 캐시 제거는 다음과 같은 단계로 일어난다.
1 캐시 장치에서 디램으로 캐시 라인 크기만큼 기존 데이터를 읽어온다
2 기존 데이터를 캐시 라인 크기만큼 백엔드 디바이스에 쓴다
3 기존 메타데이터의 상태 비트를 업데이트 하고 4kb 크기의 이 내용을 캐시 장치에 쓴다
4 새로운 데이터를 캐시 라인 크기만큼 캐시 장치에 쓴다
5 4kb 크기의 새로운 메타데이터를 캐시 장치에 쓴다
결과적으로는 캐시 장치에서 캐시 메모리에 한 번에 쓸 수 있는 크기만큼 읽어온 후에 캐시 장치에 cl과 4kb와 4kb를 쓰고 백엔드 장치에 cl을 쓴다
유효 비트를 업데이트하기 위해서 12바이트의 충돌 메타데이터 청크만이 아니라 전체 4kb 충돌 메타데이터 블록을 업데이트하고 캐시 장치에 플러시해야한다 반드시 !!
ws = cl = 4kb인 최악의 경우에는 캐시 제거가 포함된 쓰기 요청에서 캐시 장치에 기록되는 총 바이트 수가 데이터 양의 최대 3배가 될 수 있다.
(기존 데이터 읽고 기록, 메타데이터 업데이트, 새로운 데이터 쓰기 >> 3배)
만약 ws나 cl이 4kb보다 크다면 크기가 커져서 쓰기 요청을 적게 하거나 여러 캐시 라인이 동일한 4kb 메타데이터 페이지를 공유할 수 있기 대문에 오버헤드가 줄어든다. 이때는 ws가 cl이 크다.
파일 크기가 캐시 용량보다 클 때 쓰기 대역폭은 주로 세 가지 요인에 의해 결정된다
1 파일 첫 4GB에 대한 쓰기 대역폭
2 캐시 제거로 인한 쓰기 증폭 오버헤드 (최대 3배)
3 캐시 제거로 인해 백엔드 장치에 플러시해야하는 기존 데이터 처리에 필요한 쓰기 대역폭
첫 번째 접근에서는 캐시 용량을 초과해 데이터를 쓰면 캐시 제거가 발생한다.
파일 크기가 커질수록 캐시 제거의 영향이 커지면서 쓰기 대역폭은 줄어든다.
두 번째 접근에서는 각 쓰기 요청마다 캐시 제거가 필요해서 전체적으로 낮은 쓰기 대역폭이 일관되게 유지된다.
takeaway2
캐시 제거는 추가적인 메타데이터 업데이트를 필욯로 하고 그 결과 쓰기 증폭과 오버헤드가 많이 발생한다/
3-3-3. Write Invalidate
observation
그림3의 실험과는 다르게 실제 환경의 작업들은 캐시 라인 크기와 다른 다양한 쓰기 사이즈를 포함하는 경우가 많다.
관찰 결과 하나의 쓰기 요청이 여러 개의 캐시 라인을 요구할 때 (write size > cl) open CAS의 동작과 성능이 크게 변화한다.
그림 4는 하나의 쓰기 요청이 각각 4개와 128개의 캐시 라인을 필요로 할 때 open cas의 쓰기 대역폭을 보여준다. 쓰기 크기를 ws = cl에서 ws = 4 x cl로 변경할 때 유사한 패턴이 관찰된다. 하지만 쓰기 크기를 128 x cl로 변경하면 같은 패턴이 완전하게 적용되지 않는다.
파일 크기가 캐시 용량보다 크면 첫 번째 접근이 메타데이터 업데이트로 인한 오버헤드를 포함하기 때문에 두 번째 접근의 쓰기 대역폭이 여전히 첫 번째보다 더 좋다.
파일 크기가 캐시 용량보다 크거나 같을 때는 첫 번째 접근의 쓰기 대역폭이 더이상 줄어들지 않는다. 실제로 백엔드 장치로 pm9a3가 사용될 때 약간 증가한다. 반면에는 두 번째 접근에서 파일 크기가 커지면서 쓰기 대역폭이 서서히 감소한다.
또 다른 관찰 결과는 ws = 512kb일 때 p5800x가 두 번째 접근에서 pmem보다 약 25%가 더 나은 성능을 보인다.
analysis
open cas의 통계와 코드를 분석한 결과 주로 write invalidate 모드와 스토리지 장치 특성에 의해 발성하는 것임을 알게 되었다. wi 모드는 여러 모드로 활성화될 수 있고 쓰기 요청은 직접 백엔드 장치로 전달된다.
실험에서 wi모드는 32개의 캐시 라인을 제거해도 쓰기 요청을 처리할 만큼의 빈 캐시 라인을 확보할 수 없을 때 활성화된다. 512kb 쓰기 요청이 들어오면 wb엔진은 가장 최근에 사용되지 않은 데이터부터 제거하는 LRU를 사용해서 최대 32개의 캐시 라인을 비우려고 시도한다.
쓰기 요청은 총 128개의 4kb 캐시 라인을 필요로 하기 때문에 wi모드가 활성화되어 데이터가 백엔드 장치에 직접 기록된다. wi모드는 캐시 제거 횟수를 줄여주고 오버헤드를 피할 수 있게 해준다.
하지만 백엔드 장치 성능이 낮으면 쓰기 대역폭은 낮아질 수 있다.
pmem과 pm9a3의 경우 파일 사이즈가 캐시 용량보다 크고 wb = 512kb일 때 첫 번째 접근에서 wb엔진은 일의 4gb 이후에 위치한 pmem의 캐시 라인을 비우려고 한다. 하지만 이 과정에서 32개 이상 비워야 해서 wi 모드가 활성화되고 메타데이터가 업데이트되고 제거되는 오버헤드가 발생하지 않고 데이터가 pm9a3에 직접 기록된다.
첫 번째 접근이 끝나면 파일의 처음 4gb는 pmem에 저장되고 나머지는 pm9a3에 저장된다. 파일 크기가 첫 번째 접근의 쓰기 대역폭은 캐시 용량보다 작을 때 더 높은데 이는 512kb 단위로 pm9a3의 성능이 메타데이터 오버헤드를 가지는 pmem보다 약간 더 좋기 때문이다.
두 번째 접근에서는 첫 번째 접근 중 파일 끝부분이 pmem이 pm9a3에 저장되어 있어서 전체 캐시 제거가 일어나지는 않는다. 따라서 파일의 처음 4gb에 대해 캐시 히트가 발생하며 메타데이터 오버헤드 없이 pmem에 데이터가 써진다. 나머지 파일은 첫 접근과 비슷하게 wi 모드를 통해서 pm9a3에 기록된다.
캐시 히트가 발생할 때 pmem의 쓰기 대역폭이 wi모드에서의 pm9a3보다 좋아서 파일 크기가 커질수록 두 번째 접근의 전체 쓰기 대역폭이 줄어든다. 더 많은 데이터를 wi모드로 pm9a3에 직접 써야 하기 때문이다.
실험에서 백엔드 장치의 성능이 매우 중요하다. pm9a3을 더 안 좋은 성능인 pm863으로 교체할 때 파일 사이즈가 캐시 용량보다 크면 pm9a3을 사용하는 것보다 첫 번째와 두 번째 접근의 쓰기 대역폭이 훨씬 더 줄어든다.
takeaway3
작업 부하와 스토리지 장치의 성능 특성을 고려하지 않고 캐시 시스템을 고정적으로 최적화하고 설정하면 예기치 않은 성능 저하를 일으킬 수 있는 복잡한 동작이 발생할 수 있다.
WS=512KB WS = 512KB 일 때 두 번째 접근에서 PMem의 쓰기 대역폭이 P5800X보다 약간 낮다. Open CAS가 PMem을 일반 블록 장치처럼 사용하기 때문이다.
Open CAS에서 캐시 라인은 여러 목록으로 나누어진다. 만약 쓰기 요청이 여러 캐시 라인에 걸쳐 있으면 빈 캐시 라인이 목록에서 선택되고 쓰기 작업은 작은 미니 배치 단위로 그룹화된다.
P5800X를 캐시 장치로 사용할 때 NVMe 드라이버는 미니 배치 쓰기를 논블로킹 방식으로 처리하지만 PMem은 여러 쓰기를 CPU에서 순차적으로 처리해야 하므로 성능이 떨어진다.
Open CAS가 PMem을 블록 장치로 사용하기 때문에 블록 I/O 계층에서 상당한 CPU 자원이 소모되고 PMem DAX 모드를 사용하여 최소화할 수 있습니다.
takeaway 4
새로운 스토리지 장치는 캐시 시스템에 의해 충분히 지원되고 최적화되지 않아서 성능 저하가 발생할 수 있다.
