태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

회사일 하면서 삽질하거나 느낀거 끄적

Tech 2012.08.10 13:54

요새 <종료되지 않고 계속 실행되며 모종의 일을 하거나, 서비스를 하는 프로세스> 들을 만들고 있다.

초보 프로그래머 디군은 참으로 많은 삽질을 하였는데, 실수를 다시 하지 않기 위해서 몇 가지 끄적여둔다.


1. 커널파라미터와 limits를 확인
/etc/security/limits.conf, /etc/sysctl.conf
특히 nofile 때문에 방법당하는 경우가 많다.

2. 리밋은 리밋일 뿐
  하드리밋이 풀려 있어도 돌고 있는 프로세스 자체에 적용된 값은 다를 수 있다.
  쉘에서 ulimit -a 로 확인했어도 프로세스 실행 계정이 다른 경우 쉘에서 보이는 것과 다른 값으로 뜰 수 있다.
  프로세스 자체적으로 getrlimit 으로 확인하고, setrlimit 으로 필요한 리소스를 확보해야 한다.
  필요한 만큼의 리소스를 얻지 못한다면 경고를 띄우거나 실행을 거부해도 좋아 …
  실행중인 프로세스의 정보는 cat /proc/[PID]/limits 로 볼 수 있다.

3. 타임아웃
  클라이언트에서 접속을 끊었어도 서버에서 callback 걸고 기다리는 중에 모를 수 있다.
실제로 오래 기다리는 경우도 발생하기 때문에 timed_async_read 에 타임아웃 5천초를 주었는데,
다른쪽 엔드포인트에서 접속 끊은걸 5천초동안 모르고 있는 상황이 발생 -> CLOSE_WAIT 가 쌓인다...
idle 대기일 때도 적절히 소켓 너머가 살아있는지 확인해줄 필요가 있다.
그 외에도 어디에서든 IO가 생기는 경우에 타임아웃 없이 기다리는 일은 절대 없도록 한다.

4. 설명 못하면 새는거야
코드에서 new/delete 만 모아놓고 살펴봐도 자명한 메모리 릭이 보이는 경우가 많다.
new/delete 뿐 아니라 모든 경우에 해당하는데, 할당된 자원이 언제 어떻게 해제되는지
빈틈없이 설명할 수 없다면 자원이 새거나 프로그래머의 정신이 새거나 둘 중 하나다. RAII.

5. 민폐 프로세스 방지
본인 코드의 메모리 사용에 대해 100% 확신하더라도, 프로세스 자체적으로 메모리 사용량을 주기적으로 확인해서
문제가 생긴다면 자살을 하거나 로그에 경고를 남기거나 등등 모종의 조치를 취할 필요가 있다.
사용중인 모든 라이브러리들이 메모리 누수가 없다고 자신할 수 있는가?
혼자 메모리 다 처묵처묵해서 머신 통째로 방법하는 일은 피하자.

6. 최적화?
O 올바르게 동작하는 느린 코드를 빠르게 만든다
X 빠르게 동작하지만 문제가 있는 코드를 올바르게 만든다.
글로벌 락을 써도 좋으니까 일단 올바르게 동작하는 코드를 만들어라. 가능하면 이를 검증하는 테스트를 만들어라.
성능이 아무리 중요해도, 제발 바보같은 애를 먼저 만들라고!
근데 성능이 정말 중요한 부분에서 부분에서 스핀락이 느려서 어쩌고 등의 걱정을 한다면 설계부터 다시 고민해봐 임마.
premature optimization is the root of all evil

7. core dump 는 신의 축복

8. 저장소에 대고 수다를 떨어
작업을 하다가 a. 빌드에 성공, b. 테스트 통과, 둘중 한가지라도 되면 작업 브랜치에 바로 커밋해라.
여러 변경이 한번에 묶여서 커밋된 것 보다는 쓸데없이 많은 커밋이 차라리 낫다.

9. 이름 잘 짓자
예를 들어 timestamp 를 ts 로 줄여서 변수명에 붙이고 있는데,
if (ts < client_ts) … 이런게 들어가면 나중에 고생한다. 비교문에 들어가는 변수명들은 가능하면 대등하게 한다.
server_ts vs client_ts 라던가 current_ts vs client_ts 라던가 …

변수 이름을 보고 그 정확한 의미를 자명하게 알 수 없다면 이름을 바꿔라.

생각의 체계에서 "자명한 블럭"이 어느 높이에 있는지는 매우매우 중요하다.

+ 조건을 if 에 바로 넣지 말고 true/false 리턴하는 "좋은 이름의 함수"로 분리하고, 테스트를 열심히 하자.


10. c++ 테스팅 프레임웍은 짜증난다

boost-python 이 컴파일은 느리지만(... 애도) 붙이긴 쉽다. 그냥 boost-python 으로 파이썬 바인딩 하고 파이썬 unittest 로 테스트 만들어도 쓸만하다.


11. 로그 및 콘솔출력

백그라운드 프로세스는 상태 확인이 쉽지 않다. syslog 같은 곳에 적절히 떨궈도 좋다. 다른 로그랑 섞이면 헷갈리니까 local0 같은걸로 파일 분리해서 남겨도 좋다. 여튼 어떻게든 상태 확인할 길이 필요하다. tmux나 screen세션에 띄워두는 경우도 간혹 생기는데 개발 단계에서만 하자. tmux, screen이 segfault를 내면서 세션에 있던 프로세스 모두 다 들고 자폭하는 경우가 꽤 있다. nohup 으로 돌려 놓는 경우에 콘솔 출력이 많다면 nohup.out 이 하드디스크를 모두 다 채우고 문제가 생길 수 있다. ... 몇달을 돌려둬도 로그파일이 하드디스크를 다 채울 일이 없어야 한다. 오래된 애를 어딘가 아카이빙 서버로 보내고 지우거나 ...


'Tech' 카테고리의 다른 글

Amazon glacier ... 를 쓸 뻔 했던 이야기  (0) 2012.08.23
회사일 하면서 삽질하거나 느낀거 끄적  (2) 2012.08.10
D2, array.reverse property has a side-effect. orz  (45) 2011.07.12
Thrift in D  (6) 2011.05.15
fix: ugly gitweb page  (3) 2010.12.12
(1/2) Programming in clojure  (4) 2010.08.08
Trackbacks 0 : Comments 2