이 가이드에서는 가상 서버에서 높은 부하의 주요 원인과 이를 해결하는 방법을 살펴보겠습니다.

예를 들어, 서버에 호스팅된 웹사이트를 열 때 큰 지연이 발생하고, 콘솔에서 명령이 느리게 실행됩니다.

1. 부하 확인

예를 들어, CPU 코어가 6개일 경우, 최대 부하(LA, Load Average)는 6이어야 합니다. (1은 코어의 100%를 의미합니다.)

우리의 예시에서 이 지표를 확인하기 위해 사용하는 명령어는 다음과 같습니다:

top

스크린샷에서 알 수 있듯이 이 지표가 크게 초과되었으며, 이는 가상 머신에 매우 높은 부하가 걸려 있음을 나타냅니다.

따라서 서버가 느리게 작동하는 원인은 부하가 상당히 초과되었기 때문입니다. 예시에서 우리는 또한 이 부하를 생성하는 프로세스들을 확인할 수 있으며, 이 프로세스들은 (R)로 표시되어 있습니다 - (Running, 활성 프로세스).

COMMAND 항목에서 가장 많은 리소스를 소비하는 명령을 확인할 수 있습니다. 이 경우 PHP 스크립트입니다.

또한 Tasks 매개변수에 주목하십시오. 이는 가상 머신의 총 프로세스 수를 나타내며, 752개의 프로세스 중 40개가 활성 상태입니다.

예를 들어, 하루 700명의 고유 방문자와 월 21,000명의 방문자가 있는 웹사이트의 정상 작동 중, 유사한 서버 구성에서 부하는 다음과 같습니다: LA - 0.41, Tasks - 51 (2개 실행 중).

이는 서버가 플러드 또는 DOS 공격을 받고 있거나, 스팸을 발송하기 위한 스크립트가 실행되고 있거나, 서버가 공격자의 프록시로 사용되고 있음을 나타낼 가능성이 큽니다.

2. 해결책

높은 부하 상태에서 콘솔에서 효율적으로 작업하기가 어려울 수 있습니다. 우리 사례에서는 웹 서비스가 문제를 일으키고 있으므로 이를 중지합시다:

service nginx stop
service apache2 stop

일부 경우 이러한 명령어가 실행되는 데 시간이 걸릴 수 있으므로, 강제로 프로세스를 종료하는 것이 더 좋습니다.

활성 프로세스의 PID를 확인하고 다음 명령어를 사용하여 종료하십시오 (pid는 프로세스 ID입니다):

kill -9 pid

만약 top 명령어가 느리게 실행되거나 지연이 발생한다면, ps aux 명령어와 프로세스 이름을 필터링하여 사용할 수 있습니다:

ps aux | grep nginx

이 프로세스들을 종료한 후 부하는 정상으로 돌아갈 것입니다. 그 후, tail 명령어와 grep 필터를 사용하여 액세스 로그에서 반복 요청을 확인하고 스크립트 경로를 찾을 수 있습니다.

tail -f /var/log/nginx/access.log

참고: 로그 파일의 경로와 이름은 다를 수 있습니다.

그 후 악성 스크립트를 삭제하십시오. 이 스크립트들은 주요 파일과 다른 생성 날짜를 가질 것이며, 이는 파일 관리자 mc를 사용할 때 확인할 수 있습니다.

2.1 높은 부하를 유발하는 스크립트를 찾는 대체 방법

서버가 약간의 지연(참을 만한 수준)으로 명령어에 응답하는 경우, 다음 명령어를 사용하여 스크립트 파일을 찾을 수 있습니다 (pid는 PHP 프로세스 ID입니다):

lsof -p pid

악성 파일을 삭제하면 서버의 부하가 줄어들 것입니다.

악성 파일은 DOS 또는 DDOS 공격의 경우 항상 존재하지 않을 수 있습니다. 이 경우 플러드 공격으로부터 웹 서버를 보호하는 방법에 대한 자세한 설명을 참고하십시오: 플러드 공격으로부터 웹 서버 보호

이러한 상황은 서버에 인기 있는 CMS가 오랫동안 업데이트되지 않은 경우 더 자주 발생할 수 있습니다.