작년 가을에, Google BreakPad를 써서 크래시 덤프를 보낼 수 있겠다고 썼다. 여하튼 이걸 위해 간단한 웹 서비스를 만들었었다. 팀 내에서 이걸 쓰다가 좀 확장해서 (…) 같은 스튜디오 내의 다른 팀에도 약간 적용했음. 대략
- 매일 매일 얼마나 많은 덤프가 나오는지,
- 가장 많이 발생한 원인 (WinDbg의 버킷 비슷한 것) 은 뭔지,
- 같은 원인으로 죽은 덤프는 어떤지,
- 각각의 덤프 별 콜 스택 플랫폼 정보 (OS 버전, 각 모듈 별 버전) 는 어떤지
가 나오는 페이지를 만들었다. ((실제 페이지 구현은 회사에서 만든 부분이라 여기서 공개하는 건 무리)) 아니 근데 생각지도 못했던 문제를 만났다;
여름에 서버를 설치한 후, 총 3개 팀이 사용하게 했고, 이에 따라 차근차근 크래시 덤프가 쌓여간다. 최근 덤프가 좀 무섭게 쌓여서 (…) 디스크 사용량을 추적해봤더니 대략 이런 결과가; (8월 중순 쯤 서버를 리셋했고, 그 이후의 디스크 사용량)
팀 + 1개 팀 상태에서는 참 완만하게 올라갔는데, 좀 덩치 큰 다른 팀까지 적용했더니 순식간에 하드디스크가 차고 있다; 게다가 기울기가 더 올라가서, 현재 Doomsday는 다음 달 중순까지 당겨진 상태 Orz. 개발 중인 프로그램에 적용한 것이고, 개발 팀만 접근 가능한 위치라 전체 메모리 덤프를 받게 했더니 정말 저장 공간을 왕창 잡아 먹더라; 이건 내 예상 실패라고 밖엔;
HDD 가격 올랐다고 구매 신청해도 안 사줄 기세던데 이를 어찌 해결하는가; 일단 같은 콜 스택 + 같은 모듈 (이름; 버전; 체크 섬) 인 것들 지워서 지난 주 후반에 40 GiB 쯤 확보했는데, 그럼에도 불구하고 (…) 이미 216 GiB 쯤 쓴 상태. 사진은 2주 전 상태임.
저 서버를 설정할 때만 해도, 연말까지 300 GiB 정도는 넉넉하리라 생각했다 ((즉, 한 달에 50 GiB 이상은 안 나오겠지 정도로…)) 하다못해 HDD 하나 추가하는 건 별 큰 일 아니라고 생각했다. 하지만 태국 홍수 덕에 구매 팀에서 HDD 가격 비싸다고 장비도 안 사주는 마당이니, 망한 상황인 듯. 아마 1월부턴 90일 정도만 남기고 – 어차피 개발 중인 프로그램들 용으로 덤프 받는 서버라 버전 정보가 휙휙 올라가는지라; – 다 지워버리던가 해야.
사실 내가 궁금한 건 이거다; 과거의 덤프가 남아있다면 뭐가 좋을까? 그냥 간단한 텍스트 정보 – 크래시 한 상황에 대한 OS 정보, 콜 스택 정도가 있다면 충분할까? 아니면 전체 메모리 덤프가 다 있다면 오~래 가는 버그를 좀 더 쉽게 잡을 수 있을까?
_원래 목적이던 “자주 발생하는 버그를 빨리 잡자”_는 어느 정도 되어가는 것 같은데 – 일주일쯤 피크 치는 버그는 대충 잘 잡히는 듯? – 오래된 버그를 잡는데 도움이 되려면 어느 정도 범위를 가지고 있어야 할지;;;
PS. iPhone 4 렌즈 수차 정말 망이네; 화면 위 아래 수평선의 기울기를 비교해보면 Orz (…).