가자, Linux 시스템 CPU가 100% 가득 찼다!-리눅스-php.cn

어제 오후 갑자기 운영유지관리부서로부터 데이터 플랫폼 서버의 CPU 사용률이 98.94%에 달했다는 알림 이메일을 받았습니다. 최근에는 이 활용률이 70% 이상을 계속해서 유지하고 있습니다. 얼핏 보면 하드웨어 자원이 병목 현상에 도달해 확장이 필요한 것처럼 보입니다. 그러나 신중하게 생각해 본 결과 우리 비즈니스 시스템은 동시성이나 CPU 집약적인 애플리케이션이 아니라는 사실을 알게 되었습니다. 이 활용률은 너무 과장되어 있으며 하드웨어 병목 현상에 너무 빨리 도달할 수 없습니다. 어딘가에 비즈니스 코드 로직에 문제가 있을 것입니다.

2. 문제 해결 아이디어

2.1 부하가 높은 프로세스 pid

찾기

먼저 서버에 로그인하고 top 명령어를 이용해 서버의 구체적인 상황을 확인한 후, 구체적인 상황을 토대로 분석하고 판단하세요.

부하 평균 및 부하 평가 기준(8코어)을 관찰하면 서버의 부하가 높은 것을 확인할 수 있습니다.

각 프로세스의 리소스 사용량을 관찰하면 프로세스 ID가 682인 프로세스의 CPU 비율이 더 높다는 것을 알 수 있습니다

2.2 특정 이상업체 찾기

여기서 pwdx 명령을 사용하여 pid를 기반으로 비즈니스 프로세스 경로를 찾은 다음 담당자와 프로젝트를 찾을 수 있습니다.

이 프로세스는 데이터 플랫폼의 웹 서비스에 해당한다고 결론을 내릴 수 있습니다.

2.3 비정상적인 스레드와 특정 코드 줄 찾기

기존 솔루션은 일반적으로 4단계로 구성됩니다.

1. P: 1040 // 먼저 프로세스 로드별로 정렬하여 maxLoad(pid)를 찾습니다.

2.top -Hp 프로세스 PID: 1073 // 관련 로드 스레드 PID를 찾습니다

3.printf “0x%x” 스레드 PID: 0x431 // 나중에 jstack 로그 검색을 준비하기 위해 스레드 PID를 16진수로 변환합니다

4. jstack 프로세스 PID | vim +/hex 스레드 PID – // 예: jstack 1040|vim +/0x431 –

그러나 온라인 문제 위치의 경우 매초가 중요하며 위의 4단계는 여전히 너무 번거롭고 시간이 많이 걸립니다. 이전에 Taobao를 소개한 Oldratlee는 위의 프로세스를 show-busy-java-threads.sh라는 도구로 캡슐화했습니다. 이러한 유형의 문제는 온라인에서 쉽게 찾을 수 있습니다.

시스템에서 시간 도구 메서드의 실행 CPU가 상대적으로 높다는 결론을 내릴 수 있습니다. 특정 메서드를 찾은 후 코드 로직에 성능 문제가 있는지 확인하세요.

※ 온라인 문제가 더 시급하다면 2.1과 2.2를 생략하고 2.3을 직접 실행해도 됩니다. 여기에서는 완전한 분석 아이디어를 제시하기 위해 다각도로 분석했습니다.

3. 근본 원인 분석

이전 분석과 문제 해결을 통해 마침내 과도한 서버 부하와 CPU 사용을 유발하는 시간 도구 문제를 발견했습니다.

예외 메소드 논리: 는 타임스탬프를 해당하는 특정 날짜 및 시간 형식으로 변환하는 것입니다.
상위 레이어 호출: 이른 아침부터 현재 시간까지의 모든 초를 계산하고 해당 형식으로 변환한 후 집합에 넣어 결과를 반환합니다.
로직 레이어: 데이터 플랫폼의 실시간 보고서 쿼리 로직에 해당합니다. 실시간 보고서는 고정된 시간 간격으로 제공되며 하나의 쿼리에 여러(n)개의 메서드 호출이 있습니다.

그러면 현재 시각이 오전 10시라면 쿼리 하나에 대한 계산 횟수는 106060n회 = 36,000n회이고, 시간이 지날수록 그 횟수가 늘어난다는 결론을 내릴 수 있습니다. 단일 쿼리가 자정에 가까워질수록 선형적으로 증가합니다. 실시간 쿼리, 실시간 알람 등 모듈에서 대량의 쿼리 요청이 발생하면 이 메소드를 여러 번 호출해야 하므로 많은 양의 CPU 리소스를 점유하여 낭비하게 됩니다.

4. 솔루션

문제를 찾은 후 가장 먼저 고려해야 할 사항은 계산 횟수를 줄이고 예외 방법을 최적화하는 것입니다. 조사 결과, 로직 계층에서 사용될 때 이 메서드에서 반환된 집합 컬렉션의 내용은 사용되지 않고 집합의 크기 값만 사용되는 것으로 나타났습니다. 로직을 확인한 후 새로운 방식을 사용하여 계산을 단순화하고(현재 초 - 그날 이른 아침의 초) 호출된 방식을 대체하여 과도한 계산 문제를 해결합니다. 온라인 접속 후 서버 부하 및 CPU 사용량을 관찰한 결과, 비정상적인 기간과 비교하여 서버 부하 및 CPU 사용량이 30배 감소한 후 정상으로 돌아왔습니다.

![어제 오후 갑자기 운영 및 유지보수 부서로부터 데이터 플랫폼 서버의 CPU 사용률이 98.94%에 달했다는 알림 이메일을 받았습니다. 최근에는 이 활용률이 70% 이상을 계속해서 유지하고 있습니다. 얼핏 보면 하드웨어 자원이 병목 현상에 도달해 확장이 필요한 것처럼 보입니다. 그러나 신중하게 생각해 본 결과 우리 비즈니스 시스템은 동시성이나 CPU 집약적인 애플리케이션이 아니라는 사실을 알게 되었습니다. 이 활용률은 너무 과장되어 있으며 하드웨어 병목 현상에 너무 빨리 도달할 수 없습니다. 어딘가에 비즈니스 코드 로직에 문제가 있을 것입니다.