2012-09-15

IBM AIX] anti relay 설정 및 sendmail 설정 방법



Anti Relay
 설정방법
세희(kseh@kr.ibm.com)

다음은 aix5l에 서 기본적으로 사용되는 sendmail 8.11에서의 anti-relay 설정방법이다.


relay방지를 위해 sendmail 8.11.0의 환경을 설정
우선 다음 파일?이 설치되어 있는지 확인하자. 만약 설치되어 있지 않으면 smit을 사용해서 설치해야 한다.
# lslpp -l bos.adt.base
# lslpp -l bos.net.tcp.adt

AIX 5.1.0에는 현재 사용환경에 맞춰 sendmail 환 경파일을 만들 수 있도록 각종 도구와 매크로가 들어있는데, 이것들은bos.net.tcp.adt 파일?에 있다. 설 치하고 나면 이 파일들은
/usr/samples/tcpip/sendmail/cf 디렉토리에 위치한다.

이 디렉토리로 이동해보자.
#cd /usr/samples/tcpip/sendmail/cf

이 디렉토리에는 aixsample.mc 라는 파일이 있는데, 이 파일에는 사용자가 바꿀 수 있는 여러 가지 기능들이 들어있다. 이 파일을vi등으로 열어보면 다음과 같은 항목이 있다.
FEATURE(promiscuous_relay) dnl

우선 원래 파일을 겹쳐 쓰지 않도록 파일을 복사하자.
#cp aixsample.mc aix51.norelay.mc

복사한 파일을 열어보면 다음과 같이 보일 것이다. (à옆에 나오는 항목은 환경설정파일의 부분이 아니고 주석문이다.)
#vi aix51.norelay.mc
NOTE:The aixsample.mc can be edited with whatever FEATURES are needed for the
new sendmail.cf.
These features are documented at http://www.sendmail.org/m4/features.html


This is an example of a minimum .mc file:

divert(0)dnl
OSTYPE(aixsample)dnl
FEATURE(genericstable)dnlà지워도 무방
FEATURE(mailertable)dnlà지워도 무방
FEATURE(virtusertable)dnlà지워도 무방
FEATURE(domaintable)dnlà지워도 무방
FEATURE(allmasquerade)dnl
FEATURE(promiscuous_relay)dnlà승인되 지 않은 relay를 방지하려면 삭제
FEATURE(accept_unresolvable_domains)dnl à지워도 무방
FEATURE(accept_unqualified_senders)dnlà지워도 무방
DOMAIN(generic)dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)

이제 새 파일은 다음과 같이 보일 것이다.
(주의! 지울 항목은 완전히 없애야 한다. 주석처리하는 것은 소용없다.
relay와 관련 있는 항목은 "FEATURE(promiscuous_relay)dnl" 만 해당되지만, 이것만 지우면 계속 경고메시지가 나오기 때문에 지워도 무방한 항목은 지워야 한다.)

#vi aix51.norelay.mc
divert(0)dnl
OSTYPE(aixsample)dnl
FEATURE(allmasquerade)dnl
DOMAIN(generic)dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)

이제 새 옵션을 사용하여 새 sendmail.cf를 만들자. 모든 작업은 /usr/samples/tcpip/sendmail/cf 디렉토리에서만 수행해야 한다.

#m4../m4/cf.m4 aix51.norelay.mc> testmail.cf

이제 /usr/samples/tcpip/sendmail/cf 디 렉토리 아래 새 testmail.cf가 보일 것이다. 원래의 sendmail.cf를 이름을 바꾸어 복사한 다음 새로 만든 testmail.cf를 sendmail.cf로 복사한다. (원래 파일의 백업을 만드는 것을 잊지 말 것!)

#mv /etc/mail/sendmail.cf/etc/mail/sendmail.cf.orig
#mv testmail.cf/etc/mail/sendmail.cf

이제 새 /etc/mail/sendmail.cf 가 생겼다. 여기에는 관리자가 특정 파일을 지정해서 그 파일에 relay를 허용한 도메인을 적을 수 있도록 했다. 우 선 sendmail.cf를 열어보자.

