Minwoo Ahn, Jeonmin Han, Youngjing Kwon, Jinkyu Jeong USENIX OSDI 2024
개요
- 최적화를 하게 되면 병목이 계속 변경되게 된다. COZ Profiling은 병목이 바뀌는 지점을 알려줘서 어떤 부분이 최적화의 대상이 되는지 프로파일링 할 수 있는 시스템을 제공하였다.
- COZ는 코드의 특정 지점을 가상으로 빠르게 만들어서, 병목의 지점을 찾았다. 가상으로 빠를때, 나머지 친구들을 일부로 느리게 만들어서 전반적으로 B가 빨라지는 것처럼 보이도록 하였다. 정확한 프로파일링은 할 수 없지만, 얼추 정확한 프로파일링을 해준다.
Motivation
I/O나 Locking을 하게 되면, Blocking이 일어나게 되는데, COZ는 이러한 경우를 Address하지 못한다. 병목이 어디있을지 못하는 다양한 장비들에서, on-cpu의 bottleneck뿐만 아니라, off-cpu의 bottleneck도 처리할 수 있어야 한다. 이 경우에, on-cpu와 off-cpu중에서 어느부분이 bottleneck인지를 확인해야 한다.
- 프로파일러를 만들면, 프로파일러가 정확하게 동작한다는 것을 보여주어야 한다.
- 점차 병목이 CPU에서 I/O로 옮겨가고 있다.
PERF와 같은 경우에는 IP와 callchain을 sampling하는데, off-cpu구간에서는 정보가 하나도 없기 때문에 아무정보도 제공하지 못한다는 단점이 있다. 즉 이 스레드가 어떤 스레드를 기다리는 지를 확인할 수 없다.
- wperf[OSDI 2018]과 같은 경우에는 threading을 알 수 있지만, COZ의 기능을 제공할 수는 없다.
Design
Blocked되어 있는 구간에도 sampling이 일어날 수 있도록 하였다. Sample주기에 맞추어서, 어떤 것을 기다리고 있는지를 sampling에 넣도록 하였다. Wait하는 시점에 sample를 넣으면 된다. Blocked sample은 Weight으로 포현되는 어느정도 기다리는 지에 대한 정보와, Reason이 들어간다.
유저영역의 정보도 제공하였는데, 이는 블락킹의 정보가 유저레벨의 어떤 시스템콜에서 발생하는지를 제공하기 위해서이다.
Evaluation
RocksDB와 같은 경우에는 Bloom filtering을 통해서 SST table을 관리한다. Libc pread에서 제일 큰 bottleneck을 제공하는데, BCOZ와 같은 경우에는 정확히 어느정도의 impact을 가지는지를 예측하여 알려주었다.
Conclusion
Blocked sampling을 반영할 수 있는 기법들이 wperf나 tracing기법과 같이 있었지만, 본 연구는 Novel한 디자인 아이디어를 통해서 Blocked sampling이라는 효과적인 방식을 통하여, 기존에는 불가능하였던 Off-CPU Analysis가 가능함을 보였다. 단순하지만 창의적인 이 아이디어는 엔지니어링 적으로도, 연구적으로도 좋다는 개인적인 생각이 든다.
질문
- Perf를 frame graph로 만들면, 내부 스택을 알려주는데, 이걸 통해서 똑같이 알 수 있지 않을까?
(( 더 느리다고 합니다. 오버헤드가 크다. off-cpu구간은 tracing을 통해서 call stack을 포함해서 보여준다. 이 부분이 차이점.
- I/O인지 Scheduling인지 어떻게 알수 있을까? DB를 만들어서 처리하는 것인가? DB관리가 힘들지 않을까?