Linux 서버의 성능 매개변수

Linux 운영체제 기반의 서버가 실행되면 다양한 매개변수 정보도 표시됩니다. 일반적으로 운영 및 유지 관리 담당자와 시스템 관리자는 이 데이터에 매우 민감하지만 이러한 매개변수는 개발자에게도 매우 중요합니다. 특히 프로그램이 제대로 작동하지 않는 경우 이러한 단서는 문제를 빠르게 찾고 추적하는 데 도움이 될 수 있습니다.

다음은 시스템의 관련 매개변수를 볼 수 있는 몇 가지 간단한 도구입니다. 물론 많은 도구가 /proc 및 /sys에서 데이터를 분석하고 처리하여 작동하며 보다 상세하고 전문적인 성능 모니터링 및 조정에는 더 많은 전문 도구가 필요할 수 있습니다. (perf, systemtap 등) 및 기술을 사용하여 이를 완성할 수 있습니다. 결국 시스템 성능 모니터링 자체는 대학 과목이다.

1. CPU 및 메모리 카테고리

1.1 top

➜ ~ top

첫 번째 줄 뒤의 세 값은 이전 1에서 시스템의 평균 부하이고, 5일, 15일에는 시스템 부하가 상승, 안정, 하락 추세를 보이는 것을 알 수 있습니다. 이 값이 CPU 실행 단위 수를 초과하면 CPU 성능이 포화되어 병목 현상이 발생했음을 의미합니다. .

두 번째 줄은 시스템의 작업 상태 정보를 계산합니다. 말할 필요도 없이, 실행에는 CPU에서 실행되는 작업과 실행되도록 예약된 작업이 포함됩니다. 휴면은 일반적으로 이벤트(예: IO 작업)가 완료되기를 기다리는 작업이며 하위 구분에는 중단 가능 및 중단 불가능 유형이 포함될 수 있습니다. 중지됨은 일시 중지된 것입니다. 작업은 일반적으로 SIGSTOP을 보내거나 포그라운드 작업에서 Ctrl-Z를 눌러 좀비 작업을 일시 중지합니다. 프로세스가 종료되면 리소스가 자동으로 재활용되지만 종료 작업이 포함된 작업 설명자는 이러한 종류의 프로세스는 부모 프로세스가 일찍 종료되었거나 대기를 호출하지 않았기 때문에 존재하지 않는 상태로 표시됩니다. 이러한 종류의 프로세스가 발생하면 프로그램 설계에 특별한 주의가 필요합니다. 잘못된. CPU 사용량의 세 번째 줄은 유형에 따라 다음과 같은 상황이 있습니다.

　●　(us) 사용자: 낮은 nice 값(높은 우선순위) 사용자 모드(nice

●　(sy) 시스템: 커널 상태에서 CPU가 소비하는 시간 및 운영 체제 시스템 호출을 통해 시작됩니다. 사용자 상태는 특정 서비스를 실행하기 위해 커널 상태에 속합니다. 일반적으로 값은 더 작아지지만 서버에서 수행되는 IO가 더 집중되면 값이 더 커집니다

　●　(ni) nice: CPU가 높은 nice 값에 있습니다(낮은 우선순위). 낮은 우선순위(nice>0)로 실행되는 사용자 모드에서 소요된 시간입니다. 기본적으로 프로그램의 nice 값이 renice 또는 setpriority()를 통해 수동으로 수정되지 않는 한 새로 시작된 프로세스 nice=0은 여기에 포함되지 않습니다.

　●　(id) 유휴: CPU가 유휴 상태입니다(커널 유휴 핸들러 실행 중). ) 소요 시간

　●　(wa) iowait: IO 완료를 기다리는 데 소요된 시간

　●　(hi) irq: 시스템 처리 하드웨어 인터럽트에 소요된 시간