#vi /etc/mail/sendmail.cf
여기에서 아래와 같은 매크로를 찾아보자.
#Hosts that will permit relaying ($=R)
FR-o /etc/mail/relay-domains

relay-domains 파일에 relay를 허용한 도메인을 적어놓으면 된다. 현 재 여기에서는 특별히 수정할 사항은 없다.

이제 relay를 허용할 도메인이나 호스트명을 relay-domains파일에 적는다. 이때 여러분 자신의 호스트 이름도 적어야 한다. 네크워크나 호스트 IP주소로 적어도 된다.
#vi /etc/mail/relay-domains
entry1...
entry2...
entry3...

예를 들어 ibm.com도메인에서 오는 호스트들은 모두 relay를 허용하려면 relay-domains파 일에 ibm.com이라고 써놓으면 된다.

이제 sendmail에게 환경파일이 바뀐 것을 알려줘야 한다.
#refresh -s sendmail

만약 sendmail 데몬이 돌아가고 있지 않다면 다음 명령어로 sendmail이 살아있는 상태인지 아닌지 확인할 수 있다.

#lssrc -s sendmail
SubsystemGroupPIDStatus
sendmailmail5424active

만약 sendmail데몬이 살아있는 상태가 아니라면 다음 명령어로 데몬을 살린다.

#startsrc -s sendmail -a "-bd -q30m"

만약 허용되지 않은 도메인에서 relay로 이용하려고 하면 “relay denied”라는 메시지가 보일 것이다.

Troubleshhting
메일사용 시 다음과 같은 메시지가 보일 수 있다.
/etc/mail/sendmail.cf: line 140: fileclass: Cannot open
/etc/mail/local-host-names:A file or directory in the path name does not exist.

이런 경우 local-host-names 파일을 열어서 자신의 호스트 이름과 알리아스,도메인이름, relay하는 도메인이름등을 적어넣으면 된다. 예를 들어 carter라는 이름의 호스트이고 ibm.com, austin.ibm.com이라는 도메인에서 오는 메일을 relay한다면 local-host-names 파일은 다음과 같다.

#vi /etc/mail/local-host-names

carter
carter.autin.ibm.com
ibm.com
austin.ibm.com


주의
이 정보에 대해서 IBM은 직접적 책임이 없으며, 이 정보를 사용한 구현방법에 대한 책임은 전적으로 사용자의 능력과 사용환경에 의존하며, 사용결과에 대한 책임역시 사용자에게 있다.

2012-09-14

Linux] simscan설치 및 qmail-scanner와 simscan 의 비교

simscan설치 및 qmail-scanner simscan 의 비교

작성자:김경민(stone@linuxstudy.pe.kr)
잘못된 부분이나 좋은 의견이 있으면 메일로 주시면 감사드리겠습니다.

목적
Qmail-scanner(perl)에 비해 c로 작성된 simscan 의 성능 테스트 및 장단점
perl스캐너 사용시 서버의 로드가 많이 높아지는 부분을 해소해 보고자 함

다운로드 위치

필요한 것들
Ripmime(첨부파일을 필터링 하고자 한다면 필요하다)
Qmail-queue패치
Clamav(바이러스메일 체크)
Spamassassin
Trophie(or sophie)-옵션으로 설치 가능

- 설치 -
위의 다운로드 위치에서 소스를 다운로드 받는다.
먼저 clamav spamassassin을 설치하도록 한다.
simscan소스를 풀고 소스 디렉토리로 이동
주의-먼저 simscan 이라는 사용자를 만들어야 한다.

Shell# groupadd simscan
Shell# adduser g simscan r d /var/qmail/simscan M s /sbin/nologin simscan

Shell# ./configure 필요 옵션
Shell# make
Shell# make install-strip

