작년 가을에, 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 (…).
1. 어차피 버그는 쉬운것 -> 어려운 것 순서로 해결되기 마련.
2. 결국 악질 버그가 최종보스가 될테고 나중에는 이런 것들 위주로 덤프가 남을 가능성이 높음..
(물론 다른 사소한 이유로 죽기도 하겠지만 최종보스만 남은 상황에선 단순 실수가 대부분..)
재발을 막기 위해 각 케이스에 대한 발생 원인, 증상, 대응방법을 따로 정리하면서
해결이 어려운 것 위주로 남기고 나머지는 지우는 것을 권장하고 싶음.
bkangel / 그게 마일스톤 중간정리? 찍을려고 달리는 중이라 (…) 버그가 잡혀도 딴 버그가 생겨서 서로 다른 산(…)이 생기더라고요.
안정화되고나면 형 말대로 보스들만 남을듯;
근데 지금 상태에선 해결되었다라고 말하기 힘든게 많을듯요; 한 일주일 안생기다 또 오는 애들도 있고 -ㅁ-
참고로 우리팀 오래된 버그는 1년이 넘었고-_- 그 버그 추적하는 사람이 의미있는 덤프를 별도로 관리하고 있음
3월에 마일스톤 찍을 때 쯤엔 이렇게 되었으면 좋겠네요 ㅠㅠㅠㅠ
그나마 다행인 것은 요새 HDD 가격이 조금씩 안정화 되어 가고 있다는 거 (…)
ㅇㅇ; 2 TB가 20만 안쪽인듯. 그거 두 개 사다가 달면 내 후년까진 문제 없을 것 같은데…
우리는 한달 정도 저장하고 기본은 스택 메모리 덤프. 근데 설정 페이지 들어가서 크래쉬 날 때 뭘 더 집어올지 선택할 수 있게 해놓고 새로 들어 오면 그 설정 대로 덤프 떠
냅 저희도 라이브 용으로 준비 중인건 normal | scan-mem | indirect-ref 해서 1 MiB 안쪽이긴 하네요;
근데 저렇게 하려면 WER처럼 2 페이즈로 쪼개서 처리하는건가요?
저희도 하드 디스크 공간 부족 문제도 있고; 풀 메모리 덤프 내용을 바탕으로 찾을 수 있는 버그들은 거진 풀 메모리 덤프가 아니어도 찾을 수 있는 버그들이더라는 경험이 있기도 해서;
오류 났을 때 풀 메모리 덤프도 떠서 전송자 하드디스크에 보관만 해놓고 작은 메모리 덤프만 전송하는 식으로 처리해보고 있습니다. 그렇게 해놓고 디버깅 과정에서 풀 메모리 덤프도 보고 싶다는 경우에는 전송자에게 따로 연락해서 파일명 불러서 메일로 받는; 고전적인 방식으로 처리하고 있네요..
오래된 덤프 파일을 로그 형태로 몽땅 보관하는 것도 검토는 해봤는데 솔직히 필요할까 싶었습니다. 인터넷상의 좋은 글도 이거 나중에 읽어봐야지 하고 북마크해놓고서 읽지 않는 경우가 많은데 덤프 파일은 오죽할까 싶기도 했고 …
잡담으로 끝나는 망글이었습니다.-_-;
원래 만든 목적이 라이브러리 / 서버 디버깅(…)이라서 가끔 죽고 / 피드백 받기 힘든 상황을 생각한거라 개발 중일 때는 (이건 망정보로…) 풀 덤프 남기게 했죠;
그러다 클라이언트 프로그램에까지 적용했더니 이런 시망한 결과가 Orz.
네 오래된 덤프 파일 있어도 안 볼 것 같아요 (…). 그래서 아주 최소한의 로그…도 아닌 DB row 하나씩만 남기려고요 ;ㅁ;