　●　(si) softirq: 시스템 처리 소프트 인터럽트에 소요된 시간 , 소프트 인터럽트는 Softirq, 태스크릿(실제로 전자의 특별한 경우) 및 작업 큐로 구분된다는 점을 기억하십시오. 결국, 작업 큐의 실행은 더 이상 인터럽트 컨텍스트가 아닙니다.

　●　(st)훔치기: 가상 머신의 경우에만 의미가 있습니다. 가상 머신 아래의 CPU도 물리적 CPU를 공유하므로 이 기간은 가상 머신이 하이퍼바이저의 예약을 기다리는 시간을 나타냅니다. 이는 또한 이 기간 동안 하이퍼바이저가 실행을 위해 CPU를 다른 CPU에 예약한다는 의미입니다. 이 값은 내 KVM VPS 시스템에서 0이 아니지만 0.1 정도입니다. VPS가 초과 예약되었는지 확인하는 데 사용할 수 있습니까?

높은 CPU 사용량은 종종 서버 CPU 사용량이 너무 높을 때 해당하는 문제 해결 아이디어를 의미합니다.

1 사용자 사용량이 너무 높으면 일반적으로 프로세스가 큰 부분을 차지합니다. 이때, 프로그램이 비정상이라고 의심되면 성능 및 기타 아이디어를 사용하여 추가 조사를 위해 프로그램을 쉽게 찾을 수 있습니다. 2. 시스템 점유율이 너무 높은 경우 가끔 IO 작업(터미널 IO 포함)이 많은 경우 파일 서버, 데이터베이스 서버 및 기타 유형에서 CPU의 이 부분의 점유율이 높아질 수 있습니다. 그렇지 않으면(예: >20%) 일부 부품에 커널 및 드라이버 모듈에 문제가 있을 가능성이 높습니다.

3. 좋은 점유율이 너무 높으면 이는 일반적으로 의도적인 동작입니다. 프로세스 개시자는 일부 프로세스가 더 높은 CPU를 점유한다는 것을 알고 있으므로 다른 프로세스의 CPU 사용량 요청이 넘치지 않도록 적절한 값을 설정합니다.

4. iowait 점유율이 너무 높으면 일반적으로 일부 프로그램의 IO 작업 효율성이 매우 낮거나 IO 해당 장치의 성능이 너무 낮아 읽기 및 쓰기 작업을 완료하는 데 오랜 시간이 걸린다는 의미입니다. ;

5.irq/softirq 점유율이 너무 높으면 일부 주변 장치에 문제가 있어 irq 요청이 많을 가능성이 높습니다. 이때 /proc/interrupts 파일을 확인하세요.

6. 도용률이 너무 높을 때, 가격이 높을 때, 부도덕한 제조업체의 가상 머신이 과매도될 수 있습니다!

네 번째와 다섯 번째 줄은 물리적 메모리와 가상 메모리(스왑 파티션)의 정보입니다. 총 = 사용 가능 + 사용됨 + 버프/캐시 이제 버퍼와 캐시된 Mem 정보는 합산되지만 버퍼와 캐시된 Mem은

Mem입니다. 관계의 많은 측면이 명확하게 명시되어 있지 않습니다. 실제로 데이터를 비교해 보면 이 두 값은 /proc/meminfo의 Buffers 및 Cached 필드입니다. Buffers는 원시 디스크용 블록 캐시로, 주로 파일 시스템의 메타데이터(슈퍼 블록 정보 등)를 캐싱합니다. 등) 원시 블록 형태로, 이 값은 일반적으로 상대적으로 작습니다(약 20M). 캐시됨은 파일 액세스 효율성을 높이기 위해 특정 파일을 읽고 캐시하는 데 사용된다고 할 수 있습니다. 파일 시스템.

