일상2009/06/02 14:44
우리나라는 경제 위기가 닥치면 제일 먼저 환율이 요동치게 됩니다.
경제구조가 수출 중심의 경제 구조이여 분단 국가라는 특수한 전쟁상황에 놓여있기 때문입니다.
그러므로 외환보유고의 확보가 중요합니다.

1999년 IMF 위기
- 외부에서 온 외환 위기가 아니었습니다. 그 당시 일본경제, 중국경제는 매우 탄탄했습니다.
- 국내기업들이 과도한 설비투자와 사업확장으로 인해 많은 외국에 빚을 지고 나라에서 많은 국채를 발행했습니다.
- but, 만기일에 빚을 갚을 능력이 되지 않았습니다.
- 보통 빚을 갚을 능력이 되지 않으면 디폴트(파산!) 또는 모라토리움(되는대로 천천히 갚을께!)를 선포할 수 있습니다.
- 러시아 국영 기업은 디폴트를 선언, 아르헨티나는 모라토리움을 선언했었습니다.
- but, 우리나라는 내수경제 기반이 매우 취약하고 자원도 없으므로 다른 나라와의 교역이 꼭 필요하므로 디폴트와
  모라토리움을 선언할 수 없습니다.
- IMF는 미국의 입김이 크게 작용합니다. IMF 국제통화기금의 15 퍼센트 이상이 미국의 돈이기 때문에 미국만이
   IMF 기금에 대해 거부권을 행사할 수 있습니다.
- 99년 IMF 사건은 내부적인 재벌 위기(기업의 부채비율 높음)로 인해 기업을 파산시키던지 구조조정에 필요한 
   공적자금(국민세금)으로 기업을 살리게 되었습니다. (부채 비율이 높으면 금리 인상에 완전 박살납니다.)
- 대량 실직상태로 인해 자영업자의 수가 크게 늘었습니다. (치킨집, 찜닭집, 바베큐집 ...)
- 부자들은 달러와 금을 사들이고 서민들은 금모으기 운동으로 금을 내다 팔게 됩니다.

2009년 위기
-  현재 국가의 외환보유고는 여유가 있습니다.
- 기업의 부채비율이 100% 이내로 낮은 상황입니다.
- 수출경제 위주의 우리나라 뿐만 아니라 전세계를 비롯한 중국, 일본, 대만 등도 현 상황을 어려워 하고 있습니다.
- 미국서브프라임모기지론 사태로 인해 소비의 나라인 미국이 가계의 완전박살을 일으킵니다.
- 어쩔수 없이 미국 서민들의 가계들은 절약하게 됩니다.
- 유럽, 일본, 한국, 중국 등 미국에 제품을 많이 수출하는 나라들이 크게 타격을 입습니다.
- 현재 우리나라는 부동산 구매로 인해 가계 부채 비율이 매우 높습니다.
- 가계 부채로 인한 소비 위축으로 인해 인해 점차 자영업자의 수가 감소하고 있습니다.
- 금리인상 또는 부동산 가격 폭락이 이어지면 가계가 박살나게 됩니다.
- 그래서 정부에선 쉽게 금리인상과 부동산 가격을 폭락시키지 못합니다.
- 제가 생각하기에 현재의 상황은 공급과잉/소비위축 상황이라고 생각합니다.
- 그런데 물가와 공공요금은 쭉쭉 잘 오르네요. 왜죠?

* the paradox of savings : 사람들이 합리적으로 절약하고 저축할수록 소비 위축으로 인해 전체 경제 나빠짐.

그럼 전 어떻게 해야 하죠 ???
또 2019년 경제 위기가 또 오기전에 뭘 준비해놔야 하죠 ???
영화 황산벌의 대사가 생각나네요.
"강한기 살아남는기 아니라, 살아남는기 강한기야!!!" 맞나?
Posted by ryujeen
Computer Science2009/04/30 17:19
TCP 통신에서 세션을 종료하는 메커니즘을 보면 (FIN-ACK, FIN->ACK) 과정을 수행하게 됩니다.
여기서 먼저 소켓을 종료하게 되는 호스트에서 아래 그림과 같이 TIME_WAIT 상태가 됩니다.


