모모웹시스템 2차 장애진단 보고서

모모웹시스템 2차 장애진단 보고서
글쓴이: 이원영(javaservice, javaservice@hanmail.net) 2001/10/30 20:44:26 줄수:325

모모웹시스템 2차 장애진단 보고서

1. 개요

지난 IBM RS6000 H80(4-way, 2GB), WebSphere Application Server 3.5.4 기반으로 운영되고
있는 모모 웹시스템에 대한 최근 일련의 장애사항에 대하여, 지난 1,2차 기술지원에
덧붙여 이번 3차 기술지원을 통해 장애의 원인을 분석하고, 보다 안정적인 시스템 운영을
위한 조치 및 권고사항을 기술합니다.

기술지원: 한국IBM 이원영 전문과장, (주)아이켄매니저먼트 김상기
지원일자: 2001.10.24(수) 14:30 - 22:30

2. 장애의 현상

모모 웹시스템은 2달여전 S사의 i제품 기반으로 운영되고 있었으나, 이를 IBM WebSphere
Application Server 3.5.4 로 변경하였으며, 이 과정에서, 응용어플리케이션의 DB연결 및
해제를 위한 일부코딩상의 미비함을 수정함으로써, 특별한 문제가 모두 없어진 듯
하였으나, 2달여간의 운영 및 추가적인 모듈개발/적용이 지속되면서 또다시 다음과 같은
장애현상과 직면하게 되었습니다.

다소 사용자가 몰리는 시점에, 서비스 응답이 느려지거나 전혀 응답을 하지 않는
"Hang현상"이 일어나고, 이러한 현상이 몇십분간 지속되면, WebSphere Application
Server가 이를 장애상황으로 판단 자동으로 Restarting 시키는 현상이 발생하게 되며,
이는 때론 하루에 서너번, 혹은 며칠에 한번씩 발생하였습니다.
이 상황이 발생하게 되면, 일반사용자는 해당 현상이 발생한 몇십분간 서비스를 이용하지
못하게 되었습니다.

3. 장애의 원인

지속적인 모니터링 및 응용어플리케이션 소스 리뷰를 통해 분석한 결과에 의하면,
이러한 현상의 주 원인은 다음과 같습니다.

1) 시스템 메모리 부족

"vmstat"를 통해 메모리 및 CPU사용량을 모니터링 해 보면, 정상적인 시점에서는
CPU 30-40%이고 메모리 부족현상은 전혀 발생하지 않으나, 상기의 특정 현상이 발생하는
시점에는 vmstat 의 "fr", "sr" 값이 지속적으로 틔는 현상이 발생함과 동시에,
CPU사용은 90-100%를 육박하면서 특히 CPU I/O Wait 사용량이 40-60% 까지를 점유하는
현상이 발생하고 있습니다.
현재 IBM RS6000 H80(4-way,2GB)시스템에는 다음과 같은 S/W가 함께 탑재되어 운영되고
있습니다.

- IBM WebSphere Appliction Server 3.5.4
- IBM HTTP Server 1.3.12
- Apache Web Server 1.3.20 + PHP 모듈
- Oracle DataBase 8i(8.1.7) : User DB & WebSphere Repository DB
- My-SQL DataBase Server

H80(4-way,2GB)시스템은 WebSphere Application Server와 2개의 Database(Oracle, My-SQL)
를 같은 머신에서 운영하기에는 일반적인 관점에서 판단하더라도 메모리가 부족한 것으로
추정되며, 모니터링 결과도 동일한 결과를 낳고 있습니다.

"lsps -a" 명령으로 확인한 현재 사용중인 페이징스페이스 사이즈도, 3개의 disk에 분산된
각각 1GB, 즉 3GB disk 중 현재 25%로써 총 768MB 를 사용하고 있는 것으로 나타나며, 이는
추가적으로 최소한 768MB 이상의 Real 메모리를 필요로 함으로 알 수 있습니다.

지난 2차 기술지원의 결과로 Oracle Database 의 SGA(공유메모리)의 사이즈를 줄이라고
권장드렸으나, 이러한 조치는 그다지 큰 효과를 보지는 못하였습니다.