그리고 avail Mem은 새로 열린 프로그램에 스왑 없이 얼마나 많은 메모리 공간을 제공할 수 있는지 나타내는 데 사용되는 새로운 매개변수 값입니다. 이는 대략 free + buff/cached와 동일하며, 이는 또한 위의 설명인 free를 확인시켜 줍니다. + 버퍼 + 캐시된 Mem은 실제 사용 가능한 물리적 메모리입니다. 게다가 스왑 파티션을 사용하는 것이 반드시 나쁜 것은 아니므로 스왑 파티션 사용은 심각한 매개변수는 아니지만 빈번한 스왑 인/아웃은 좋은 것이 아닙니다. 이러한 상황은 주의가 필요하며 일반적으로 물리적 메모리가 부족함을 나타냅니다.

마지막은 각 프로그램의 리소스 사용량 목록으로, CPU 사용량은 모든 CPU 코어 사용량의 합입니다. 일반적으로 top이 실행될 때 프로그램 자체는 많은 수의 /proc 작업을 읽으므로 기본적으로 top 프로그램 자체가 가장 좋습니다.

top 매우 강력하기는 하지만 일반적으로 콘솔에서 시스템 부하 정보를 실시간으로 모니터링하는 데 사용됩니다. 동시에 장기간(일 또는 수개월) 동안 시스템 부하 정보를 모니터링하는 데는 적합하지 않습니다. 프로세스도 누락되며 통계 정보를 제공할 수 없습니다.

1.2 vmstat

vmstat는 top 외에 일반적으로 사용되는 또 다른 시스템 감지 도구입니다. 아래 스크린샷은 -j4로 Boost를 컴파일할 때의 시스템 로드입니다.

r은 실행 가능한 프로세스 수를 나타내며 데이터는 대략적으로 일치합니다. b는 중단할 수 없는 휴면 프로세스 수를 나타냅니다. swpd는 사용된 가상 메모리 양을 나타내며 이는 top-Swap 값과 동일합니다. -used, 매뉴얼에는 일반적으로 버퍼 수가 캐시된 Mem보다 훨씬 적다고 나와 있습니다. 버퍼는 일반적으로 20M 정도입니다. io 도메인의 bi 및 bo는 초당 디스크로 수신되고 전송되는 블록 수를 나타냅니다. 초(블록/초), 시스템 도메인 in은 초당 시스템 인터럽트 수(클록 인터럽트 포함)를 나타내고, cs는 프로세스 전환으로 인한 컨텍스트 전환 수를 나타냅니다.

그러고보니 리눅스 커널을 컴파일할 때 -j 매개변수가 CPU Core인지 CPU Core+1인지 고민하는 분들이 많았던 것 같은데요? vmstat 모니터링을 켜는 동안 위의 -j 매개변수 값을 수정하여 Boost 및 Linux 커널을 컴파일하면 기본적으로 두 경우 모두 컨텍스트 스위치가 변경되지 않았으며 -j 값을 크게 증가시킨 후에야 컨텍스트 스위치가 크게 증가하는 것을 발견했습니다. 아직 특정 컴파일 시간을 테스트하지는 않았지만 이 매개변수에 너무 집착하는 것은 불필요한 것 같습니다. 정보에 따르면 시스템 시작 또는 벤치마크 상태가 아닌 경우 매개변수 컨텍스트 스위치>100000을 사용하면 프로그램에 문제가 있을 수 있습니다.

1.3 pidstat

프로세스에 대한 포괄적이고 상세한 추적을 수행하려는 경우 pidstat보다 더 적합한 것은 없습니다. 스택 공간, 페이지 누락 조건, 능동 및 수동 전환 및 기타 정보를 한눈에 볼 수 있습니다. 이 명령의 가장 유용한 매개변수는 프로세스의 각 스레드에 대한 자세한 정보를 나열할 수 있는 -t입니다.

-r: 페이지 오류 및 메모리 사용량을 표시합니다. 페이지 오류는 프로그램이 가상 메모리 공간에 매핑되어 있지만 아직 실제 메모리에 로드되지 않은 페이지에 액세스해야 하는 경우입니다.

