Percona server與騰訊雲cdb熱點更新性能壓測

2019 年 11 月 14 日
筆記

特別聲明

本文針對騰訊雲資料庫cdb做熱點單行更新性能壓測，不涉及其他可用性，功能性介紹。本文的壓測結果也不作為任何潛在雲客戶的購買建議(我可木有收廣告費)。本文僅代表個人壓測結果，感興趣的朋友可以自行壓測。

一壓測目的

鑒於有贊業務迅速發展，對於秒殺場景有比較強烈的需求,當前我們的自建資料庫使用Percona Server 5.7.22 版本，在應對快手直播以及秒殺場景下，單行更新性能有點吃緊。因此我對比有贊自建資料庫和騰訊 cdb在熱點秒殺單行更新場景下的性能差異。

二壓測實例配置

2.1 cdb的配置

OS CPU 56core 2.50GHz 文件系統 /data1 ext4 noatime,acl,user_xattr 1 2 MySQL版本 5.7.18-txsql-log 20190203

參數

binlog_format[ROW] max_binlog_cache_size[17179869184G] max_binlog_size[256M]    open_files_limit[102400] sync_binlog[0] table_definition_cache[768]    table_open_cache[512] thread_cache_size[512] innodb_adaptive_flushing[ON]    innodb_adaptive_hash_index[ON] innodb_buffer_pool_instances[8]    innodb_buffer_pool_size[22G] innodb_file_per_table[ON] innodb_flush_log_at_trx_commit[2]    innodb_flush_method[O_DIRECT] innodb_io_capacity[20000] innodb_lock_wait_timeout[7200]    innodb_log_buffer_size[64M] innodb_log_file_size[1G] innodb_log_files_in_group[2]    innodb_max_dirty_pages_pct[75.000000] innodb_open_files[1024] innodb_read_io_threads[12]    innodb_stats_on_metadata[OFF] innodb_thread_concurrency[0] innodb_write_io_threads[12]

2.2 youzan 自建資料庫

OS CPU 56core 2.40GHz 文件系統 /dev/sdb1 /srv ext4 defaults,noatime 1 2 MySQL版本 5.7.22

binlog_format[ROW] max_binlog_cache_size[4G] max_binlog_size[1G]    open_files_limit[65535] sync_binlog[0] table_definition_cache[2000]    table_open_cache[4096] thread_cache_size[1024]    innodb_adaptive_flushing[ON] innodb_adaptive_hash_index[ON] innodb_buffer_pool_instances[8]    innodb_buffer_pool_size[10G] innodb_file_per_table[ON] innodb_flush_log_at_trx_commit[2]    innodb_flush_method[O_DIRECT] innodb_io_capacity[20000] innodb_lock_wait_timeout[50]    innodb_log_buffer_size[16M] innodb_log_file_size[2G] innodb_log_files_in_group[2]    innodb_max_dirty_pages_pct[75.000000] innodb_open_files[4096] innodb_read_io_threads[24]    innodb_stats_on_metadata[OFF] innodb_thread_concurrency[0] innodb_write_io_threads[24]

注意

cdb的資料庫 table_open_cache table_definition_cache 給的比較小,如果是真正的業務使用上千個表的話，性能會有損耗。關於 bps 因為是單行測試，沒有和記憶體大小沒有太大關係，而且10g已經足夠大。該差異可以忽略。

三壓測案例

熱點更新 ,使用 mysqlslap 多並發更新同一行。

CREATE TABLE `seckill` (    `id` int(11) DEFAULT NULL,    `num` bigint(20) DEFAULT NULL  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;    insert into seckill(id,num) values(1,200000000000000);    mysqlslap  -uroot -hxxxxx -P 3306 --create-schema='test' --query='begin;update seckill set num=num-1 where id =1 and num>1;commit;' --number-of-queries=1000000  --concurrency=xx

主要模擬資料庫在並發數分別設置為:36,48,56,64,72,96,144,192,256個活躍會話下的性能表現，總共壓測兩組，普通模式和優化模式。其中

普通模式核心參數

innodb_flush_log_at_trx_commit=1 sync_binlog=1 innodb_deadlock_detect=on

優化模式核心參數

innodb_flush_log_at_trx_commit=2 sync_binlog=0 innodb_deadlock_detect=off

四壓測結果

普通模式

普通模式下設置"雙1" ，死鎖檢測開啟，cdb性能表現比percona server 高約15%-50%。隨著並發數增加，兩者差距減少。

優化模式

優化模式下設置非"雙1"，死鎖檢測關閉，cdb在並發數小於70的時候性能表現比percona server 高約8%。並發數大於70總有，percona server性能比 cdb 高約10%。

和相關人員溝通了解到他們做如下程式碼級別的性能優化:

並行寫 redo , mtr_commit 提交的時候，先計算其所佔 log_sys->buf 所在位置，釋放 log_sys->mutex，然後再將內容 Copy 到緩衝區，提升並發量；非同步刷 redo，即用戶執行緒不需要同步等待 redo log 落盤，而是通過系統執行緒統一刷 redo ，將同步 IO 等待操作轉化為非同步操作； Innodb 執行緒調度優化，實現了基於資源的鎖調度系統，而不是傳統的 FIFO 鎖調度；

五小結

總體而言 cdb 熱點更新的性能表現上還是很有競爭力的。限於時間和精(jin)力(qian)(主要是該實例比較貴 151RMB/每小時) 我沒有做sysbench的通用壓測。有興趣的朋友可以自己壓測對比一下看看。

雲的資料庫有很多優勢，備份，ha，監控，升級降級等各種常規運維都自動化，簡化DBA很多事情。劣勢是習慣自建運維的人而言云資料庫也有很多限制比如宿主機黑盒，底層cpu 個數，iops，各種安全規則等等。給實際操作帶來很多不便利比如遇到非業務導致的性能問題，大概率只能聯繫雲dba支援排查了，而且他們的響應時間也是個問題。

後續寫寫如果從自建資料庫遷移到雲資料庫要做哪些事情。大家也可以聊聊上雲之後，作為DBA 你感覺到有什麼改變？