메모리 과다사용현상이 일어나게 되면, file caching 으로 할당되어 있던 Real 메모리
영역이 모두 소진되는 순간부터, Real 메모리공간이 급작스럽게 page-in/out 일 발생하고
되고, 이 과정동안으로 시스템 전체의 성능이 급격하게 저하되게 되고, 특히 Database 의
성능저하로 이어지게 됩니다. 일정한 빈도로 늘 잘 처리되는 "우편번호검색" 조차 Oracle
Database의 성능저하로 인해 응답시간이 느려지고, 결국 들어오는 요청들이 점차
Queuing 되어 동시에 최대로 처리해 줄 수 있는 WebSphere Worker-Thread 의
Maximum 값을 초과하게 되며, 이 시점에 "Hang현상"이 발생하게 됩니다. 만약, 메모리
부족현상이 수분이내에 끝이 나면, 그 상황을 극복하고 Queuing 되어 있는 요청들이
빠져나감으로 인해 다시 정상적으로 돌아오게 되지만, 지속될 경우는 운영자가 명시적인
방법으로 WebSphere Application Server를 restarting 시켜주거나, 혹은 일정시간이
경과하면 자동으로 WebSphere 가 restarting 하게 됩니다.

2) 메모리를 과다하게 사용하는 응용어플리케이션

언급한 장애상황은 시스템 운영중에 단지 1GB 정도되는 파일을 압축(compress)하는
작업만으로도 쉽게 재현이 됩니다.

그러면 과거 장애 시점에 어떤 응용어플리케이션이 메모리를 과다하게 사용하였을까가
초미의 관심사인데, 현재까지의 조사에 의하면 다음과 같은 어플리케이션이 가장 가능성이
높습니다.


- 민원처리 및 기타 게시판 사용시 첨부파일 업로드

첨부파일 업로드를 위한 모듈은 jspSmart사(http://www.jspsmart.com) 의 smartupload
라는 shareware 모듈의 소스를 변형하여 MyUpload 라는 이름으로 사용하고 있는데,
이 모듈은 특정조건에서 CPU 100%를 점유하게 되는 과거버전의 버그와, 특히, 첨부한
파일의 크기만큼을 무조건 메모리에 점유하는 핵심적인 문제점을 안고 있는 모듈입니다.
관련정보:
jspSmartUpload 패키지 사용을 금합니다
http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=servlet&c=r_p&n=995622233

- 우편번호 검색

우편번호검색은 모모 웹시스템 중 일반사용자가 가장 많이 사용하는 업무입니다. 특정
조건문자열을 입력할 경우, 대량의 건수가 조회되는 현상이 발생하는데,
(예: 공백, "_", "가락", "동") 내부적으로 2만건이 넘은 결과가 java.util.Vector라는
객체에 일시적으로 담기게 되고, 이 때, 해당 결과만큼의 메모리가 일시적으로
사용됩니다.

실제로, requestmon 이라는 trace 모듈을 통해 기록된 로그를 분석한 결과에 의하면,
가장 시스템에 오랫동안 점유한 응용어플리케이션은 우편번호 검색관련한 것이 전체의
39% 를 차지하고 있으며, 첫화면이 15%정도를 점유한 것으로 나타납니다. 그 만큼,
우편번호 검색은 핵심적인 튜닝의 대상이 되는 응용프로그램입니다.

NOTE: 건수가 많다고 하여, SQL 쿼리수행시간이 길어지는 것은 아닙니다. rs.next()를
통해 Vector 에 담는 시간이 오래 걸리게 되며, 로그기록에 의하면 10분이 넘는 응답
시간도 있었습니다.

PS: 279 현재실행중인 서비스 모니터링 - requestmon -
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=982131370



4. 조치 및 권장 사항

4.1 메모리 증설

현재의 2GB 메모리는 현재의 시스템을 원활하게 운영하기에는 부족하며, 최소한 1GB의
추가적인 메모리 증설이 필요합니다. 보다 안정적인 서비스를 제공하기 위해서는 2GB의
증설을 통해 전체 4GB로 운영하실 것을 강력히 권장합니다. 혹은, DB서버와 WAS서버를
분리하는 것도 효과적인 방법이 될 수 있습니다.

4.2 jspSmartUpload (MyUpload)모듈 수정

jspSmartUplad모듈의 경우는 파일첨부시 첨부될 파일사이즈만큼의 메모리를 무조건
할당시키는 알고리즘 대신 InputStream으로 부터 일정한 byte 씩 순차적으로 읽어들여
특정 파일에 조금씩 곧바로 기록하는 형식으로 가져감으로써, 대량의 메모리 점유현상이
일어나지 않도록 관련모듈 개발자가 수정주어야 합니다.

4.3 우편번호 검색시 대량 조회 제한

우편번호 검색을 위한 모듈인 ZipProcess.java 의 search() 메소드에서, 다음과 같이
일정한 건수제한을 두어야 합니다.

....
Vector list = new Vector();
while(rs.next()) {
ZipEntity entity = new ZipEntity();
entity.zip1 = rs.getString(1).substring(0,3);
....
list.addElement(entity);
}
return list;

==>

....
int MAX = 100;
Vector list = new Vector();
for(int i=0; rs.next() && i< (MAX+1) ; i++ ) {
ZipEntity entity = new ZipEntity();
entity.zip1 = rs.getString(1).substring(0,3);
....
list.addElement(entity);
}
return list;

위와 같이 변경하고, 해당 결과를 보여주는 최종적인 zip_search.jsp 에서는 Vector
의 건수가 MAX+1 일 경우, "검색결과가 MAX(100) 값을 초과하였습니다" 와 같은
메세지를 뿌려주는 방법을 취하십시요. 또한, zip_search.jsp 의 JavaScript에서
submit 하기전에 검색어에 대한 입력값 check 로직을 강화하십시요.

이보다 더 권장하는 사항은 MAX건수를 초과할 경우, 타 게시판에서의 문서검색시에
적용하였듯, 페이지 개념을 도입하여 페이지 단위로 검색결과를 보여주도록 쿼리문을
수정하세요.


4.4 기타 조치 사항 및 권장사항

아래의 내용은 현재의 장애 상황과 직접적인 관련은 없으나, 보다 안정적인 서비스 및
운영상의 권고사항입니다.

1) WebSphere Appliction Server 3.5.4 e-Fix 49796 적용