만약 서버에서 FIN을 전송하기 이전의 패킷이 delay로 인해 클라이언트로 FIN 보다 늦게 도착할 수 있기 때문에
timeout 시간 동안 TIME_WAIT 상태가 된다. 정상적인 세션 종료로 보이지만 이로 인해 시스템에 문제를
안겨줄 수 있다. 수 많은 소켓 세션들이 TIME_WAIT 상태가 되면 더 이상 새로운 연결을 하지 못하는
문제가 생긴다.

이러한 문제를 피하기 위한 방법들이 있다.
1. 통신 종료 프로토콜을 서버쪽에서 먼저 종료하지 않도록 한다.
: TIME_WAIT 상태가 수 많은 세션을 처리하는 서버쪽에 생기는 것을 지양한다.

2. 소켓의 LINGER 옵션을 이용한다.
: LINGER 옵션은 close 함수를 호출한 후 상대방에서 정상적으로 세션 종료가
  이루어졌는지를 확인
  - close은 지정한 LINGER 시간 동안 또는 정상 종료(FIN에 대한 ACK를 수신)때까지 block 된다.
  - LINGER 시간으로 timeout 되면 ETIMEOUT 에러 발생
struct linger ling;

        
ling.l_onoff = 1;     /* SO_LINGER 옵션을 적용한다, TRUE/FALSE */

ling.l_linger = 0;    /* 대기시간 (sec) */

setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));  /* 옵션 적용 */

 l_onoff == 0 : 이 경우 l_linger의 영향을 받지 않는다. 소켓의 기본설정으로 소켓버퍼에 남아 있는 모든 데이터를
 보낸다. 이 때 close()는 바로 리턴을 하게 되므로 백그라운드에서 이러한 일이 일어나게 된다.

 l_onoff > 0 이고 l_linger == 0 : close()는 바로 리턴을 하며, 소켓버퍼에 아직 남아있는 데이터는 버려 버린다.
 TCP 연결상태일 경우에는 상대편 호스트에 리셋을 위한 RST 패킷을 보낸다. hard 혹은 abortive 종료라고 부른다.
 
 l_onoff > 0 이고 l_linger > 0 : 버퍼에 남아있는 데이터를 모두 보내는 우아한 연결 종료를 행한다.

 이때 close()에서는 l_linger에 지정된 시간만큼 블럭상태에서 대기한다. 만약 지정된 시간내에 데이터를 모두 
 보낸 후 FIN에 대한 ACK를 받으면 리턴이 되고, 시간이 초과되었다면 에러와 함께 리턴

3. shutdown 함수 이용
: 기본적으로 close 함수는 socket descriptor를 파괴시킨다. 그러나 shutdown 함수는 TCP 세션 종료를 상대에게 알린다.
  또한 소켓 stream의 READ/WRITE 각각에 대해 종료를 명시할 수 있다. 예를 들어 READ에 대해 shutdown 시키면
  더 이상 recv 소켓 버퍼에서 READ 하지 않겠다라는 것을 명시하고 SEND에 대해 shutdown 시키면 send 소켓 버퍼에
  있는 데이터를 모두 보내고 더 이상 send 하지 않겠다라는 것을 명시한다.

* 우아하게 소켓 닫는 법
1) 소켓의 SEND 스트리밍에 대해서 shutdown 함수 호출
2) recv 함수를 통해 0을 리턴함을 확인 (상대방으로부터 FIN을 받았을 때)
3) close 함수를 통해 소켓 close

Posted by ryujeen
Computer Science2009/04/10 11:42

