Percona를 사용하면 99% 디스크 IO 스파이크

2024-6-21 • tag-icon

따라서 디스크 I/O가 무작위로 급증하는 것처럼 보이는 서버가 있습니다. 임의의 시간에 99.x%까지 올라가고 뚜렷한 이유 없이 한동안 높은 수준을 유지한 다음 다시 감소합니다. 예전에는 이것이 문제가 되지 않았지만 최근에는 디스크 I/O가 오랜 시간 동안(어떤 경우에는 최대 16시간까지) 99%로 유지되었습니다.

서버는 CPU 코어 4개와 RAM 4GB를 갖춘 전용 서버입니다. Ubuntu Server 14.04.2를 실행하고 있으며 percona-server 5.6을 실행하고 있으며 다른 주요 내용은 없습니다. 가동 중지 시간이 모니터링되고 있으며 우리가 다루는 서버의 CPU/RAM/디스크 I/O를 영구적으로 표시하는 화면이 있습니다. 서버도 정기적으로 패치 및 유지 관리되고 있습니다.

이 서버는 복제본 체인의 세 번째 서버이며 장애 조치 머신으로 존재합니다. MySQL 데이터 흐름은 다음과 같습니다.

마스터 --> 마스터/슬레이브 --> 문제 서버

3대의 머신은 모두 동일한 사양을 가지며 동일한 회사에서 호스팅됩니다. 문제 서버는 첫 번째 및 두 번째 데이터 센터와 다른 데이터 센터에 있습니다.

'iotop' 도구는 디스크 I/O가 'jbd2/sda7-8' 프로세스에 의해 발생하고 있음을 보여줍니다. 우리가 아는 바로는 이것이 파일 시스템 저널링과 디스크에 대한 플러시를 처리합니다. 'sda7' 파티션은 '/var'이고 sda8 파티션은 /home입니다. 정기적으로 /home에 읽기/쓰기가 있어서는 안 됩니다. mysql 서비스를 중지하면 디스크 I/O가 즉시 정상 수준으로 떨어지므로 문제를 일으키는 것이 percona라고 확신하며 이는 MySQL이 있는 /var 파티션과 일치합니다. 데이터 디렉터리는 (/var/lib/mysql)에 있습니다.

우리는 NewRelic을 사용하여 모든 서버를 모니터링하는데, 디스크 I/O가 급증할 때 이를 야기할 수 있는 어떤 것도 볼 수 없습니다. 로드 평균은 ~2입니다. CPU 사용량은 ~25%에 머물고 있으며 NewRelic은 특정 프로세스가 아닌 'IO 대기'로 인해 이러한 현상이 발생한다고 말합니다.

mysql 구성 파일은 Percona 구성 마법사와 고객 앱에 필요한 일부 설정의 조합을 통해 생성되었지만 특별히 멋진 것은 아닙니다.

MySQL 구성 -http://pastebin.com/5iev4eNa

우리는 문제를 해결하기 위해 다음을 시도했습니다.

분명히 잘못된 것이 있는지 확인하기 위해 mysqltuner.pl을 실행했습니다. 결과는 다른 2개의 데이터베이스 서버에 있는 동일한 도구의 결과와 매우 유사하며 사용 간에 크게 변하지 않습니다.
vmstat, iotop, iostat, pt-diskstats, fatrace, lsof, pt-stalk 등을 사용했지만 눈에 띄는 것은 없습니다.
'innodb_flush_log_at_trx_commit' 변수를 조정했습니다. 0, 1, 2로 설정해 보았지만 아무런 효과가 없는 것 같습니다. 이는 MySQL이 트랜잭션을 로그 파일에 플러시하는 빈도를 변경했어야 합니다.
mysql의 '전체 프로세스 목록 표시'는 디스크 I/O가 높을 때 매우 흥미롭지 않으며 단지 마스터에서 읽는 슬레이브를 표시합니다.

도구의 출력 중 일부는 확실히 꽤 길어서 Pastebin 링크를 제공하고 iotop의 출력을 복사하여 붙여넣을 수 없어서 대신 화면 캡처를 제공했습니다.

아이오톱

pt-diskstats:http://pastebin.com/ZYdSkCsL

