Introduction

• OSDI 2022 revision을 참여하면서, 우리가 만든 ListDB와 PMem-RocksDB 간 성능을 비교하는 그래프가 있는데, YCSB 대신 USENIX FAST’20 에서 발표되었던 Facebook에서 직접 개발한 MixGraph 워크로드로 벤치마크를 수정해달라는 요청을 받았다.
• 디테일한 아이디어는 논문에서 확인할 것 [pdf]
• 스크립트 관련해서는 공식 wiki를 참고할 것 [link]
• 논문의 주요내용
• 나의 생각
• PMem-RocksDB란?
• github wiki에 있는 mixgraph 스크립트 예시

시행착오

1. QPS가 sine 모양으로 나오지 않는 이슈

   • 코드에 몇 줄 추가해서 query가 sine 모양으로 나오는지 log를 찍고 plot을 해보았는데 flat한 모양이 나왔다.

   • 해결방법

     

     • db_bench를 실행할 때 sine_mix_rate option을 true로 설정
     • 아 ㅋㅋ 이거 왜 default 아니냐고... ㅋㅋ

2. 멀티쓰레드 버그이슈

   • pmem-rocksdb의 db_bench 코드를 분석해보았는데 다행히 mixgraph 코드가 들어있는 버전이었다.
   • 문제는 pmem-rocksdb에서 mixgraph를 멀티쓰레드로 돌리면 터진다는 점...

     • 기존 RocksDB에서 mixgraph를 멀티쓰레드로 돌리면 터지는, 버그가 있었던걸로 보이는데 고치기 전의 버전으로 PMem-RocksDB를 작성한걸로 보인다.

     • 자료 (나와 정확히 같은 이슈)

       https://github.com/facebook/rocksdb/issues/8215

     • 현재 RocksDB에서 해당 버그는 고쳐짐.

   • pmem-rocksdb에서 돌렸을 때 정확히 같은 에러를 뱉는 걸 확인할 수 있었고, 오류가 나는 이유는 RateLimiter를 업데이트 하는 과정에서 concurrency 이슈가 있었던 걸로 보인다.
   • 왜 RateLimiter를 사용하냐면 mixgraph 워크로드는 QPS가 sine 함수 모양으로 가도록 해야하기 때문에 RateLimiter를 통해서 query request 속도를 실시간으로 조정한다.
   • 해결방법
     • 해당 버그 지점 및 MixGraph() 함수 내에서 RateLimiter를 수정하는 여러 지점이 있는데 이를 최신 RocksDB 버전에 맞게 고쳐주었다.

3. 너무나도 이상적인 sine 모양

   • 그래도 나름 실제 trace를 기반으로 만든 synthetic 워크로드인데 sine 모양이 너무나도 이상적으로 나온다.
   • 내가 돌린 결과

   

   • 논문에서 보여준 그림

   

   • 해결방법
     • db_bench 옵션으로 sine_mix_rate_noise를 추가한다.
     • 이건 default가 0인건 인정하는데 sine_mix_rate도 그렇고 왜 둘다 문서에 내용을 안적어준지 모르겠다. 예시 스크립트에도 없고...

4. ReporterAgent는 왜 총 ops만 보여주는 것인가

   • 아무래도 실험 그래프를 그려야 하기 때문에 각 second 당 몇개의 ops가 처리되는지를 알아볼 필요가 있었다.
   • RocksDB는 굉장히 큰 오픈소스 프로젝트이기에 당연히 이를 log로 찍을 수 있는 옵션을 제공하고 있다. 이 클래스의 이름은 ReporterAgent.
   • ReporterAgent class의 위치는 tools/db_bench_tool.cc에서 확인할 수 있고, 주석에 적혀있다싶이, benchmark에 옵션을 주면 csv 파일로 내가 설정한 경로에 저장을 해준다.
   • 당연한 얘기겠지만 ReportAgent는 thread-safe하게 작성되어 있기 때문에 concurrency를 별도로 고려해주지 않아도 된다.

   

   • 다음과 같이 report_file 이라는 옵션을 설정할 수 있다. 추가적으로 report_interval_seconds 라는 옵션도 설정해서 몇 초를 주기로 log를 찍을 건지도 설정 가능하다.

   

   • 하지만 여기서 문제는 ReportAgent는 get, put, seek 등을 합친 총 ops만 보여준다는 점이었다.
   • 해결방법1 (feat. Wonbae Kim)
     • thread 별로 파일을 만들고 (예: thread_0.dat, thread_1.dat ...), 각 파일안에 <query_type, microsecond> 를 기록한다.
     • 별도의 파이썬 스크립트를 작성하여 merge 한다.
   • 해결방법2
     • tools/db_bench_tools.cc 에 직접 각 second 마다 어떤 종류의 op가 몇개 찍히는지를 추가했다.
     • 어떤 방법으로 할 지 고민하다가,
       • std::vector<std::map<uint64_t, uint64_t>> 를 get, put, seek 3개 만들고 쓰레드 별로 기록한 데이터들을 merge
         • 여기서 key는 시각, value는 ops 개수
         • e.g. {0.1, 1234} / {0.2, 2345} 이런식으로
       • 그리고 최종 데이터만 남겨서, history_file 이라는 옵션을 만들어서 그 경로에 작성하도록 하였다.
       • 벤치마크가 끝나고 나서 최종적으로 thread 별 데이터를 merge 하므로 concurrency를 고려할 필요는 없다.
   • 해결방법2로 고른 이유
     • 무엇보다 해결방법1은 완전히 raw data를 파일에 작성하는 것이기 때문에 추후 python으로 하는 merge가 너무 오래걸린다. python 스크립트를 multi thread로 돌려도 벤치마크 시간보다 오래걸림
     • 메모리 문제
       • 해결방법1로 했을 때 2가지 방법이 있다.
         • 메모리에 계속해서 <query_type, microsecond>를 저장한 뒤, 마지막에 file로 덤프
           • 벤치마크 결과에 영향을 주진 않지만, 워크로드가 길어지면 메모리 사용량이 기하급수적으로 증가
         • 벤치마크를 진행하면서 실시간으로 file에 작성
           • 벤치마크 결과에 영향을 줄 수 있다.

결과

• 몇 번 시행착오를 거쳐서 우리가 만든 ListDB와 PMem-RocksDB를 비교하는 MixGraph 벤치마크를 돌려보았다.

• 워크로드 설명

  • 워크로드 종류 : Prefix Dist
  • get : put : seek ratio = 7 : 3 : 0
  • thread 개수 : 80
  • key size : 48 byte
  • value size : 16 bytes to 10KB (Introduction 참고)
  • noise 0.5
  • idle
    • 쿼리 개수 : 200 millions
    • QPS range : 325k ~ 975k
  • heavy
    • 쿼리개수 : 5 billions
    • QPS range : 8000k ~ 24000k
  • idle workload는 Pmem-RocksDB가 saturate 지점에 도달되는 모습

  

  • heavy workload는 ListDB가 saturate 지점에 도달되는 모습. PMem-RocksDB는 이미 고점보다 훨씬 빡센 parameter가 주어졌기 때문에 flat한 모습이 유지된다.

  

  • 결론 : ListDB가 PMem-RocksDB 보다 훨씬 높은 throughput을 보여준다.
  • Github repository
    • feature
      • benchmark 돌리는 스크립트
      • history_file option을 통해 각 ops별(get, put, seek) report를 작성
      • gnuplot 을 통해 그래프 작성
    • 주의