작은 쿼리는 되고 큰 쿼리는 실패한다: 어느 패킷 크기인가?

작은 쿼리는 돌아오고 큰 쿼리는 멈추거나 끊기며, 첫 직감은 패킷 크기에 뭔가 문제가 있다는 것이다. 그 직감은 대개 옳고 거의 항상 잘못된 계층을 겨냥한다. 세 가지 설정이 패킷이라는 단어를 공유하며 데이터베이스 드라이버의 전송 패키징, 데이터베이스 서버의 메시지 한도, IP 경로의 최대 전송 단위라는 서로 무관한 세 가지를 측정한다. 하나를 조정해 다른 하나가 만든 증상을 고치려는 것이 바로 오 분짜리 문제를 일주일짜리 튜닝으로 만드는 길이다. 아래 순서가 내가 가장 적은 시간을 쓴 순서다.

세 계층, 하나의 공유 단어

아래 각 행은 소유자가 다른 별개의 단위이며, 어느 것도 다른 것에서 추론할 수 없다. 데이터베이스 메시지는 여러 TCP 세그먼트와 여러 IP 패킷에 걸칠 수 있으므로 허용 크기를 늘려도 경로가 넓어지지 않고, 드라이버 설정을 줄이는 것은 인터페이스 MTU를 바꾸는 것과 같은 작업이 아니다. 이 단어는 세 개의 서로 다른 구성 파일에 나타나므로 검색하면 무관한 세 가지 답이 나온다. 먼저 오류 문구를 읽고, 그다음 어느 파일을 열지 결정하라.

구성 파일을 열기 전에 실패한 작업이 어느 계층에 속하는지 적어 두라. 오류 문구가 보통 그렇게 말하며, 사람들이 건너뛰는 부분이 바로 그 문구다.

설정을 바꾸기 전에 공급자를 식별하라

SQL Server의 경우 애플리케이션, 드라이버 또는 공급자 이름, 버전, 유효한 연결 구성을 기록하라. 진단 스크립트와 데스크톱 애플리케이션은 서로 다른 공급자를 통해 같은 서버에 도달할 수 있으므로, 하나에 도움이 되는 설정이 다른 하나에 대해 아무것도 증명하지 않는다. 공급자의 기본값은 다르며, 비슷한 이름의 연결 문자열 필드는 모든 공급자가 그것을 같은 방식으로 해석한다는 증거가 아니다.

오래된 우회 방법이 그 구문을 썼다는 이유만으로 유지 관리되는 드라이버를 구형으로 바꾸지 마라. 현재 문서는 그 오래된 구성 요소에 대한 새 개발을 권장하지 않으며, 그 제한을 물려받는 것은 설정 하나를 위한 나쁜 거래다.

메시지 거부는 경로 정체가 아니다

MySQL 8.4에서 통신 패킷 문서는 적용 가능한 한도를 넘는 너무 큰 문, 행 또는 바이너리 로그 이벤트가 거부된다고 설명하며, 클라이언트와 서버 양쪽 한도가 모두 중요할 수 있다는 점을 밝히고, 그것은 데이터베이스 계층에서의 거부이지 네트워크가 거대한 IP 패킷을 실어야 한다는 진술이 아니다. 실제 오류와 문제 메시지의 모양을 읽어라. 작은 행이 많은 큰 결과는 하나의 거대한 행과 다른 사례이며, 실패하는 방식도 다르다.

MariaDB 설치에는 자체 버전의 문서화된 한도와 진단이 필요하다. MySQL 기본값을 MariaDB에 복사하는 것은 단계를 더한 추측이다.

경로 증거는 실제로 어떤 모습인가

경로 크기 문제에는 고유한 지문이 있다: 특정 경로와 주소 체계를 따라 재현되는 크기 의존 전송 실패이며, 터널의 오버헤드가 개입하고 발견 피드백이 경로가 허용하는 대로 동작한다. 타임아웃 하나만으로는 느린 쿼리, 드라이버 버그, 서버 측 한도와 구별되지 않으며, 타임아웃을 MTU 문제의 증거로 취급하는 것은 자신 있게 잘못된 계층으로 보낸다.

경로를 시험한다면 목적지, 계정, 작업 부하를 고정해 유일한 변수가 조사하는 크기가 되게 하라. 세 가지가 바뀐 시험은 어느 것이 중요했는지 아무것도 말해 주지 않는다.

문서화된 변수 하나를 바꾸고 기록하라

목적지, 계정, 공급자, 작업 부하를 일정하게 유지하고 원래 값을 기록한 뒤, 지원되는 변경 하나를 적용하고 결과를 기록하라. 시험 하나를 통과하게 하는 더 작은 설정은 그 시험한 스택에 관한 유용한 증거이며, 보편적 최적값도 아니고 원래 실패의 원인을 확립하지도 않는다. 이들은 서로 다른 주장이며, 첫 번째만이 단일 실험으로 뒷받침된다.

식별된 한도를 그 계층에서 해결하고, 어느 계층이었는지 적어라. 그 기록이 경로가 문제였는데도 다음 사람이 드라이버를 튜닝하는 것을 막는다.