jaso extends j2ee

요즘 몇주동안 neptune의 확장성 테스트를 수행하고 있습니다. 주로 neptune의 TabletServer 4대로 15 ~ 20개의 클라이언트가 동시에 random write를 수행하는 테스트입니다.
테스트를 통해 얻고자 하는 것은 neptune에 Tablet 갯수가 많아지고 관리하는 테이터가 계속 증가할 경우에도 꾸준한 성능을 보장하는지 여부에 대한 테스트입니다.
이 테스트를 처음 수행했을 때에는 시간이 지나면서(약 1 ~ 2시간 정도) write 성능이 점점 느려져서 심지어는 처음보다 3배 이상 느려지는 경우도 있었습니다.
다양한 튜닝이 시도 되었습니다. lock을 최소화하고 file i/o를 줄이기 위해 major compaction, split 등을 스케쥴링 했습니다. 점점 좋아지는 모습이 보였습니다.
다음으로 작업을 수행한 부분이 파일 시스템의 교체였습니다. 코드 상에서는 많은 부분이 튜닝되어 이제는 3 ~ 4시간 정도 지난 다음에야 느려지기 시작했습니다. 의심이 가는 부분이 change log 저장 시간이 파일이 많아 질수록 오래 걸렸습니다. 이 문제는 change log 파일이 많아지고 동시에 파일 쓰기가 수행되고 파일의 추가, 삭제가 발생할 때 더욱 느려졌습니다. 일단 파일시스템의 inode 정보에 lock이 걸리지 않나 의심을 했습니다. 과감하게 파일시스템 교체 결심... ext3 -> xfs로 파일 시스템을 변경했습니다.
교체 결과는 일단 성공적이었습니다.
마지막 남은 부분은 TabletServer에서 ChangeLogServer로 파일 append를 요청하고 처리결과는 ACK 받는 부분에서 가끔 5 ~ 10초 지연 상황이 발생하였습니다. 많은 추론을 해본 결과 일단은 socket의 read() 호출시 소켓 버퍼에 읽을 값이 없으면 해당 쓰레드가 wait 모드로 간 다음 다른 부하로 인해 해당 쓰레드가 늦게 깨어날 가능성에 촛점을 맞추었습니다. 또 다시 고민을 한 결과 오늘 점심 먹으면서 혹시 GC 때문이지 않을까 하는 의견이 나왔습니다. 일반적인 상황에서 GC가 수행되면 모든 쓰레드는 블락되기 때문이죠... 그래서 GC 수행을 Concurrent mode로 바꾸고 몇가지 옵션을 수정하였습니다. 결과는 대만족이었습니다. 모든 상황이 다 해결되었습니다. ㅋㅋㅋ
이제 데이터량이 증가하여도 처음의 속도를 그대로 유지하고 있습니다. 좀 더 테스트를 수행해봐야 겠지만 Bigtable의 논문에 있는 TPS 기준으로 하면 2000 ~ 2500 TPS 정도는 나올 것 같습니다. ㅋㅋㅋ

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준