옵션 설명
--enable-user=유저명 (simscan을 유저를 셋팅한다. 기본값으로 simscan)
--enable-clamav=y|n (clamav 를 이용한 스캐닝. 기본값으로 y 이다.)
--enable-clamdscan=clamdscanPTAH
--enable-custom-smtp-reject=y|n (바이러스 이름을 포함하여 리턴 메시지를 보내도록한다)
주의 위의 옵션을 사용하기 위해서는 소스디렉토리/contrib/qmail-queue-custom-error.patch 의 패치를
Qmail에 해주어야 한다. 또한 나중에 설명되는 옵션중에 하나인 enable-dropmsg 의 값이 y이면 안된다.)
--enable-per-domain=y|n ( 많은 도메인에 대해서 메일서비스를 하고 있으며 각각에 대한 simscan 의 설정을
하고자 한다면 y를 택하도록 한다.)
--enable-attach=y|n ( 첨부파일에 대해서 체크를 할 것인지의 여부를 정한다. /var/qmail/control/ssattach 파일안에 필터링할 파일명이나 확장자를 넣어주면 된다.)
--enable-spam=y|n (스팸메일에 대한 필터링을 할 것인지에 대한 옵션이다. 스팸어세신에 의해서 status YES인 메일에 대해서는 반송을 하게 될것이다.)
--enable-spam-passthru=y|n ( 스팸 어세신에서 붙은 status값을 무시하고 그냥 통과시키고자 할 경우에 사용한다. 이는 나중에 procmail 이나 maildrop으로 스팸 편지함이나 별도의 디렉토리에 스팸 메일을 저장하고자 한다면 유용하게 사용될 수 있을 것이다.)
--enable-spam-hits=점수 (기본값으로 10 이 셋팅되며 스팸 어세신에서 정한 값을 넣으면 될 것이다.)
--enable-spamc=PTAH (spamc 바이너리파일의 위치를 잡아준다. 자동으로 잡을것이다^^)
--enable-spamc-args (spamc 에 필요한 옵션을 지정할 수 있다. 필자의 경우에 퍼포먼스를 위해 spamd 를 소켓을 사용하게 하였으며 소켓의 위치는 /tmp/spamd 였다, 쌍따옴표로 지정한다는 점에 주의 하라)
Ex) --enable-spamc-args=-U /tmp/spamd
--enable-dropmsg=y|n (스팸 메일에 대한 메시지를 sender 에게 보내지 않겠다는 옵션이다.)
--enable-quarantinedir=디렉토리위치( 스팸,바이러스 메일을 따로 저장해둘 디렉토리를 지정한다)
--enable-received=y|n ( 메일헤더에 received를 추가할 것인지에 대한 옵션이다. 버전정보 및 처리시간이 기록되어진다.)

-필자의 경우의 configure
./configure --enable-spam --enable-per-domain --enable-attach --enable-received=y --enable-spamassassin-path=/usr/bin/spamassassin --enable-spam-hits=5.1 --enable-spamc-args=-U /tmp/spamd


컴파일 및 설치가 완료 되었다면 이제 큐메일의 run 파일을 고치도록 한다.
필자의 run 파일의 내용이다.
기존에 셋팅했던 큐메일 스캐너를 잠시 내렸다^^;

#!/bin/sh
QMAILQUEUE="/var/qmail/bin/simscan"
#QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue.pl"
export QMAILQUEUE
Q_UID=`id -u qmaild`
Q_GID=`id -g qmaild`
exec /usr/local/bin/softlimit -m 55000000 /usr/local/bin/tcpserver -vHRl 0 -x /etc/tcp.smtp.cdb -u $Q_UID -g $Q_GID 0 25 /var/qmail/bin/qmail-smtpd spamgw.linuxstudy.pe.kr /bin/checkpassword /bin/true 2>&1

메일서버 재시작

메일 테스트
메일을 보내보고 도착한 메일을 열었을 때 헤더에 다음과 같은 라인이 존재하는지 확인해 보자
필자의 경우에 --enable-received=y 를 주었기 때문에
Received: by simscan 1.1.0 ppid: 18392, pid: 18393, t: 0.0957s
         scanners: clamav: 0.84rc1/m:30/d:813 spam: 3.0.2