성능 문제로 inline 함수를 사용하였지만 그다지 효과를 보지 못하였습니다.
도대체 inline 함수가 적용되는 건지 확인해보니... 제가 짠 inline 함수안에
for loop 코드가 있어서 적용되지 않더군요.
또 까먹지 않게 적어 놓습니다.

* inline 함수의 제약조건

- inline 함수 내에서는 루프문(do whie, while, for), switch, goto문을 사용할 수 없다.
- inline 함수호출시 호출되기 전에 먼저 inline 함수가 정의되어 있어야 한다.
- inline 함수 내에서 재귀호출을 할수 없다.
- inline 함수는 한 수식 내에서 두 번이상 호출될수 없다.
- 함수 포인터로 inline 함수의 주소를 취할 수 없다.
- inline 함수는 호출방식이 아니라 치환전개방식이기 때문이다.


Posted by ryujeen
Computer Science2009/04/09 18:01
가끔 검색에 관련된 라이브러리를 구현하다 보면 성능에 민감한 부분이 발생한다.

도대체 코드의 어떤 부분(함수에서) 부하를 많이 주게 되는지 검사해볼 필요성을 느끼게 된다.

그럴 경우 리눅스에서는 gprof 유틸리티가 있다.

1) 소스 파일을 컴파일 할 때, 오브젝트 파일을 링크할때도 -pg 옵션을 주어야 한다.
CC          = gcc
CXX         = g++
RM          = rm -f
 
INC_PATH    = -I ../inc -I /usr/include/mysql
LIB_PATH    = -L /usr/lib64/mysql
LIBS        = -lmysqlclient
DEFS        = -D _DEBUG_MODE_
 
CFLAGS      = -pg -fPIC -ggdb $(DEFS) $(INC_PATH)
CXXFLAGS    = $(CFLAGS)
LDFLAGS     = $(LIB_PATH) $(LIBS)
 
.cpp.o:
    $(CXX) -c $(CXXFLAGS) -o $@ $<
.c.o:
    $(CC) -c $(CFLAGS) -o $@ $<
 
OBJS        = ip6_lookup.o db_query.o ip6_client.o ip6_server.o sample.o
EXES        = sample
 
all :: $(EXES)
 
$(EXES) :: $(OBJS)
    $(CXX) -pg -o $@ $^ $(LDFLAGS)
 
clean   ::
    $(RM) $(EXES) *.o core.o

2) -pg 옵션과 함께 컴파일된 바이너리(실행파일)을 실행한다.
   자동으로 gmon.out 파일이 생성된다.
# ./sample

3) profiling 결과를 얻는다.
 # gprof sample gmon.out > profile.txt

4) profiling 결과를 보면 소스에서 어떤 함수에서 가장 시간을 많이 소비하는지 얼마나 많은 수의 호출이 일어나는지
    확인할 수 있다.
Flat profile:
 
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ns/call  ns/call  name
 57.14      0.20     0.20  3700006    54.05    54.05  mbt_keymatch
 28.57      0.30     0.10   800003   125.00   387.51  mbt_match
  5.71      0.32     0.02   800000    25.00   412.51  IP6Client::find_client(in6_addr)
  5.71      0.34     0.02                             main
  2.86      0.35     0.01   900003    11.11    11.11  get_idx
  0.00      0.35     0.00   900447     0.00     0.00  get_postfix_bits
  0.00      0.35     0.00   800447     0.00     0.00  mbt_hash_id
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 중략 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 성능 10배 이상 더 나오게 고쳐봅시다. T.T ~ 된장~
Posted by ryujeen
일상2009/03/13 10:15
드디어 전문연구요원 기간이 끝났군요.

이런 날이 올 줄이야... 에헤야 디야~ 두려움이 하나 사라졌다.

주특기 1713 = 전산기운용

아침에 문자는 안오네요. 그냥 병무청 홈페이지 가서 확인했습니다.

드디어 민간인!

이제 쉬고 싶군요 ^^


Posted by ryujeen