본질적으로 제 질문은 Solaris 가상 머신의 메모리 할당과 관련이 있습니다.
저는 두 개의 Solaris 8 가상 머신에서 두 개의 오래된 Sun ONE 6 Java 웹 서버를 실행하고 있습니다. 합리적인 양의 스왑 공간이 사용되고 있다는 것을 알 수 있지만 이것이 이러한 시스템에 더 많은 RAM을 추가해야 한다는 것을 의미하는지 정확히 확신할 수 없습니다.
서비스 피크 시간(보통 아침)에 이러한 서버가 호스트하는 웹 애플리케이션의 응답 시간은 최대 11초까지 올라갑니다(상대적으로 간단한 웹 페이지 로딩 작업에는 다소 해롭습니다). 사용량이 많지 않은 시간대의 평균 응답 시간은 약 5초입니다.
아래 출력에서 이러한 컴퓨터의 RAM 사용량에 대해 무엇을 추론할 수 있습니까? 이 정보가 합리적으로 충분합니까? 아니면 서버 메모리 부족을 배제하기 위해 다른 명령을 실행해야 합니까?
마지막으로 설정의 핵심에는 Java 애플리케이션이 있으므로 다음 사항도 고려했습니다.
1) 힙의 객체 할당을 추적하여 잠재적인 메모리 누수를 감지합니다.
2) 이것이 네트워킹 지연과 관련이 있는지 확인하려면 성능 프로파일링을 수행하십시오. 애플리케이션이 단일 Oracle 데이터베이스와 통신하기 때문에 이에 대해 언급했지만, 네트워크 분할 관점에서 보면 이 둘이 매우 유사하기 때문에 이것이 사실인지 의심스럽습니다.
귀하가 제공할 수 있는 모든 종류의 통찰력과 피드백에 감사드립니다.
시간을 내어 도와주셔서 감사합니다.
서버 1:
40 processes: 38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle, 0.4% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
12676 webservd 112 29 10 616M 242M sleep 103:37 0.48% webservd
18317 root 1 59 0 23M 19M sleep 67:24 0.08% perl
9479 support 1 59 0 6696K 2448K cpu/1 0:11 0.05% top
8012 root 10 59 0 34M 704K sleep 80:54 0.04% java
1881 root 33 29 10 110M 13M sleep 33:03 0.02% webservd
7808 root 1 59 0 83M 67M sleep 7:59 0.00% perl
1461 root 20 59 0 5328K 1392K sleep 6:49 0.00% syslogd
1691 root 2 59 0 27M 680K sleep 4:22 0.00% webservd
24386 root 1 59 0 15M 11M sleep 2:50 0.00% perl
23259 root 1 59 0 11M 4240K sleep 2:42 0.00% perl
24718 root 1 59 0 11M 5464K sleep 2:29 0.00% perl
22810 root 1 59 0 19M 11M sleep 2:21 0.00% perl
24451 root 1 53 2 11M 3800K sleep 2:18 0.00% perl
18501 root 1 56 1 11M 3960K sleep 2:18 0.00% perl
14450 root 1 56 1 15M 6920K sleep 1:49 0.00% perl
서버 2
42 processes: 40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle, 0.4% user, 0.8% kernel, 0.0% iowait, 0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
5607 webservd 74 29 10 284M 173M sleep 20:14 0.21% webservd
15919 support 1 59 0 4056K 2520K cpu/1 0:08 0.09% top
13138 root 10 59 0 34M 1952K sleep 210:51 0.08% java
13753 root 1 59 0 22M 12M sleep 170:15 0.07% perl
22979 root 33 29 10 112M 7864K sleep 85:07 0.04% webservd
22930 root 1 59 0 3424K 1552K sleep 17:47 0.01% xntpd
22978 root 2 59 0 27M 2296K sleep 10:49 0.00% webservd
13571 root 1 59 0 9400K 5112K sleep 5:52 0.00% perl
5606 root 2 29 10 29M 9056K sleep 0:36 0.00% webservd
15910 support 1 59 0 9128K 2616K sleep 0:00 0.00% sshd
13106 root 1 59 0 82M 3520K sleep 7:47 0.00% perl
13547 root 1 59 0 12M 5528K sleep 6:38 0.00% perl
13518 root 1 59 0 9336K 3792K sleep 6:24 0.00% perl
13399 root 1 56 1 8072K 3616K sleep 5:18 0.00% perl
13557 root 1 53 2 8248K 3624K sleep 5:12 0.00% perl
답변1
서버에 RAM이 부족한지 확인하려면 vmstat 명령 출력의 sr 열이 유용한 측정항목입니다. vmstat 10 10참조 및 피크 기간(10초마다 10개 샘플) 과 같은 것을 실행하고 출력을 게시하십시오. swap -s출력도 유용할 것입니다. vmstat 대신 다음을 실행하는 것이 좋습니다. sar -g 5 5
어쨌든 "top" 출력에 따르면 server2에는 RAM이 부족한 것 같습니다. Solaris에는 가상 및 물리적 메모리 소비자를 식별하는 데 도움이 될 수도 있는 top과 유사한 지원 명령이 있습니다.
prstat -s rss -n 5
prstat -s size -n 5
답변2
이 스냅샷에서 눈에 띄는 것은 다음과 같습니다.
- 많은 Perl 프로세스
- 다중 webservd 프로세스
- 머신은 98% 및 99% 유휴 상태입니다.
이러한 사실은 다음과 같은 질문으로 이어진다.
- Perl 프로세스 수를 줄일 수 있습니까?
- 스레드 웹 서버 모델로 전환할 수 있는 방법은 없을까요?
- 기계가 스트레스를 받을 때 시스템 상단은 어떤 모습입니까?
마지막으로 이를 추적하기 위해 다음을 수행합니다.
- Wireshark와 같은 네트워크 스니퍼를 사용하여 HTTP 프로세스의 어느 부분이 실제로 보류되고 있는지 확인하세요. 연결인가요? 페이지 전달인가요? 페이지의 동적 부분을 전달하는 것인가요?
- HTTP 스트레스 도구를 사용하고 웹 서버에 스트레스를 주어 반응 방식을 확인하세요. vmstat 및 top으로 응답 보기: 저는 이 작업을 수행하기 위해 터미널에서 screen을 사용하는 것을 좋아합니다.
행운을 빌어요!
답변3
나는 항상 메모리 사용량을 추적하는 가장 쉬운 방법은 시스템 계산이라는 것을 알았습니다. 많이 뛰어다닐 수 있으므로 사용 패턴을 보려면 최소 일주일 동안 검토하는 것이 중요합니다.
"sys" crontab을 편집하면 /usr/lib/sa/sa1 스크립트의 일부 주석 처리된 실행을 볼 수 있습니다. 실행 빈도에 따라 저장된 회계 데이터의 시간 해상도가 결정됩니다. 나는 보통 24x7 시스템에 대해 다음과 같은 작업을 수행합니다.
20,40 * * * * /usr/lib/sa/sa1
그러면 해당 월의 날짜까지 /var/adm/sa에 통계가 저장됩니다. 이제 sar를 사용하여 거기에 저장된 날짜에 대한 메모리 통계를 덤프합니다. 3일이 나에게 가장 성수기였다고 가정해 보겠습니다.
sar -f /var/adm/sa/sa03 -g
주요 관심 열은 pgscan/s입니다. 해당 숫자가 오랫동안 200을 초과하면 시스템에 메모리가 부족한 것입니다. 100에서는 더 많은 메모리로 인해 이점을 얻을 수 있지만 성능 저하가 심각하지는 않습니다. 요즘은 디스크 스왑이 메모리보다 훨씬 느려서 단기적인 점프를 제외하고는 0으로 유지하려고 노력합니다.