웹 서버 포퍼먼스 튜닝 [3] – 아파치 설정
4. 아파치 웹 서버의 성능 개선안
실제 유닉스 환경에서 가장 많이 사용되고 있는 웹 서버가 아파치 웹 서버인데, 이제 마지막으로 아파치 웹 서버에서의 성능을 개선하기 위한 방안을 한번 알아보자.
가. httpd.conf , srm.conf , access.conf 파일의 최적화 수정
예전에는 httpd.conf, srm.conf, access.conf 파일로 나누어져 있었지만 요즘의 아파치 웹 서버는 모든 config 관련 내용이 httpd.conf에 들어가 있다.
a. ServerType : StandAlone
이것은 이용자 접속 요청시 웹 서버의 Child Processor의 생성에 있어서 기존 Spare Child Processor를 복사(Fork)하여 빠르게 대쳐할수 있도록 한다. 가령 100명의 이용자가 동시에 웹 서버로 접속할 경우 그때마다 config 파일을 참고로 하여 새로운 Child Processor가 만들어지는 inetd 방식보다 기존의 여유 Child processor를 fork 하여 대응하는 것이 훨씬 빠르고 효율적이다.
b. HostNameLookup off
이것은 접속자의 IP 주소에 대한 Reverse Lookup 을 방지한다. 대부분의 이용자들은 자신의 IP 주소에 대한 호스트, 도메인 이름이 없다.
그러므로 만일HostNameLookup on 을 하여 웹서버가 매번 접속 요청자에 대한 네임 서버 검색 후 로그 파일을 작성하도록 하면 그 만큼 접속 시간과 부하량이 증가하게 된다.
c. Rotate log를 사용한다.
이용자가 접속할때마다 기록되는 access_log의 경우 한번 접속당 약 85Byte가 증가하여 하루 100만번의 접속으로 access_log 파일은 무려 약 405MByte가 증가한다. 이렇게 되면 접속때마다 log file을 access 하는데 상당한 시간과 부하가 발생된다. 그러므로 로그 파일을 일정 시간마다 초기화 함으로서 언제나 경량화 시켜줄 필요가 있는데, 이것은 httpd/support 디렉토리 존재하는 rotatelogs라는 유틸리티를 쓰면 해결할 수 있다. 레드햇 리눅스 5.2 이상의 경우 syslog을 이용하여 log 파일을 관리하고 있다.
[ 형 식 : rotatelog logfilename time ]
httpd.conf의 TransferLog logs/access_log를 아래와 같이 수정
TransferLog “|/usr/loca/etc/httpd/support/rotatelogs
/usr/local/etc/httpd/logs/access_log 86400”
## 86,400초 (24시간)마다 access_log을 갱신한다는 뜻
참고 : error log 역시 위와같은 방법으로 수정 가능
d. ServerAlias를 이용한다.
가상 호스팅 추가시 ServerName www.domain.com 외에
ServerAlias *.domain.com domain.com
를 아래에 추가하여 Alias 도메인의 가상 호스팅을 위해 불필요한
<virtualhost..>
필드의 추가를 생략할 수 있다.
e. Error_log파일을 통합한다.
가상 호스팅의 경우 가급적 error_log 파일들은 하나의 error_log 파일로 지정해 관리한다. (운영체제의 동시 file open수 제한을 피하는 소극적 방법?)
f. KeepAlive on
이것은 접속 요청자에게 웹 서버 프로세스가 웹 페이지들을 전송할 때 내부의 여러
개체(그림파일) 전송까지 새로운 프로세스를 만들지 않고 담당 프로세스가 계속 접속을 유지 할 수 있도록 한다.
g. MaxRequestPerChild 를 증가시킨다.
프로세스가 일정 횟수의 클라이언트 요청을 처리하고 종료되는 추치인
MaxRequestPerChild 30
을 시스템의 안정성에 따라 증가시켜준다. 보통 100 이상을 권한다. 만일 자신의 웹 서버 시스템이 상당히 안정적이라면 아예 1,000을 주기도 한다.
h. StartServer, Min, Max Spare Server 수를 가급적 증가시켜준다.
디폴트는 각각 5, 5, 10정도인데 웹 서버가 standalone 방식을 경우 새로운 접속 요청을 받으면 기존의 spare Child Processor를 Fork 하여 새로운 Child Processor를 만들어 내므로 기본적으로 Spare 프로세스가 많을 수 록 폭주에 빨리 대처할 수 있다. 각각 비례적으로 증가시키는 것이 바람직하다.
예) StartServer 20, Min SpareServer 20, Max SpareServer 40 (4배씩 증가)
i. MaxClient 150
이것은 동시에 떠 있을수 있는 최대 Processor 수를 제한하는 것인데, 이것은 결국 최대 동시 이용자수 제한과 같다. 물론, http 프로토콜의 특성상 접속자체가 비연결성을 가지므로, 150정도가 충분할수 있으나 필요시 더 늘려줄수도 있다. 그러나 OS에서의 기본 제한 수치를 넘어설 수 있으므로, 주의 해야 한다. 가령 nobody가 만들어낼수 있는 최대 프로세스의 개수가 150개로 OS에서 제한하고 있는데 MaxClient를 그 이상으로 조정하면 문제가 생길수 있다.
나. 운영체제(OS)의 각종 제한 설정 확인
앞서 언급한 각 Processor 수치와 가상 호스팅을 위한 동시에 Open되는 Log 파일의 개수를 확장하기 위해서는 해당 웹 서버의 운영체제의 자원에 대한 제한 수치를 확인할 필요가 있다.
ulimit
ulimit은 운영체제의 각종 Limit을 확인하는 명령어로서 아래의 수치를 확인할수 있다.
The Max number of system processess
The Max number of processes per user
The Max number of open files (can have open files)
웹 서버는 보통 nobody라는 이용자 권한을 가진 ChildProcessor에 의해 서비스된다. 가령 레드햇 리눅스의 경우 6.0 버전 이상부터 그 기본 수치가 상당히 증가되었는데, 이전 5.2버전의 경우
ulimit -a 으로 아래의 결과를 보인다.
[root@ns named]# ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 256
virtual memory (kbytes) 2105343
여기서 max user processes가 256 정도인데, 아파치 웹 서버의 conf 파일에서 MaxClient 를 256 이상 설정하면 OS의 기본 설정을 초과하므로 문제가 발생할 수 있다.
OpenFiles 역시 256이므로, access_log, error_log를 각 가상 호스팅 이용자에게 따로 부여할 경우에는 웹 서버의 log 파일의 총 개수가 256보다 아래여야 할것이다. 물론 이용자가 cgi 프로그램을 동시에 실행하여 open되는 file수도 고려해야 한다.
참고로 ulimit는 OS의 기본 설정을 확인하거나 기본 수치에 대해 줄일 때 사용할수 있다. 그러므로 ulimit을 통해 각 분야별 수치를 증가시키는 것은 아무런 효과가 없다.
OS의 기본 제한 수치를 증가시키고자 한다면 리눅스의 경우 별도의 커널 수정과 커널
컴파일이 필요하다. 그러나 레드헷 6.0부터 커널의 각종 설정들이 상당히 증가되어 (예 : openfiles,max user processes 가 1024로 증가)
이젠 굳이 커널을 수정하여 컴파일할 필요가 없다.
– 참고 자료 –
Apache Server Survival Guide [SAMS-Net]
Web Performance Tuning [O’REILLY]
TCP/IP [O’REILLY]
http://www.apache.org Web Site
http://www.linux.org Web Site
다른 프로그램을 웹 서버와 연동하여 사용할때에는 그 프로그램역시 웹
서버의 성능에 맞추어서 튜닝을 해 주어야 합니다.
특히 DB 서버…( 오라클, Mysql 등…)
그럼….조만간에 오라클 튜닝에 대해 올리도록 열심히 공부할께요..^^
