mysql 경고 해결 방법: "InnoDB: page_cleaner: 1000ms 의도 루프에 XXXms가 걸렸습니다.설정이 최적이 아닐 수 있습니다.
mysql import mysql dummctrad < 덤프 파일을 실행했습니다.sql이 서버에 있고 완료하는 데 시간이 너무 오래 걸립니다.덤프 파일은 5G에 관한 것입니다.서버는 Centos 6, 메모리=16G 및 8코어 프로세서, mysql v 5.7 x 64-
이러한 메시지 flush"및 "waiting for table flush" "waiting for table flush"입니까?InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal
mysql 로그 내용
2016-12-13T10:51:39.909382Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal. (flushed=1438 and evicted=0, during the time.)
2016-12-13T10:53:01.170388Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4055ms. The settings might not be optimal. (flushed=1412 and evicted=0, during the time.)
2016-12-13T11:07:11.728812Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=1414 and evicted=0, during the time.)
2016-12-13T11:39:54.257618Z 3274915 [Note] Aborted connection 3274915 to db: 'dummyctrad' user: 'root' host: 'localhost' (Got an error writing communication packets)
프로세스 리스트:
mysql> show processlist \G;
*************************** 1. row ***************************
Id: 3273081
User: root
Host: localhost
db: dummyctrad
Command: Field List
Time: 7580
State: Waiting for table flush
Info:
*************************** 2. row ***************************
Id: 3274915
User: root
Host: localhost
db: dummyctrad
Command: Query
Time: 2
State: update
Info: INSERT INTO `radacct` VALUES (351318325,'kxid ge:7186','abcxyz5976c','user100
*************************** 3. row ***************************
Id: 3291591
User: root
Host: localhost
db: NULL
Command: Query
Time: 0
State: starting
Info: show processlist
*************************** 4. row ***************************
Id: 3291657
User: remoteuser
Host: portal.example.com:32800
db: ctradius
Command: Sleep
Time: 2
State:
Info: NULL
4 rows in set (0.00 sec)
업데이트-1
mysqlforum, innodb_lru_scan_depth
innodb_lru_scan_depth 값을 256으로 변경하면 삽입 쿼리 실행 시간 + 경고 메시지 로그 없음(기본값은 innodb_lru_scan_depth=depth;)이 향상되었습니다.
SET GLOBAL innodb_lru_scan_depth=256;
InnoDB: page_cleaner: 1000ms의 루프에 4013ms가 소요되었습니다.설정이 최적이 아닐 수 있습니다(시간 동안 124=1438 및 퇴출=0).
이 문제는 일반적으로 데이터베이스 변경률이 높은 MySQL 인스턴스에서 발생합니다.5GB Import를 실행하면 더러운 페이지가 빠르게 생성됩니다.더티 페이지가 생성되면 페이지 클리너 스레드는 더티 페이지를 메모리에서 디스크로 복사합니다.
당신의 경우 5GB Import를 항상 하는 것은 아닐 것입니다.이는 매우 높은 데이터 로딩 속도이며 일시적인 것입니다.InnoDB가 점차 따라잡을 것이기 때문에 경고는 무시해도 좋습니다.
다음은 이 경고의 원인이 된 내부 설명입니다.
페이지 클리너는 버퍼 풀에서 디스크로 플러시할 더티 페이지를 초당 1회 검색합니다.표시된 경고는 플래시에 더러운 페이지가 많다는 것을 나타내며, 플래시에 4초 이상 걸리면 해당 작업이 1초 이내에 완료됩니다.다시 말해, 씹을 수 있는 것보다 더 많이 물어뜯는 것이다.
를 you you you you you you you 를 줄여서 했습니다.innodb_lru_scan_depth199~256입니다.이렇게 하면 페이지 클리너 스레드가 초당 1회 주기 동안 더티 페이지를 검색하는 버퍼 풀의 거리가 줄어듭니다.한 입만 더 깨물어보라는 거군요.
버퍼 풀 인스턴스가 많으면 플러싱으로 인해 더 많은 작업이 수행된다는 점에 유의하십시오.innodb_lru_scan_depth를 줄이지 풀의 이했을 수 .따라서 스캔 깊이를 줄이지 않고 버퍼 풀의 수를 늘림으로써 이 병목 현상이 의도하지 않게 발생했을 수 있습니다.
『 』의 innodb_lru_scan_depth기본적으로는 너무 높은 값을 이 옵션에 부여한 것 같습니다.
둘 수 .IOPS는 "IPS"로 지정합니다.innodb_io_capacity ★★★★★★★★★★★★★★★★★」innodb_io_capacity_max throughput의 입니다.InnoDB의 I/O throughput의 스루풋을 나타냅니다.그러나 이 제한은 유연합니다.플래시가 새로운 더티 페이지 작성 속도보다 낮은 경우 InnoDB는 플러시 속도를 이 제한 이상으로 동적으로 높입니다.두 번째 옵션은 InnoDB가 플러시 속도를 얼마나 높일 수 있는지에 대한 엄격한 제한을 정의합니다.
플러싱 속도가 새로운 지저분한 페이지를 만드는 평균 속도를 따라갈 수 있다면 괜찮을 것입니다. 수 있는 페이지로 차게 는 더티 페이지를 초과합니다.innodb_max_dirty_page_pct버퍼 풀의 경우.이 시점에서 플래시 속도는 자동으로 증가하며 page_cleaner가 경고를 보낼 수 있습니다.
또 다른 솔루션은 MySQL을 보다 빠른 디스크로 서버에 설치하는 것입니다.페이지 플러싱에 필요한 처리량을 처리할 수 있는 I/O 시스템이 필요합니다.
평균 트래픽 아래에서 이 경고가 항상 표시되는 경우 이 MySQL 서버에서 쓰기 쿼리를 너무 많이 수행하려고 시도한 것일 수 있습니다.스케일아웃하고 쓰기를 각각 고유한 디스크 시스템을 사용하는 여러 MySQL 인스턴스로 분할해야 할 때가 올 수 있습니다.
페이지 클리너에 대한 자세한 내용은 다음을 참조하십시오.
병목현상은 데이터를 HDD에 저장하는 것입니다.모든 HDD: SSD, 일반 HDD, NVMe 등
이 솔루션은 주로 InnoDB에 적용됩니다.
저도 같은 문제가 있었어요, 몇 가지 해결책을 적용했어요.
첫 번째: 무엇이 문제인지 확인
atop -d에 디스크 사용현황이 표시됩니다.디스크가 'busy'인 경우 데이터베이스에 대한 모든 쿼리를 중지합니다(그러나 mysql 서버 서비스는 중지하지 마십시오).
쿼리 수를 모니터링하려면 mytop, innotop 또는 동등한 쿼리를 사용합니다.
쿼리가 0개인데 디스크 사용량이 몇 초에서 몇 분으로 여전히 100%에 가까운 경우, 이는 mysql 서버가 이전과 같이 더러운 페이지를 플러시하거나 클리닝을 수행하려고 시도하고 있음을 의미합니다(Bill Karwin의 훌륭한 게시물).
그런 다음 이러한 솔루션을 적용할 수 있습니다.
두 번째: 하드웨어 최적화
어레이가 RAID 1+0이 아닌 경우는, 이러한 솔루션을 사용해 데이터를 2배의 속도로 보존하는 것을 검토해 주세요.데이터 쓰기를 통해 HDD 코터롤러의 가능성을 확장해 보십시오.SSD 이상의 HDD를 사용해 보십시오.이 소울션을 적용하는 방법은 하드웨어 및 예산에 따라 다르며 변경될 수 있습니다.
세 번째: 소프트웨어 튜닝
하드웨어 코트롤러는 정상적으로 동작하지만 데이터 저장 속도를 연장하려면 mysql 구성 파일에서 다음과 같이 설정할 수 있습니다.
3.1.
innodb_flush_log_at_trx_commit = 2-> innodb 테이블을 사용하는 경우.파일당 1개의 테이블을 사용하는 것이 가장 좋기 때문에 제 경험으로는 효과가 있습니다.
innodb_file_per_table = 1
3.2.
InnoDB 계속:
innodb_flush_method = O_DIRECT
innodb_doublewrite = 0
innodb_support_xa = 0
innodb_checksums = 0
위의 행은 일반적으로 HDD에 저장해야 하는 데이터 양을 줄여주므로 성능이 향상됩니다.
3.3
general_log = 0
slow_query_log = 0
위의 행은 로그 저장을 무효로 합니다.물론 HDD에 저장해야 할 데이터량이기도 합니다.
3.4 사용상의 상황을 다시 확인합니다.
tail -f /var/log/mysql/error.log
넷째: 일반적인 주의사항
일반적인 주의:
이는 MySQL 5.6 및 5.7.22에서 테스트되었습니다.
OS: Debian 9
RAID: 1 + 0 SSD 드라이브
데이터베이스:InnoDB 테이블
innodb_write_pool_size = 120G innodb_write_pool_size = 8 innodb_read_io_size = 64 innodb_write_io_size = 64 innodb_write_size
서버의 총 RAM 용량: 200 GB
그 후, CPU 사용율이 높아지는 일이 있습니다.이것은 정상적인 현상입니다.데이터 쓰기가 고속이기 때문에 CPU 사용율이 높아지기 때문입니다.
my.cnf를 사용하는 경우 MySQL 서버를 재시작하는 것을 잊지 마십시오.
제5회: 보충
내가 이 별난 짓을 한 게 신기해서:
SET GLOBAL innodb_lru_scan_depth=256;
상기의
큰 테이블로 작업해도 성능에는 변화가 없습니다.
위의 수정 후에도 경고는 삭제되지 않았지만 전체 시스템이 상당히 빠르게 작동합니다.위의 모든 것은 실험일 뿐이지만, 저는 결과를 측정해 보았습니다. 조금 도움이 되었기 때문에 다른 사람에게 도움이 될 수 있기를 바랍니다.
이는 단순히 파일 시스템 전체의 성능 저하를 나타내는 것일 수 있습니다.이것은 관련이 없는 문제의 증상입니다.제 경우 시스템 로그를 분석하고 한 시간 동안 조사했습니다. MySQL 구성을 거의 수정하는 단계에 이르렀을 때 클라우드 기반 호스팅을 확인하기로 했습니다.알고 보니 "이웃에서 과도한 I/O 스파이크"가 발생했습니다.호스트에게 I/O를 전달한 후 바로 해결되었습니다.
MySQL과 관련이 없는 더 근본적인 문제가 있는지 확인하기 위해 기준/예상 파일 시스템 성능을 파악하고 MySQL을 중지하고 파일 시스템 성능을 측정하는 것이 좋습니다.
언급URL : https://stackoverflow.com/questions/41134785/how-to-solve-mysql-warning-innodb-page-cleaner-1000ms-intended-loop-took-xxx
'programing' 카테고리의 다른 글
| Java 어플리케이션마다 1개의 JVM이 있습니까? (0) | 2022.10.23 |
|---|---|
| JavaScript 문자열에서 HTML 태그를 삭제하는 방법 (0) | 2022.10.23 |
| SQL Syntax Error for 5.5.35-MariaDB (0) | 2022.10.23 |
| 컴포넌트의 useState에서 업데이터를 스테이트하기 위한 콜이 여러 번 발생하면 여러 번 재렌더가 발생합니다. (0) | 2022.10.23 |
| Javascript 변수 유형을 얻는 더 좋은 방법? (0) | 2022.10.23 |