가 있으며 스팸어세신의 점수를 5.1로 주었기 때문에 아래와 같이 헤더가 추가되어 있다.
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on test
X-Spam-Level:
X-Spam-Status: No, score=0.4 required=5.1 tests=AWL,NO_REAL_NAME autolearn=no
        version=3.0.2

메일이 위의 헤더를 가지고 있다면 정상적으로 simscan이 작동한다.

-간단Tip-
Clamav 와의 연동시 퍼미션 문제가 나올 경우에 아래와 같이 clamav 유저를 simscan 의 그룹으로 추가해 준다.
Shell# usermod G imscan clamav

Enable-per-domain 옵션시 각 도메인 별로의 설정(simcontrol)
Shell# cat /var/qmail/control/simcontrol
example.com:clam=no,spam=yes,attach=.mp3
:clam=yes,spam=yes,trophie=yes,spam_hits=20.1

첨부파일 필터링

Shell# cat /var/qmail/control/ssattach
.exe
.jpeg
.pif



Qmail-scanner simscan 의 장단점 비교

비교는 어디까지나 필자의 경험상으로 작성된 것이면 상황에 따라 또는 설정에 따라 얼마든지 달라질 수 있다.

-테스트 방법-

 A 호스트에서 웹 프로그램으로 첨부파일 100k 짜리와 함께 간단한 메시지를 100통 발송
스캐너가 설치된 B 서버의 메일 메시지에 남은 시간을 계산하여 평균값을 냈다.
로컬 전송의 수치를 기본값과 100을 주었을 때를 비교해 보았다.


Simscan
Qmail-scanner
비고
메시지 처리시간 평균
1.6665
5.42134148
concurrencylocal의 기본값 사용
메시지 처리시간 평균
1.8093
5.25143428
Concurrencylocal 100사용
로그 파일
별도 로그가 없음
smtp
로그에 같이 남음
별도 로그 남기기 쉬움
Simscan의 경우에 별도로 sender 의 아이피 정보나 기타 필요한 정보를 따로 저장하지 않기 때문에 소스를 수정하던지 다른 방법으로 자동 필터링 시스템을 생각해야 할 것 같다.

전체적으로 c 로 작성된  simscan이 메시지 처리 능력에서는 다소 앞선 듯 보이기는 한다.
하지만 qmail-scanner 의 경우에는 perl로 작성되어 있어서 원하는 대로 쉽게 수정이 가능하다는 장점이 있을것이다.

Linux] SuSELinux_qmail_install


SuSE Linux 9.2 Professional 상에서 qmail+mysql+vpopmail+qmailadmin+qmail-scanner+spamassassin+courier-imap+squirrelmail 설치하기



목적 :
1. 사용자 계정을 mysql 을 이용함으로써 추가나 삭제를 할수 있다.
2. vpopmail 을 설치함으로써 가상 도메인에 대한 관리를 손쉽게 할수 있다.
3. qmail-scanner 을 설치함으로써 바이러스에 대한 필터링을 한다.
4. squirrelmail로 웹상에서 메일을 사용할 수 있게 한다.
5. qmailadmin으로 웹상에서 메일계정을 쉽게 관리할 수 있게 한다.
6. qmailMrtg로 웹상에서 메일서버의 트래픽을 쉽게 관찰할 수 있게 한다.


아래의 파일은 2005.05.09 현재 최신 버전을 다운 받은 리스트이며, 위와 같은 조합의 메일 시스템을 구축하기 위한 모듈들입니다.