디스크 I/O가 높을 때 "vmstat 2"는 기록되는 내용이 대부분 "bo"(버퍼 아웃)로 인해 발생함을 보여줍니다. 이는 디스크 저널링(버퍼/RAM을 디스크로 플러시)과 관련이 있습니다.

http://pastebin.com/E3LWzwjj

"lsof -p mysql-pid"(프로세스의 열린 파일 나열)는 기록되는 파일이 대부분 /var/lib/mysql 디렉토리에 있는 .MYI 및 .MYD 파일이고 master.info 및 Relay- bin 및 릴레이 로그 파일. mysql 프로세스를 지정하지 않아도(따라서 모든 파일이 전체 서버에 작성됨) 출력은 매우 유사합니다(대부분 MySQL 파일이며 다른 것은 많지 않음). 이는 확실히 Percona에 의해 발생하고 있음을 확인시켜 줍니다.

디스크 I/O가 높으면 "seconds_behind_master"가 증가합니다. 아직은 어떤 방향으로 그런 일이 일어나는지 잘 모르겠습니다. "seconds_behind_master"는 일시적으로 정상 값에서 임의의 큰 값으로 점프했다가 거의 즉시 정상으로 돌아옵니다. 일부 사람들은 이것이 네트워크 문제로 인해 발생할 수 있다고 제안했습니다.

'슬레이브 상태 표시' -http://pastebin.com/Wj0tFina

RAID 컨트롤러(3ware 8006)에는 캐싱 기능이 없습니다. 누군가는 캐싱 성능이 좋지 않아 문제가 발생할 수 있다고 제안했습니다. 컨트롤러에는 동일한 고객(웹 서버이기는 하지만)의 다른 서버에 있는 카드와 동일한 펌웨어, 버전, 개정판 등이 있으므로 결함이 없다고 확신합니다. 또한 어레이에 대한 검증을 실행했는데 정상적으로 돌아왔습니다. 또한 변경 사항을 알려주는 RAID 검사 스크립트도 있습니다.

두 번째 데이터베이스 서버에 비해 네트워크 속도가 형편없어서 아마도 네트워크 문제가 아닌가 하는 생각이 듭니다. 이는 디스크 I/O가 높아지기 직전에 대역폭이 급증하는 것과도 관련이 있습니다. 그러나 네트워크가 "급증"하더라도 높은 트래픽 양으로 급상승하지 않고 평균에 비해 상대적으로 높을 뿐입니다.

네트워크/디스크 IO

네트워크 속도(AWS 인스턴스에 대한 iPerf를 사용하여 생성됨)

문제 서버 - 0.0-11.3초 2.25MBytes 1.67Mbits/sec 두 번째 서버 - 0.0-10.0초 438MBytes 366Mbits/sec

느린 것 빼고는 네트워크도 괜찮은 것 같습니다. 패킷 손실은 없지만 서버 간 약간의 느린 홉 MTR

관련 명령의 출력도 제공하게 되어 기쁘지만 저는 새로운 사용자이기 때문에 이 게시물에 링크를 2개만 추가할 수 있습니다.

편집하다이 문제와 관련하여 호스팅 제공업체에 연락했는데, 친절하게도 하드 디스크를 동일한 크기의 SSD로 교체해 주었습니다. 이러한 SSD에 RAID를 재구축했지만 불행하게도 문제는 지속됩니다.

답변1

어떤 버전의 MySQL 서버를 사용하시나요? 5.5 이후에는performance_schema를 사용하여 데이터베이스에서 실시간 통계를 얻을 수 있습니다. 나는

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

정확히 무슨 일이 일어나고 있는지 확인하기 위해.

또 다른 해결책은 버퍼 풀 사용량을 확인하는 경우 메모리로 이동해야 하는 콜드 페이지가 있다는 것입니다.

답변2

공격하는 가장 좋은 방법은 보는 것입니다.http://www.brendangregg.com/linuxperf.html브렌든의 조언을 따르세요.

특히 스토리지에 가장 많이 액세스하는 사람이 누구인지 알려주는 iosnoop 도구가 필요합니다. 하지만 그의 사고 과정과 방법론을 배우기 위해 이 책을 끝까지 읽어보면 장기적으로 많은 도움이 될 것이므로 큰 도움이 될 것입니다.

답변1

답변2

관련 정보