WebSphere 표준에러 로그에 "null input" 이라는 에러가 간헐적으로 나타납니다.
이러한 에러가 하나씩 발생할 때마다, 가용한 Worker-Thread 가 하나씩 비활성화
상태로 변하게 됩니다. 현재는 그 건수가 지난 2달여 동안 몇십회 밖에 되지 않는
것으로 봐선, 이것으로 인한 장애는 없었겠으나, e-fix를 적용하는 것이 바람직합니다.
관련문서

NOTE: e-fix PQ49796 은 WebSphere 3.5.4용으로 비공식 e-fix 입니다.
2001.10.24 적용조치 하였음.

2) Database 연동을 위한 DB Connection Pool 기능변경

현재, Oracle JDBC 드라이버가 제공하는 OracleConnectionCacheImpl 을 이용하여
Connection Pool 을 사용하고 있으나, 이를 WebSphere Application Server가 Oracle
DB와 연동할 때 표준으로 사용하고 있는 WebSphere DB Connection Pool 을 이용토록
하십시요.
현재, 서울청/전산소는 이미 변경되어 있으며, 문제없이 잘 동작하는 만큼 타 청도
며칠간을 모니터링을 지켜본 후에 특별한 문제가 발생하지 않는한 변경하실 것을
권장합니다.

관련된 권장 파라메터

WebSphere DB Connection Pool(DataSource: kpostdb)
minimum-pool-size : 10
maximum-pool-size : 70 --> 90
connection-timeout : 3(3초)
idle-timeout : 1800 --> 1200(20분)
orphan-timeout : 1800 --> 1200(20분)

NOTE: 상기 파라메터는 2001.10.24일 이미 적용하였음.


3) AIX TCP/IP no 파라메터 변경

tcp_keepintvl = 150 --> 40 (이미 고쳐져 있음)
rto_length=13 --> 7
rto_limit=7 --> 4
tcp_keepidle=1200(10분) --> 7200(1시간)

NOTE: no 파라메터의 시간에 관련한 수치는 단위가 1/2 초(half of second)입니다.

NOTE: 현재, telnet 접속이 action이 없는 경우 10분만에 끊어지는 이유는 상기의
tcp_keepidle 값이 10분으로 마추어져 있기 때문입니다.
특히, 이 수치는 DB Connection Pool 의 유휴제한시간과 밀접한 관계가
있습니다. DB Pool 에서 사용되지 않은채 10분이 지날 경우, 해당 연결은
TCP/IP 레벨에서 자동으로 끊어지게 되고, 이는 응용어플리케이션의
SQLException 을 야기하는 원인이 됩니다. 실제 로그파일을 보면 "접속종료"
라는 SQLException 을 종종 만나고 있습니다.


