InnoDB：page_cleaner：1000ms預期循環花費了xxx毫秒。設置可能不是最佳

我在Ubuntu 16.04.1 LTS上使用5.7.16-10-log Percona服務器。InnoDB：page_cleaner：1000ms預期循環花費了xxx毫秒。設置可能不是最佳

我最近從m4.2xlarge實例類型將我的AWS ec2實例升級到了m4.4xlarge。發佈升級我的MySQL錯誤日誌週期性地填充有下面幾行：

2017-09-15T17:10:30.678258+05:30 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4460ms. The settings might not be optimal. (flushed=140, during the time.) 
2017-09-15T17:14:31.048443+05:30 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6047ms. The settings might not be optimal. (flushed=107, during the time.) 
2017-09-15T17:15:06.312119+05:30 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8262ms. The settings might not be optimal. (flushed=64, during the time.)

這些都是常見的，當Percona的Innobackupex運行按照時間表完全備份和增量備份。在這種時候，這裏的磁盤使用情況按iostat：已

Device:   rrqm/s wrqm/s  r/s  w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 
xvda    0.00  0.00 0.00 0.00  0.00  0.00  0.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdf    0.00 10.00 0.00 2.00  0.00 48.00 48.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdb    21.00  0.00 672.00 816.00 63328.00 104448.00 225.51 30.65 20.74 19.28 21.94 0.67 100.00 

Device:   rrqm/s wrqm/s  r/s  w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 
xvda    0.00  0.00 0.00 0.00  0.00  0.00  0.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdf    0.00  0.00 0.00 0.00  0.00  0.00  0.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdb    0.00  4.95 630.69 802.97 62875.25 102677.23 230.95 30.27 21.11 19.80 22.14 0.69 99.01 

Device:   rrqm/s wrqm/s  r/s  w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 
xvda    0.00  0.00 0.00 0.00  0.00  0.00  0.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdf    0.00  0.00 0.00 0.00  0.00  0.00  0.00  0.00 0.00 0.00 0.00 0.00 0.00 
xvdb    23.00 153.00 988.00 668.00 94888.00 72104.00 201.68 26.84 16.21 14.57 18.62 0.59 98.40

我保持甚至從我發現被推薦的一些默認值爲1024降下來LRU掃描深度後，獲得在MySQL錯誤日誌這些消息網絡上的類似帖子。

SET GLOBAL innodb_lru_scan_depth=256;

按照別人推薦，我也試圖找出問題是否與LRU列表或刷新列表中，而不是使用：

SHOW ENGINE INNODB STATUS\G

在下面的輸出，在某些情況下，我能看到沖洗名單比等待零的寫道：

---------------------- 
BUFFER POOL AND MEMORY 
---------------------- 
Total large memory allocated 50300190720 
Dictionary memory allocated 18819582 
Internal hash tables (constant factor + variable factor) 
    Adaptive hash index 3805993024 (764908736 + 3041084288) 
    Page hash   5976584 (buffer pool 0 only) 
    Dictionary cache 210046766 (191227184 + 18819582) 
    File system   1570552  (812272 + 758280) 
    Lock system   119847848 (119530904 + 316944) 
    Recovery system  0 (0 + 0) 
Buffer pool size 2948760 
Buffer pool size, bytes 0 
Free buffers  417019 
Database pages  2346130 
Old database pages 866201 
Modified db pages 60127 
Pending reads  0 
Pending writes: LRU 0, flush list 10, single page 0 
Pages made young 5082, not young 0 
0.17 youngs/s, 0.00 non-youngs/s 
Pages read 2139505, created 206625, written 1680831 
1323.32 reads/s, 0.70 creates/s, 21.87 writes/s 
Buffer pool hit rate 1000/1000, young-making rate 0/1000 not 0/1000 
Pages read ahead 1314.62/s, evicted without access 0.00/s, Random read ahead 0.00/s 
LRU len: 2346130, unzip_LRU len: 0 
I/O sum[0]:cur[128], unzip sum[0]:cur[0]

這裏的my.cnf中的一個片段，我用：

[mysqld] 

# GENERAL # 
user       = mysql 
default-storage-engine   = InnoDB 
socket       = /var/run/mysqld/mysqld.sock 
pid-file      = /var/run/mysqld/mysqld.pid 
basedir = /usr 
tmpdir = /var/tmp 
lc-messages-dir = /usr/share/mysql 
explicit_defaults_for_timestamp 
log_timestamps     = SYSTEM 
skip-name-resolve 
net-write-timeout    = 600 
net-read-timeout    = 600 
innodb-page-cleaners   = 8 
performance-schema    = OFF 

# MyISAM # 
key-buffer-size    = 32M 

# SAFETY # 
max-allowed-packet    = 16M 
max-connect-errors    = 1000000 
sysdate-is-now     = 1 

# DATA STORAGE # 
datadir      = /var/lib/mysql/ 

# BINARY LOGGING # 
server-id      = 2 
log-bin      = /var/lib/mysql/mysql-bin 
expire-logs-days    = 14 
sync-binlog     = 1 
max_binlog_size    = 1G 
max_binlog_files    = 20 

