☰

Solaris SunOS 5.10에서 스틸 타임 데이터에 어떻게 액세스합니까?

tag-icon • tag-icon performance virtual-machines solaris performance-monitoring
Solaris SunOS 5.10에서 스틸 타임 데이터에 어떻게 액세스합니까?

우리가 실행하고 있는 솔라리스 버전은 상단에 스틸타임을 보고하기에는 너무 오래된 버전이라고 생각합니다. 이전 버전의 Solaris에서 이 정보를 얻을 수 있는 방법이 있습니까? 기본 버전 정보는 다음과 같습니다.

-bash-3.2$  uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32

저는 이러한 Sun VM 시스템에 대한 실제 전문 지식이 없기 때문에 오해가 있을 수 있으며 이 상황에서 필요한 작업을 수행하는 더 나은 방법이 있을 수 있습니다. Intel 정신 모델을 적용하면 CPU가 부족해지고 있다고 생각됩니다. 하지만 이를 어떻게 측정할 수 있습니까?

업데이트

Intelish 용어를 용서하십시오. 기본적으로 우리는 단일 블레이드에서 두 개의 VM을 실행하고 있는데, 하나는 애플리케이션 서버이고 다른 하나는 애플리케이션에 대한 SSO 지원을 제공합니다. 애플리케이션 서버의 속도가 크게 느려지는 순간도 있고, 타사 SSO 애플리케이션이 곤경에 빠지는 순간도 있습니다.

사일로와 정치도 관련되어 있으므로 SSO 호스트나 실제 하드웨어 계층에 대한 가시성이 없습니다.

나의 현재 운영 가설은 SSO 애플리케이션이 이상 작동할 때 CPU를 너무 많이 차지하여 애플리케이션 서버가 로드를 따라잡을 만큼 충분한 실제 컴퓨팅 시간을 얻을 수 없다는 것입니다. 애플리케이션의 GC 로그를 분석했는데 눈에 띄는 한 가지 항목은 다음과 같습니다.

[Times: user=0.71 sys=1.36, real=1.47 secs]

이는 일반적으로 10개의 병렬 GC 작업자 스레드를 사용하며 user >> real >> sys이상한 시간 패턴의 원인 중 하나는 충분한 CPU를 확보할 수 없는 VM입니다. (우리는 교체하지 않으며 시스템은 모두 SSD 기반이므로 IO 대기는 문제가 되지 않습니다.)

이 시점에서 나는 이 이론을 증명하는 데 도움이 되는 데이터를 얻어야 하며, 내 Linux 생각에서는 맨 위의 1%만 확인하겠습니다. 인터넷 검색에서는 최신 버전의 Solaris에서도 동일한 작업을 수행할 수 있다고 말합니다. 내 문제는 우리가 최신 버전의 Solaris를 실행하고 있지 않다는 것입니다.

답변1

여기서 실제 문제는 성능 저하인 것 같습니다. 그리고 솔라리스 10 T1000/T2000 서버에서는 스틸타임이 의미가 없을 것 같습니다.

영역에서 실행 중인지 확인하려면 다음 /usr/bin/zonename명령을 사용하십시오. (Solaris 버전에 따라 위치가 다를 수 있습니다. , 및 도 확인하십시오 /bin. /sbin/) /usr/sbin이외 zonename의 항목이 반환 되면 global영역에서 실행 중인 것입니다.

어떤 이유로 인해 명령에 액세스할 수 없는 경우 영역에 있는지 확인하는 데 사용할 수 있는 zonename몇 가지 명령이 있습니다 . ps먼저 다음을 찾으세요 init.

ps -ef | grep init

initPID가 인 프로세스를 찾지 못하면 1영역에 있는 것입니다. zsched(IIRC) 도 찾아볼 수 있습니다 .

ps -ef | grep zsched

그것이 자신의 상위 프로세스(PID와 PPID가 모두 동일하고 보다 큼 1)인 하나의 프로세스를 반환하면 영역에서 실행되고 있는 것입니다.

영역에 있는 경우 속도가 느려지는 리소스 제한이 발생할 수 있습니다. 하지만 그럴 가능성은 없습니다.

무엇또 다른그래도 서버에서 실행 중입니까? 다른 구역도 포함됩니다. 저는 귀하가 설명하는 것과 유사한 Sun T 시리즈 서버에서 ZFS ARC와 대용량 메모리 페이지를 사용하는 응용 프로그램(예: Oracle 데이터베이스) 간의 상호 작용으로 인해 발생하는 정말 불쾌한 성능 문제를 보았습니다.

ZFS ARC는 4k 메모리 페이지를 사용하므로 메모리를 조각화합니다.모두서버의 메모리. 서버가 해당 상태가 되고 프로세스에 상당한 양의 대용량 메모리 페이지가 필요한 경우 커널은 많은 양의 메모리를 이동하는 데 필요한 작은 페이지 묶음을 큰 페이지로 통합해야 합니다. 그리고 이 모든 작업은 단일 스레드로 수행됩니다. 그리고 초기 T 시리즈 서버의 단일 스레드는느린서버는 네트워크를 통해 많은 연결을 처리하는 웹 서버나 데이터베이스 서버와 같이 대기 시간이 긴 수많은 스레드를 처리하도록 설계되었기 때문입니다.

따라서 커널은 작은 메모리 페이지를 큰 페이지로 통합하는 것만으로도 오랜 기간 동안 작업을 수행합니다.

그런 다음 ZFS ARC는 대규모 페이지 사용 프로세스가 완료되고 조각화된 후 페이지를 다시 가져옵니다.

나는 당신이 이와 똑같은 문제를 겪고 있다고 생각합니다.

알아 보려면 다음을 실행하십시오.

echo ::memstat | mdb -k

영역을 실행 중인 경우 전역 영역에서 루트로. 사용 가능한 메모리가 매우 부족하면 이 문제가 발생할 수 있습니다.

이를 확인하려면 전역 영역에서 루트로 다음 dTrace 스크립트를 다시 실행하여 커널이 항상 어디에서 시간을 소비하는지 확인하세요.

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

이를 파일(예: )에 복사하고 hot.d실행 파일( chmod 755 hot.d)로 설정한 다음 전역 영역에서 루트로 실행합니다.

./hot.d

속도가 느려지는 경우 실행하세요. 을 방출한 후 더 이상은 아니지만 10~20초 동안 실행한 다음 matched 1 probe으로 중단 합니다 CTRL-C. 그런 다음많은대부분은 신경 쓰지 않는 출력입니다. 그러나 마지막 스택 추적 출력은 샘플링된 가장 일반적인 출력이며 커널이 항상 어디에서 시간을 소비하는지 알려줍니다.

그러면 문제가 어디에 있는지 확실히 알 수 있습니다. 완전히 해결할 만큼 정확하지 않을 수도 있고 추가 조사가 필요할 수도 있지만 어디를 봐야 할지 알게 될 것입니다.

idle포함 된 스택 추적이 많이 보이면 wait사용자 공간 문제가 있는 것입니다. stack()위의 dTrace 스크립트를 로 바꿔서 ustack()사용자 스택을 가져오면 이를 식별할 수 있습니다 .

coalesce그리고 함수 이름에 많은 스택 추적이 표시된다면 커널은 대용량 메모리 페이지를 만드는 데 모든 시간을 소비하고 있는 것입니다. 이에 대한 해결 방법은 ZFS ARC 크기를 심각하게 제한하여 메모리를 확보하는 것입니다. 나는해야만했다슬개골성능 저하를 방지하기 위해 몇 대의 서버에서 ZFS ARC를 1GB 미만으로 줄였습니다.

관련 정보