리눅스 시스템 튜닝 전략 Ver 0.1 글쓴날 : 2000년 2월 글쓴이 : 문태준 (http://www.taejun.pe.kr, taejun@taejun.pe.kr, taejun@hitel.net) 본 내용은 System performance Tunning 부록 B를 번역 및 편집한 것입니다. 리눅스에 맞게 변경하려고 한 것인데 아직은 베타판입니다. 좀더 수정작업을 해야합니다. 여러분들 의견 주시면 감사하겠습니다. 참고자료 : System Performance Tunning (O'REILLY 출판사, 영문판) 부록B (92년도에 나온 책이지만 시스템 관리측면에서 많은 도움을 주는 책입니다) Essential System Administration (한빛 번역판) 7장 시스템 자원관리 (유닉스 시스템 관리에 관련된 내용을 담고 있습니다. 내용은 괜찮은 편이지만 번역 자체가 깔끔하지는 않습니다) 0. 들어가며 성능에 문제가 생기기전에 시스템을 분석하는것이 정말로 중요하다. 하루중 서로 다른 시간대에 시스템의 load average 가 어느정도 되는지, 대부분의 사용자가 어떤 작업을 하고자하는지? 그리고 시스템의 다른 일반적인 정보에 대해서는 미리 알고 있다고 하고 시작하겠다. 시스템에 문제가 생긴다면 다음을 먼저 점검해보자 ㅇ CPU 로드 측정 ㅇ 메모리 문제 점검 ㅇ 메모리에 문제가 없다면 디스크 I/O 점검 ㅇ 디스크와 메모리에 문제가 없는데도 시스템에 문제가 생기면 CPU의 오버헤드에 문제가 있다. 1. 프로세스 통계 설정(Process Accounting) 먼저 시스템에 프로세스 통계를 설정할 수 있는 프로그램이 설치되어 있어야한다. 필자의 경우 패키지가 포함이 되어있었다. 이에 대해서는 통계 설정에 관련된 내용을 참고한다. 본 필자가 작성한 것이 있으니 그것을 보면 될 것이다. 2. 문제가 생기기전 점검사항 시스템이 정상적으로 작동할때 정기적인 모니터링을 해 두어야 시스템에 문제가 생겼을때 어떻게 해야할지 알 수 있다. ㅇ 주요 사용자들한테 성능이 괜찮다는 동의를 먼저 얻어야한다. 그리고 시스템 성능을 계속 유지할 수 있도록 정기적으로 점검한다. ㅇ 시스템 통계 프로그램을 설치했다면 그것을 사용하자. 시스템에서 CPU, I/O, 메모리 집약적인 다섯개의 프로그램들을 알고 있어야한다. ㅇ vmstat 등의 프로그램을 이용 I/O연산이 얼마나 분산되어있는지, CPU가 작동하지 않고 노는 시간(idle)은 얼마인지, 정상적인 부하가 걸릴경우 메모리를 얼마나 사용하고 있는지 확인한다. 3. 문제가 생겼을경우 시스템이 정상적으로 잘 작동하고 있을때 모니터링을 했다면, 사용자가 불평하기전에 언제 시스템 성능이 나빠지는지 알수가 있다. 그러면 이러한 문제에 대해서 어떻게 대응해야할지도 알 수가 있을 것이다. ㅇ 어떤 프로그램을 실행하고 있으며 어떻게 사용하고 있는가? 예를 들어 네트웍을 통해 파일에 접근하고 있다면 네트웍 성능이 떨어지는게 문제의 한 부분이라는걸 알 수 있을 것이다. ㅇ load average를 보기 위해 uptime 을 실행하자. 줄어들고 있는가 늘어나고 있는가? 높은가 낮은가? ㅇ ps aux 를 실행해보자 - 디스크 액세스나 페이징을 기다리고 이는 프로세스가 있는가? 그렇다면, I/O와 메모리를 점검하자. - CPU, 메모리를 가장 많이 사용하는 프로세스를 찾으면 부하분산에 도움이 될 것이다. ㅇ vmstat 5 5 를 시행해보자(5초간 5번) - cpu에서 시스템에서 사용하는 cpu시간(sy 항목)이 50%를 넘는가? 그렇다면 I/O에서 문제가 있는 것으로 예상된다. 소스코드에 접근할 수 있다면 해당 프로그램이 효율적으로 I/O를 사용하는지 점검하자. - 시스템 전체 부하가 높은데도 cpu에서 휴지시간(idle time, id 항목)이 10%를 넘는가? 그렇다면 I/O나 메모리에 문제가 있는 것으로 예상된다. - 휴지시간이 항상 0인가? CPU가 100% 사용되는것은 좋은 일이다. 그러나 항상 100% busy인 상태에 있다면 어디선가 작업이 계속 축적되고 있는것이다. 이는 cpu의 과부하를 말해준다. - 디스크의 활동이 분산되지 않았다면, I/O 작업을 효율적으로 분산시켜야한다. 이중에서 한가지도 해당하지 않고 메모리와 I/O관련 튜닝을 할 필요가 없다고 분석되었다면 CPU에 과부하가 걸린것이다. CPU의 과부하에 대처할 몇가지 방법이 있다. 그렇지만 CPU의 과부하는 메모리와 I/O문제로 나누어지기때문에 찾아내기 힘든 부분이다. - 필요없는 대몬을 없앤다. rwhod와 routed는 시스템 성능을 저해하는 프로그램으로 이를 없애는 것만으로도 많은 도움이 될 것이다. - at이나 cron등을 이용 작업을 밤이나 시스템의 부하가 적을때 실행하는 것도 좋은 방법이다. - CPU집약적인 작업은 nice를 이용 실행우선순위를 낮추면 편집과 갈은 상호대화적인 작업의 성능이 향상될 것이다. - cpu집약적인 작업의 실행우선순위를 높이면 작업 자체는 빨라지겠지만 상호대화적인 작업의 성능은 떨어질 것이다. - nice를 이용하는것은 임시방편일 뿐이다. 부하가 계속 증가한다면 nice를 이용하는 것에도 한계가 있다. 시스템을 업그레이드하거나 부하를 분산할 시스템을 구입하자. 4. 메모리 문제 파악하기 시스템에 과부하가 걸려있는데도 휴지기간(idle time)이 많거나 ps에서 많은 양의 메모리를 필요로 하는 프로그램이 실행되고 있다면 메모리 문제를 생각해 볼 수 있다. ㅇ vmstat 5 를 실행해보자. - swap-out이 지속적으로 항상 발생한다면 메모리가 부족한 것이다. 주기적으로 swap-outs이 발생하는건 정상적인 것이다. BSD 시스템에서는 비상호대화적인 작업을 스왑아웃한다. 현재 실행하고 있는 프로그램에서 스왑아웃이 계속 발생한다면 프로그램이 죽을 수도 있으며 심각하게 메모리가 부족하다는것을 가리킨다. 스왑아웃필드(so)가 항상 0에 가까워야한다. - ps나 통계시스템에서 메모리 집약적인 작업이 있는가? RSS필드나 storage integral이 큰 프로그램을 찾아보자. (RSS는 프로세스가 사용중인 실제 메모리 크기. kbytes 단위.) (storage integral은 sa -K 옵션을 이용해 볼수있음.) 메모리 문제를 해결할 몇가지 방법을 찾아보자. - 시스템에서 버퍼 캐쉬가 있다면 크기를 줄인다. 대신 디스크 I/O성능에 영향을 줄 수있다. - 정적으로 할당한 스트림 버퍼(STREAMS buffers)가 있다면 , 버퍼(2048-4096 byte)의 크기를 줄인다. 그러면 네트웍의 성능은 떨어질 수 있지만 netstat 를 이용해 현재의 시스템에서 실제로 필요한 버퍼의 크기를 예상할 수 있을 것이다. - 커널 테이블의 크기를 줄인다. 이를 통해 시스템의 자원을 제약할 수 있다. (파일 갯수, 프로세스 갯수등) - 많은 메모리를 필요로 하는 프로그램은 밤에 돌리자. - 많은 메모리를 필요로 하는 프로그램은 배치 큐를 이용해 작업하자. at, cron등 활용 - 자기만 사용하는 프로그램이라면 프로그램에서 메모리를 효율적으로 사용하는지 점검하자. - 메모리 요구량을 줄이기 위해 공유 메모리를 사용하자. - sendmail은 메모리를 많이 사용하는 프로그램으로 sendmail을 실행하는데 사용되는 시간에 제한을 두자. 아니면 네트웍을 재구성해서 메일서버를 다른 시스템으로 옮길 수 있다. - 이막스는 메모리를 많이 사용하는 프로그램으로 다른 에디터를 사용하자. - 이 모든게 안되면 메모리를 구입하자 5. 디스크 I/O 문제 파악하기 시스템에 과부하가 걸려있는데도 휴지기간(idle time)이 많다면 디스크 I/O 문제를 생각해 볼 수 있다. 보통 메모리 문제와 I/O문제는 서로 관련이 되어있다. ㅇ vmstat 5 를 실행한다. 그리고 이것을 정상적인 시스템 상황과 비교해본다. 정상적인 경우보다 디스크 연산이 더 높은가? ㅇ 디스크 활동이 시스템 디스크에 골고루 분산되어있는가? ㅇ 그렇지 않다면 가장 활동적인 디스크가 가장 빠른 디스크인가? ㅇ 디스크 활동이 디스크의 특정 영역에 집중되어있는가? 디스크에 적당히 분포되어있는가? 아니면 서로 다른 반대방향의 지점에 있는가? ㅇ NFS를 사용하고 있는가? 사용자들이 자신의 지역?파일에 접근하는데 속도가 느리다고 보고를 하는가? 원격 파일시스템을 사용하는가? 만약 원격 파일시스템을 사용하면 네트웍 상황에 대해서 살펴보자. 이경우에는 지역 디스크 I/O문제는 아니다. ㅇ vmstat를 이용 메모리 상황을 살펴보자. 시스템에서 페이징이나 스와핑이 계속 일어나고 있다면, 메모리에 문제가 있으며 이경우 디스크 I/O에 심각한 문제를 초래할 수 있다. 먼저 메모리 문제를 살펴보아야한다. 이에 대한 해결책을 찾아보자. ㅇ 파일시스템을 재구성하고 가능한한 I/O작업을 분산시킨다. ㅇ 루트 파일시스템에 가장 빠른 디스크 드라이브와 컨트롤러를 사용한다. 루트 파일 시스템이 대부분 가장 많은 I/O작업을 한다. 특정한 파일의 성능이 중요하다면 성능이 중요한 파일을 하나의 파일시스템에 넣고 이 파일시스템에 가장 빠른 드라이브를 사용한다. ㅇ 퍼포먼스가 중요한 파일을 블락 사이즈가 큰 파일시스템에 넣는다. (리눅스에서 기본은 1k) ㅇ 버퍼 캐쉬의 크기를 늘린다. 그러면 대신 메모리에 문제가 생길 수 있다. ㅇ 단편화를 제거하기 위해 주기적으로 파일시스템을 재구성한다. ㅇ 자주 사용하는 파일을 파일시스템의 시작부분에 집중시키는 프로그램을 사용할수 있다. 디스크 용량에 문제가 생길 수도 있다. 파일시스템에 여유공간이 부족한가? 그렇다면 몇가지 방법을 생각해보자. - 필요없는 파일을 cron 등을 이용 정기적으로 삭제하자. 오래된 코어 덤프 파일, 에디터 백업파일, auto-save 파일 등등. ㅇ 디스크 쿼터를 이용해 사용자의 디스크 용량 사용을 제한할 수 있다. ㅇ 매우 작은 파일이 모여있는 파일시스템에는 작은 블럭 사이즈를 사용한다. (소스 코드, 작은 데이타 파일 등등) 6. 네트웍 문제 점검 네트웍 문제 점검 ㅇ rlogin이나 NFS를 이용하 파일에 접근하는 사용자가 성능이 느리다고 생각이 든다면 이는 네트웍 용량이나 데이터 정합성이 문제가 있을 수 있다. ㅇ netstat -i 를 실행하자. 충돌(collison)이 크면 네트웍에 오버헤드가 걸렸다고 생각할 수 있다. input이나 output 에러가 많다면 하드웨어 문제일 수 있다. 입력에러가 많다면 네트웍의 특정한 곳에 문제가 있을 가능성이 크며 출력에러가 많다면 시스템과 네트웍 인터페이스에 문제가 있을 가능성이 크다. ㅇ 충돌이나 네트웍 하드웨어의 문제가 아니라면, 어떤 시스템이 가장 느린지를 찾아야한다. spray 프로그램을 이용해 느린 시스템에 다량의 패킷을 보내자. dropped 패킷이 크다면, 원격 시스템은 아마도 들어오는 자료에 대해 충분히 빠르게 대응하지 못할 것이다. 원격 시스템에 cpu, 메모리, 디스크 I/O문제가 있는지 확인하자. 그게 아니라면 그 시스템은 네트웍의 과부하에 견디지 못할 것이다. 네트웍을 다시 재구성하고 느린 시스템을 파일 서버로 사용하지 말자. ㅇ droppted 패킷이 많다면 데이타 corruption 이 많다는 것이다. 원격 시스템에서 netstat -s를 실행한다. 그리고나서 지역 시스템에서 원격 시스템으로 spray 명령을 사용하고 다시 netstat -s 를 실행한다. UDP socket full drops가 증가하는게 spray의 결과에서 나온 drop 패킷과 같거나 더 많다면 원격 시스템은 느린 네트웍 서버이다. socket full drops 의 증가하는 숫자가 dropped 패킷보다 작다면 네트웍에 문제가 있는지 확인해보자. ㅇ nfsstat 를 실행하고 클라이언트의 RPC 데이타를 관찰해보자. 생략... ㅇ 현재의 시스템에서 스트림 기반 네트웍 작업을 한다면, netstat -m (?. 안돔) 을 실행하자. 충분한 스트림 버퍼가 있는가? 네트웍 부하 줄이는 방법 ㅇ 사용자가 네트웍을 통해 I/O집약적인 프로그램을 실행하지 않도록 막자. grep 프로그램이 I/O 집약적인 프로그램중의 대표적인 예이다. 대신 네트웍을 통해 로그인해서 작업하자. ㅇ 네트웍에 연결된 컴퓨터와 디스크를 재구성해서 가능한 많은 사용자가 지역 지역 시스템에서 작업을 하도론 만든다. ㅇ 디스크없는 워크스테이션의 숫자를 줄인다. 가능하다면 이런 워크스테이션은 제거한다. ㅇ 뛰어난 네트웍 성능을 가진 시스템을 파일서버로 사용한다. ㅇ 스트림 버퍼가 작다면(그리고 SunOS 4.0이나 System V.3또는 이전 버전을 운영한다면) 버퍼를 늘리기 위해 커널을 재구성한다. 데이터 integrity(정합성)에 문제가 있다면 유일한 해결책은 문제가 있는 하드웨어를 찾아서 바꾸는 것이다. 네트웍 분석툴이 이러한 작업을 하는데 반드시 필요할 것이다. 7. 터미널 I/O 유닉스 시스템은 전형적으로 터미널에 아주 높은 우선순위을 준다. 그래서 키보드에서 작업을 하고 반응을 확인하는데 문제가 생기는 경우는 거의 없다. 그렇지만 몇가지 문제가 생길 수 있느것을 생각해보자. ㅇ ps에서 getty 프로세스에서 사용하는 시간이 계속 늘어나고 있다면 누군가가 터미널 라인에서 채팅을 하고 있는 것이다. 파일을 수정해서 터미널 라인을 사용하지 못하게 하자. (어떤 파일은 시스템과 연관되어 있다) ㅇ 사용자가 터미널의 성능에 대해 불평을 하는 경우 시스템에 직접 연결된 것인지, 아니면 rlogin을?사용한 것인지, X 터미널인지, 아니면 다른 방법을 이용해 연결한 것인지 확인을 하자. 이럴경우 터미널 I/O문제라기보다 네트웍에 문제가 있을 가능성이 많다. ㅇ 상호대화적인 작업에서 반응이 느리다면 CPU 성능에 관련된 문제를 해결하는게 좋다. System V.2, V.3 또는 SunOS 4.0를 사용하고 있다면 스트림 버퍼가 부족할 수도 있다. netstat -m을 실행하고 samll data blocks 할당에 문제가 있는지 살펴조자(?) 그러다면 커널에서 스트림 버퍼를 더 작게한다? 8. 일반적인 팁 몇가지 상호대화적인 작업의 성능을 향상시킬수 있는 몇가지 팁이 있다. ㅇ pwd 대신 dirs를 사용한다. ㅇ ps를 가급적 사용하지 않는다. ㅇ sh 를 사용하는 경우, 경로를 줄여서 사용한다. ㅇ 디렉토리당 파일을 최소화한다. ㅇ 이막스대신 vi 등을 사용한다. ㅇ grep이나 fgrep 대신 더 빠른 egrep을 사용한다.? ㅇ NFS를 사용하는 경우 grep이나 I/O집약적인 프로그램을 실행하지 않는다. ㅇ 원격시스템의 파일에 접근하려면 NFS대신 rlogin을 사용한다.