태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'개발'에 해당되는 글 3건

  1. 2012.08.10 회사일 하면서 삽질하거나 느낀거 끄적 (2)
  2. 2009.12.05 안드로메다 #1 (2)
  3. 2007.03.25 개발이란 것은, (2)

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

Tech 2012. 8. 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
  1. etermory 2012.08.10 15:02 Modify/Delete Reply

    확신이 간다면 라이브러리를 의심하라!

    • Favicon of http://blog.dgoon.net dgoon 2012.08.10 16:36 Modify/Delete

      의심이 가도 소스코드에 접근할 수 없는 라이브러리면 낭패임.

Write a comment


안드로메다 #1

Daily life/Hard study 2009. 12. 5. 15:29

체크인: 기분, 기대하는것

D: 기대기대+_+, Activity 가 뭔지 알고시펑
Y: 이런건 처음? 안드로이드 동작 과정을 알고싶다
-----

따로 책을 보기보다는 여기(http://developer.android.com/guide/topics/fundamentals.html) 문서들을 읽으면서 따라가기로 한다. 영어로 되어 있지만 공부도 할겸... 다 사람이 쓴거다, 사람이 읽을 수 있다.

여기부터 두서없는 기록.

안드로이드 어플리케이션은 각 리눅스 프로세스 하나+JVM 을 가지고 그 위에 올라간다. 어플리케이션이라고 해도 그저 프로세스일 뿐이다. 사용자가 느끼는 어플리케이션과는 단위가 약간 다르다. 앞으로는 안드로이드 어플리케이션은 그냥 컴포넌트라고 부르기로 하자. 컴포넌트는 4가지 종류가 있는데,

Activity, Service, Broadcast receiver, Content provider

얘네들이다. Activity는 화면을 가진 페이지 하나-정도의 개념이고, Service는 화면 없이 돌아가는 프로세스이다. 예를 들어 간단한 게임을 만든다고 할 때, 게임 플레이가 진행되는 화면이 하나의 Activity, 열심히 배경음악을 연주하는 보이지 않는 프로세스가 Service. 이렇게 하나의 어플리케이션은 여러개의 컴포넌트로 구성된다.

Broadcast receiver는 시스템 이벤트, notification 등을 받는 녀석. Content provider는 내장 SQLite 에 접근하기 위한 녀석이다. 실제 테스트/연습용 프로그램들에서는 Activity, Service 두개를 자세히 보면서 시작하면 될 듯.

Intent는 컴포넌트들 사이를 오가며 정보를 전달하는 일종의 사자(Messenger) 이다.

사용자가 느끼는 어플리케이션 단위는, 여러개의 Activity가 Stack 으로 구성된 TASK 라고 볼 수 있다. Task 는 4가지 종류가 있는데,

Standard, SingleTop, SingleInstance, SingleTask

이런 아이들이 있다. 별도로 지정하지 않으면 Standard. 각 태스크 타입마다 태스크의 Activity가 들어가고 나오는 동작이 조금씩 다르자. 자세한건 문서 참조.


-----
회고: 좋았던거, 안좋았던거, 다음에 할거

D: 코드를 보면서 문서를 읽어서 좋았다. 와~ 코드를 써가면서 문서를 읽으면 좋을텐데 ... 오늘 읽은걸 다 돌려보셍
Y: 생각보다 영어공부를 많이했다. 우 ~ 클래스 실체를 확인을 못한게 아쉽. Overview를 보고 백그라운드 음악을 돌려보고싶음.

이 장소를 Daum지도에서 확인해보세요.
서울특별시 서초구 서초4동 | 토즈 강남대로점
도움말 Daum 지도
Trackbacks 0 : Comments 2
  1. 지아 2009.12.06 00:47 Modify/Delete Reply

    안드로이드 스터디?
    나도 하고 싶어요.. ㅠ ㅠ
    하지만 현실은.... (털썩)

    • Favicon of http://deisys.net dgoon 2009.12.06 08:42 Modify/Delete

      저도 딸 갖고 싶어효. 하지만 현실은... ㅠㅠ

Write a comment


개발이란 것은,

Tech 2007. 3. 25. 11:13
이런 것이다.

돈을 받고 있으니 나름 프로(실력은 아마추어 ㅡ.ㅡ)의식을 가지고 일하는데... 저런 일들이 나에게도 가끔(자주?) 발생한다. 나뿐만 아니라 경험이 부족한 개발자라면 누구나 한번쯤은 경험하지 않았을까. 패턴에 대한 공부가 너무 극에 치우친 경우, 스크립트 언어를 막 배워서 열광하고 있는 열혈코더, 꿈에 부푼 엔진 개발자 ... 등. 열의 있는 개발자라면 누구나 "멋들어진 시스템" 을 만들고 싶어하고 그 프로세스, 혹은 "그것"의 이름도 그만큼 뽀대나는 것을 원할 것. 하지만 그 뽀대나는 프로세스가 결과물을 죽이는 경우가 있다. 물론, 언제나 그런 것은 아니지만 꽤나 흔히들 빠지는 함정인 것은 확실.

개발(코딩 외의 컴포넌트도 포함해서)은 Goal-driven process 가 되어야 한다. 이걸 잊고 한동안 또 뻘짓하고 있었는데, 올블록에서 우연히 저 글을 찍고 "으악! 또 이러고 있었어" 라며 자괴감에 휩싸였다. ... 역시 코드 만드는 일은 내 일이 아닌것 같다.


'Tech' 카테고리의 다른 글

Ruby On Rails - Scaffold의 함정  (2) 2007.04.18
Javascript - folding  (2) 2007.04.16
책 제본했다! 아자~  (4) 2007.04.07
지름: AgileWebDevelopmentWithRails, PDF Ver  (0) 2007.04.01
Ruby on Rails 공부(?)중  (0) 2007.03.30
개발이란 것은,  (2) 2007.03.25
Trackbacks 0 : Comments 2
  1. Favicon of http://flutia.egloos.com flutia 2007.03.25 14:48 Modify/Delete Reply

    '완벽한 설계란 더 추가할 것이 없을 때가 아니라 더 뺄 것이 없는 상태이다.'라는 말이 있습니다. 물론 언더엔지니어링은 좋지 않지만 과도한 오버엔지니어링 역시 금물이죠. 개인적인 경험으로는 언더엔지니어링 상태에서 좋은(GREEN) 상태로 코드를 개선하는 것은 쉽지만 오버엔지니어링 상태에서 좋은 상태로 가는 것은 상당히 힘들더군요.^^;

    항상 '가장 적합한 '해결책을 찾는 것이 중요하죠.. ^^

    하지만 역시나 개발자의 로망(?)은 뽀대나는 걸 적용해보는 겁니다. -_-)b
    (사실 개발자로서 자기계발을 할 때 가장 중요한 요소가 아닐까 싶군요.)

  2. Favicon of http://blog.daum.net/evered 호갱 2007.03.26 23:26 Modify/Delete Reply

    제가 절대로 이해할 수 없는 분야의 일을 하고 계신가 보군요...
    존경스럽습니다.../--/

Write a comment