Debian/Ubuntu 임의 디스크 확장

Debian/Ubuntu 임의 디스크 확장

debian 12(BookWorm)에서 mysql 8.0.34를 실행합니다.

디스크가 꾸준히 소모되는 것처럼 보이지만 디스크에 들어가거나 디스크를 검색할 때 아무 것도 공간을 차지하지 않는 것 같다가 디스크가 가득 차면 다시 정상으로 재설정되는 무작위 문제가 발생합니다. 전체 과정은 약 45분 정도 소요됩니다.

Debian 12를 새로 설치하면 운영 체제에 설치된 유일한 서비스는 mysql입니다.

마지막 두 이미지는 약 1초 만에 100% 디스크 소비에서 44%로 다시 돌아갔습니다.

왜 이런 일이 발생하는지에 대한 설명이나 디버깅에 대한 제안을 주시면 감사하겠습니다.

여기에 이미지 설명을 입력하세요.

lsof +L1 실행

명령 PID 사용자 FD 유형 장치 크기/닫기 NLINK 노드 이름

mysqld 886068 mysql 521u REG 254,1 194824503296 0 29360306 /tmp/#29360306 (삭제됨)

돌고래에게 물어봐야 할까요?

답변1

lsof +L1 실행

COMMAND      PID       USER   FD   TYPE DEVICE     SIZE/OFF NLINK     NODE NAME    
mysqld    886068      mysql  521u   REG  254,1 194824503296     0 29360306 /tmp/#29360306 (deleted)

이는 열려 있는 동안 삭제된 임시 파일이며 mysqld, 명령을 실행하면 크기가 약 194G인 것으로 보입니다 lsof +L1.

파일에 포함된 내용을 확인하려면 /proc/<PID number>/fd/<FD number>프로세스가 여전히 존재하고 열려 있는 동안 해당 파일에 액세스할 수 있습니다. 따라서 이 경우 예를 들어 다음과 같이 시도해 볼 수 있습니다.

sudo file -L /proc/886068/fd/521

실제로 어떤 유형의 파일인지 알아보세요.

MySQL 데이터베이스를 중지하고 다시 시작할 수 있습니까? 중지 되면 mysqld파일이 "해제"되고 파일 시스템이 자동으로 해당 파일을 정리합니다. 또는 거의 무한한 출력을 생성하는 어리석은 쿼리를 실행했을 수 있는 데이터베이스 세션을 찾을 수 있는 경우 해당 세션을 강제로 종료할 수 있으며, 이로 인해 mysqld해당 세션과 관련된 임시 파일이 닫힐 수 있습니다.

인터넷에서 MySQL 서버에 액세스할 수 있는 경우 일부 침입자나 악성 코드가 데이터베이스를 악용하여 데이터베이스 내의 일부 데이터를 "숨길" 수 있습니다.

임시 파일에 대한 MySQL 8.0.x 문서에서:

mysqld가 종료되면 MySQL은 임시 파일이 삭제되도록 준비합니다. 이를 지원하는 플랫폼(예: Unix)에서는 파일을 연 후 링크를 ​​해제하여 이를 수행합니다. 단점은 이름이 디렉토리 목록에 나타나지 않으며 임시 파일 디렉토리가 있는 파일 시스템을 채우는 대용량 임시 파일을 볼 수 없다는 것입니다. (이 경우 lsof +L1mysqld와 관련된 대용량 파일을 식별하는 것이 도움이 될 수 있습니다.)

MySQL은 정렬(ORDER BY 또는 GROUP BY) 시 일반적으로 하나 또는 두 개의 임시 파일을 사용합니다. 필요한 최대 디스크 공간은 다음 식으로 결정됩니다.

(정렬된 내용의 길이 + sizeof(행 포인터)) * 일치하는 행 수 * 2

행 포인터 크기는 일반적으로 4바이트이지만 매우 큰 테이블의 경우 향후 커질 수 있습니다.

특정 명령문의 경우 MySQL은 숨겨지지 않고 이름이 #sql로 시작하는 임시 SQL 테이블을 생성합니다.

일부 SELECT 쿼리는 중간 결과를 보관하기 위해 임시 SQL 테이블을 만듭니다.

따라서 귀하의 시스템은 상당히 큰 결과 집합이 포함된 일부 쿼리를 자주 실행하고 중간 결과 또는 정렬을 위해서는 큰 임시 파일을 생성해야 하는 것 같습니다.

특정 쿼리가 자주 반복되고 결과 정렬 요구 사항에 따라 중간 파일이 생성되는 경우 데이터베이스가 해당 테이블에 효율적으로 사전 액세스할 수 있도록 하는 인덱스를 추가하는 것을 고려해야 합니다. 자주 반복되는 쿼리에 필요한 방식으로 정렬합니다. 이것은 또한 당신에게중요한쿼리 성능이 향상되었습니다.

물론, 실제 쿼리를 검사하여 애플리케이션이 더 스마트한 방식으로 구현될 수 있는 어리석은 쿼리를 생성하고 있음을 발견한 경우 버그 보고서(쿼리 개선을 위한 제안을 할 수 있는 경우)는 해당 쿼리를 사용하는 모든 사람에게 도움이 될 수 있습니다. 관련 앱.

(저는 실제로 DBA는 아니지만 직장에서 DBA와 수년간 논의한 결과 적절한 인덱싱이 부족하고 어리석은 방식으로 무언가를 검색하는 애플리케이션 생성 쿼리가 데이터베이스 성능 저하와 관련된 가장 일반적인 두 가지 문제인 것 같다는 사실을 알게 되었습니다. 이유. 개발에서는 중요하지 않을 수 있지만 데이터 양이 프로덕션 규모로 증가하면 비효율성이 분명해집니다.

관련 정보