Closed sss654654 closed 2 years ago
min-guk
commented
2 years ago AC-key 라는 논문을 살펴보니, 100GB DB에서 Cache Size를 1MB, 10MB, 100MB, 1GB, 10GB 조절을 했네요.
지금 실험을 살펴보면, 1GB DB에서 Cache Size를 4MB, 8MB, ... 이렇게 사이즈를 조절을 했구요. 우선 1GB DB는 시스템 메모리 사이즈보다 DB가 작기 때문에, Application layer에서의 Cache로 인한 영향을 확인하기가 어려운 것 같네요. 그리고 Cache Size을 생각보다 극단적으로 키워야지 눈에 띄는 차이가 나는 것으로 보이네요.
FillRandom으로 DB를 크게 20GB~30GB Load한 다음, Read Random/Hot을 대상으로 Cache 사이즈를 1MB, 10MB, 100MB, 1GB 이렇게 조절해보세요.
min-guk
commented
2 years ago min-guk
commented
2 years ago 마지막으로 이 팀 뿐만 아니라 다른 팀들도 모른다고 해서, 막연하게 조언을 구하지는 않았으면 좋겠습니다. 왜 자신이 예상한 결과와 다른지, 운영체제 책을 보고, 구글링을 하고, 논문을 뒤지고, 코드를 뒤져봤으면 좋겠습니다.
단순히 "잘 모르겠습니다"가 아니라, 틀리더라도 "이러한 원인으로 인한 것 같은데, 제 생각이 맞을까요?"가 생각하는 힘을 기르는 태도이자 더 성장할 수 있는 태도이지 않을까 생각됩니다.
질문을 받는 입장에서도 고민한 흔적이 보이면, 더 알려주고 싶은 마음이 클 것 같아요.
min-guk
commented
2 years ago 아 그리고 해당 논문은 KV store에서 가장 유명한 Cache 관련 논문이니, Cache팀은 해당 논문의 Introduction과 Background만이라도 읽어보면 아주 큰 도움이 될 것 같습니다.
sss654654
commented
2 years ago 넵 알겠습니다!! cache_size가 너무 커질경우 workload를 고려하여 제가 설정한 db보다는 cache_size를 적게 해야된다는 고정관념에 사로잡혀서 여러모로 알아보지 않고 조금씩 변화하는 cache_size에 대하여만 실험을 돌렸고 결과가 나오지 않아 질문을 올리게 된 것 같습니다! 해당 논문과 다른 cache구조에 대하여 구글링을 통해 좀더 자세히 살펴본 뒤 다음 질문을 드릴 때는 더 완벽히 준비한 뒤 드리도록 하겠습니다. 죄송합니다.
min-guk
commented
2 years ago 죄송할 질문은 아니에요. 제가 너무 말을 강하게 한 것 같아 미안하네요.
학생들이 결과 그 자체 보다, 결과 뒤의 그 원인에 대해서 주체적으로 고민하고 공부하고 생각해봤으면 하는 아쉬움에 한 이야기였습니다.
그러한 생각하는 힘을 이번 스터디에서 배워갔으면 하는 바램이었는데, 제가 좀 정도가 심했던 것 같네요.
괜히 앞으로 학생들의 질문을 위축 시킬, 잘못된 답변과 피드백이었네요.
앞으로도 질문 많이 해주세요! 미안해요 ㅠㅠ
4주차 벤치마크 실험에서 캐시사이즈를 늘려가며 read할 때의 latency를 측정하였으나 캐시사이즈가 커질수록 latency가 일정한 우하향 곡선을 그리지 않았습니다. 이때문에 조교님께 질문하여 shell_script에 관한 option에 대하여 shell_script를 사용하여 한번에 실험을 돌리란 조언을 받은 후 4주차 이후로부터 shell script를 사용하여 여러 실험을 돌려보았습니다.
환경설정 LevelDB: version 1.23 Date: Sat Aug 6 08:00:13 2022 CPU: 40 * Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz CPUCache: 14080 KB Keys: 16 bytes each Values: 100 bytes each (50 bytes after compression) Entries: 10000000 RawSize: 1106.3 MB (estimated) BlockSize: 4096 CacheSize: ['default','4MB','8MB','16MB','32MB','64MB','128MB'] WriteBufferSize: 4194304 MaxFileSize: 2097152 FileSize: 629.4 MB (estimated)
[Load] fillrandom / --use_existing_db=0 readrandom / --use_existing_db=1 [2.854 ,3.014,3.230,3.166,2.865,3.174,3.100] // cache_size가 커질수록 read할때의 latency가 줄어들어야 한다고 생각 [3.167,3.178,2.820,3.249,3.133,2.959,3.170] [3.122,2.938,3.200,3.221,3.254,3.087,3.274] [2.981,3.042,3.146,3.059,3.189,3.198,3.133]
readseq [0.219,0.296,0.322,0.212,0.343,0.253,0.310] [0.338,0.349,0.220,0.251,0.222,0.237,0.242] [0.220,0.251,0.234,0.242,0.228,0.257,0.242]
[Load] fillseq readrandom [2.426 ,2.674,2.353,2.456,2.836,2.837,2.819] [2.810 ,2.796,2.786,2.815,2.845,2.845,2.786] [2.812 ,2.651,2.804,2.835,2.826,2.789,2.487] [2.545,2.802,2.459,2.818,2.730,2.683,2.844]
readseq [0.153,0.152,0.159,0.149,0.148,0.142,0.151] [0.153,0.158,0.147,0.148,0.148,0.159,0.149]
이하 각각의 Load에 대한 readhot, seekrandom 또한 cache_size가 증가하더라도 결과를 보며 우하향 곡선을 보인다고는 할 수 없다고 깨달았습니다
num을 매우 크게 늘려 실험을 한번에 돌린 후 다음 날 결과를 확인하여도 캐시 사이즈에 따른 read latency가 우하향 곡선을 보이지 않았습니다.
이에 벤치마크 실험 마크다운을 작성하기 전 cache에 대한 벤치마크 실험에 관한 조언을 받고자 깃 이슈를 통해 올리게 되었습니다.