Yonghwan's Blog

맨날 리눅스 리눅스 하면서도, 참 아는 게 없다. 어쩌면 Technician 수준. I/O가 마구 치솟는데, 누가 그러는지를 모른다. iotop을 떠올리는데도 한참 시간이 걸렸다. 체득되어있지 않은 게지. iotop을 쓰려고 보니 설치되어 있지 않았다. 준비되어 있지 않은 것이고, ㅎㅎ 시간을 꼭 내서 Admin's Tool을 만들어둬야...

암튼, 다음과 같은 방법으로 대충 바쁜 놈을 잡을 수는 있다. 그런데 정량적으로 뽑기는 거의 불가능한 듯.

[root@skcc-omspap2 ~]# sysctl -w vm.block_dump=1; sleep 3; sysctl -w vm.block_dump=0
[root@skcc-omspap2 ~]# dmesg | more

암튼, 좀 부끄러운...

매번 볼 때 마다 까먹으니깐 일단 기록.

한참 옛날 이야기지만, 어떤 여성 포털에 당시 일하던 회사에서 서버를 납품한 적이 있었다. LVS로 엮은 웹서버가 한 다섯 대 정도 있었고, DB서버가 8way 였던가? 한 대 들어갔다. 웹 개발 회사에서 납품한 PHP기반의 웹서비스가 돌아가기 위한 환경이었는데, 웹서버는 놀고 있는데 DB 서버의 Load가 50까지 차 올라갔다. (물론, 사이트가 꽤 떴었고, 사용자의 폭발적 증가가 근원적 문제였다. 문제 아닌가? 암튼,)

결국, 여기 저기 파해쳐본 결과, 일단 PHP로 개발된 웹 Application이 수준 이하였던 것이 가장 큰 이유였고, (세션 관리의 부재, 과다한 DB Query 발생 등등) 그 다음은 사용하는 SQL문이 Bind Variable을 사용하지 않는 RAW Statement(어떤 전문 용어가 있는지는 모르겠다.)였다는 것.

일단, PHP의 세션 기능을 이용하도록 Application을 수정하고, DBMS 연동을 위한 shared code를 만들어 사용하게 했고, SQL문을 Bind Variable을 사용하도록 수정했다.

말할 것도 없지만, 결과는 엄청난 Load 감소.

이 과정에서 문제는... DBA들은 문제가 해결되기 전까지 그냥... 시종 일관, DB에는 문제가 없다는 말만 반복했다는 아픈 기억. 그렇지... SQL 문법 오류도 없고 그냥 부하가 많았던 거였지... ㅎ

세월도 흐르고, 장소도 다르지만, 이 오래된 문제는 지금도 있는 듯. 역시, 일단 서버 성능 문제가 부각되겠지만... 암튼, 용어를 기억해두려고.

• bind variable, PreparedStatement
  
• 임시 방편으로, init{SID}.ora 파일에서 CURSOR_SHARING=FORCE 설정
  
• DSS나 QUERY REWRITE를 사용할 때에는 사용하지 말라고 함.

prompt
prompt * SQL문 parsing time 구하기
prompt
SELECT NAME, 
 VALUE 
FROM V$SYSSTAT
WHERE NAME = 'parse time cpu'
or NAME = 'parse time elapsed'
or NAME like 'parse count%';

뭐 일단, 여기까지.