특정 어플리케이션에 한정된 문제가 아닌것 같네요.
사용자가 많아지면 반드시 다음 수순으로 튜닝해줘야 합니다.
0. 파일시스템 관련 체크(iostat)
1. 시스템 TCP/IP 관련 튜닝
2. pop3 데몬을 standlone 모드로 가동(qpopper 권장)
3. 아파치 튜닝
4. mysql 설정 튜닝
5. 웹메일 소스 수정.
상당히 고달픈 작업이 되겠네요.
현재로서는 어느 부분에서 병목현상이 일어나는지 모르기 때문에
이 부분부터 찾아내는게 수순입니다.
좀 광범위한 내용으로 답변해서 좀 머쓱하네요... ㅇㅇ.
[이현철]님이 남기신 글:
>역시 그만큼 프로세스 라든지 LA가 움직이면
>cpu도 활발하게 움직여야하는데
>언제나 저 수준에서 뭐물고 있는것을 보면..
>프로그램 이 문제인것 같네요..
>좋은 대답감사합니다.
>
>그런데 이 서버는 웹메일서버입니다. 유저의데이타를
>mysql에 db에 저장합니다.
>LA가 8정도일때보면
>mysql.sock 컥넥션수가 엄청많습니다.
>
>mysql문제일수도 있는지요...
>
>뭐가 문제인지 이것도 살펴보고 저것도 살펴보고하는데..구름잡는 느낌입니다.
>오늘 LA가 8일때 아래와 같은 현상이 나타나고 있습니다.
>이럴경우에는 pop프로그램이 이상한지요..?
>
>[giga-mgr@mail log]$ netstat -na |grep mysql.sock | wc -l
> 88
>[root@mail root]# netstat -na |grep 110 | more
>tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
>tcp 0 0 10.0.40.10:110 211.5.230.26:62923 SYN_RECV
>tcp 0 0 10.0.40.10:110 219.188.104.47:65083 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.255.77.162:31013 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.14.15.195:21519 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.251.69.162:51265 SYN_RECV
>tcp 0 0 10.0.40.10:110 218.135.154.53:1057 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.196.112.2:2128 SYN_RECV
>tcp 0 0 10.0.40.10:110 221.113.126.85:3219 SYN_RECV
>tcp 0 0 10.0.40.10:110 220.8.100.117:1240 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.141.114.42:37716 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.238.198.62:34003 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.18.205.34:41017 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.18.205.34:44872 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.238.195.74:33107 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.5.130.98:60661 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.126.210.242:31151 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.5.91.146:34791 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.126.210.242:16151 SYN_RECV
>tcp 0 0 10.0.40.10:110 222.13.17.175:3403 SYN_RECV
>tcp 0 0 10.0.40.10:110 218.222.204.151:42416 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.251.75.162:41839 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.238.179.226:11306 SYN_RECV
>tcp 0 0 10.0.40.10:110 220.49.148.182:1150 SYN_RECV
>tcp 0 0 10.0.40.10:110 220.220.204.19:1660 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.184.2:11503 SYN_RECV
>tcp 0 0 10.0.40.10:110 220.210.134.50:32868 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.196.81.218:35349 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.126.210.242:36840 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.251.68.226:29155 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.251.84.194:10394 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.150.64.6:10242 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.203.2:19839 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.233.18.2:32730 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.206.66:38332 SYN_RECV
>tcp 0 0 10.0.40.10:110 220.159.87.136:1076 SYN_RECV
>tcp 0 0 10.0.40.10:110 219.97.38.228:58625 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.255.58.162:16305 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.196.208.2:52266 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.214.194:62643 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.196.234.194:36105 SYN_RECV
>tcp 0 0 10.0.40.10:110 219.97.38.228:57311 SYN_RECV
>tcp 0 0 10.0.40.10:110 211.126.195.106:11117 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.206.66:44128 SYN_RECV
>tcp 0 0 10.0.40.10:110 218.222.204.150:59668 SYN_RECV
>tcp 0 0 10.0.40.10:110 61.117.168.194:35404 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.233.22.154:57350 SYN_RECV
>tcp 0 0 10.0.40.10:110 210.230.246.98:60242 ESTABLISHED
>tcp 0 0 10.0.40.10:110 211.18.214.34:15046 ESTABLISHED
>tcp 0 0 10.0.40.10:110 61.117.168.194:43727 ESTABLISHED
>tcp 0 0 10.0.40.10:110 210.233.22.154:47789
>
>
>
>[산이]님이 남기신 글:
>
>>
>>[이현철]님이 남기신 글:
>>
>>>-----------------------------------------
>>>답변자가 기본적으로 참고할 내용입니다.
>>>- 배포판(옵션) :
>>>- 커널버전(옵션) :
>>>- 데몬버전(예:apache 1.3.27) :
>>>- 데몬설치유형(RPM/컴파일/기타) :
>>>-----------------------------------------
>>>top명령어를 보면 여러가지가 정보가 나오는데요.
>>>아래와 같을 경우에 cpu사용률이 알맞은 것인지.. 메모리 사용량과
>>>cpu사용률을 보면 서버가 어느정도 자기실력을 발휘하는지 알수있다고 하는데
>>>제가 보면 제대로 서버의cpu와 메모리가 최적화로 움직이는 어떤지
>>>잘모르겠습니다.
>>>아래와 같이 load average가 8 이상이 지속되고 있는데요.
>>>여러가지 이유가 있다고 생각됩니다.만..
>>>
>>> 8:38pm up 58 days, 17:36, 4 users, load average: 8.46, 8.38, 6.26
>>>391 processes: 379 sleeping, 1 running, 11 zombie, 0 stopped
>>>CPU0 states: 2.0% user, 6.0% system, 0.1% nice, 91.2% idle
>>>CPU1 states: 2.2% user, 2.0% system, 0.0% nice, 95.1% idle
>>>CPU2 states: 1.2% user, 7.3% system, 0.0% nice, 90.3% idle
>>>CPU3 states: 3.0% user, 2.3% system, 0.0% nice, 94.0% idle
>>>Mem: 3099020K av, 3021228K used, 77792K free, 0K shrd, 448716K buff
>>>Swap: 2097096K av, 625264K used, 1471832K free 1523648K cached
>>
>>========================================
>>
>>일단은 현재 running 되고 있는 프로세스가 CPU 를 제대로 활용하지
>>못하고 있는 것 같습니다.
>>
>>반드시 그렇지는 않지만 보통 LA 가 1 이면 CPU 는 보통 50% 이상을
>>차지해야 CPU 를 제대로 활용한 셈입니다(예를 들자면).
>>
>>LA 가 높을 수록 CPU 사용률이 많아야 정상적입니다.
>>그런데 위의 경우는 그 반대로, LA 가 꽤 놓은데 CPU 사용률이
>>적다는 것은 해당 프로그램에서 어떤 설정이나 코드 알고리즘이
>>제대로 튜닝되지 않았다는 내용입니다(알고리즘적인 병목현상).
>>
>>한가지 예를 들자면,
>>
>>네트워크 소켓프로그램에서 select(2) 같은 함수를 많이 사용하는데
>>TIMEOUT 시간을 아주 짧게 주면 CPU 사용률은 상당히 올라갑니다.
>>그대신 알고리즘적인 병목현상(LA 가 올라가는 경우)은 많이 줄어들게
>>됩니다.
>>
>>그 반대로 TIMEOUT 시간을 길게 주면 CPU 사용률은 다소 작지만
>>어떤 병목현상(위의 경우와 같은)이 일어날 수 있습니다.
>>
>>해당 프로그램을 튜닝해 보세요.
>
>========================================
======================================== |
sun's longitude:242 25 57.38
/board/delete.php:소스보기 