minflt/s는 액세스해야 하는 물리적 페이지가 어떤 이유로(예: 공유 페이지, 캐시 메커니즘 등) 물리적 메모리에 이미 존재하지만 페이지 테이블에서 참조되지 않는 경우를 의미합니다. 현재 프로세스에서 MMU는 해당 항목만 설정하면 됩니다. 비용은 상당히 적습니다.

majflt/s는 현재 사용 가능한 물리적 메모리에 무료 물리적 페이지를 적용해야 합니다. 사용 가능한 여유 페이지가 없습니다. 다른 물리적 페이지를 스왑 공간으로 전환하여 여유 물리적 페이지를 해제한 다음 외부에서 물리적 페이지로 데이터를 로드하고 해당 항목을 설정합니다. 이 비용은 상당히 높으며 여러 가지가 있습니다. 이전

-s와 데이터 수준의 차이점: StkSize가 스레드용으로 예약한 스택 공간과 StkRef가 실제로 사용하는 스택 공간을 포함한 스택 사용량입니다. ulimit -s를 사용하여 CentOS 6.x의 기본 스택 공간이 10240K이고 CentOS 7.x 및 Ubuntu 시리즈의 기본 스택 공간 크기가 8196K인지 확인하세요

-u: CPU 사용량, 매개변수는 이전과 유사합니다.

-w: 스레드 컨텍스트 스위치 수. 리소스 대기 및 기타 요인으로 인해 발생하는 cswch/s 활성 전환으로도 세분화됩니다. nvcswch/s 스레드 CPU 시간으로 인한 패시브 스위칭에 대한 통계

ps가 매번 프로그램의 pid를 가져온 다음 pidstat를 조작하는 것은 매우 번거로울 것이므로 이 킬러 -C는 특정 문자열을 지정할 수 있으며, 명령에 이 문자열이 포함되어 있으면 프로그램 정보가 인쇄되고 계산됩니다. -l은 전체 프로그램 이름과 매개변수를 표시할 수 있습니다. ➜ ~ pidstat -w -t -C “ailaw” -l

단일, 특히 다중 스레드 작업 때로는 pidstat가 일반적으로 사용되는 ps보다 낫습니다!

1.4 기타

단일 CPU를 별도로 모니터링해야 하는 경우 htop 외에도 mpstat를 사용하여 SMP 프로세서의 각 Core의 작업 부하가 분산되어 있는지, 일부 핫스팟 스레드가 Core를 점유하는지 확인할 수도 있습니다. . ➜ ~ mpstat -P ALL 1

특정 프로세스가 차지하는 리소스를 직접 모니터링하려면 top -u taozj를 사용하여 다른 사용자 독립적인 프로세스를 필터링하거나 다음 방법을 사용하여 선택할 수 있습니다. ps 명령을 사용자 정의할 수 있습니다. 인쇄해야 하는 항목 정보:

while:; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd' done

; 상속 관계를 명확히 하기 위해 다음이 일반적으로 사용됩니다. 매개 변수를 사용하여 프로세스 트리 구조를 표시할 수 있으며 표시 효과는 pstree

➜ ~ ps axjf

보다 훨씬 상세하고 아름답습니다. 2. 디스크 IO 클래스

iotop은 각 프로세스 및 스레드의 실시간 디스크 읽기 속도를 직관적으로 표시할 수 있습니다. lsof는 일반 파일(사용자)의 열기 정보를 표시할 수 있을 뿐만 아니라 /dev/와 같은 장치 파일의 열기 정보도 조작할 수 있습니다. 예를 들어, 파티션을 마운트 해제할 수 없는 경우 lsof를 사용하여 디스크의 파티션 사용 상태를 확인할 수 있으며, +fg 매개변수를 추가하면 파일 열기 플래그 표시도 추가로 표시할 수 있습니다.

