VPN 게이트웨이가 CPU에 묶여 있나요? 먼저 코어별 부하를 읽으세요

더 큰 인스턴스를 사기 전에 세 가지 한계 중 어디에 도달했는지 정한다. 코어 하나만 가득 차고 나머지가 놀고 있다면 흐름별 암호 작업을 가리킨다. 전송 중 모든 코어가 포화되면 총 처리 용량을 가리킨다. CPU는 낮은데 재전송 수가 늘어나면 경로를 가리킨다. 각각 첫 조치가 다르고, 더 큰 인스턴스로 해결되는 것은 하나뿐이다.

세 가지 한계, 하나의 표, 세 가지 조치

행을 단계가 아니라 진단으로 읽는다. 큰 터널 하나를 나르는 게이트웨이에서 가장 흔한 결과는 스레드 하나가 100%이고 나머지가 노는 상태이며, 그 흐름의 암호화가 코어 하나에서 돌기 때문이다. 전송 중 모든 코어가 바쁘다면 기계는 이미 할 수 있는 만큼 일하고 있다. CPU는 낮은데 재전송이 늘어난다면 프로세서가 계속 데이터를 떨어뜨리는 네트워크를 기다리는 것이다.

증거의 순서대로 고친다. 흐름을 워커에 분산하는 것은 첫 경우에 도움이 되고 둘째에는 아무것도 하지 않는다. 더 큰 인스턴스는 둘째에 도움이 되고 첫째에는 돈을 낭비한다. MTU나 손실 수정만이 셋째에 닿는다. 자기가 어느 행에 있는지 알기 전에 용량을 사는 것 은 추측의 비싼 판본이다.

고정된 스레드와 바쁜 호스트를 분리한다

코어별 사용률부터 보는 것은 고정된 코어 하나가 평균 속에 숨지 못하게 하기 위해서다. 전송 중 한 번 실행하면 부하가 평평한지 뾰족한지 알 수 있다. 두 모양 모두 정보가 되지만, 뾰족한 프로필은 샘플링 창이 암호화가 아니라 스케줄러 활동을 잡았다는 뜻인 경우가 많다.

mpstat -P ALL 1 5

바쁜 코어를 프로세스에, 다음으로 스레드에 귀속시킨다. 아래 후속 실행은 부모와 자식 스레드를 함께 유지하는데, 데몬이 연결마다 포크할 때 중요하다:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

커널 암호화는 사용자 공간 프로세스 카운터에 절대 나타나지 않는다. 스레드를 따로 샘플링하고 그 모습을 프로세스 회계와 비교한다:

top -H -b -n 1 | head -20

소켓 카운터는 마지막에 읽는 것은 CPU를 더 늘리는 것이 과연 도움이 될지를 결정하기 때문이다. CPU가 평평한데 재전송이 늘어나는 것은 프로세서 문제가 아니다. 샘플링하는 동안 전송을 계속 돌려야 하며, 그러지 않으면 숫자는 놀고 있는 기계를 설명한다:

ss -ti | grep -E 'retrans|cwnd|rtt'

통제된 전송, 두 번 실행

노는 카운터는 아무것도 증명하지 못하고, 무작위 엔드포인트에 대한 벤치마크는 거의 증명하지 못한다. 클라이언트 하나, 목적지 하나, 실행이 허용된 대표 전송 하나를 고르고 같은 창에서 처리량과 대화형 지연을 기록한다. 대량 복사가 끝나기 전에 게이트웨이가 포화될 수 있고, 사용자가 실제로 느끼는 것은 지연 곡선이다. 전송, 클라이언트 수, 데몬 버전을 숫자 옆에 적는다.

여러 병렬 흐름으로 실행을 반복한다. 흐름을 늘리면 늘어나면 흐름별 창을, 코어 하나가 고정된 채 평평하면 처리를 가리킨다.

그다음 선택 작업 부하를 멈추고 한 번 더 반복한다. 같은 호스트의 백업, 로그 전송기, 데이터베이스는 터널과 무관한 바쁜 평균을 만들 수 있다. 호스트가 그 밖에 조용한데 CPU가 여전히 고정되어 있다면 증거는 VPN 프로세스를 가리킨다. 떨어진다면 이웃을 재고 있었고, 게이트웨이는 문제가 아니었다.

하드웨어를 사기 전에 경로를 배제한다

재전송 증가, 줄어드는 혼잡 창, 늘어나는 왕복 시간은 모두 프로세서에서 멀어진다. 터널 MTU와 경로 MTU를 비교하고, 하위 링크의 손실을 확인하고, 클라이언트 자신의 업링크가 한계가 아님을 확인한다. 더 큰 게이트웨이는 패킷을 떨어뜨리는 링크를 고치지 못하며, 사용자는 두 고장을 같은 말로 설명한다. 재전송 카운터가 몇 분 만에 둘을 갈라놓는다.

가상 서버에서는 제공자 지표를 게스트 자체 지표에 더한다. 스틸 타임은 초과 판매가 게스트 안에서 보이는 방식이고, 게스트 안의 어떤 튜닝도 그것을 없애지 못한다. 게스트 카운터는 호스트를 보지 못하므로 깨끗한 게스트 그래프는 건강한 호스트의 증거가 아니다.

변경 하나, 측정 하나

증거가 뒷받침하는 가설을 고르고, 지원되는 설정을 정확히 하나 바꾼다: 워커 수, 문서화된 오프로드 옵션, 인스턴스 크기 중 하나다. OpenVPN은 처리와 전송의 같은 구분에 대해 성능 문제 해결 안내서를 공개한다: OpenVPN 성능 문제 해결.

플래그를 믿지 말고 오프로드 옵션이 실제로 활성인지 확인한 뒤, 동일한 전송을 다시 돌려 같은 것끼리 비교한다. 실제 개선과 조용한 오후를 구별하는 유일한 방법이다. 되돌릴 수 있는 체크포인트를 남겨 두어야 하는데, 두 번째 변경에서 무엇이 도움이 되었는지 놓치기 쉽기 때문이다. 한 번에 하나의 변수는 하루에는 느리고 한 달에는 빠르다.

그래프를 좋게 보이려고 인증이나 암호 제품군을 약화하지 않는다. CPU가 여전히 증상을 따르지 않는다면 추측으로 업그레이드하는 대신 경로와 애플리케이션 점검으로 돌아간다.