서버 속도가 느려지고 있지만 맨 위 프로세스가 100% 차단된 것을 항상 보여주는 것은 아닙니다. vmstat몇 초 만에 작업이 프로세서, 디스크 또는 메모리 중 무엇을 기다리고 있는지 확인할 수 있습니다. 물론 첫 번째 줄만 보고 섣부른 결론을 내리지 않는다는 전제하에 말입니다.
, 그리고 프로세스들을 확인해야 합니다. 이것이 바로 진정한 메모리 부족 현상과 CPU 부하 또는 제대로 응답하지 않는 스토리지 문제를 구분하는 유일한 방법입니다.
여러 샘플에 대해 vmstat을 실행합니다.
vmstat 보통 패키지에 포함됩니다 소품 또는 procps-ng먼저 1초마다 한 줄씩, 총 6줄을 읽으세요.
vmstat 1 6 -w 값이 읽기 어려워지면 열 너비를 넓힙니다.
vmstat -w 1 6두 번째 터미널도 열어 두세요. 읽기를 시작하고, 속도 저하 현상을 재현한 다음, 동시에 변경되는 열을 기록하세요. 저장 또는 컴파일 작업 중 발생하는 단일 급증은 몇 분 동안 높은 상태를 유지하는 대기열만큼 큰 영향을 미치지 않습니다.
r, b, CPU 열을 함께 읽으세요.
그룹에서는 , 아르 자형 이는 실행 중이거나 프로세서 시간을 기다리는 실행 가능한 작업의 수를 나타냅니다. 이 값을 논리 프로세서 수와 비교하십시오.
nproc
가동 시간만약에 아르 자형 사용 가능한 CPU 수보다 훨씬 높은 수준을 유지하고 있으며 우리를 또는 싸이 수치가 높게 나온다면, 해당 기기의 프로세서 시간이 부족한 것일 가능성이 큽니다. 이는 사용자 공간에서 실행되는 코드에 해당하며, 싸이 핵심의 활동을 측정합니다. 값 싸이 비정상적으로 높은 사용률은 시스템 호출, 인터럽트 또는 컨텍스트 변경이 많을 때 발생할 수 있습니다.
칼럼 비 비 함께 타고 와CPU 탓을 하기 전에 저장 장치를 먼저 확인하세요. 와 이는 입출력 작업이 대기 중인 동안 프로세서가 유휴 상태인 시간을 나타냅니다.
IDCPU 유휴 시간;와: 입장/출구를 기다리는 중;성
VPS에서, 성 반복적인 오류는 물리적 호스트에 과부하가 걸렸음을 나타낼 수 있습니다. 물리적 머신에서 이 열은 일반적으로 0으로 유지됩니다. 가이드는 다음과 같습니다. Linux에서의 평균 로드 이 측정값은 차단된 작업도 포함하고 CPU 사용률에만 국한되지 않으므로 완전한 수치입니다.
if와 only if를 사용하여 진정한 메모리 압력을 인식하기
기둥 swpd, 무료, 버프 그리고 숨겨진 메모리 사용량을 간략하게 보여주지만, 포화 상태를 나타내기에는 충분하지 않습니다. Linux는 RAM의 일부를 캐시로 재사용합니다. ~ 안에 vmstat 열을 대체하지 않습니다 주문의 무료.
무료 -h
스왑온 --쇼swpd 스왑 사용량을 나타냅니다. 0이 아닌 값이 시스템이 여전히 페이지를 교환하고 있음을 의미하는 것은 아닙니다. 이 점에 특히 주의하십시오. 만약에 그리고 그래서
만약에: 스왑 영역에서 RAM으로 데이터를 읽어옵니다.그래서데이터가 RAM에서 스왑 영역으로 이동되었습니다.
반복되는 값 만약에 또는 그래서, 추억 사용 가능 지속적으로 낮은 메모리 사용량과 저하된 응답 시간은 메모리 부족의 강력한 신호입니다. 현재 스왑 활동이 없는 오래된 스왑 영역은 이와 같은 의미를 갖지 않습니다. 가이드에서 자세히 설명합니다. 무료 및 사용 가능한 RAM 캐시의 역할에 대한 자세한 내용은 해당 기사에서 확인할 수 있습니다. Linux에서 스왑 습관적으로 비우면 안 되는 이유를 설명합니다.
bi, bo 및 iostat 명령어를 사용하여 디스크 대기 시간을 확인하십시오.
섹션에서 이오, 바이 그리고 악 비 와 높은 수준을 유지하려면 다음으로 전환하세요. iostat :
iostat -xz 1 5특히 보세요 기다리다대기열과 %유용 각 디스크마다 다른 값을 사용해야 합니다. 단일 임계값에만 의존하지 마세요. NVMe SSD는 여러 작업을 동시에 처리할 수 있지만, 하드 드라이브는 임의 접근 시 성능이 빠르게 저하됩니다. 시스템의 평소 작동 상태 및 현재 처리 속도와 값을 비교해 보세요.
에 관한 기사 Linux에서 iostat 사용 이 문서에서는 이러한 카운터를 올바른 장치에 연결하는 방법을 설명합니다. 속도 저하와 함께 오류가 발생하는 경우 커널 메시지도 확인하십시오.
journalctl -k -b -p 경고..알림
systemctl --실패서비스를 다시 시작하기 전에 프로세스를 검색하세요.
vmstat 이는 프로세스 이름이 아니라 차단 원인의 가능성을 나타냅니다. 그런 다음 의심되는 리소스에 따라 작업을 정렬합니다.
ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pcpu | 헤드
ps -eo pid,user,stat,ni,pcpu,pmem,comm --sort=-pmem | 헤드
htop 통계, 상태 디 이는 일반적으로 방해받지 않는 수면에 해당합니다. 이는 열을 설명할 수 있습니다. 비 PID가 높지만 바로 종료하지 마세요. 먼저 해당 서비스의 종류, 열려 있는 파일, 로그를 확인하세요.
ps -fp PID
systemctl status service-concerned --no-pager
Journalctl -u service-concerne -n 100 --no-pager데이터베이스는 메모리 누수 없이 많은 양의 RAM을 소비할 수 있으며, 프로세스는 특정 상태에 있을 수 있습니다. 디 디스크 또는 네트워크 스토리지를 기다리는 중일 수 있습니다. 재시작하면 문제가 해결되지 않고 증상이 일시적으로 가려지는 경우가 있습니다. 조치를 취하기 전에 소요 시간, 작업 부하 및 오류를 확인하십시오.
겹치는 카운터를 기준으로 결정하세요
여러 열이 동일한 내용을 나타낼 때 진단이 유용해집니다.
- CPU 포화
아르 자형비해 여전히 높은 수준nproc, 와 함께우리를또는ID; - 기억력 압박 :
사용 가능낮게 머물다,만약에또는그래서여러 샘플에 대한 반환값이 증가하고 지연 시간이 늘어납니다. - 디스크 대기 중 :
비그리고와일어나, 그럼iostat기기가 느린 것을 확인시켜 줍니다. - 가상화 경합 :
내부 부하가 중간 정도임에도 불구하고 VM에서 계속 표시됩니다.
OOM 킬러 인스턴스를 검색하려면 커널 로그를 사용하십시오.
journalctl -k -b | grep -Ei 'out of memory|oom-killer|killed process'거기 vmstat 매뉴얼 페이지 각 분야를 설명합니다. iostat 자세한 스토리지 메트릭을 확인하세요. 속도 저하 전후의 수치를 기록해 두세요. 시간 경과에 따른 비교 없이는 높은 수치라도 해석하기 어렵습니다.