2.1 iostat

➜ ~ iostat -xz 1

실제로 iostat -xz 1을 사용하든 sar -d 1을 사용하든 디스크에 대한 중요한 매개변수는 다음과 같습니다.

avgqu-s: I/O 요청 대기 중 장치로 전송됨 단일 디스크에 대한 대기열의 평균 길이(값 > 1이 장치 포화를 나타내는 경우, 다중 디스크 어레이가 있는 논리 디스크 제외)

await(r_await, w_await): 각 장치 I/O에 대한 평균 대기 시간 요청 작업(ms)(요청이 대기열에 대기하고 처리되는 시간의 합 포함)

svctm: svctm이 장치에 전송된 I/O 요청의 평균 서비스 시간(ms)입니다. wait, 이는 I/O 대기가 거의 없음을 의미합니다. 디스크 성능이 매우 좋습니다. 그렇지 않으면 디스크 큐 대기 시간이 길어지고 디스크 응답이 좋지 않습니다.

%util: 장치 사용량, I 비율을 나타냅니다. /O 초당 작업 시간, %util>60%일 때 단일 디스크 성능은 감소하고(대기 증가에 반영), 100%에 가까울 때 장치는 포화 상태가 됩니다. 단, 여러 디스크가 있는 논리 디스크는 제외됩니다.

또한 모니터링되는 디스크 성능은 상대적으로 낮지만 애플리케이션의 응답에 반드시 영향을 미치는 것은 아닙니다. 커널은 일반적으로 성능 향상을 위해 I/O 비동기 기술과 읽기 및 쓰기 캐싱 기술을 사용하지만 이는 제한적입니다. 위의 물리적 메모리 제한으로 인해.

위 매개변수는 네트워크 파일 시스템에도 유용합니다.

3. 네트워크 카테고리

서버에 있어서 네트워크 성능의 중요성은 자명합니다. iptraf 도구는 네트워크 카드의 전송 및 수신 속도 정보를 직관적으로 표시할 수 있어 비교적 간단하고 편리합니다. sar -n DEV 1 볼륨 정보를 통해서도 얻을 수 있으며, 네트워크 카드에는 100M 네트워크 카드, 기가비트 네트워크 카드 등 최대 속도 정보가 기본으로 탑재되어 있어 장치의 활용도를 쉽게 확인할 수 있습니다.

일반적으로 네트워크 카드의 전송 속도는 네트워크 개발에서 가장 중요한 관심사가 아니라 특정 UDP 및 TCP 연결의 패킷 손실률, 재전송 속도, 네트워크 지연 및 기타 정보입니다.

3.1 netstat

➜ ~ netstat -s

시스템 시작 이후 각 프로토콜의 전체 데이터 정보를 표시합니다. 매개변수 정보는 상대적으로 풍부하고 유용하지만, 두 실행 간의 차이를 사용하여 현재 시스템의 네트워크 상태 정보를 얻거나 시계를 사용하여 수치 변화 추세를 시각화할 때까지는 누적 값을 얻을 수 없습니다. 따라서 netstat는 일반적으로 포트 및 연결 정보를 검색하는 데 사용됩니다.

netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)

– 타이머는 도메인 이름 역방향 쿼리를 취소하고 표시 속도를 높일 수 있습니다. 더 일반적으로 사용되는 것은

➜ ~ netstat -antp #모든 TCP 연결 나열입니다.

➜ ~ netstat -nltp # 모든 로컬 TCP 수신 소켓을 나열하고 -a 매개변수를 추가하지 마세요.

3.2 sar

sar 이 도구는 너무 강력하여 CPU, 디스크 및 페이지 교환을 포함한 모든 것을 제어할 수 있습니다. 여기서는 주로 네트워크 활동을 분석하기 위해 네트워크가 NFS, IP, ICMP, SOCK 등과 같은 다양한 수준에서 다양한 프로토콜의 데이터 정보를 분류하지만 TCP 및 UDP에만 관심이 있습니다. 일반적인 상황에서 세그먼트 및 데이터그램의 전송 및 수신 상태를 표시하는 것 외에도 다음 명령에는

