높은 동시성 및 응답 속도 빠름은 성능 최적화의 두 가지 핵심 지표에 해당합니다. 처리량 및 대기 시간
사진 출처: www.ctq6.cn
애플리케이션 로드각도: 제품 단말기의 사용자 경험에 직접적인 영향을 미칩니다
시스템 리소스각도: 리소스 사용량, 포화도 등
성능 문제의 본질은 시스템 리소스가 병목 현상에 도달했지만 요청 처리가 더 많은 요청을 지원할 만큼 빠르지 않다는 것입니다. 성능 분석은 실제로 애플리케이션이나 시스템의 병목 현상을 찾아 이를 피하거나 완화하려고 노력하는 것입니다.
애플리케이션 및 시스템 성능을 평가하기 위한 지표 선택
애플리케이션 및 시스템에 대한 성능 목표 설정
성능 벤치마킹 수행
병목 현상을 찾기 위한 성능 분석
성능 모니터링 및 경고
다양한 성능 문제에 대해 다양한 성능 분석 도구를 선택하십시오. 다음은 일반적으로 사용되는 Linux 성능 도구와 해당 유형의 성능 문제를 분석한 것입니다.
사진 출처: www.ctq6.cn
"평균 부하"를 어떻게 이해해야 할까요?
평균 부하: 단위 시간당 시스템의 실행 가능 및 중단 불가능 상태에 있는 프로세스의 평균 수입니다. 활성 프로세스의 평균 수입니다. 우리가 전통적으로 이해한 것처럼 CPU 사용량과 직접적인 관련이 없습니다.
무정전 프로세스는 커널 상태에서 중요한 프로세스(예: 장치를 기다리는 일반적인 I/O 응답)에 있는 프로세스입니다. 무정전 상태는 실제로 프로세스 및 하드웨어 장치에 대한 시스템의 보호 메커니즘입니다.
합리적인 평균 부하란 무엇인가요? 실제 생산 환경에서 시스템의 평균 부하를 모니터링하고 과거 데이터를 기반으로 부하 변화 추세를 판단합니다. 부하 증가 추세가 뚜렷할 경우 적시에 분석 및 조사를 수행합니다. 물론 임계값을 설정할 수도 있습니다(예: 평균 부하가 CPU 수의 70%보다 높은 경우)
실제 작업에서는 평균 부하와 CPU 사용량의 개념을 혼동하는 경우가 많습니다.
CPU 사용량이 많으면 평균 부하가 증가합니다. 이때 두 가지 모두
I/O 집약적인 프로세스를 기다리고 있습니다. I/O도 평균 부하를 증가시킵니다. 이때 CPU 사용량이 반드시 높지는 않습니다.
CPU 스케줄링을 기다리는 프로세스가 많아지면 평균 부하가 증가합니다. 시간이 지나면 CPU 사용량도 상대적으로 높을 것입니다
평균 부하가 높을 때는 CPU 집약적인 프로세스로 인해 발생할 수도 있고, /O가 바쁘기 때문에 발생할 수도 있습니다. 특정 분석 중에 mpstat/pidstat 도구를 결합하여 로드 소스 분석을 지원할 수 있습니다
2 새 작업의 컨텍스트는 이러한 레지스터와 프로그램 카운터로 전송되고 마지막으로 프로그램 카운터가 가리키는 위치로 점프하여 새 작업을 실행합니다. 그중 저장된 컨텍스트는 시스템 커널에 저장되었다가 작업 일정이 변경될 때 다시 로드되어 원래 작업 상태가 영향을 받지 않도록 합니다. Linux 중국어 커뮤니티를 팔로우하세요작업 유형에 따라 CPU 컨텍스트 전환은 다음과 같이 나뉩니다.
프로세스 컨텍스트 스위칭
스레드 컨텍스트 스위칭
인터럽트 컨텍스트 스위칭
프로세스 컨텍스트 스위칭
리눅스 프로세스는 프로세스의 실행 공간을 커널 공간과 사용자 공간으로 나눈다. 권한 수준. 사용자 모드에서 커널 모드로의 전환은 시스템 호출을 통해 완료되어야 합니다.
시스템 호출 프로세스는 실제로 두 가지 CPU 컨텍스트 전환을 수행합니다.
CPU 레지스터의 사용자 모드 명령 위치가 먼저 저장되고, CPU 레지스터가 커널 모드 명령의 위치로 업데이트되고, 커널 모드로 점프하여 커널 작업을 실행합니다.
시스템 호출 후; 완료되면 CPU 레지스터는 원래 저장된 사용자 상태 데이터를 복원한 다음 사용자 공간으로 전환하여 계속 실행합니다.
시스템 호출 프로세스에는 가상 메모리와 같은 사용자 모드 리소스 프로세스가 포함되지 않으며 프로세스를 전환하지도 않습니다. 이는 전통적인 의미의 프로세스 컨텍스트 전환과는 다릅니다. 따라서 시스템 호출을 종종 특권 모드 스위치 라고 합니다.
프로세스는 커널에 의해 관리되고 예약되며 프로세스 컨텍스트 전환은 커널 모드에서만 발생할 수 있습니다. 따라서 시스템 호출과 비교하여 현재 프로세스의 커널 상태와 CPU 레지스터를 저장하기 전에 프로세스의 가상 메모리와 스택을 먼저 저장해야 합니다. 새로운 프로세스의 커널 상태를 로딩한 후에는 해당 프로세스의 가상 메모리와 사용자 스택을 새로 고쳐야 합니다.
프로세스는 CPU에서 실행되도록 예약된 경우에만 컨텍스트를 전환하면 됩니다. 다음과 같은 시나리오가 있습니다. CPU 시간 분할이 차례로 할당되고, 시스템 리소스가 부족하여 프로세스가 중단되고, 프로세스가 절전 기능을 통해 적극적으로 중단됩니다. 및 우선순위가 높은 프로세스 선점 시간 하드웨어 인터럽트가 발생하면 CPU의 프로세스가 일시 중지되고 대신 커널에서 인터럽트 서비스가 실행됩니다.
스레드 컨텍스트 전환
스레드 컨텍스트 전환은 두 가지 유형으로 나뉩니다.
전면 스레드와 후면 스레드는 동일한 프로세스에 속하며 전환 중에 가상 메모리 리소스는 변경되지 않습니다. 스레드의 개인 데이터, 레지스터 등만 전환하면 됩니다.
전면 스레드와 후면 스레드가 속합니다. 이는 프로세스 컨텍스트 전환과 동일합니다.
동일한 프로세스에서 스레드를 전환하면 리소스를 덜 소모하는데, 이는 멀티스레딩의 장점이기도 합니다.
인터럽트 컨텍스트 전환
인터럽트 컨텍스트 전환에는 프로세스의 사용자 모드가 포함되지 않으므로 인터럽트 컨텍스트에는 커널 모드 인터럽트 서비스 프로그램 실행에 필요한 상태만 포함됩니다(CPU 레지스터, 커널 스택, 하드웨어 인터럽트). 매개변수 등).
인터럽트 처리 우선순위가 프로세스보다 높으므로 인터럽트 컨텍스트 전환과 프로세스 컨텍스트 전환이 동시에 발생하지 않습니다
Linux는 멀티 태스킹 운영 체제로서 CPU 시간을 짧은 시간 조각으로 나누고 스케줄러를 통해 이를 각 작업에 차례로 할당합니다. CPU 시간을 유지하기 위해 Linux는 미리 정의된 비트 속도를 통해 시간 인터럽트를 트리거하고 글로벌 지피를 사용하여 부팅 이후 비트 수를 기록합니다. 이 값 + 1이 되면 시간 인터럽트가 발생합니다.
CPU 사용량 , 유휴 시간을 제외한 총 CPU 시간의 비율입니다. CPU 사용량은 /proc/stat의 데이터에서 계산할 수 있습니다. /proc/stat에서 부팅 후 비트 수의 누적 값은 부팅 후 평균 CPU 사용량으로 계산되기 때문에 일반적으로 별 의미가 없습니다. 일정 기간 간격으로 취한 두 값의 차이를 취하여 해당 기간 동안의 평균 CPU 사용량을 계산할 수 있습니다. 성능 분석 도구는 일정 기간 동안의 평균 CPU 사용량을 제공합니다. 간격 설정에 주의하세요.
CPU 사용량은 top이나 ps를 통해 볼 수 있습니다. 성능 이벤트 샘플링을 기반으로 하는 perf를 통해 프로세스의 CPU 문제를 분석할 수 있습니다. 시스템의 다양한 이벤트와 커널 성능을 분석할 수 있을 뿐만 아니라 특정 애플리케이션의 성능 문제를 분석하는 데에도 사용할 수 있습니다.
성능 최고 / 성능 기록 / 성능 보고서(-g는 호출 관계 샘플링을 켭니다)
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能
레이어별 분석 결과 근본 원인은 앱 내부의 직접 디스크 I/O입니다. 그런 다음 최적화를 위한 특정 코드 위치를 찾습니다.
좀비 프로세스
위의 최적화 이후 iowait는 크게 줄어들었지만 좀비 프로세스 수는 여전히 증가하고 있습니다. 먼저 좀비 프로세스의 상위 프로세스를 찾습니다. pstree -aps XXX를 사용하여 좀비 프로세스의 호출 트리를 인쇄하고 상위 프로세스가 앱 프로세스인지 확인합니다.
앱 코드를 확인하여 하위 프로세스의 끝이 올바르게 처리되었는지 확인하세요(wait()/waitpid() 호출 여부, SIGCHILD 신호 처리 함수 등록 여부 등).
iowait가 증가하면 먼저 dstat 및 pidstat와 같은 도구를 사용하여 디스크 I/O 문제가 있는지 확인한 다음 strace를 직접 사용할 수 없는 경우 어떤 프로세스가 I/O를 일으키는지 알아보세요. 프로세스 호출을 분석하려면 perf 도구를 사용하여 분석할 수 있습니다.
좀비 문제의 경우 pstree를 사용하여 상위 프로세스를 찾은 후 소스 코드를 보고 하위 프로세스 종료에 대한 처리 로직을 확인합니다.
CPU 성능 표시기
CPU 사용량
사용자 모드(사용자) 및 낮은 우선 순위 사용자 모드(nice)를 포함한 사용자 CPU 사용량이 너무 높으면 이를 나타냅니다. 애플리케이션이 상대적으로 사용 중입니다.
시스템 CPU 사용량, CPU가 커널 모드에서 실행되는 시간의 비율(인터럽트 제외) 높은 표시는 커널이 상대적으로 사용 중임을 나타냅니다.
CPU 사용량이 /O, iowait, A 높은 표시는 시스템과 하드웨어 장치 간의 I/O 상호 작용 시간이 상대적으로 길다는 것을 나타냅니다.
소프트/하드 인터럽트 CPU 사용량, 높은 표시는 많은 수의 인터럽트가 발생함을 나타냅니다.
CPU/게스트 CPU를 훔쳐 가상 머신이 점유한 CPU 비율을 나타냅니다.
평균 로드
이상적으로 평균 로드는 논리적 CPU 수와 동일합니다. CPU를 완전히 활용하면 시스템 부하가 더 커진다는 뜻입니다.
프로세스 컨텍스트 전환
자원을 확보할 수 없을 때의 자발적 전환과 시스템이 스케줄링을 강제할 때의 비자발적 전환을 포함합니다. 컨텍스트 전환 자체는 Linux의 정상적인 작동을 보장하는 핵심 기능입니다. 과도한 전환은 레지스터와 커널에서 원래 실행 중인 프로세스의 CPU 시간을 소비하게 됩니다. 가상 메모리 등의 데이터 저장 및 복원 측면에서는
CPU 캐시 적중률
CPU 캐시 재사용률이 높을수록 성능이 좋아지는데요. 그 중 싱글에서는 L1/L2가 많이 사용됩니다. 코어, L3는 멀티코어에 사용됩니다
성능 도구
평균 부하 사례
먼저 가동 시간을 사용하여 시스템 평균 부하를 확인합니다
부하가 증가했는지 판단한 후 mpstat, pidstat를 사용하여 확인합니다. 각각 각 프로세스의 CPU 및 CPU 사용량을 알아보세요. 또한, 공개 계정 Linux를 검색하고 백그라운드에서 "git books"라고 답하면 깜짝 선물 패키지를 얻을 수 있습니다.
컨텍스트 전환 사례
먼저 vmstat를 사용하여 시스템 컨텍스트 전환 및 인터럽트 시간을 확인합니다
그런 다음 pidstat를 사용하여 프로세스의 자발적 및 비자발적 컨텍스트 전환을 관찰합니다
마지막으로 pidstat 사용 스레드 컨텍스트 전환 상황 관찰
프로세스 CPU 사용량이 높은 경우
먼저 top을 사용하여 시스템과 프로세스의 CPU 사용량을 확인하고 프로세스를 찾습니다.
그런 다음 perf top을 사용하여 관찰합니다. 프로세스 호출 체인을 확인하고 특정 프로세스 Function
시스템 CPU 사용량이 높은 사례
먼저 top을 사용하여 시스템 및 프로세스의 CPU 사용량을 확인합니다. Top/pidstat는 높은 프로세스를 찾을 수 없습니다. CPU 사용량
최고 출력 재검사
CPU 사용량은 낮지만 실행 중 상태인 프로세스로 시작
성능 기록/보고서에서 단기 프로세스 원인 발견(execsnoop 도구)
무정전 및 좀비 프로세스 사례
먼저 top을 사용하여 iowait의 증가를 관찰하고 다수의 무정전 및 좀비 프로세스
strace가 프로세스 시스템 호출을 추적할 수 없음
perf는 콜 체인을 분석한 결과 근본 원인이 디스크 직접 I/O에서 비롯된 것을 발견했습니다.
소프트 인터럽트 사례
top은 시스템 소프트 인터럽트 CPU 사용량이 높은 것을 관찰했습니다
보기/ proc/softirqs를 실행하여 변경률이 빠른 것을 확인했습니다. 여러 개의 소프트 인터럽트
sar 명령이 네트워크 패킷 문제인 것으로 확인되었습니다
tcpdump를 사용하여 네트워크 프레임의 유형과 소스를 알아내고 SYN의 원인을 확인합니다. FLOOD 공격
다양한 성능 지표를 기반으로 적절한 도구를 찾으세요. 시스템에 이미 설치된 도구만 최대한 활용하십시오. 따라서 도구가 제공할 수 있는 지표 분석은 일부 주류에 대한 이해가 필요합니다.
출처: www.ctq6.cn
먼저 top/vmstat/pidstat와 같은 더 많은 표시기를 지원하는 몇 가지 도구를 실행해 보면 어떤 유형의 성능 문제인지 확인할 수 있습니다. process 그런 다음 추가 분석을 위해 호출 상황을 분석하기 위해 strace/perf를 사용합니다. 소프트 인터럽트로 인해 발생한 경우 /proc/softirqs
사진 출처: www.ctq6.cn
CPU 최적화
애플리케이션 최적화
컴파일러 최적화: 컴파일 단계에서 gcc -O2
알고리즘 최적화와 같은 최적화 옵션을 활성화합니다.
비동기 처리: 프로그램이 리소스를 기다리는 동안 차단되는 것을 방지하여 프로그램의 동시 처리를 개선합니다. (폴링을 이벤트 알림으로 대체)
멀티 프로세스 대신 멀티스레딩: 컨텍스트 전환 비용 절감
캐시 활용: 프로그램 처리 속도 향상
시스템 최적화
CPU 바인딩: 프로세스를 1개/다중 CPU에 바인딩하여 CPU 캐시 적중률을 높이고 CPU 스케줄링으로 인한 컨텍스트 전환을 줄입니다.
CPU 독점: 프로세스를 할당하는 CPU 선호도 메커니즘
우선 순위 수준 조정: nice를 사용하여 비핵심 응용 프로그램의 우선 순위를 적절하게 낮춥니다
프로세스에 대한 리소스 표시 설정: cgroups는 특정 응용 프로그램 자체 문제로 인해 시스템 리소스가 고갈되는 것을 방지하기 위해 사용 제한을 설정합니다
NUMA 최적화: 최대한 CPU 접근 가능 로컬 메모리
인터럽트 로드 밸런싱: irpbalance, 인터럽트 처리 프로세스를 각 CPU에 자동으로 로드 밸런싱
TPS, QPS, 시스템 처리량의 차이와 이해
QPS (TPS)
동시 횟수
응답 시간
QPS(TPS)=동시 횟수/평균 응답 시간
사용자 요청 서버
내부 서버 처리
서버가 클라이언트로 돌아갑니다
QPS는 TPS와 유사하지만 페이지 방문이 TPS를 형성하지만 페이지 요청에는 서버에 대한 여러 요청이 포함될 수 있으며 이는 여러 QPS로 계산될 수 있습니다
QPS(초당 쿼리 수) 초당 쿼리 수, 서버가 초당 응답할 수 있는 쿼리 수
TPS(초당 트랜잭션 수), 소프트웨어 테스트 결과.
몇 가지 중요한 매개변수를 포함한 시스템 처리량:
3Memory
Linux 메모리 작동 방식
메모리 매핑
메모리 매핑
액세스 메모리(DRAM)만 커널은 물리적 메모리에 직접 액세스할 수 있습니다. Linux 커널은 각 프로세스에 대해 독립적인 가상 주소 공간을 제공하며 이 주소 공간은 연속적입니다. 이런 방식으로 프로세스는 메모리(가상 메모리)에 쉽게 접근할 수 있습니다. 🎜🎜가상 주소 공간의 내부는 커널 공간과 사용자 공간의 두 부분으로 나누어집니다. 서로 다른 단어 길이를 가진 프로세서의 주소 공간 범위가 다릅니다. 32비트 시스템 커널 공간은 1G를 차지하고 사용자 공간은 3G를 차지합니다. 64비트 시스템의 커널 공간과 사용자 공간은 모두 128T로 각각 메모리 공간의 가장 높은 부분과 가장 낮은 부분을 차지하고 중간 부분은 정의되지 않습니다. 🎜
모든 가상 메모리에 실제 메모리가 할당되는 것은 아니며 실제 사용되는 메모리에만 할당됩니다. 할당된 물리적 메모리는 메모리 매핑을 통해 관리됩니다. 메모리 매핑을 완성하기 위해 커널은 각 프로세스별로 페이지 테이블을 유지하여 가상 주소와 물리적 주소 간의 매핑 관계를 기록합니다. 페이지 테이블은 실제로 CPU의 메모리 관리부인 MMU에 저장되며, 프로세서는 하드웨어를 통해 접근할 메모리를 직접 찾아낼 수 있다.
프로세스가 액세스한 가상 주소를 페이지 테이블에서 찾을 수 없으면 시스템은 페이지 폴트 예외를 생성하고 커널 공간에 들어가 물리적 메모리를 할당한 다음 프로세스 페이지 테이블을 업데이트한 다음 사용자 공간으로 돌아가 재개합니다. 프로세스의 작동.
MMU는 페이지 크기가 4KB인 페이지 단위로 메모리를 관리합니다. 너무 많은 페이지 테이블 항목 문제를 해결하기 위해 Linux는 다단계 페이지 테이블 및 HugePage 메커니즘을 제공합니다.
가상 메모리 공간 분배
사용자 공간 메모리는 낮은 것부터 높은 것까지 다섯 가지 메모리 세그먼트로 나뉩니다.
읽기 전용 세그먼트 코드 및 상수 등
데이터 세그먼트 전역 변수 등
Heap 동적으로 할당된 메모리, 낮은 주소부터 시작하여 위쪽으로 증가
파일 매핑 업데이트 라이브러리, 공유 메모리 등은 높은 주소에서 시작하여 아래쪽으로 증가합니다.
Stack 지역 변수 및 함수 호출 컨텍스트 등을 포함합니다. 스택 크기는 고정되어 있습니다. 일반적으로 8MB
메모리 할당 및 재활용
allocation
malloc은 두 가지 방식으로 시스템 호출에 해당합니다.
brk() 작은 메모리 블록(<128K)의 경우 힙의 최상위 위치를 이동하여 할당합니다. 메모리는 해제된 후 즉시 반환되지 않고 캐시됩니다.
**mmap()** 큰 메모리 블록(>128K)의 경우 메모리 매핑을 사용하여 직접 할당합니다. 즉, 파일 매핑 세그먼트에서 사용 가능한 메모리 할당을 찾습니다.
전자의 캐시는 페이지 누락 예외 발생을 줄이고 메모리 액세스 효율성을 향상시킬 수 있습니다. 그러나 메모리가 시스템에 반환되지 않기 때문에 메모리 할당/해제를 자주 수행하면 메모리가 사용 중일 때 메모리 조각화가 발생합니다.
후자는 해제되면 시스템으로 직접 반환되므로 mmap이 발생할 때마다 페이지 폴트 예외가 발생합니다. 메모리 작업이 바쁜 경우 메모리를 자주 할당하면 페이지 오류 예외가 많이 발생하여 커널 관리 부담이 증가합니다.
위의 두 호출은 실제로 메모리를 할당하지 않습니다. 이 메모리는 처음 액세스할 때 페이지 오류 예외를 통해서만 커널에 들어가고
시스템에 맡기고, 더티 페이지는 디스크에 동기화합니다. 커널 스레드 pdflush가 책임집니다. 애플리케이션에 의해 수정되었으며 당분간 디스크에 기록되지 않은 이러한 더티 페이지
데이터(더티 페이지)를 새로 고치려면 먼저 디스크에 기록한 다음 메모리를 기록해야 합니다. 해제 가능
메모리 매핑으로 얻은 파일 매핑 페이지를 해제하여 다음에 파일에 액세스할 때 파일에서 다시 읽을 수도 있습니다.
프로그램에서 자동으로 할당한 힙 메모리의 경우 메모리 관리의 익명 페이지입니다. 이 메모리는 직접 해제할 수 없지만 Linux에서는 Swap 메커니즘을 제공합니다. 자주 액세스하지 않는 메모리는 디스크에 기록하여 메모리를 확보하고, 다음과 같은 경우 디스크에서 메모리를 읽을 수 있습니다. 다시 액세스했습니다.
스왑 원칙
스왑의 핵심은 스왑 인 및 스왑 아웃의 두 가지 프로세스를 포함하여 디스크 공간이나 로컬 파일을 메모리로 사용하는 것입니다.
스왑 아웃: 프로세스가 사용하지 않는 메모리 데이터를 일시적으로 디스크에 저장하고 메모리를 해제합니다.
스왑 인: 프로세스가 다시 메모리에 액세스하면 디스크에서 메모리로 읽어옵니다.
Linux는 메모리 리소스가 부족한지 어떻게 측정합니까?
직접 메모리 회수 새로운 대용량 블록 메모리 할당을 요청했지만 남은 메모리가 부족합니다. 이때 시스템은 메모리의 일부를 회수합니다.
kswapd0 커널 스레드는 정기적으로 메모리를 회수합니다. 메모리 사용량을 측정하기 위해 페이지_분, 페이지_로우, 페이지_하이의 세 가지 임계값을 정의하고 이를 기반으로 메모리 재활용 작업을 수행합니다.
남은 메모리 < 페이지_min, 프로세스에 사용 가능한 메모리가 모두 소진되었습니다. 커널만 메모리를 할당할 수 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
