etcd請(qǐng)求出現(xiàn)高延遲
etcd的請(qǐng)求為何出現(xiàn)高延遲?
Leader在接收到的寫(xiě)請(qǐng)求,講一個(gè)日志條目復(fù)制到集群多數(shù)節(jié)點(diǎn)并應(yīng)用到存儲(chǔ)狀態(tài)的流程,會(huì)出現(xiàn)哪些情況導(dǎo)致請(qǐng)求超時(shí)？
- Leader向從節(jié)點(diǎn)發(fā)消息:Leader需要并行將消息通過(guò)網(wǎng)絡(luò)發(fā)送給Follower節(jié)點(diǎn),依賴(lài)網(wǎng)絡(luò)性能;Leader需持久化日志條目到WAL,依賴(lài)磁盤(pán)IO順序?qū)懭胄阅堋?/li>
- 應(yīng)用日志條目到存儲(chǔ)狀態(tài)機(jī)時(shí),etcd后端key-value存儲(chǔ)引擎是boltdb,boltdb是一個(gè)基于B+ Tree實(shí)現(xiàn)的存儲(chǔ)引擎,當(dāng)寫(xiě)入數(shù)據(jù)、提交事物時(shí),它會(huì)將
dirty page持久化到磁盤(pán)中。- 在整個(gè)寫(xiě)流程過(guò)程中,etcd節(jié)點(diǎn)的cpu、內(nèi)存、網(wǎng)絡(luò)資源應(yīng)充足,否則可能也會(huì)影響性能。
定位網(wǎng)絡(luò)延時(shí)抖動(dòng)
使用ping/traceroute/mtr、ethtool、ifconfig/ip、netstat、tcpdump等命令獲取相關(guān)數(shù)據(jù)。
etcd應(yīng)用層提供了節(jié)點(diǎn)之間網(wǎng)絡(luò)統(tǒng)計(jì)的metrics指標(biāo):
| 指標(biāo) | 解釋 |
|---|---|
| etcd_network_active_peer | peer之間活躍的連接數(shù) |
| etcd_network_peer_round_trip_time_seconds | peer之間rtt延時(shí) |
| etcd_network_peer_send_failures_total | peer發(fā)送的失敗消息數(shù) |
| etcd_network_client_grpc_send_bytes_total | server發(fā)送給client的總字節(jié)數(shù) |
| etcd_network_client_grpc_received_bytes_total | server接收到client的總字節(jié)數(shù) |
網(wǎng)絡(luò)質(zhì)量導(dǎo)致etcd性能:
- expensive request中的大包查詢(xún)會(huì)使網(wǎng)卡出現(xiàn)瓶頸,產(chǎn)生丟表等錯(cuò)誤,從而導(dǎo)致etcd吞吐量下降、高延時(shí),這是因?yàn)闃I(yè)務(wù)沒(méi)有遵循最佳實(shí)踐,查詢(xún)了大量key-value。
- 在跨故障部署的時(shí)候,故障域可能是可用區(qū)、城市,各個(gè)節(jié)點(diǎn)的RTT越高,請(qǐng)求的延時(shí)跟高。
磁盤(pán)I/O
etcd_disk_wal_fsync_duration_seconds(表示W(wǎng)AL日志持久化的fsync系統(tǒng)調(diào)用延時(shí)數(shù)據(jù))
和etcd_disk_backend_commit_duration_seconds(后端boltdb事物提交的延時(shí))觀(guān)察應(yīng)用層寫(xiě)入磁盤(pán)的性能。
如果etcd的WAL模塊在fdatasync操作超過(guò)1秒時(shí),將相應(yīng)的日志輸出。
etcd_disk_backend_commit_duration_seconds指標(biāo)的異常時(shí),說(shuō)明事物提交過(guò)程中的B+ Tree樹(shù)重平衡、分裂、持久化dirty page、持久化meta
page 等操作耗費(fèi)了大量時(shí)間。
etcd_disk_backend_commit_duration_seconds較高、etcd_disk_wal_fsync_duration_seconds正常,說(shuō)明B+ Tree的重平衡、分裂過(guò)程中的
較高時(shí)間復(fù)雜度邏輯操作導(dǎo)致。
disk_backend_commit_rebalance_duration和disk_backend_commit_spill_duration分別表明事物提交過(guò)程中B+ Tree的重平衡和分裂操作
耗時(shí)分布區(qū)間。
etcd_disk_wal_fsync_duration_seconds記錄的是WAL文件順序?qū)懭氲某志没瘯r(shí)間, etcd_disk_backend_commit_duration_seconds記錄
的是整個(gè)事物提交的耗時(shí)。
Expensive request
etcd 3.2和etcd 3.3版本寫(xiě)請(qǐng)求完成之前,需要更新MVCC的buffer,進(jìn)行升級(jí)鎖操作。然而此時(shí)若集群中出現(xiàn)一個(gè)long expensive read request,
則會(huì)導(dǎo)致寫(xiě)請(qǐng)求延時(shí)抖動(dòng)。
在etcd 3.4中,logger默認(rèn)為capnslog,trace特性只有在當(dāng)logger為zap時(shí)才開(kāi)啟,因此你需要設(shè)置--logger=zap。
trace特性不能記錄所有類(lèi)型的請(qǐng)求,目前只覆蓋了MVCC模塊中的range/put/txn等常用接口。