qmail 관련
http://qmail.kldp.org/src : qmail-1.03,
http://inter7.com : vpopmail, qmailadmin, autoresponder
http://www.ezmlm.org/ : ezmlm, ezmlm-idx
http://qmail.org/netqmail/ : netqmail 패치
autorespond-2.0.4.tar.gz // 자동응답담당하는 모듈
daemontools-0.76.tar.gz // qmail 자동화 관리툴
ezmlm-0.53.tar.gz // qmail 지원하는 메일링리스트
ezmlm-idx-0.440.tar.gz //
maildrop-1.8.0.tar.bz2 // qmail-scanner에 연동되는 모듈
netqmail-1.05.tar.gz // qmail 패치
qmail-1.03.tar.gz
qmailadmin-1.2.7.tar.gz // 웹상에서 메일계정관리
ucspi-tcp-0.88.tar.gz
vpopmail-5.4.2.tar.gz // 가상 메일지원모듈
qmailmrtg7-4.2.tar.gz // qmail 트래픽 모니터링
qmail-scanner-1.25.tgz // qmail-scanner (바이러스 필터링)
Mail-SpamAssassin-3.0.3.tar.gz // spamAssassin http://spamassassin.apache.org
Time-HiRes-1.67.tar.gz // qmail-scanner설치시 필요
clamav-0.84.tar.gz // qmail-scanner 애드온
mysql
mysql-4.x.x.tar.gz // http://www.mysql.com

imapd
(http://inter7.com/
courier-imap-4.0.2.20050403.tar.bz2 // 웹메일을 지원하기 위한 모듈

web
httpd-2.0.54.tar.gz // http://www.apache.org
php-5.0.4.tar.gz // http://www.php.net
squirrelmail-1.4.4.tar.gz // 웹메일 클라이언트 http://www.squirrelmail.org

기타
텍스트상에서 웹서핑하기 위한 도구
lynx-2.8.5-26.i586.rpm // http://www.rpmfind.net,  http://www.lynx.org



패치
qmail-1_03-mysql-0_6_6.patch
   -> 사용자 여부를 시스템 계정이 아닌 mysql 에서 하기 위한 패치.
qmail-103.patch
   -> oversize dns 을 위한 패치
checkpassword-0.81--mysql-0.6.6.patch
   -> pop3 사용시 사용자에 대한 패스워드 확인을  mysql 에서 하기 위한 패치. vpopmail 을 설치한다면 필요없습니다.
qmailqueue-patch          
   -> qmail-scanner 를 위한 queue 패치입니다.
qmail-smtp-auth.tar.gz
   -> 이것은 smtp 사용시 팝계정을 가진 사용자에 한해 smtp 를 사용하게 하자는 패치입니다. 좋더군요.
relaymailfrom.patch
   -> 옵션으로 보내는 사람의 메일 주소로 smtp 릴레이를 막자는 패치입니다.

패치가 많다고 해서 한번에 다 적용하려고 하지 말고. 하나씩 설치할때마다 필요한 패치를 그때 그때 적용하고 qmail 을 재 빌드하고 컴파일 하면 됩니다.
** 위의 netqmail을 이용해서 패치를 해도 됩니다.

설치 순서

* qmail 압축 풀기

# tar -xvzf qmail-1.03.tar.gz
# cd qmail-1.03

* qmail 설치를 위한 디렉토리 생성

# mkdir  /var/qmail

* qmail 운영을 위한 유저, 그룹을 만들어 주기 위해 운영체제에 따라 INSTALL.ids를 편집한다. 리눅스상에서는 다음과 같다.
  INSTALL.ids 는 qmail-1.03 디렉토리에 존재한다.

groupadd nofiles
useradd -g nofiles -d /var/qmail/alias alias
useradd -g nofiles -d /var/qmail qmaild
useradd -g nofiles -d /var/qmail qmaill
useradd -g nofiles -d /var/qmail qmailp
groupadd qmail
useradd -g qmail -d /var/qmail qmailq
useradd -g qmail -d /var/qmail qmailr
useradd -g qmail -d /var/qmail qmails

* qmail과 부수적인 패키지 설치

Mail Server] hMailServer 설치



Linux]Red Hat RHEL4에 Oralcle 10g R2 설치, Intsall HOWTO



Linux]리눅스 튜닝전략


리눅스 시스템 튜닝 전략 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을 사용한다.

Linux]리눅스-윈도 간 원격 터미널 접속 방법 총정리


http://kldp.org/node/85900

kldp에 있는 링크입니다.

도움이 되길 바라며.