3 3 27 33 87 133 213常見問題MongoDB云數(shù)據(jù)庫常見問題診斷Q:連接實例提示網(wǎng)絡(luò)超時?#/u01/mongodb_current/bin/mongo--:3717--authenticationDatabaseatconnect(src/mongo/shell/mongo.js:181:14)4at(connect):1:6atsrc/mongo/shell/mongo.js:181exception:connectfailedtelnetQ:連接實例示鑒權(quán)失??？$mongo--host:3717--authenticationDatabaseadmin-urootat(auth):7:2atsrc/mongo/shell/2.連接的用戶跟數(shù)據(jù)庫不匹配，比如root用戶是admin數(shù)$mongo--host:3717atshellHelper.show(src/mongo/shell/utils.js:630:33)atshellHelper(src/mongo/shell/utils.js:524:36)at(shellhelp2):1:1atsrc/mongo/shell/mongo.js:47$mongo--host:3717--authenticationDatabaseadmin-usmg-100101/:3717,dds-uf69:3717--authenticationDatabase故障等都有可能導致主備切換，在生產(chǎn)環(huán)境應(yīng)該使用副本集的方式來正確連接MongoDB來實現(xiàn)高可用。$mongo--host:3717failed連接數(shù)問題8."intern{{},Q:生產(chǎn)環(huán)境連接數(shù)快滿了，如何限制每個ECS到實例的連接數(shù)量？3.正在跑一些計算量很大的mapreduce仍然無法決問云數(shù)據(jù)庫MongoDBFAQ應(yīng)的MongoDB里面會有ACIDfunctiongetCollectionDiskSpaceFragRatio(varres=db.getSiblingDB(dbname).runCommand({});Object.keys(res.indexDetails).forEach(function(key){varsize=res['indexDetails'][key]['block-manager']['filebytesavailableforreuse'];});varsize=res['wiredTiger']['block-maprint("collectionand}}c);getCollectionDiskMongoDB主備切換時機是什么時候？MongoDB主備切換流程是怎樣的？2.如果超出ElectionTimeoMongoDB寫入一個文檔有些步？Modifieddbpages'innodb_status.3249"Logsequencenumber270334432414027 SETSET[GLOBAL]character_set_client=utf8;SET[GLOBAL]character_set_connection=utf8;SET[GLOBAL]character_set_databaseSET[GLOBAL]character_set_resultsSET[GLOBAL]character_set_server效mysql>UPDATEtSETc=CONCAT(becomeassociatedwithaclientconnectionbutforwhichauthenticationoftheclientuserhasnotyetbeendone。意現(xiàn)象分析原因RDSPostgreSQLFAQ你的字段以前定義的時候是不是用了大小寫并且在PostgreSQL中如何設(shè)置與vacuumf與vacuumfreeze相關(guān)的參數(shù)主2.vacuum_freeze_table_age3.autovacuum_freeze_max_age可以被簡單理解為每個元組兩次被freeze之間的XID差值的一個最小值。增大該參數(shù)可以避免一些無用的freeze操作，減小該參數(shù)可以使得在表必須被強制普通的vacuum使用visibilitymap來快速定位哪些數(shù)據(jù)頁需要被掃描，只會掃描那些臟頁，其他的數(shù)據(jù)頁即使其中元組對應(yīng)的xmin非常舊也不會被掃vacuum_freeze_table_age表示表的年齡大于該值時，會進行aggressive當表的年齡超過vacuum_freeze_table_age則會aggressivevacuum當元組的年齡超過vacuum_freeze_min_age后可以進行freeze為了保證整個數(shù)據(jù)庫的最老最新事務(wù)差不能超過vacuum之間的新老事務(wù)差不能超過20億，即兩次aggressivevacuum之間表的年齡增長（vacuum_freezvacuum_freeze_min_ag于等于autovacuum_freeze_max_age，則元組對應(yīng)的表也就是說，在經(jīng)過autovacuum_freeze_max_age-vacuum值得一提的是，vacuum_freeze_table_age設(shè)置的值如果比作用。所以默認的規(guī)則，vacuum_freeze_table_age要設(shè)置的比autovacuum_freeze_max_age小。但是也不能太小，太小的話會造成頻繁的min(vacuum_freeze_table_age,0.95autovacuum_freeze_max_age)。所以官方文檔推薦vacuum_freeze_table_age=0.95autovacuum_autovacuum_freeze_max_age和vacuum_freeze_min_age的差但是如果設(shè)置autovacuum_freeze_max_age和vacuum_freeze_table_age過占用更多的空間。例如，我們把autovacuum_freeze_max_age設(shè)置為最大值/questions/20039856/import-excel-data-into-postgrePostGresql上去,需要做哪些準備呢?目前有沒有比較好用地址為/aliyun/rds_dbsync/blob/master/README.md3.使用mysql2postgres改之。我遇到的問題就只有一個，mysql列定義中的zerofill需要手工去6.-v-nt--complete-insert=TRUE--compact--no-create-info--skip-quote-names[dbname老一些版本的pgsql如果不支持批量插入的standard_conforming_str云數(shù)據(jù)庫RedisFAQMongoDB性能問題MongoDB磁盤IO高問題阿里云數(shù)據(jù)庫MongoDB的IOPS使用率/document_detail/57141.html通過點擊"監(jiān)控信息"可以查看到當前的IOPS使用量，因為絕大部分情況下阿量=data_iops=log_iops。通過db.serverStatus().systemInfo命令可以查看IO相關(guān)的其他指標監(jiān)控，不廠商負責，用戶只需要核心關(guān)注業(yè)務(wù)的正確使用MongoD您可以通過mongostat或者阿里云數(shù)據(jù)庫自治服務(wù)DAS實時查看當前的cachedirty，目前阿里云數(shù)據(jù)庫MongoDB暫不支持cachedirty歷史情況查看。如果/v4.2/reference/program/mongostat//manual/core/journaling//manual/reference/write-concern/一般很難事先預估熱數(shù)據(jù)與CacheSize的實例費用的一個折衷。通用經(jīng)驗下，我們建議在MongoDB實例在日常態(tài)運行必然很大。另一方面，過多累贅的Index創(chuàng)建也會產(chǎn)生更多的數(shù)據(jù)規(guī)模，導致WiredTigerCache只能緩存更小的熱數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)寫操作過程中也同樣多一于這部分內(nèi)容，可以參考：/manual/indexes/5業(yè)務(wù)架構(gòu)和運維優(yōu)化5.1控制并發(fā)寫入/取線數(shù)MongoDB是多線程應(yīng)用，但是我們并不推薦"極致壓榨"MongoDB實例本身的通過數(shù)據(jù)的水平拆分來線性擴容MongoDB的寫5.2盡可能免峰值寫入部分業(yè)務(wù)，比如日志系統(tǒng)的定期寫入或者游戲系統(tǒng)中用戶信息的批量持久化，容易造成一個一個IOPS峰值。針對這種情況，在當前的實例配置不足以支撐5.3免業(yè)務(wù)高峰期間做運維作一些對性能影響較大的運維操作本質(zhì)上也是認為造成了IOPS峰值，在無法避免的情況下，應(yīng)該盡可能避免在業(yè)務(wù)高峰期執(zhí)行。常見的容易引起IO高峰的MongoDB空間使用問題概述1看空間使用在MongoDB控制臺的“基本信息”頁中會顯示實例的總1.3監(jiān)控分析實例的角色?？梢酝ㄟ^點擊"監(jiān)控信息"，選擇對應(yīng)的角色查看M其中一個MongoDB物理節(jié)點的空間使用由兩大塊組成，分別為data_size和log_size,其中這里的data_size是數(shù)據(jù)磁盤使用空間(不包括local庫)，主要包ins_size=data_size+log_sizedb.stats()，db.$collection_name.stats()以外，我們推薦使用阿里云MongoDB/document_detail/162422.htmll/manual/reference/method/l/manual/reference/method/db.collection.stats/l/manual/reference/method/db.collel/manual/reference/method/db.collectl/manual/reference/method/db.collection.totalS2分片群間使用率的概念。所以控制臺不再提供"基本信息"中的空間使用率。2.1監(jiān)控分析configserver節(jié)點不會成為空間瓶頸，建議選擇忽略，直接查看各個sha2.2詳分析分片集群的空間使用的詳細查看方法與副本集模式略有不同，需要逐個登錄各個shard通過命令查看，在每個分片上的空間使用情況詳情就與副本集情況完本文后續(xù)章節(jié)會重點帶您了解和深入分析“不同分片下空間使用不均衡”，“同一2.確認引起空間增長的主要源頭，比如是日志3.確認當前的增長是否符合預期，針對不符合預期的大量寫入場景做應(yīng)用分4.確認當前的數(shù)據(jù)是否存在大量碎片，能否通過回收碎片的方式回收空間。5.確認是否需要做磁盤空間擴容，或者部署定時歷史數(shù)據(jù)刪除或TTLIndex。6.歷史數(shù)據(jù)大量刪除完成，通過compact或者重做副本集的方式回收碎片空db.runCommand({compact:"collectionName"})。l/manual/reference/commal/document_detail/96530.html如前文所述，在大量remove的場景下我們會需要使用compac間。然而在極端場景下，compact操作雖然提示成功了，但實際上磁盤空間并并不是只要存在碎片就一定能回收成功。compact的基本原理并不是立馬開辟新的空間存放數(shù)據(jù)來替換原來的文件，而是將數(shù)據(jù)不斷地往前面的空間空洞挪在大量刪除數(shù)據(jù)后，compact無法回收索引文件，只對數(shù)據(jù)文件生效。這個可以通過使用命令db.$table_name.stats().indexSizes或者直接查看索引物理文src/mongo/util/processinfo_linux.cpp74'Location13538:coufull-timediagnostic以將內(nèi)核版本升級到4.0以上，或者可以通過重啟mongod進程臨時解體的bug鏈接參考：/browse/WT-408340現(xiàn)主備延遲的情況下，實際oplog可以使用的大小不再受限于配置文件定義的固定集合大小，理論上可以達到用戶申請磁盤容量的20%。這就造成了另外,處于備份和恢復效率的考慮,阿里云MongoDB使用物理備份的方式在Hidden備份mongodb實例,期間會涉及到大量的chepoint導致占用了更多的數(shù)據(jù)和日志空間。針對以上場景，當空間占用量不是特別大的話通常建議直接忽略即可。也可以uselocaldb.runcommand((compact:"oplog.rs",force:true})4不同分片之間的空間使用不均衡4.1shardingkey類型選彝不合疆在一個分片集群中，片鍵類型的選擇至關(guān)重要，一般會使用hash分片或者會比ranged好很多，因為根據(jù)不同的key值，MongoDB通過內(nèi)部的哈希41的一個現(xiàn)象：新插入的數(shù)據(jù)在一個熱點的chun的數(shù)據(jù)寫入chunkC所在分片，當chunkC寫滿以后會在本分片中split出新的chunk，后續(xù)通過集群負載均衡器Balan費大量的時間和IO,在一個高并發(fā)寫入的場景下，數(shù)據(jù)的負載均衡速度可能跟42l/manual/core/sharding-shard-key/l/manual/core/hashed-sharding/l/manual/core/ranged-sharding/4.2shardingkey字段選擇不合理通過sh.status()可以看到各個分片上的chunk數(shù)量基本一致，但實際上絕大部分數(shù)據(jù)都只存在部分chunk上，導致這些熱點chunk2019-08-27T13:31:22.076+0800W2019-08-27T13:31:22.076+0800WSHARDING[conn12682019-08-27T13:31:22.076+0800WSHARDING[conn12682019-08-27T13:31:22.076+0800WSHmongos負載均衡主要考慮的是各個際數(shù)據(jù)嚴重傾斜。因為一個chunk內(nèi)shardKey幾乎完全相同但又觸發(fā)到64M的chunk分裂閾值，這時就會分裂出一個空的chunk。久而久之，雖然chunk的數(shù)量變多了并且完成了chunk的遷移，但實際上遷移走的chunk都是空的在遷移chunk時基于代價的考慮，認為空chunk遷移代價更低，空的chunk遷移)43l/manual/core/sharding-data-partitioning/l/manual/tutorial/split-chunks-in-sharded-cluster/MongoDB分片集群允許部分db做sharding，部分然會帶來這樣的一個問題：不做shading的db的數(shù)據(jù)必然只能存在一個分片mongos集群導入到一個新的mongos集群，而邏輯導入過程中444.4大規(guī)的movechunk作可能引起分片的磁蜜占用不均movechunk的本質(zhì)是向目標端shard寫入數(shù)據(jù)后remove源端數(shù)據(jù)。默認情況行一段時間后才做了Sharding。從原理上說movechunk引起的空間碎片和大規(guī)模delete一樣，因此針對出現(xiàn)大量movechunk或者remove文檔的情況，可以針對該分片進行compact操作來回收碎片空間，正常情況下compact后數(shù)據(jù)會進行重組進而回收文件的碎l/manual/tutorial/migrate-chunks-in-sharded-cll/manual/tutorial/manage-sharded-cluster-bala或副本集模式下的節(jié)點數(shù)據(jù)量超過3T就必須業(yè)務(wù)拆分或者升級至分片集群，45阿里云MongoDB在副本集部署模式下即將支持云盤以實現(xiàn)計算存儲分離。在云盤存儲下，單個節(jié)點的數(shù)據(jù)存儲上限將達到數(shù)十T，以及云原生架構(gòu)基本上不會再有備庫延遲問題，所以阿里云MongoDB內(nèi)核層面不再對oplog做定制化改造，與官方的"固定集合"形態(tài)保持一致，備庫延遲引起的oplog放當故障發(fā)生時可繞過耗時的OSS物理備份下載，46MongoDB內(nèi)存高問題概述要引起用戶足夠的關(guān)注，因為它往往是業(yè)務(wù)側(cè)的變動引起，突發(fā)的內(nèi)存飆升容到內(nèi)存，其作為一個DBMS，還需要負責客戶端元數(shù)據(jù)、存儲引擎等很多工作，這些工作都涉"Wiredtiger存儲引擎"與"客戶端連接及請求的處理"。本文將由淺入深幫您查看、分析和優(yōu)化云數(shù)據(jù)庫MongoDB的內(nèi)存使用。471.1監(jiān)控分析保持一致；"bytes_read_into_cache"表示每秒從磁盤將數(shù)據(jù)加載到內(nèi)存的大48//virtual表示該mongo的內(nèi)存使用使用詳情，可以通過的db.serverStatus().wiredTiger.cdb.serverStatus().tcmalloc進行查看，/manual/reference/command/serverStatus/是其中最大的一部分，引擎內(nèi)存最大使用內(nèi)存由配置參數(shù)cachesize決定。為了兼容性能和安全性，阿里云數(shù)據(jù)庫MongoDB為cachesize設(shè)置的大小默認為申請內(nèi)存的60%左右，由于存在向上取cacheSizeGB4911dds.mongo.standard25dds.mongo.2xmonopolize避免內(nèi)存使用滿了阻塞用戶請求，這個過程稱為"eviction"。默認值eviction_targeteviction_triggereviction_dirty_target5eviction_dirty_triggereviction_dirty_trigger,dirty>=20%，并一直持續(xù)，說明內(nèi)存淘汰壓力很大，用戶的請求線程會阻塞參您可以通過mongostat或者阿里云數(shù)據(jù)庫自治服務(wù)DAS實時查看當前的/v4.2/reference/program/mongostat/tcmalloc優(yōu)先會還到自己的cache里；然后逐步再歸還給操作系統(tǒng)。所以關(guān)于tcmalloc未歸還OS的內(nèi)存大小，可tcmalloccache大小=pageheap_free_bytes+tota/archives/34751數(shù)量很多，這一塊占用的內(nèi)存也不容忽視。尤其在MongoDB4.0以前全量邏輯備份期間可能打開非常多的文件句柄并且未能及時歸還OS導致內(nèi)存快速上漲，或者低版本的MongoDB在大量刪除c/browse/WT-4336正常的業(yè)務(wù)數(shù)據(jù)寫入情況下，Secondary會維持一個最大約256M的buffer用Secondary并行回放createinl/manual/core/index-creation/#index-build-impact-on-database-perfol/manual/core/index-creation/#index-build-procdb.serverStatus().metrics.query.planCacheTotalSizeEstim首先需要強調(diào)一點，內(nèi)存優(yōu)化并非是為了盡可能減少內(nèi)存使用，而是統(tǒng)性能完全沒問題的前提下，內(nèi)存使用盡可能穩(wěn)定和夠用，從而在機器資源和排錯實戰(zhàn)RDSMySQL活躍線程數(shù)高問題table_open_cache_instances（需要重啟）參數(shù)。前正在執(zhí)行的DDL都可以解決。2.4行鎖沖突行鎖沖突導致的活躍線程數(shù)的表現(xiàn)是Innodb_row_lock_waits和也可以通過執(zhí)行showengineinnodbstatus查看RDSMySQL慢SQL問題概述最好的情況是自頂向下了解業(yè)務(wù)，以及每個業(yè)務(wù)涉及的SQL，這樣就能厘清業(yè)前言判斷查詢的性能就是看查詢執(zhí)行的時間，這個時間針對不同的業(yè)務(wù)要求上也有就越多。同樣一個業(yè)務(wù)場景不同的架構(gòu)設(shè)計、數(shù)據(jù)庫表索引設(shè)計，由不同的人高的性能。最好的情況是自頂向下了解業(yè)務(wù)，以就能厘清業(yè)務(wù)和數(shù)據(jù)庫負載的關(guān)系；也能找到短板，并對短板做有針對性的優(yōu)細請參考文檔/product/xtrace。全鏈路監(jiān)控和全鏈路壓下面針對數(shù)據(jù)庫的各種導致SQL慢的排查思路，原因和解決方法進行闡述：如果監(jiān)控比較細微或?qū)憫?yīng)時間比較敏感的話，/document_detail/95667.html。如果資源使用利用率各考/document_detail/96061.html。方鏈接/doc/refman/5.6/en/explain-output.html#explain-池耗盡，影響整個業(yè)務(wù)。查看近期有沒有修改過參數(shù)的控制臺路徑是選擇“云數(shù)/documen參數(shù)buffer_pool_instances/join_buffer_size/AHI等的變化也會導致性能變慢。關(guān)于這方面的文章比較多，這里不一一贅述。查看近期有沒有修改過參數(shù)的控/documen2存失效緩存的設(shè)計在架構(gòu)上很好地承擔了大量的查詢，但并不能保證緩存命中率常高。這樣的情況RDSMySQL可以用SQL限流、打開線程池、語句并行隊/docu參考/document_detail/164859.html。這種情況可以從磁盤空間，或SQL洞察/慢查詢里找到對應(yīng)語句。如從binlog拖數(shù)這種情況可以通過監(jiān)控指標的變化或SQL洞察/慢查詢里找到對應(yīng)語句。2.4未關(guān)閉的事務(wù)如果某個任務(wù)突然變慢，應(yīng)該考慮是否有鎖阻塞的問題?？梢酝ㄟ^“如何定位長如果負載隨時間有規(guī)律性變化，則瓶頸隨負3SQL異常影響SQL語句執(zhí)行的因素大概分為以下幾類庫引擎特性、查詢條件的區(qū)分度、結(jié)果集大小、表的數(shù)據(jù)量、CPU時間。3.1業(yè)務(wù)場發(fā)生改變應(yīng)用有沒有進行過發(fā)布，需要看下應(yīng)用的部署日志或發(fā)布系的方法參考文檔/document_detail/96123.html。同時段的SQL可以跟昨天同時間對比，或上周同時間對比。借助SQ/document_detail/99478.html。3.2掃描行數(shù)多這種情況可以通過監(jiān)控指標的變化或SQL洞察/慢查詢里找到對應(yīng)語句。3.4囊引不合建議分批執(zhí)行或放在業(yè)務(wù)低峰期執(zhí)行，當然了盡量帶上WHERE條件。如下圖7監(jiān)控指標擇“云數(shù)據(jù)庫RDS”->選擇“實例列表”->點擊實例鏈接，進入實例頁面->選擇“監(jiān)控與報警”->選擇“資源監(jiān)控”/“引擎監(jiān)控InnoDB緩存讀命InnoDB緩沖池的讀命中率、使用率以及緩MySQL執(zhí)行語句BufferL每秒從InnoDB表讀取、更新、刪除、插入的行數(shù)因為上面已經(jīng)有路徑或幫助文檔，這里不再贅述。在實際業(yè)務(wù)場景會比上面提到的情況復雜的多，有可能是多種情況的巡檢維護RDSMySQL巡檢到底巡檢什么作者tplinux作系統(tǒng)巡檢如果沒有zabbix建議使用sar這個小工[root@mongodb01data]#sar-u103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:26:44AMCPU%user%nice%system%iowait%steal%idle10:26:54AMall0.550.000.415.610.0393.40[root@mongodb01data]#sar-r103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:28:36AMkbmemfreekbmemused%memusedkbbufferskbcachedkbcommit%commit10:28:46AM2230843265825299.32143468165490801877406837.81[root@mongodb01data]#sar-b103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:30:25AMtpsrtpswtpsbread/sbwrtn/s10:30:35AM67.1761.635.5416169.9986.20```1.4系統(tǒng)交換活動信息監(jiān)控[root@mongodb01data]#sar-w103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017x86_6410:31:56AMproc/scswch/s10:32:06AM0.002234.44`[root@mongodb01data]#ll/var/log/messages[root@mongodb01data]#ll/var/log/dmesgMySQLerrorlogMySQL慢查詢?nèi)罩镜刃畔?innodb_buffer_pool_size""sync_binlog"'binlog_format''innodb_flush_log_at_trx_commit':'read_only':'log_slave_updates''innodb_io_capacity''query_cache_type''query_cache_size''max_connections''max_connect_errors''server_id'showfullprocesslistshowglobalstatusshowengineinnodbstatus\Gtaill-fshow.logwait等待Innodb_buffer_pool_wait_free80Innodb_log_waits鎖等待Innodb_row_lock_current_waits當前等待的待鎖定的行數(shù)Innodb_row_lock_waits一行鎖定必須等待的總時長Table_locks_waited表鎖等待次數(shù)mysql鎖監(jiān)控表級鎖Table_locks_waitedTable_locks_immediate行級鎖Innodb_row_lock_current_waits當前等待鎖的行鎖數(shù)量Innodb_row_lock_time請求行鎖總耗時Innodb_row_lock_time_avg請求行鎖平均耗時Innodb_row_lock_time_max請求行鎖最久耗時Innodb_row_lock_waits行鎖發(fā)生次數(shù)等待事件Innodb_buffer_pool_wait_free/Innodb_log_waits臨時表/臨時文件Created_tmp_disk_tables/Created_tmp_files打開表/文件數(shù)Open_files/Open_table_definitions/Open_tables并發(fā)連接數(shù)Threads_running/Threads_created/Threads_cached81Aborted_clients客戶端沒有正確關(guān)閉連接導致客戶端終止而中斷的連接數(shù)Aborted_connects試圖連接到mysql服務(wù)器而失敗的連接數(shù)BinlogBinlog_cache_disk_use使用臨時二進制日志緩沖但超過binlog_cache_size值并使用臨時文件Binlog_cache_use使用臨時二進制日志緩沖的事務(wù)數(shù)量Binlog_stmt_cache_disk_use當非事務(wù)語句使用二進制日志緩存Binlog_stmt_cache_use使用二進制日志緩沖非事務(wù)語句數(shù)量鏈接數(shù)Connections試圖連接到（不管成不成功）mysql服務(wù)器的鏈接數(shù)臨時表Created_tmp_disk_tables服務(wù)器執(zhí)行語句時在硬盤上自動創(chuàng)建的臨時表的數(shù)量。是指在排序時，內(nèi)存不夠用(tmp_table_size小于需要排序的結(jié)果集)，所以需要創(chuàng)建基于磁盤的臨時表進行排序Created_tmp_files服務(wù)器執(zhí)行語句時自動創(chuàng)建的內(nèi)存中的臨時表的數(shù)量索引Handler_commit內(nèi)部交語句Handler_rollback內(nèi)部rollback語句數(shù)量Handler_read_first索引第一條記錄被讀的次數(shù)如果高它表明服務(wù)器正執(zhí)行大量全索引掃描82Handler_read_key根據(jù)索引讀一行的請求數(shù)如果較高說明查詢和表的索引正確Handler_read_last查詢讀索引最后一個索引鍵請求數(shù)Handler_read_next按照索引順序讀下一行的請求數(shù)Handler_read_prev按照索引順序讀前一行的請求數(shù)Handler_read_rnd根據(jù)固定位置讀一行的請求數(shù)如果值較高說明可能使用了大量需要mysql掃整個表的查詢或沒有正確使用索引Handler_read_rnd_next在數(shù)據(jù)文件中讀下一行的請求數(shù)如果你正進行大量的表掃該值會較高innodbInnodb_buffer_pool_wait_free一般情況通過后臺想innodbbufferpool寫Innodb_log_waits日志緩沖區(qū)太小我們在繼續(xù)前必須先等待對它的清空Innodb_row_lock_current_waits當前等待鎖的行鎖數(shù)量Innodb_row_lock_time請求行鎖總耗時Innodb_row_lock_time_avg請求行鎖平均耗時Innodb_row_lock_time_max請求行鎖最久耗時Innodb_row_lock_waits行鎖發(fā)生次數(shù)Open_table_definitions被緩存的.frm文件數(shù)量Opened_tables已經(jīng)打開的表的數(shù)量如果較大table_open_cache值可能太小Open_tables當前打開的表的數(shù)量Queries已經(jīng)發(fā)送給服務(wù)器的查詢個數(shù)83Select_full_join沒有使用索引的聯(lián)接的數(shù)量如果該值不為0你應(yīng)該仔細檢查表的所有Select_scan對第一個表進行完全掃的聯(lián)接的數(shù)量Slow_queries查詢時間超過long_query_time秒的查詢個數(shù)Sort_merge_passes排序算法已經(jīng)執(zhí)行的合并的數(shù)量如果值較大增加sort_buffer_size大小線程Threads_cached線程緩存內(nèi)的線程數(shù)量Threads_connected當前打開的連接數(shù)量Threads_created創(chuàng)建用來處理連接的線程數(shù)Threads_running激活的（非睡眠狀態(tài)）線程數(shù)INFORMATION_SCHEMA.INNODB_LOCKS;INFORMATION_SCHEMA.INNODB_LOCK_WAITS;參考一下《老司機帶你體驗SYS庫多種新玩法'SELECTtable_schema,table_name,engine,Auto_incrementFROMinformation_schema.tableswhereINFORMATION_SCHEMA.TABLE_SCHEMAnotin("information_schema","performance_schema","mysql")'84參考一下《老司機帶你體驗SYS庫多種新玩法2.5存儲引是否為innodbINFORMATION_SCHEMA.TABLESengine=inn2.6MySQL主從檢測2.6.1主從狀態(tài)2.6.2主從是否延遲Master_Log_File==Relay_Master_Log_File&&Read_Master_Log_Pos==Exec_Master_Log_Pos三高可用巡檢3.2中間件的巡檢總結(jié)本的巡檢是避免不了的，如果有其他的巡檢姿勢也歡迎一起討論。順便前幾天（因為客戶的環(huán)境不能直連linux但可以直連MySQL）/enmotplinux/On-Site-Inspection85RDSMySQL運維之小版本升級概述任何軟件滿足客戶的需求都不是一蹴而就的，都是通過版本迭代完善功能和優(yōu)在以往我們遇到過很多版本升級遇到的問題，所以這篇文章就來聊聊如何少踩升級方法/document_detail/96060.html。86小版本的升級可以用自動升級和手動升級兩種：自動升級會在運維時間自動幫/document_detail/96059.html。哪些小版本需要升級？升級需要多長時間？需要原地修改配置就可以，比較快。跨機升級的完整時間取決于實例大小和備升級對應(yīng)用的影響？87性能問題RDSMySQL實例IO高問題概述存儲形態(tài)InnoDBAIO實現(xiàn)了一套獨立的IO系統(tǒng)來處理數(shù)據(jù)頁的讀取和寫入，如果SQL882.1高吞吐的寫入89innodb_max_dirty_pages_pctinnodb_max_dirty_pages_pct_lwminnodb_io_capacity_max90取的數(shù)據(jù)量非常大，可能會造成很大的讀IO吞吐。緩可以從自治眼務(wù)->性趨勢看bufferpool命中率：91事務(wù)只有在提交時才會寫binlog文件，如果存在大事務(wù)，比如一條deletesql優(yōu)化議93RDSMySQL實例空間問題概述實例的空間使用率是RDSMySQL用戶日常需要重點關(guān)注的監(jiān)控項之一。如果庫備份無法正常完成、存儲空間擴容任務(wù)的執(zhí)行耗時可能更長等。一般來說，有當前的空間使用總量，沒有具體的各類數(shù)據(jù)分別占用空間大小的信息，也沒1.1.2監(jiān)控與疆警94的各類數(shù)據(jù)占用的磁盤空間大小的信息，并且會顯示各部分空間大小的歷史變其中磁盤空間總體使用量即對應(yīng)當前實例實際已經(jīng)使用了的所有存儲空間總量，數(shù)據(jù)空間使用量臨時文件空間使用量系統(tǒng)文件空間使用量詳細的空間使用情況，包括數(shù)據(jù)與日志的空間使用對比、空間使用的歷史變化95這個列表中的統(tǒng)計，則是針對數(shù)據(jù)庫中的表所使用的數(shù)據(jù)文件保留大小數(shù)據(jù)空間索引空間未使用空間需要注意的是上面列表中的空間大小是從統(tǒng)計信息中采集的，和真實的空間大1.2命令行如何查看表空間962.1.2有大字段錄位置又沒有新的記錄插入，就可能造成空間沒有被很好的利用?？梢酝ㄟ^972.PolarDB采用分布式存儲也支持非常大的存儲空間，且按需自動擴容。3.RDS創(chuàng)建時選xengine引擎，xengRDSPostgreSQLRDSPostgreSQL實例IO高問題概述982IO高的常見原因2.1SQL掃描行高沖區(qū)進行返回，如果數(shù)據(jù)未在共享緩沖區(qū)命中就會需要從磁盤中進行讀取，讀的IOPS比較高，說明大量的從磁盤讀取數(shù)據(jù)到數(shù)據(jù)庫共享緩沖區(qū)中，可能存2.1.2查看引監(jiān)控2.1.3查看性能洞察99可以找到對應(yīng)的問題SQL，可以對問題SQL進行索引2.2導入數(shù)據(jù)2.3.2看引擎監(jiān)控作行數(shù)此時發(fā)現(xiàn)操作行數(shù)沒有明顯增加，此時可以懷疑是vacuum或者CheckPointheap_blks_scannedmax_dead_tuples通過pg_stat_user_tables也可以查看歷史vacuidx_tup_fetch|last_vacuum||vacuum_countautovacuum_countautoanalyze_countautovacuum_vacuum_cost_delay指的是vacuum動作代價達到autovacuum_vacuum_cost_limit時vacuum進程休息的時間單位是ms。autovacuum_vacuum_cost_limit指的是vacuuCheckPoint指的是將數(shù)據(jù)庫共享緩checkpoint_write_time|9109283buffers_backend_fsync|0DSMySQL內(nèi)存使用問題概述存使用率過高會有OOM風險，如果bufferpool命中率低，大量的數(shù)據(jù)頁無法到bufferpool配置參數(shù)的限制，但是還有很多內(nèi)存是和調(diào)整的，比如內(nèi)存臨時表消耗的內(nèi)存、prefetchcache、tablec索引、行鎖對象等，詳細的內(nèi)存占用和相關(guān)參數(shù)限制參考MySQL官方文檔。updateperformance_schema.setup_instrumentssetenabmemory_summary_by_account_by_event_namememory_summary_by_host_by_event_namememory_summary_by_thread_by_event_namememory_summary_by_user_by_event_namememory_summary_global_by_event_name有這種現(xiàn)象。建議業(yè)務(wù)實現(xiàn)中盡量避免multiplestatements1.數(shù)據(jù)頁沒有足夠的預熱，導致查詢的延遲較高。通常發(fā)生在實例發(fā)2.臟頁累計太多。當當前未刷臟的最老ls會觸發(fā)用戶線程同步刷臟，引發(fā)實例嚴重的性能下降。優(yōu)化方式是業(yè)務(wù)均3.大規(guī)格內(nèi)存實例innodb_buffer_pool_instanc內(nèi)存臨時表大小受到tmp_table_s制后將轉(zhuǎn)化為磁盤臨時表，如果瞬間有大量的連接創(chuàng)建大量的臨時表，有可能建太多表和設(shè)置非常大的table_open_cache參數(shù)。還有自適應(yīng)哈希索引占用的內(nèi)存默認是buffferpoolsize的1/64。如成內(nèi)存上漲，如果碰見內(nèi)存使用率異常增加或?qū)嵗齇OM，您可以參考運維實戰(zhàn)RDSMySQL高并發(fā)場景實戰(zhàn)度上升趨勢。在這么大訪問流量下，所有的核心鏈路的增刪改查都是在數(shù)據(jù)庫近于零》實例和應(yīng)用機器等，判斷能否支撐得住雙11的峰值。需要針對上述的預估做一全鏈路壓測是基于場景化的仿真測試,其數(shù)據(jù)最接近業(yè)務(wù)的系統(tǒng)值，針對全鏈路3性能評測3.4.工具3.5.注意事項2)ECS的網(wǎng)絡(luò)帶寬4架構(gòu)調(diào)優(yōu)4.1.數(shù)據(jù)庫架構(gòu)調(diào)優(yōu)4.2.降低只讀實例和主實例的延遲4）只讀節(jié)點規(guī)格過小5）其他（無主鍵）4.3.提升緩存命中率應(yīng)用簡單可靠應(yīng)用更新無額外性能消耗5實例調(diào)優(yōu)5.1.彈性擴容5.2.參數(shù)調(diào)優(yōu)6.1.版本升級庫存注釋語句隊列語句返回線程池對于高并發(fā)場景，AliSQL使用線程7監(jiān)控報警務(wù)。AliSQL設(shè)計了基于語句規(guī)則的并發(fā)控制，StatementConcurrencyControl,簡稱CCL。2)本地熱Binlog（數(shù)據(jù)庫服務(wù)器上運維實戰(zhàn)RDSPostgreSQL慢SQL問題概述慢SQL會消耗較多的數(shù)據(jù)庫資源，很容易造成數(shù)據(jù)庫的負載增加，慢SQL的這個命令顯示PostgreSQL計劃器為提供的語句所生成的執(zhí)行計劃。該執(zhí)行計劃會顯示將怎樣掃描語句中引用的表—普通的順序掃描、索引掃描等等—以及在引用多個表時使用何種連接算法來把來自每個輸入表的行連接在一起。顯示中最重要的部分是估計出的語句執(zhí)行代價，它是計劃器對于該語句要運行多久的猜測（以任意的代價單位度量，但是習慣上表示取磁盤頁面的次數(shù)）。事實上會顯示兩個數(shù)字：在第一行能被返回前的啟動代價，以及返回所有行的總代價。對于大部分查詢來說總代價是最重要為執(zhí)行器將在得到一行后停止）。此外，如果你用一個LIMIT子的數(shù)量，計劃器會在終端代價之間做出適當?shù)牟逯祦砉烙嫷降啄膫€計劃是真正HashCond:(t2.unique2lverbose:顯示關(guān)于計劃的額外信息。特別是：計劃樹中每個結(jié)點的輸出列列表、模式限定的表和函數(shù)名、總是把表達式中的變量標上它們的范圍表別名，以及總是打印統(tǒng)計信息被顯示的每個觸發(fā)器的名稱。這個參數(shù)默認lbuffers:包括緩沖區(qū)使用的信息。特別是：共享塊命中、讀取、標記為臟和寫入的次數(shù)、本地塊命中、讀取、標記為臟和寫入的次數(shù)、以及臨時塊讀取和寫入的次數(shù)。一次命中表示避免了一次讀取，因為需要的塊已經(jīng)在緩存中找到了。共享塊包含著來自于常規(guī)表和索引的數(shù)據(jù)，本地塊包含著來自于臨時表和索引的數(shù)據(jù)，而臨時塊包含著在排序、哈希、物化計劃結(jié)點和類似情況中使用的短期工作數(shù)據(jù)。臟塊的數(shù)量表示被這個查詢改變的之前未被修改塊的數(shù)量，而寫入塊的數(shù)量表示這個后臺在查詢處理期間從緩存中替換出去的臟塊的數(shù)量。為一個較高層結(jié)點顯示的塊數(shù)包括它的所有l(wèi)timing:在輸出中包括實際啟動時間以及在每個結(jié)點中花掉的時間。反復讀取系統(tǒng)時鐘的負荷在某些系統(tǒng)上會顯著地拖慢查詢，因這個選項關(guān)閉結(jié)點層的計時，整個語句的運行時間也總是會被度量。只有l(wèi)summary:在查詢計劃之后包含摘要信息（例如，總計的時間信息）。當使括從緩存中獲取計劃所需的時間以及重新計劃所需的時間輸出包含和文本輸出格式相同的信息，但是更容易被程序解析。這個參數(shù)例如cost、rows、width等。閱讀執(zhí)行計劃是查詢計劃從下往上閱讀，每個節(jié)點執(zhí)行返回的結(jié)果會傳遞給父也包含掃描函數(shù)結(jié)果集、子查詢結(jié)果等。目前支持的掃描節(jié)點如下:引postgres=>explain(ANALYZE是ms。rows代表實際輸出行。loops代表節(jié)點循環(huán)次數(shù)。掃描時對每行記錄進行過濾操作，過濾條件為classno_index索引對表進行索引掃描的postgres=>explain(ANALYZE,VERBOSE,BUFIndexOnlyScanusingno_indexonpublic.class表明使用public.no_index索引對表進行覆蓋索引掃描。HeapFetches表明需要掃描數(shù)據(jù)塊的文件。當新建表之后，如果沒有進行過vacuum和autovacuum操作，這時還沒有VM文件，而索引并沒有保存記錄的版本信息，索引Index是需要掃描數(shù)據(jù)塊（HeapFetches代表需要掃描的數(shù)據(jù)塊個數(shù)）來獲取版本postgres=>explain(AN描位圖，位圖中每位代表了一個掃描到的數(shù)據(jù)塊，通過位圖可以定位到一些通過計劃可以看出是全表掃描的t1表，過濾條件是可以看出時間從2.6ms降低至0.157msRDSPostgreSQLCPU高問題概述SQLServer實例的CPU使用率持續(xù)較高時，很容易導致數(shù)據(jù)庫訪問卡慢的情資監(jiān)控CPU基本念符合條件的活動的時鐘周期，比如停滯等待IO而導致較高的使用率，CPUCPU高的常見因掃行高通過創(chuàng)建合適索引可以極大程度的降低SQL的響應(yīng)時間以及降低CPU資源的活躍會話高明數(shù)據(jù)庫資源已遠超目前能提供服務(wù)的負載。一般合理的活躍會話數(shù)量是當前RDSPostgreSQL實例IO高問題2.1SQL掃描行高2.1.2查看引擎監(jiān)控2.1.3查看性能洞察可以找到對應(yīng)的問題SQL，可以對問題SQL進行索引3導入數(shù)據(jù)3.1查看資源監(jiān)控的數(shù)據(jù)盤IOPS4Vacuum操作此時發(fā)現(xiàn)操作行數(shù)沒有明顯增加，此時可以懷疑是vacuum或者CheckPointheap_blks_scanned通過pg_stat_user_tables也可以查看歷史vacuseq_tup_readlast_vacuum||||vacuum_count1autovacuum_count|0autovacuum_vacuum_cost_delay指的是vacuum動作代價達到autovacuum_vacuum_cost_limit時vacuum進程休息的時間單位是ms。autovacuum_vacuum_cost_limit指的是vacuuCheckPoint指的是將數(shù)據(jù)庫共享緩checkpoint_write_timeRDSPostgreSQL監(jiān)控實戰(zhàn)基于Pigsty解決實際監(jiān)控問題1為什么需要監(jiān)控系統(tǒng)離開監(jiān)控系統(tǒng)管理數(shù)據(jù)庫就像蒙眼開車，我們通過利用監(jiān)控系統(tǒng)實現(xiàn)對數(shù)據(jù)庫1.1實驗1：利用監(jiān)控系統(tǒng)觀測查詢負載1）使用正常連接數(shù)負載，觀察系統(tǒng)狀態(tài)whiletrue;dopgbench-nv-P1-c4--select-only--rate=1000-T10postgres://test:test@pg-test:5434/test;dowhiletrue;dopgbench-nv-P1-cpostgres://test:test@pg-test:5434/test;done如上圖所示，我們可以看到整個集群的GPS數(shù)據(jù)，主庫上的TPS差不多是50接下來我們稍微改動一下，施加同樣的負載，但使用十倍的連接數(shù)量，原來我們使用了2條讀寫連接，4條只讀連接，現(xiàn)在翻十倍變?yōu)?0條和40條，觀察whiletrue;dopgbench-nv-P1-c40--selectpostgres://test:test@pg-test:5434/test;dopostgres://test:test@pg-test:5433/test;do其中的ActiveClientsbyInstance是按照實例劃分的連接數(shù)。如上圖所示，通過最近5分鐘的情況可以看到，之前使用的是6條連接，2主2從2從，現(xiàn)在postgres://test:test@pg-test:5433/test;do命令二：whiletrue;dpostgres://test:test@pg-test:5434/test;done如上圖所示，我們回到主頁可以看到，監(jiān)控面板目前的負載水平已經(jīng)超過表。當我們將負載定量重新調(diào)低后，整個系統(tǒng)的負載以上實驗反映了監(jiān)控系統(tǒng)的基本功能，它能夠如實地反映用戶給集群施加的負1.2實驗二：重啟主庫，觀察集群領(lǐng)導權(quán)交接我們通常所說的高可用，指的是當一個系統(tǒng)的主庫宕機時，應(yīng)該有一個從庫自動被提升出來接管系統(tǒng)。如果沒有監(jiān)控系統(tǒng)的話，這個操作對我們而言是一個比如我們登錄到第一臺主庫所在的機器上，然后執(zhí)行ssh-tnode-1sudoreboot，可以看到負載都開始報錯。但在短短數(shù)秒內(nèi)，無論是讀流量還是寫流如上圖所示，我們可以看到監(jiān)控系統(tǒng)中原本的主庫pg-test1已經(jīng)被踢掉了，pg-test2被提升成新的主庫了，開始承接寫流量。當pg-test1重啟完成之后，通過以上兩個實驗可以看出，監(jiān)控系統(tǒng)對于反應(yīng)系統(tǒng)狀態(tài)來說，是一個非常實2用監(jiān)控系統(tǒng)解決一些實際問題2.1用監(jiān)控系統(tǒng)解決問題2.1.1.黃金監(jiān)控指標數(shù)據(jù)庫負值和飽和度是最重要的指標。按照GoogleSRE的監(jiān)控最佳實踐，這些指標可以分為4大類，飽和度、延遲、流量和錯誤，都具有很重要的2.1.2.PGLoad衡量數(shù)據(jù)庫的負載程度PG的負載是不是也可以采用類似于CPU利用率和機器負載的方式來定義？當然可以，而且這是一個極棒的主意。讓我們先來考慮單進程情況下的PG負載，假設(shè)我們需要這樣一個指標，當該PG進程完全空閑時負載因子為0，當該進程處于滿載狀態(tài)時負載為1(100%）。類比CPU利用率的定義，我們可以使用“單個PG進程處于活躍狀態(tài)的時長占比”來表示單個PG后端進程的利用率。如上圖所示，在一秒的統(tǒng)計周期內(nèi)，PG處于活躍（執(zhí)行查詢或者執(zhí)行事務(wù)）狀態(tài)的時長為0.6秒，那么這一秒內(nèi)的PG負載就是60％。如果這個統(tǒng)計周期中都處于忙碌狀態(tài)，而且還有0.4秒的任務(wù)在排隊，如那么就可以認為對于并行場景，計算方法與多核CPU的利用率類似，首先把所有PG進程在統(tǒng)計周期（1S）內(nèi)處于活躍狀態(tài)的時長累加，然后除以“可用的PG進程／連接數(shù)”，或者說“可用并行數(shù)”，即可得到PG本身的利用率指標，如上圖所示。兩個PG后端進程分別有20Oms+400ms與80Oms的活躍時長，那么整體的負載水平為：(0.2S+0.4S+0.8S)/1S/2=70%總結(jié)一下，某一段時間PG的負載可以定義為：pg_load=pg_active_seconds/time_eroid/parallellpg_active_seconds是該時間段內(nèi)所有PG進程處于活躍狀態(tài)的時長之和。ltime_peroid是負載計算的統(tǒng)計周期，通常為1分鐘，5分鐘，15分鐘，以及因為前兩項之商實際上就是一段時間內(nèi)的每秒活躍時長總數(shù)，因此這個公式進一步可以簡化為活躍時長對時間的導數(shù)除以可用并行數(shù)，即：程活躍總時長pg_active_seconds這個指標，以及如何評估計算數(shù)據(jù)庫可用并行2.1.3.黃金指標：數(shù)據(jù)庫飽和度飽和度用于反映數(shù)據(jù)庫整體資源利用率理論上應(yīng)當取所有飽和度指標的最大值-record:pg:ins:saturation0expr:pg:in-record:pg:ins:saturation1expr:pg:in-record:pg:ins:saturation5expr:pg:ins:load5>nod2.2查詢定位優(yōu)化2.2.1.什么是慢查詢？ALTERTABLEpgbench_accountsDROPCONSTRAINT2.2.2.定位慢查詢定位集群RT異常，定位到具體的實例和查詢。首先，使用PGCluster面板定位慢查詢所在的具體實例，這里以pg-test2為例，然位具體的慢查詢：編號為-6041100154778468427下降到7，花費在該查詢上的時間占比顯著增加，可以確定就是這個查詢變慢2.2.3.發(fā)現(xiàn)異常查詢以aid作為過濾條件查詢pgbench_accounts表查詢變慢，大概率是這張2.2.4.性優(yōu)化我們嘗試在pgbench_accounts表上為aid列添加索引，看看能否解決這個問可以看到，查詢的響應(yīng)時間與QPS已經(jīng)恢復正常，整個集群的負載水平也恢復正常，報警也平息下來。精準衡量優(yōu)化效果，直觀展示工作成績，真正做到2.3定位系統(tǒng)故人工時時盯著指標，是一個非常辛苦的活，更好的選擇是由機器來盯著這些指標，您設(shè)定好規(guī)則，機器發(fā)現(xiàn)這些指標超出異常范圍的送報警，Pigsty里面提供了一系列的報警規(guī)則，同時報警事件也可以在監(jiān)控系統(tǒng)的面板里面看到，通過這種條狀甘特圖的方式，我們可以看到哪一個時間段觸發(fā)了報警事件，從而有的放矢的去排查。報警系統(tǒng)提供了很多計算好的衍生2.4系統(tǒng)水位評估2.4.1.水位評估：飽和度的歷史分位點除了直觀的衡量實時的數(shù)據(jù)庫負載水平，還可以用來計算數(shù)據(jù)庫的水位，水位就是一個長期的資源使用量指標，通常來說，如果我們的某一個數(shù)據(jù)庫集群長時間處于高負載狀態(tài)，我們就是說它水位比較高，我們可能就要給它擴容。如擴容和縮容的依據(jù)就是所謂的水位，水位就是過去某一個時間段飽和度的百分位點。比如說現(xiàn)在采用的就是過去一天里面水位的99分位點，對于那種有周期性的負載來說，一天是一個比較好的這種衡量指標，如果您的業(yè)務(wù)周期性是點或者99.99分位點，來評估集群的水位。比如這里某一套集群，它的水位系統(tǒng)的資源利用率很有用。評估資源利用率，就可以評估成本，及時的進行優(yōu)參考文檔：http://pigsty.cc3.2公開文檔與演示本教程著眼于在本地單機創(chuàng)建Pigsty演示環(huán)境，如果您已經(jīng)有可以用于部署的機器實例，可以參考部教。如果用戶的本地計算機上已經(jīng)安裝有Vagrant、Virtualbox與Ansibl正常情況下執(zhí)行結(jié)果詳見參考-標準流。3.3快速上手gitclone/Vonng/pigsty性能問題RedisCPU高問題概述用率顯得尤為重要。當實例的CPU打滿時會導致數(shù)據(jù)庫響應(yīng)緩慢，嚴重影響看數(shù)據(jù)節(jié)點是否出現(xiàn)CPU瓶頸，然后查閱"Proxy節(jié)點2CPU使用率高的一般排查步驟2.1確認是否存在流量突增/熱點Keyl/document_detail/100453.htmll/document_detail/188013.html但需要注意的，這里提供的結(jié)果僅僅作為基力上限要以實際的業(yè)務(wù)壓測為準，當業(yè)務(wù)代碼沒有任何變動的情況下CPU突增，建議您結(jié)合監(jiān)控圖先觀察當前Redis實例的各項QPS指標是否同樣存在l/document_detail/160585.htmll/document_detail/181195.html路一般有以下幾種，本質(zhì)上就是通過多線程或者架構(gòu)升級的方式解決：在讀寫分離添加只讀實例，或者使用多分片我們做一下簡單對比，比如阿里云Redis社區(qū)標準版能夠承載的QPS為K(社Redis社區(qū)版集群Redis社區(qū)版讀寫分離Redis企業(yè)版-性能增強型主備Redis企業(yè)版-性能增強型集群Redis企業(yè)版-性能增強型讀寫分離寫(key均勻情況)K*分片數(shù)KK*3*分片數(shù)讀(keyK*分片K*只讀K*3*分片數(shù)K*3*只讀節(jié)均勻情況)數(shù)節(jié)點數(shù)點寫(熱K(最壞情況)K讀(熱K(最壞情況)K*只讀節(jié)點數(shù)K*3*只讀節(jié)點2.2認是否存在慢詢慢查詢隊列以供查看。查詢執(zhí)行時間指的是不包括像客戶端響應(yīng)(talking)、發(fā)送回復等IO操作，而單單是執(zhí)行一個查詢命令所耗費的時間，您可以通過控制臺提供的參數(shù)slowlog-log-slower-than和slowlog-max-lel/document_detail/164435.html通常Redis指令消耗的CPU與指令的時間復雜以上的復雜度在業(yè)務(wù)代碼設(shè)計時需要謹慎對待它對應(yīng)的流量評估。具體每個控制臺CloudDBA提供有"緩存分析"找出實例中的存在性能隱患的大Key，詳情可參考：/document_detail/102093.html2.3確認是否存在流量不均在使用讀寫分離/集群架構(gòu)模式下，當集群出現(xiàn)響應(yīng)延遲時，首群下所有對外提供服務(wù)的物理節(jié)點均出現(xiàn)HighCPU，限流，還是部分節(jié)點出除了上述提到的bigkey和熱點key容易引起的集群還有幾種情況可能導致讀寫分離架構(gòu)下的各個主節(jié)點，只讀節(jié)點之間的流量不lscan系列命令由于存在上下文關(guān)系，需要將該類命令全部轉(zhuǎn)發(fā)至第一個只leval和evalsha命令，可以通過readonl制其分發(fā)向只讀節(jié)點（讀寫分離版）從而降低mas3通用最佳實踐可參考：/document_detail/146758.html。/document_detail/107695.html。l節(jié)點宕機導致的全量同步，期間存在部分對外服務(wù)節(jié)可能比slave高很多，因為master向slave傳輸數(shù)據(jù)時可能做了合并，類l高頻建連操作可能消耗更多的CPU，因為連接的建立和釋放均會消耗一定l在連接數(shù)較多的情況下頻繁調(diào)用info指令查看各項監(jiān)控信息可能導致CPU使用率更高，因為部分info子命令的監(jiān)控信息統(tǒng)計需要遍歷每一個client連接，所以當連接數(shù)超過5k的情況下建議https://redis.io/commands/bgrewriteaof。Redis內(nèi)存高問題概述作為內(nèi)存型數(shù)據(jù)庫，阿里云數(shù)據(jù)庫Redis的內(nèi)存使用率是一個非常重要的監(jiān)控指標，當實例內(nèi)存不足時會導致數(shù)據(jù)庫響應(yīng)緩慢，甚至導致寫入錯誤等不利影以將其配置為在達到最大內(nèi)存限制時采用key逐出的方式以保證Redis的正常運行，但應(yīng)當注意Redis的淘汰是同步進行的，觸發(fā)淘汰后會命令處理時延（因為需要逐出可用內(nèi)存后才部署架構(gòu)為主備模式下，只提供當前主節(jié)點的內(nèi)存使用。通過監(jiān)控圖查看內(nèi)存例，且可能通過多個Proxy節(jié)點做路由轉(zhuǎn)發(fā)和負載均衡，通過監(jiān)控圖查看內(nèi)存通過阿里云控制臺提供的監(jiān)控圖可以大概確認當前實例的內(nèi)存使用情況，在大部分場景下，絕大部分的內(nèi)存均為實際的數(shù)據(jù)存儲需求，當觀察到內(nèi)存超過一定閾值后擴容即可。然而在一些特定場景下，我們可能認為Redis的內(nèi)存使用Redis官方提供有infomemory4)"MEMORYP