# CACHES AND LIMITS # 
tmp-table-size     = 32M 
max-heap-table-size   = 32M 
query-cache-type    = 0 
query-cache-size    = 0 
max-connections    = 500 
thread-cache-size    = 50 
open-files-limit    = 4510 
table-definition-cache   = 4096 
table-open-cache    = 4096 

# INNODB # 
innodb-flush-method   = O_DIRECT 
innodb-log-files-in-group  = 2 
innodb-log-file-size   = 512M 
innodb-flush-log-at-trx-commit = 1 
innodb-file-per-table   = 1 
innodb-buffer-pool-size  = 45G 
innodb-print-all-deadlocks  = ON 

# LOGGING # 
log-error      = /var/log/mysql/mysql-error.log 
slow-query-log-file   = /var/log/mysql/mysql-slow.log 
lower-case-table-names   = 1 
character-set-client-handshake = FALSE 
character-set-server   = utf8mb4 
collation-server    = utf8mb4_general_ci 

#Slow query queries 
slow-query-log     = 1 
long-query-time    = 10 
slow-query-log-always-write-time = 15 #Slow query queries 
log-slow-verbosity    = full 
log-slow-rate-type    = query 
log-slow-rate-limit   = 100 #queries logged/sec 
log-queries-not-using-indexes = 1

任何意見/幫助/指示燈來排除故障和解決這個問題會有很大的幫助。

這裏就是限制-a看起來像我的生產：

$ ulimit -a 
core file size   (blocks, -c) 0 
data seg size   (kbytes, -d) unlimited 
scheduling priority    (-e) 0 
file size    (blocks, -f) unlimited 
pending signals     (-i) 257583 
max locked memory  (kbytes, -l) 64 
max memory size   (kbytes, -m) unlimited 
open files      (-n) 1024 
pipe size   (512 bytes, -p) 8 
POSIX message queues  (bytes, -q) 819200 
real-time priority    (-r) 0 
stack size    (kbytes, -s) 8192 
cpu time    (seconds, -t) unlimited 
max user processes    (-u) 257583 
virtual memory   (kbytes, -v) unlimited 
file locks      (-x) unlimited

來源

2017-09-15 Deb

對我來說，這似乎很明顯，這不是MySQL的問題......它只是抱怨由於innobackupex顯然將過度的負擔放在磁盤上，此刻它出現意外緩慢的磁盤訪問。「設置可能不是最佳的」，但這並非孤立地發生。您是否將備份寫入到MySQL'datadir'所在的同一卷中？您的新實例的EBS網絡帶寬是舊網絡帶寬的兩倍，這可能會允許讀取和寫入備份文件，以使EBS卷超出其功能。 –

我有一個單獨的EBS卷用於備份。你會建議將備份轉移到從屬服務器上嗎？在這種情況下，我可能會依靠pt-table-checksum來確保從服務器與主服務器一致，因此備份也不錯。 – Deb

請提供'SELECT * FROM information_schema.INNODB_METRICS WHERE name LIKE'buffer_％' ;' - 我會看看我能從那裏得到一些線索。 –

事情在my.cnf/INI的[mysqld]部分做

移動innodb_page_cleaners是在節＃＃INNODB和更改爲

innodb_page_cleaners=64 # will autolimit to be = innodb_buffer_pool_instances

添加一行

innodb_buffer_pool_instances=8 # from default of 1 to reduce mutex contention 
please POST in original question results of 
ulimit -a so we can see the Ubuntu limits.

來源

2018-01-25 13:45:29

我的innodb_buffer_pool_instances已經設置爲8，innodb_page_cleaners也是如此。將ulimit -a的輸出添加到了我上面的帖子中。 – Deb

@deb他發佈了完整的配置/報告 - 您的選擇。完整的MySQLTuner報告將會有所幫助。 pastebin.com對於超出容量的列表/報告很有幫助，請告訴我們鏈接。 –

您打開的文件被限制爲1024個，將其提高到90000. 每個文件的操作系統成本在RAM中幾乎沒有。驗證您的更改，實施時。然後在您的配置部分要做的事情只有1次更改，如果沒有負面影響，則顯示器，請再次更改下一個工作日。許多可以動態更改，請參閱用戶指南。 log_queries_not_using_indexes = 0從1＃或設置 long_query_time時間= 500＃10

慢查詢的單個焦點或不使用索引避免信息的混合袋

thread_cache_size=100 # from 50 to minimize 
threads_created 
open_files_limit=30000 # from 4510 
table_definition_cache=10000 # from 4096 
table_open_cache=10000 # from 4096

這幾天值得的修改/監控將會改善你的實例。

進一步分析，您使用SSD或旋轉硬盤驅動器有多少內存？請發表文章A）SHOW GLOBAL STATUS; B）顯示全局變量;

來源

2018-02-05 13:37:43

InnoDB：page_cleaner：1000ms預期循環花費了xxx毫秒。設置可能不是最佳

回答

相關問題