웹 서버를 위한 솔라리스 튜닝
일반적으로 시스템 튜닝 과정에서 OS 튜닝은 가장 나중에 하는 영역이다. 예를 들어 초기 CERN 웹 서버를 이용하면 OS 파라미터들이 튜닝돼 있다고 해도 최근에 나온 아파치 웹 서버의 1/10에도 미치지 못하는 성능을 낸다. 또한 최근에 나온 웹 엔진들 역시 퍼포먼스를 고려하지 않은 것을 이용하게 되면 마찬가지 결과를 가져온다. 예를 들어 HP-UX에서 OSDK(Oracle Servlet development kit) 웹 엔진을 이용할 때 원하는 퍼포먼스가 나오지 않는다고 제아무리 전문가들을 불러 OS를 최적화한다 해도 앞서 말한 CERN
서버의 경우처럼 성능 개선의 여지는 좁다.
솔라리스8은 이전의 SunOS 4.X나 솔라리스 2.5.1 이전의 버전처럼 이용자가 반드시 튜닝해야 할 파라미터들이 극히 줄었다. 한 마디로 초기 설정이 점차 최적화돼 나오고 있다는 것이다(퍼포먼스 분석가/튜닝 전문가에게는 상당히 아쉬운 일이 아닐 수 없지만). 그와 더불어 하드웨어 드라이버에 있어서도 최신의 드라이버를 사용함으로써 하드웨어적인 성능 개선을 얻을 수 있을 뿐 아니라 솔라리스8에는 SUNWncar, SUNWncarx, SUNWncau라는 Solaris Network and Cache Accelerator가 포함돼 있어 네트워크와 관련해서는 그 이전의 어떤 버전보다 나은 환경을 제공하고 있다.
기존의 솔라리스를 이용하는 환경에서 퍼포먼스를 생각한다면 반드시 최신의 버전을 이용해야 하며, 현재 나온 HP-UX, AIX, 디지털유닉스(OSF1) 등 상용 유닉스 중에서 웹 환경에 있어서는 솔라리스가 그 자체만으로도 가장 나은 성능을 얻을 수 있다.
먼저 가장 중요한 것은 대부분의 사이트가 해당되는 작은 크기의 파일이 중심이 되는 http 환경에서 브라우징 속도는 기본적으로 네트워크 대역폭과는 '별다른' 관련이 없다는 점이다. 이에 대해 실제로 간단한 실험을 한 번 해보자. 아파치만 기본 설치한 두 서버를 가진 환경에서 한 서버는 10Mbps 스위치에, 다른 하나는 100Mbps 스위치에 연결한 후 두 서버의 아파치 초기 화면을 띄워보자. 물론 한 서버에 접속하고 나서 로컬 캐시를 삭제한 후 다른 서버에 접속해야 한다는 점을 잊지 말자. 이 두 가지 경우에서 브라우징 속도에 차이가 있을까?
결과를 살펴보면 거의 느낄 수 없다. 이렇게 작은 사이즈 파일 위주의 환경에서는 서비스 제공자 입장에서 볼 때 자신의 네트워크의 부하가 적고 이용자의 네트워크가 일정 수준 이상의 대역폭을 확보하고 있다면, 이용자들의 브라우징 속도를 빠르게 해주기 위해서는 엄청난 규모의 확장이 아니고서는 큰 대역폭의 회선을 얻는 것은 별도움이 되지 않는다.
솔라리스 네트워크 튜닝
웹 서버 튜닝에는 네트워크 튜닝만이 포함되는 것은 아니다. 모든 시스템 튜닝은 CPU, 메모리, I/O(디스크와 네트워크)가 유기적으로 얽혀 있기 때문에 모든 부분에서 골고루 설명해야 하는데, 지면 관계상 주요 부분만 살펴본다.
하지만 달리 생각하면, 요사이 컴퓨팅 환경에서는 네트워크 튜닝시 네트워크 그 자체의 튜닝 부분을 제외하고는 CPU나 디스크 I/O같은 다른 환경적 요소를 덜 받게 됐다는 점도 간과할 수 없다. CPU의 경우, 예전의 SunOS 4.X 대역에서는 TCP/IP 프로토콜 통신도 커다란 CPU - bound 프로세스였다. 하지만 솔라리스가 날로 발전하고 CPU 성능의 급성장으로 인해 이젠 아무리 바쁜 사이트라도 서버 사이징(Server Sizing)만 잘해놓으면, CPU가 네트워크에 대해 문제를 일으키지 않는다. 참고로 솔라리스 2.5.1까지만 해도 초당 수백 건의 접속만 감당할 수 있었다가 2.6에 이르면서 초당 수천 건의 접속을 감당하게 됐으며, 이 수치는 날로 늘어나고 있다.
또한 메모리 역시 GB 급으로 가고 있고, 웹 컨텐츠 전체를 물리적 메모리나 스왑으로 올릴 정도로 메모리가 커짐에 따라, Disk-bound 프로세스에서도 벗어나게 됐다.
우선 솔라리스에서 네트워크 튜닝은 기본적으로 거의 모든 플랫폼에서 공통적으로 적용할 수 있다는 특징이 있다. 달리 표현하자면, 그만큼 적다는 말이 된다. 앞서 말한 것처럼 솔라리스가 최신판으로 올라갈수록 OS 자체가 점차 최적화돼가고 있기 때문에 몇 가지 고정된 파라미터 값을 제외하고는 손댈 영역이 점점 없어지고 있는 것이다.
LAN 카드 설정, /dev/hme
SPARC 플랫폼에서 솔라리스는 100Mbps 고속 이더넷 인터페이스 카드를 /dev/hme로 정의한다. 그런데 이 인터페이스는 자동으로 10/ 100Mbps를 맞추는 오토센싱(auto-sensing) 기능을 지원하지만 이것이 잘 안 될 때가 종종 있다. 특히 스위치가 풀 듀플렉스를 지원하는데 하프 듀플렉스로 맞춰지는 일이 비일비재한데 이럴 때는 수동으로 설정해줘야만 한다. hme를 100Mbps 풀 듀플렉스로 설정하는 방법은 ndd 커맨드를 이용하는 방법과 /etc/system에 파라미터 값을 넣어주는 두 가지 방법이 있는데, 그중 ndd를 이용하는 방법은 다음과 같다.
# ndd -set /dev/hme adv_autoneg_cap 0 (오토 센싱 기능 off)
# ndd -set /dev/hme adv_100fdx_cap 1 (100Mbps 풀 듀플렉스 기능 on)
# ndd -set /dev/hme adv_100hdx_cap 0
# ndd -set /dev/hme adv_100T4_cap 0
이는 재부팅시에는 설정 값이 지워진다. 이를 방지하기 위해서는 /etc/init.d/inetsvc에 다음과 같은 명령문을 넣어주면 된다.
/usr/sbin/ndd -set /dev/hme adv_100fdx_cap 1
또 다른 방법은 /etc/system에 커널 파라미터 값을 넣어 주는 것인데, /etc/system 끝에 다음과 같은 줄을 넣어주고 재부팅하면 된다.
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_100fdx_cap=1
웹 환경에 맞는 TCP 튜닝 파라미터
먼저 솔라리스에서는 네트워크 드라이버나 TCP 프로토콜의 파라미터 값을 보여주거나 변경할 때 ndd를 사용한다. 영구히 변경할 때는 /etc/init.d/inetsvc에 다음과 같은 형태로 넣어준다.
/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000
또는 /etc/system에 약간 변형된 형태(set ip:ip_forwarding =0)로 파라미터 값을 등록하면 된다. 단 /etc/system에 등록할 때 주의할 점은 이 파일을 편집할 때 잘못된 변수 값이나, 잘못된 형식 등으로 인해 부팅이 되지 않는 경우가 종종 있는데, 이럴 때는 스팍 플랫폼의 경우엔 ok prom 프롬프트에서 'boot -i'으로 인터페이스 부팅을 한 다음 [/etc/system]을 참조하겠느냐는 부분에 /dev/null을 참조한다고 하면 된다.
그리고 TCP 프로토콜도 hme(100Mbps 인터페이스, 스팍 플랫폼)와 마찬가지로 /dev/tcp이다. 먼저 /dev/tcp에서 튜닝이 가능한 파라미터들의 정보를 확인하는 명령은 다음과 같다.
#ndd [-get] /dev/tcp ?
[ ]안의 내용은 솔라리스에서는 언제나 생략할 수 있는 옵션이다. 이 옵션을 치면 tcp 튜닝 파라미터들의 리스트가 출력된다.
tcp_time_wait_interval(솔라리스 2.6 이전까지는 tcp_close_wait_interval이었음) : 메모리에서 TCP 연결이 끊어져도 tcp가 쓰던 소켓 정보를 일정 기간 대기 상태로 가지고 있고, 이를 가지고 있는 시간인데 기본값은 240,000ms(4분)이지만, 이는 tcp 소켓을 많이 요구하는 서버, 즉 웹 서버에서는 너무 길게 waiting하는 것이 메모리 낭비이므로 60,000ms(1분)정도로 줄이는 것이 좋다. 그러나 이를 너무 줄일 경우, 커넥션 품질 자체가 불안할 수 있으므로 더 이상 줄이지 않는 것이 바람직하다.
tcp_conn_req_max_q0 : TCP/IP 프로토콜 통신에서 half-open connection 상태, 즉 마지막 ACK를 받지 못한 상태의 커넥션을 몇 개까지 가지고 있을지에 대한 파라미터 값이다. 기본값은 1024인데 이 파리미터는 뒤에 설명할 tcp_conn_req_max_q와 형태가 비슷하다고 무조건 늘리는 경우가 있는데 불필요하며, 이 파라미터는 completed connection마저도 listen queue에 들어가지 못하는 경우를 제외하고는 변경할 필요가 없다.
tcp_conn_req_max_q : 바로 웹 서버 튜닝에서 가장 많이 사용하는 파라미터이다. 기본값은 128인데, 1024 이하 정도로 늘려주는 것이 바람직하다. 이는 completed connection이 실제 처리되기까지 받아주는 큐 크기로 너무 부족하면 상당히 바쁜 웹 서버의 경우, 사용자의 요청을 놓치는 경우가 발생할 수 있기 때문이다.
tcp_slow_start_initial : TCP 프로토콜 통신에서 처음에 테스트용으로 보내는 초기화 패킷 수를 말한다. 썬의 기본값은 1인데 다른 벤더들(특히 MS)이 2개를 사용하므로 이를 2로 변경해주는 것이 바람직하다. 솔라리스 8의 경우 가끔 4인 사례를 발견할 수 있었다.
네트워크 모니터링
#netstat -s -Ptcp : 이 커맨드를 이용하면 모든 프로토콜의 정보를 출력하는데 -Ptcp라는 옵션을 추가하면 우리가 TCP 프로토콜의 파라미터를 변경하기 전 TCP와 관련한 정보만 출력해준다. 여기서 우리가 주목해 봐야 할 것은 tcpListenDropQ0와 tcpList enDrop인데, tcpListenDropQ0는 accept() system call시 drop된 것의 카운트(갯수)이고 tcpListenDrop(Q)은 three-way handsha ke라고도 불리는 처음 두번째 ACK를 받기 전 incompleted connection이 큐에 들어가지 못한 카운트다.
일반적으로 시스템 튜닝 과정에서 OS 튜닝은 가장 나중에 하는 영역이다. 예를 들어 초기 CERN 웹 서버를 이용하면 OS 파라미터들이 튜닝돼 있다고 해도 최근에 나온 아파치 웹 서버의 1/10에도 미치지 못하는 성능을 낸다. 또한 최근에 나온 웹 엔진들 역시 퍼포먼스를 고려하지 않은 것을 이용하게 되면 마찬가지 결과를 가져온다. 예를 들어 HP-UX에서 OSDK(Oracle Servlet development kit) 웹 엔진을 이용할 때 원하는 퍼포먼스가 나오지 않는다고 제아무리 전문가들을 불러 OS를 최적화한다 해도 앞서 말한 CERN
서버의 경우처럼 성능 개선의 여지는 좁다.
솔라리스8은 이전의 SunOS 4.X나 솔라리스 2.5.1 이전의 버전처럼 이용자가 반드시 튜닝해야 할 파라미터들이 극히 줄었다. 한 마디로 초기 설정이 점차 최적화돼 나오고 있다는 것이다(퍼포먼스 분석가/튜닝 전문가에게는 상당히 아쉬운 일이 아닐 수 없지만). 그와 더불어 하드웨어 드라이버에 있어서도 최신의 드라이버를 사용함으로써 하드웨어적인 성능 개선을 얻을 수 있을 뿐 아니라 솔라리스8에는 SUNWncar, SUNWncarx, SUNWncau라는 Solaris Network and Cache Accelerator가 포함돼 있어 네트워크와 관련해서는 그 이전의 어떤 버전보다 나은 환경을 제공하고 있다.
기존의 솔라리스를 이용하는 환경에서 퍼포먼스를 생각한다면 반드시 최신의 버전을 이용해야 하며, 현재 나온 HP-UX, AIX, 디지털유닉스(OSF1) 등 상용 유닉스 중에서 웹 환경에 있어서는 솔라리스가 그 자체만으로도 가장 나은 성능을 얻을 수 있다.
먼저 가장 중요한 것은 대부분의 사이트가 해당되는 작은 크기의 파일이 중심이 되는 http 환경에서 브라우징 속도는 기본적으로 네트워크 대역폭과는 '별다른' 관련이 없다는 점이다. 이에 대해 실제로 간단한 실험을 한 번 해보자. 아파치만 기본 설치한 두 서버를 가진 환경에서 한 서버는 10Mbps 스위치에, 다른 하나는 100Mbps 스위치에 연결한 후 두 서버의 아파치 초기 화면을 띄워보자. 물론 한 서버에 접속하고 나서 로컬 캐시를 삭제한 후 다른 서버에 접속해야 한다는 점을 잊지 말자. 이 두 가지 경우에서 브라우징 속도에 차이가 있을까?
결과를 살펴보면 거의 느낄 수 없다. 이렇게 작은 사이즈 파일 위주의 환경에서는 서비스 제공자 입장에서 볼 때 자신의 네트워크의 부하가 적고 이용자의 네트워크가 일정 수준 이상의 대역폭을 확보하고 있다면, 이용자들의 브라우징 속도를 빠르게 해주기 위해서는 엄청난 규모의 확장이 아니고서는 큰 대역폭의 회선을 얻는 것은 별도움이 되지 않는다.
솔라리스 네트워크 튜닝
웹 서버 튜닝에는 네트워크 튜닝만이 포함되는 것은 아니다. 모든 시스템 튜닝은 CPU, 메모리, I/O(디스크와 네트워크)가 유기적으로 얽혀 있기 때문에 모든 부분에서 골고루 설명해야 하는데, 지면 관계상 주요 부분만 살펴본다.
하지만 달리 생각하면, 요사이 컴퓨팅 환경에서는 네트워크 튜닝시 네트워크 그 자체의 튜닝 부분을 제외하고는 CPU나 디스크 I/O같은 다른 환경적 요소를 덜 받게 됐다는 점도 간과할 수 없다. CPU의 경우, 예전의 SunOS 4.X 대역에서는 TCP/IP 프로토콜 통신도 커다란 CPU - bound 프로세스였다. 하지만 솔라리스가 날로 발전하고 CPU 성능의 급성장으로 인해 이젠 아무리 바쁜 사이트라도 서버 사이징(Server Sizing)만 잘해놓으면, CPU가 네트워크에 대해 문제를 일으키지 않는다. 참고로 솔라리스 2.5.1까지만 해도 초당 수백 건의 접속만 감당할 수 있었다가 2.6에 이르면서 초당 수천 건의 접속을 감당하게 됐으며, 이 수치는 날로 늘어나고 있다.
또한 메모리 역시 GB 급으로 가고 있고, 웹 컨텐츠 전체를 물리적 메모리나 스왑으로 올릴 정도로 메모리가 커짐에 따라, Disk-bound 프로세스에서도 벗어나게 됐다.
우선 솔라리스에서 네트워크 튜닝은 기본적으로 거의 모든 플랫폼에서 공통적으로 적용할 수 있다는 특징이 있다. 달리 표현하자면, 그만큼 적다는 말이 된다. 앞서 말한 것처럼 솔라리스가 최신판으로 올라갈수록 OS 자체가 점차 최적화돼가고 있기 때문에 몇 가지 고정된 파라미터 값을 제외하고는 손댈 영역이 점점 없어지고 있는 것이다.
LAN 카드 설정, /dev/hme
SPARC 플랫폼에서 솔라리스는 100Mbps 고속 이더넷 인터페이스 카드를 /dev/hme로 정의한다. 그런데 이 인터페이스는 자동으로 10/ 100Mbps를 맞추는 오토센싱(auto-sensing) 기능을 지원하지만 이것이 잘 안 될 때가 종종 있다. 특히 스위치가 풀 듀플렉스를 지원하는데 하프 듀플렉스로 맞춰지는 일이 비일비재한데 이럴 때는 수동으로 설정해줘야만 한다. hme를 100Mbps 풀 듀플렉스로 설정하는 방법은 ndd 커맨드를 이용하는 방법과 /etc/system에 파라미터 값을 넣어주는 두 가지 방법이 있는데, 그중 ndd를 이용하는 방법은 다음과 같다.
# ndd -set /dev/hme adv_autoneg_cap 0 (오토 센싱 기능 off)
# ndd -set /dev/hme adv_100fdx_cap 1 (100Mbps 풀 듀플렉스 기능 on)
# ndd -set /dev/hme adv_100hdx_cap 0
# ndd -set /dev/hme adv_100T4_cap 0
이는 재부팅시에는 설정 값이 지워진다. 이를 방지하기 위해서는 /etc/init.d/inetsvc에 다음과 같은 명령문을 넣어주면 된다.
/usr/sbin/ndd -set /dev/hme adv_100fdx_cap 1
또 다른 방법은 /etc/system에 커널 파라미터 값을 넣어 주는 것인데, /etc/system 끝에 다음과 같은 줄을 넣어주고 재부팅하면 된다.
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100hdx_cap=0
set hme:hme_adv_100fdx_cap=1
웹 환경에 맞는 TCP 튜닝 파라미터
먼저 솔라리스에서는 네트워크 드라이버나 TCP 프로토콜의 파라미터 값을 보여주거나 변경할 때 ndd를 사용한다. 영구히 변경할 때는 /etc/init.d/inetsvc에 다음과 같은 형태로 넣어준다.
/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000
또는 /etc/system에 약간 변형된 형태(set ip:ip_forwarding =0)로 파라미터 값을 등록하면 된다. 단 /etc/system에 등록할 때 주의할 점은 이 파일을 편집할 때 잘못된 변수 값이나, 잘못된 형식 등으로 인해 부팅이 되지 않는 경우가 종종 있는데, 이럴 때는 스팍 플랫폼의 경우엔 ok prom 프롬프트에서 'boot -i'으로 인터페이스 부팅을 한 다음 [/etc/system]을 참조하겠느냐는 부분에 /dev/null을 참조한다고 하면 된다.
그리고 TCP 프로토콜도 hme(100Mbps 인터페이스, 스팍 플랫폼)와 마찬가지로 /dev/tcp이다. 먼저 /dev/tcp에서 튜닝이 가능한 파라미터들의 정보를 확인하는 명령은 다음과 같다.
#ndd [-get] /dev/tcp ?
[ ]안의 내용은 솔라리스에서는 언제나 생략할 수 있는 옵션이다. 이 옵션을 치면 tcp 튜닝 파라미터들의 리스트가 출력된다.
tcp_time_wait_interval(솔라리스 2.6 이전까지는 tcp_close_wait_interval이었음) : 메모리에서 TCP 연결이 끊어져도 tcp가 쓰던 소켓 정보를 일정 기간 대기 상태로 가지고 있고, 이를 가지고 있는 시간인데 기본값은 240,000ms(4분)이지만, 이는 tcp 소켓을 많이 요구하는 서버, 즉 웹 서버에서는 너무 길게 waiting하는 것이 메모리 낭비이므로 60,000ms(1분)정도로 줄이는 것이 좋다. 그러나 이를 너무 줄일 경우, 커넥션 품질 자체가 불안할 수 있으므로 더 이상 줄이지 않는 것이 바람직하다.
tcp_conn_req_max_q0 : TCP/IP 프로토콜 통신에서 half-open connection 상태, 즉 마지막 ACK를 받지 못한 상태의 커넥션을 몇 개까지 가지고 있을지에 대한 파라미터 값이다. 기본값은 1024인데 이 파리미터는 뒤에 설명할 tcp_conn_req_max_q와 형태가 비슷하다고 무조건 늘리는 경우가 있는데 불필요하며, 이 파라미터는 completed connection마저도 listen queue에 들어가지 못하는 경우를 제외하고는 변경할 필요가 없다.
tcp_conn_req_max_q : 바로 웹 서버 튜닝에서 가장 많이 사용하는 파라미터이다. 기본값은 128인데, 1024 이하 정도로 늘려주는 것이 바람직하다. 이는 completed connection이 실제 처리되기까지 받아주는 큐 크기로 너무 부족하면 상당히 바쁜 웹 서버의 경우, 사용자의 요청을 놓치는 경우가 발생할 수 있기 때문이다.
tcp_slow_start_initial : TCP 프로토콜 통신에서 처음에 테스트용으로 보내는 초기화 패킷 수를 말한다. 썬의 기본값은 1인데 다른 벤더들(특히 MS)이 2개를 사용하므로 이를 2로 변경해주는 것이 바람직하다. 솔라리스 8의 경우 가끔 4인 사례를 발견할 수 있었다.
네트워크 모니터링
#netstat -s -Ptcp : 이 커맨드를 이용하면 모든 프로토콜의 정보를 출력하는데 -Ptcp라는 옵션을 추가하면 우리가 TCP 프로토콜의 파라미터를 변경하기 전 TCP와 관련한 정보만 출력해준다. 여기서 우리가 주목해 봐야 할 것은 tcpListenDropQ0와 tcpList enDrop인데, tcpListenDropQ0는 accept() system call시 drop된 것의 카운트(갯수)이고 tcpListenDrop(Q)은 three-way handsha ke라고도 불리는 처음 두번째 ACK를 받기 전 incompleted connection이 큐에 들어가지 못한 카운트다.