트러블 슈팅

트러블 슈팅을 위한 정보 파악 단계

A단계 : 사용자 현상 파악

• 503/500 에러
• 무응답/느린 응답
• 예상과는 다른 어플리케이션 동작 (예) 간헐적 인증 실패)

B단계 : 서버 상태 파악

• 어플리케이션 서버
• 메모리 사용률 (Swap 사용여부 )
• CPU 사용률
• Disk 용량, I/O
• 연계서버 상태 (Database 서버 등)

C단계: 어플리케이션의 정보 파악

• 어플리케이션 로그
• OOM 등 전형적인 Fatal 여러 발생여부
• 자주 발생하는 에러 스택
• WAS의 주요 설정
• 소스
• Stack Dump
• GC로그
• Heap Dump - 서비스 운영중에 덤프를 뜰 수 없음
• 실행경로 프로파일링

자주 만나는 해결 방식

해결유형1: 인프라 요소 설정 변경

어플리케이션의 로직과는 상관없이 공통적인 설정을 변경해서 해결하는 경우

Database 등 외부 Reosurce에서 병목이 있을 때 부적절한 설정 때문에  발생하는 경우가 많음.

사례

• A. 사용자가 몰릴 시 간헐적으로  느린 응답, 500, 503에러
• B. Swapping 영역 사용.
• C. 잦은 GC, OOM, Connection pool의 getConnection()에서 대기

해결책

• ConnectionPool

- DBCP : maxActive (maxTotal), maxWait (maxWaitMills), validation query

• JDBC : Socket timeout 등
• Web Server

- Apache Httpd : maxClients

• Web Application Server

- Tomcat: maxThreads, AJP connector의 backlog 값

• JVM : GC option

해결유형2: 메모리릭 경로 제거

사례

• C. 서버가 동작한지 오래되면 잦은 GC, OOM
• 주로 Cache 로직에서 발생

- 캐쉬 용량의 한도값이 적절한가?

- 모든 서버에 같은 현상이 궁극적으로는 생김.

• Thead 불안정성에 의한 메모리릭

- 일부 서버에만 OOM 발생

해결유형3: 무한 루프 경로 제거

사례

• B. 100%에 가까운 CPU 사용. 특정 서버에서만 발생하는 경우가 많음.
• C. 스택덤프를 뒤져보면 계속 실행 중인 스레드가 있음. 모든 CPU가 100%가 걸리면 덤프조차 못 뜰수 있음.
• 특정 조건이 들어왔을때 혹은 Thread 불안정성 때문에 생기는 무한루프가 많음.

- 부조건 무한루프였으면 개발할때 모를리가 없음.

• 잘못된 정규식에서 발생한 사례도 있음

해결유형4: 접속이 느려지거나 접속이 안 될 때

사례

• 아파치 데몬 개수를 확인, 기본적으로 아파치 웹 서버의 경우 Max Clients가 256으로 설정되어 있음
• 동시에 256개의 데몬이 뜨게 되면 더 이상의 접속을 받아들이지 않고, 기존의 프로세스가 죽을 때까지 대기한 후 접속이 끊기게 되면 그때 접속 가능
• 현재의 상태가 비정상적인 접속인지 여부를 판단

-  netstat -na | grep ES로 ESTABLISHED된 연결 상태를 확인하여 클라이언트 의 IP가 정상적인 연결인지 여부를 확인

- netstat -na|grep ES|awk '{print $5}'|sort로 클라이언트의 IP만 Sort 하여 확인

- 통상적으로 HTTP 1.1 규약에서부터 적용되기 시작 한 KeepAlive 기능을 지정하였을 경우 한 클라이언트 IP에서 동시에 3~5개 정 도의 http 프로세스 생성 가능

해결유형5: 서비스 거부 공격(DoS)이 가해졌을 때

사례

• 동시에 서비스할 수 있는 프로세스의 한계가 있다는 점을 악용한 공격
• 공격지의 IP를 속이기가 매우 어려우므로 netstat으로 확인 후 비정상적인 접속으로 확인 될 경우 해당 IP를 차단.

해결유형6: include를 잘못하여 무한 루프가 돌 경우

사례

• 프로그래밍 과정에서 의 실수로 php 파일에서 같은 php 파일을 include하는 경우
• a.php 파일에서 b.php 파일을 include하고 b.php 파일에서 다시 a.php 파일을 include하는 경우
• 이러한 경우에는 무한 루프가 돌게 되어 결국은 아파치 데몬이 금새 Maxclients에서 지정한 개수가 차버림
• include를 하지 못하도록 차단을 하는 방법

- iptables -A INPUT -p tcp -i lo -s xxx.xxx.xxx.xxx --sport 1024:65535 -j DROP

- 서버 내에서 include 시에는 lo(Lookback Interface)를 통해 sport 가 1024 이후의 High Port를 이용하여 통신한다는 특성을 이용

- ps aux | grep http로 보이는 프로세스에서 ls -la/proc /pid/로 각각의 http 프로세스가 어떤 파일을 참조하고 있는지 일일이 추적

(예:cwd -> /home/user1/public_html/infinite_loop/)

해결유형7: 프로세스가 과도한 메모리를 사용할 경우

사례

• 메모리를 무한정 소모하는 것을 차단하기 위해서는 아파치의 설정 인자 (Directive) 중에서 RLimitMEM을 사용하여 차단
• CPU 점유율을 제한하는 RLimitCPU
• 사용자당 프로세스의 개수를 제한할 수 있는 RLimitNPROC

해결유형8: 아파치 데몬은 떠 있는데, 접속이 되지 않는 경우

사례

• MaxClients에 도달하지도 않았는데, 실제로 접속이 되지 않는 경우라면 웹 서버가 TCP SYN Flooding 공격을 받고 있을 가능성이 있음
• netstat -na | grep SYN으로 확인하여 많은 SYN_RECEIVED 프로세스가 보인다면 이 공격 때문임
• Syncookie 기능활용

참조

http://blog.pages.kr/65

https://d2.naver.com/helloworld/1286587