PS: 확인방법 : no -a
변경방법 : no -o rto_length=7
no -o rto_limit=4
no -o tcp_keepidle=7200
no -o tcp_keepintvl=40

NOTE: 상기의 파라메터는 명령을 수행한 시점에 곧바로 적용되나, 다음번 시스템이
rebooting 될 경우 다시 초기화가 일어 납니다. 따라서, /etc/rc.net 파일의
끝에 다음 라인을 추가해 줌으로써, rebooting 시에도 적용되도록 해야 합니다.

[/etc/rc.net]
-----------------------------------------------------------
.......

if [ -f /usr/sbin/no ] ; then
/usr/sbin/no -o extendednetstats=0 >>/dev/null 2>&1

# Added By Foo Bar, 2001.10.24
/usr/sbin/no -o tcp_keepidle=7200 >>/dev/null 2>&1
/usr/sbin/no -o tcp_keepintvl=40 >>/dev/null 2>&1
/usr/sbin/no -o rto_length=7 >>/dev/null 2>&1
/usr/sbin/no -o rto_limit=4 >>/dev/null 2>&1

fi
-----------------------------------------------------------



4) 각종 로그파일을 날짜별로 관리

Apache 웹로그파일을 시스템 오픈이후 지금까지 그대로 사용해 온 관계로 현재 이
파일의 사이즈가 2GB에 도달하여 지난 9월 4일 이후 전혀 로그를 남기지 못하고
있었습니다. AIX 시스템의 default 설정에서는 파일사이즈가 2GB를 넘지 못합니다.
따라서, 이 로그파일들을 날짜별로 관리하도록 변경하십시요.

웹서버로그 : /iws_log/apache/access_log
/iws_log/apache/error_log
/iws_log/apache/access_www_log
/iws_log/apache/error_www_log

WebSphere 로그파일
/iws_log/websphere/stdout.txt
/iws_log/websphere/stderr.txt

로그를 날짜별로 매일 밤 23:50분에 자동으로 백업하는 작업을 위해, UNIX의 cron
기능을 이용하였으며, 다음과 같이 등록되어 있습니다.

# crontab -e
....
50 23 * * * /log/shell/logback.sh #Daily apache & websphere logfile backup

/log/shell/logback.sh 는 다음과 유사한 형식으로 작성되어 있습니다.

----------------------------------------------------------
#!/bin/sh
date=20011031
cp /iws_log/apache/access_log /iws_log/apache/access_log. 2>&1 >/dev/null
cp /dev/null > /iws_log/apache/access_log 2>&1 >/dev/null
.....
----------------------------------------------------------

NOTE: 해당 로그파일은 현재 자동으로 압축시키지 않으므로 그날그날 필요시 수작업으로
압축하여 보관토록 하십시요. 이 로그파일은 각종 장애의 원인분석 및 DOS해킹시도분석,
동시사용자 및 일일Hit량 분석등에 매우 유용하게 사용되어 집니다.



5) 지속적인 모니터링 방법

아래의 5개의 요소는 늘 모니터링 하시고, 각종 장애 및 현상을 예의주시하시기
바랍니다.

1) vmstat 3
2) tail -f /log/shell/ose/ose_yyyyMMdd.log
3) tail -f /iws_log/websphere/trace.log
4) topas
5) http://www.xxxxx.kr/tuning/requestmon.jsp


5. 기타

추가적인 기술지원은 아래의 담당자를 통해 지속적인 IBM 기술지원을 받도록 하십시요.

IBM Websphere 영업기술지원 팀장 박석홍차장 seokhong@kr.ibm.com, 011-898-7904
IBM ITS 팀장 조만성차장 manseong@kr.ibm.com, 011-898-7083


PS: 모모웹시스템 1차 장애진단보고서
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=999512880

WonYoung Lee. Advisory IT Specialist,
WebSphere/AD Technical Sales Support, IBM Korea.
E-mail: lwy@kr.ibm.com
Phone: 011-898-7904
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
자바서비스넷 이원영