[NES-8] NES의 writeback 캐시 티어 읽기 쓰기 동작 조정

[bgy217]

• NES Writeback 캐시 티어의 쓰기 동작이 베이스 풀에 데이터 쓰고 캐시 풀에 올리는 (promote) 방식으로 동작하고 있던 것을 발견했다.
• 이 동작은 의도한 동작과 정 반대이므로 해당 동작을 캐시 풀에 쓰고 베이스 풀에 비동기로 내리는 (non blocking flush) 방식으로 변경한다.
• 관련 지라: https://jira.nexr.kr/browse/NES-8#

[bgy217]

• 쓰기 직후 flush의 유무가 성능이 미치는 영향은 미미하다.
• agent에 의한 flush 정책과 체계에 혼선을 주지 않고 베이스 풀의 로드를 줄이기 위해 쓰기 직후 flush는 수행하지 않기로 했다.
• 살짝 더 좋은 성능은 덤이다.

[bgy217]

• 데이터 읽기 동작에 따른 읽기 성능
  • (기존 방법) 캐시 티어에 없는 오브젝트를 베이스 티어에서 찾아가라고 유도, 이후에 캐시 티어에 promote
    • 1178MB/s
  • 캐시 티어에 없는 오브젝트를 promote 요청 후 읽기 재요청 권고
    • 275MB/s
  • 캐시 티어에 없는 오브젝트를 무조건 promote 한 뒤에 전달
    • 504MB/s
  • 캐시 티어에 없는 오브젝트를 promote 하여 전달하고 해당 오브젝트가 이미 promote 중이면 읽기 재요청 권고
    • 777MB/s
  • 모든 성능 측정은 캐시를 비운 후에 수행했다.
• 기존 방식이 제일 빠른 속도를 보여주므로, 기존 방식을 바꾸지 않는 방식으로 진행할 것.

[bgy217]

• 쓰기로 분류되는 요청 중에 기존의 오브젝트에 조작을 가하는 요청들은 대상 오브젝트가 evict되어 캐시 티어에 없는 경우 오작동을 일으킬 수 있다.
• 기존의 오브젝트를 필요로 하는 쓰기 요청은 쓰기 요청을 수행하기 전에 오브젝트의 promote를 시도하도록 하여 문제를 해결하였다.
• 새로운 오브젝트를 만들어서 쓰는 다음의 요청은 promote 과정 없이 진행하도록 개발했다.
  • CEPH_OSD_OP_CREATE (none exclusive)
  • CEPH_OSD_OP_WRITEFULL

[bgy217]

• 기존의 랜덤 읽기/쓰기 성능
  • Run status group 0 (all jobs):
    READ: bw=111MiB/s (116MB/s), 12.9MiB/s-14.7MiB/s (13.5MB/s-15.4MB/s), io=32.5GiB (34.9GB), run=300048-300178msec
    WRITE: bw=116MiB/s (121MB/s), 14.3MiB/s-14.8MiB/s (15.0MB/s-15.5MB/s), io=33.9GiB (36.4GB), run=300048-300178msec
• 동작 조정 후 랜덤 읽기/쓰기 성능
  • Run status group 0 (all jobs):
    READ: bw=155MiB/s (163MB/s), 17.8MiB/s-19.9MiB/s (18.7MB/s-20.9MB/s), io=45.6GiB (48.9GB), run=300103-300272msec
    WRITE: bw=162MiB/s (170MB/s), 20.1MiB/s-20.5MiB/s (21.0MB/s-21.5MB/s), io=47.6GiB (51.1GB), run=300103-300272msec
• fio로 수행했고 클러스터 구성은 ssd osd 1개 hdd osd 3개이다.
• fio 프로파일은 다음과 같다.

[global]
name=fio_s3_bench
ioengine=http
http_verbose=0
https=off
http_mode=s3
http_host=10.0.3.58:8085
http_s3_keyid=QZOEVBYO758KQX7AGYH4
http_s3_key=ZKlmWxaD6h8dPI24GbgyyWvSos0moFMn1cqPYkgG
http_s3_region=default
direct=1
rw_sequencer=identical
stonewall

[s3_8m]
filename=/bench-bucket/8mobj
time_based=1
rw=randrw
size=40G
bs=8M
time_based=1
runtime=300
ramp_time=0
numjobs=8