TCP ➜ ~ sudo sar -n TCP,ETCP 1

도 포함됩니다.

active/s: connect()를 통해 로컬로 시작된 TCP 연결, TCP 상태가 CLOSED -> SYN-SENT에서 변경됨

passive/s: accept()를 통해 원격으로 시작된 TCP 연결, TCP 상태 LISTEN에서 -> SYN-RCVD

retrans/s(tcpRetransSegs): 초당 TCP 재전송 횟수. 일반적으로 네트워크 품질이 좋지 않거나 서버에 과부하가 걸려 패킷이 손실되는 경우 TCP 확인 재전송 메커니즘에 따라 발생합니다. . 재전송 작업

isegerr/s(tcpInErrs): 매초마다 오류 패킷 수신(예: 체크섬 실패)

UDP ➜ ~ sudo sar -n UDP 1

noport/s(udpNoPorts): 매초 수신 데이터그램 수 수신되었으나 지정된 대상 포트에 응용 프로그램이 없습니다

idgmerr/s(udpInErrors): 수신되었으나 위의 이유 외에 기계에서 전달할 수 없는 데이터그램 수

물론 이러한 데이터는 어느 정도, 이는 네트워크 안정성을 설명할 수 있지만 특정 비즈니스 수요 시나리오와 결합될 때만 의미가 있습니다.

3.3 tcpdump

tcpdump는 좋은 것이라고 해야 합니다. 로컬에서 디버깅할 때 Wireshark를 사용하는 것을 좋아한다는 것은 모두 알고 있지만 온라인 서버에 문제가 있으면 어떻게 해야 할까요?

부록의 참고 자료는 환경을 복원하고 tcpdump를 사용하여 패킷을 캡처하는 방법을 제공합니다. 문제가 다시 발생하면(예: 로그 표시 또는 특정 상태 표시) 패킷 캡처가 종료될 수 있으며 tcpdump 자체에는 다음이 있습니다. C/-W 매개변수는 캡처된 패킷 저장 파일의 크기를 제한할 수 있습니다. 이 제한에 도달하면 저장된 패킷 데이터가 자동으로 회전되므로 캡처된 패킷의 전체 수를 제어할 수 있습니다. 그 후에는 데이터 패킷을 라인에서 꺼내서 Wireshark를 사용하여 원하는 대로 볼 수 있습니다. tcpdump에는 GUI 인터페이스가 없지만 패킷 캡처 기능이 전혀 약하지 않습니다. 네트워크 카드, 호스트, 포트, 프로토콜 등과 같은 다양한 필터링 매개변수를 지정할 수 있습니다. 캡처된 패킷은 완전하고 타임스탬프가 있으므로 패킷은 온라인 프로그램 분석도 그만큼 간단할 수 있다.

다음은 Chrome이 시작될 때 자동으로 웹 서버에 대한 3개의 연결 설정을 시작하는 것을 볼 수 있습니다. 여기에서는 dst 포트 매개변수가 제한되어 있으므로 서버의 응답 패킷이 필터링됩니다. SYNC와 ACK를 사용하여 열면 연결 프로세스가 여전히 매우 명확해집니다. tcpdump를 사용하는 경우 캡처 필터 조건을 최대한 구성해야 하며, 한편으로는 후속 분석을 용이하게 하는 반면, tcpdump를 활성화한 후에는 네트워크 카드와 시스템의 성능에 영향을 미칩니다. 이는 결국 온라인 서비스의 성능에 영향을 미칩니다.

더 많은 Linux 기사를 보려면 Linux Tutorial 칼럼을 방문하여 알아보세요!

위 내용은 Linux 서버의 성능 매개변수의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!