差不多時間到了我要再說一下One more time we're going to present this in ChineseSo if you don't have this little thingProbably want to get itThink they have it on every floor我們現在開始說中文了非常感謝大家來參加我們的這個Talk很高興今天還挺多人的其實我們今天會來說這個ACD的度量指標概覽先做一個簡單的自我介紹我叫張文嘉 您可以叫我文嘉我是ACD和Coronadis的contributor這個錦衣是我的同事我們都在Google工作它是ACD的Maintainer和Coronadis的member這個衣不認識 還有一瓶就是對於任何一個軟件產品你的性能肯定是最重要的就是客戶用不用它然後就是看你的性能是不是達到他們的要求可是在你拿到了這個軟件產品之後對於一個工程師來說在每天的工作當中你這個軟件容不容易維護然後在你手上的有限信息裡面是不是能在最快的時間裡面及時發現問題 解決問題這個是我們每個人工程師每天的工作當中日子好不好過 是不是所以實際上我和錦衣在Google是在GKE這個組工作所以我們每天的日常工作當中非常重要的一塊就是維護客戶的GKE集群如果有人不知道GKEGKE是Google Coronadis Engine然後如果在座的各位有相關的經驗的話你們可能也會感同身受SED作為一個data store不管是在Coronadis還是在別的系統當中這個系統如果出現Performance問題可能最早就是體現在SED這個組件上面所以SED的觀測性也是非常重要的所以今天我們就是要來詳細的介紹SED裡面的這個度量指標這是我們今天的一個議程我們會從SED的MetricsAltress度量指標的藉口開始說起然後說一些在我們的官方這個Documentation裡面官方這個文檔當中記錄的一些經典的SED的度量指標然後我們會花比較多的時間在近一年當中添加的SED的度量指標然後最後我們會舉一些小的例子來跟大家探討一下怎麼樣有機的整合不同的SED的指標然後來達到你的這個監控目的在我們今天的這個講述的過程當中可能會涉及到SED裡面它本身的一些架構和概念因為時間關係我們不會深入的來說這些具體的概念就有一個非常好的機會就是在明天中午11點20僅依會有一個SED Deep Diving專門說SED核心的這個RAFT Consensus Algorithm這個RAFT Consensus Algorithm如果你們沒有聽說過的話它是它是一個分布十一致性算法怎麼說呢它是基本上說是SED為什麼成為SED它為什麼可以做到它的這些功能所以如果你們今天聽了這個我們的這個Talk然後再去僅依明天的這個RAFT Consensus的這個Talk就會更清晰的了解這個整個整個故事是怎麼回事好下面我們就開始進入我們今天的議程首先先簡單的說一下這個SED杜良指標的接口SED的杜良指標接口而且每一個SED的服務器它都會把杜良指標導出到客戶端接口的slash matrix這個路徑上所以說你如果Curl比如說Default缺省是2379你Curl 2379 matrix就可以得到這個SED服務器的杜良指標那還有一種方式呢你是可以通過一個flag叫做這個應該也是近一年之內加的一個flag你通過這個flag然後你可以自定義一個不同於客戶端接口的一個專門用來提供杜良指標的一個接口它的好處它這個好處在於什麼呢就是你一個data center安全性非常重要對不對然後你也不想所有人都可以去讀寫你的SED裡面的具體數據那在這種情況下你會對你的客戶端接口進行加密然後你把2379加密了以後你可以定義一個另外一個比如說9379專門來得到 matrix這樣子需要監控的那個用戶就就不需要有這個客戶端的呈現只需要去監控9379就可以了好這個我們在拿到了Metrix的接口以後開始說一下一些經典的 SED 杜良指標比如說經典因為他們在 SED 裡面時間已經比較長了就是從SED 開發出來比較早期就存在那我們可以想想一般都是一些比較必要的指標這些指標主要分為三類第一類是服務器指標然後我們還繼續會說到硬盤指標以及網絡指標順便說一下我們下面說的那些 list都是在這個documentation matrix.md上面會找到服務器指標當中我們從第一個開始說起Has leader這是一個最基本最重要的指標比如說你如果說 SED你有一個指標你監測一個指標這就是那個指標怎麼說呢比如說你的電腦而我不工作了你先看看電源有沒有插上SED 如果有出現異常你最先看一看它的這個集群還有沒有 leaderleader 都沒有了可能掛掉了 是不是leader 是什麼我先問一下在做的各位有多少人知道 leader 是什麼我是大概了解一下我還稍微說一下我再說一遍就是 Raph's consensus algorithm是一個比較複雜的東西要解釋起來比較難菅義明天會說那我今天講一些最基本的東西Raph 它是一個leader-based一致性的算法它就是說一個集群裡面所有的節點在一起我們選一個人來當leader然後所以就 has leader是非常重要的一件事情然後這個 leader他選上了以後他不能當一輩子就是如果他出現什麼問題的話其他的 follower就會很自覺地說算了我們再選一個別的leader然後什麼時候會開始重新選呢就是在這個集群裡面的leader會一直給他的 follower發一個叫 heartbeat就會一直說I'm still hereI'm still hereI'm still here然後如果這些 follower就是看不見這個 heartbeat一段時間就會知道說這個leader可能有問題了是吧這個時候就會發現leader change所以leader change是一個正常的行為那什麼時候不正常了呢我們看第二個那個獨良指標就是在很短的時間裡面他發生的次數非常多非常頻繁的時候你就會想要看一下是出現了什麼問題對不對一個非常大的可能性就是你的網絡可能有什麼問題你的網絡開始變慢了如果你的網絡開始變慢了那你可能就需要調節一下你的這個SD設置裡面的heartbeat timeout和election timeout那我們怎麼知道這個網絡是不是真的很慢或者說根據網絡的一個什麼樣的指來設定heartbeat timeout和election timeout呢這個我們會在下面的講到網絡的時候會繼續說到下面這四個指標可以看到都是跟proposals有關的指標proposals是什麼呢它是raft裡面一致性的這個請求again這個簡易明天會說到這個proposal的具體的細節那麼我今天大概說一下這個每一個獨良指標對你的影響proposals committed total就是說這個指標提出的指標提出的數量我說什麼請求提出的數量然後這個你要知道的是就是不同的SD集群當中不同的節點它對請求提交的數量是有可能不同時一致的就是說什麼呢有的節點可能快一點有的節點慢一點它在一個時間你看到committed total有可能不一樣然後leader它可能提出的指標提出的這個請求是最多的那你就說那我什麼時候需要引起重視然後需要做出反應呢就說如果某一個節點某一個follower跟這個leader的指標相差的特別多然後甚至越來越多那麼這個follower這個follower節點又可能開始變慢出現了一些問題你就可以開始做一些反應然後下面一個叫做proposal applied total就是請求實際上應用的這個數據數字那在SD裡面那每一個服務器對請求的commit和ply是不同步進行的所以說proposal applied total和proposal committed total這兩個數字在一個SD服務器上它是有可能不一樣的那即便是不一樣也不會差很多不會差很多是一個什麼概念呢就是說在一個複合很大的SD集群當中它可能這兩個也就差幾千而已如果在座各位在使用當中看到過更大的你可以告訴我我們需要update的一下然後如果這個這兩個數字的差距越來越大那就很有可能是你的SD超複合了是吧然後下面一個是proposal spending就是說等待被commit的請求的數量那在一個接點上如果這個數字越來越大這個接點可能出了什麼問題它沒有辦法commit然後proposal failed total就failed看起來就比較比較恐怖但是這個failed在有的情況下是可以出現的你在leader election大家說現在沒有一個leader我們要選一個leader的時候proposal是可以failed的但是如果這個情況變得不是一個臨時的狀況了變成就是failed的total就是一直出現那就比較不好就是說明可能你的SD集群可能叫做一個loss of quarrel在reft裡面就是說大多數的接點可能已經不工作了那這個是一個比較scary的事情是比較恐怖的事情你就需要你可能需要停掉你的集群然後重新restore quarrelOK然後下面一個是scd的硬盤狀態指標scd對於硬盤的表現是很敏感的然後它這個reft它為什麼可以保持一個各個接點之間的一致性basically它最基本的這個原理就是說我這個狀態機它從一個一模一樣的狀態開始出來的一模一樣的lock然後它的最終狀態肯定也是一樣的所以說在這個scd的這個運行過程當中很重要的操作是把請求的這個Wall lock存到磁盤上還有一個就是要把這個狀態機的快照存到這個硬盤上面那所以你如果去監測Wall f sync duration seconds你就可以得到說這個硬盤的表現是怎麼樣子的如果硬盤如果這兩個數值特別高的話就說明你的硬盤太慢了好下面就是網絡狀態指標在scd當中就是scd不同節點之間the peer之間的數據傳送是通過網絡的還有一個就是scd的服務器和它的grpc客戶端之間的數據傳送是通過網絡的所以你可以看到在這個方面主要是一個peer相關的指標和client grpc相關的指標那麼就很明顯就是這個數據傳送然後廢油的特別多網絡之間的數據傳送廢油的特別多或者特別慢那肯定是網絡有了什麼問題斷掉了開始變慢了這裡我要提到一個非常重要的指標就是這個round trip time seconds我剛剛說到就是我們要避免過度頻繁的leader change我們根據什麼來調整scd的配置來控制這個leader change不要太頻繁呢就是去看這個round trip time它直接反映了你的網絡的速度然後我們有一個我們其實有一個推薦值就是說一般0.5到1.5倍的round trip time是用來設置heartbeat time out然後用10倍的round trip time來設置為你的election time outOK 就三個slides我們已經講完了我們所有這個在正式文件上面記錄在案的度量指標下面有十幾個slides我們都會focus在過去這一年裡面新加的一些非常有用的scd的度量指標說明兩個問題一個是過去一年裡面scd的observability大大的提高了還有一個問題就是說我們的正式文檔需要同樣強度的提高如果大家有興趣可以在這方面給我們幫助我們從最簡單的開始說起首先我們增加了一些版本相關的指標包括scd的機群版本scd的服務器版本和服務器所用的Go的版本如果你們以前用過scd的話知道這些數據都可能需要你通過看scd的配置通過看scd log來得到現在你就可以直接從matrix來得到就很方便然後那snapshot就是狀態機當前快照我們剛剛說過這個是一個很重要的操作對於scd來說對機群也有非常大的影響但是以前沒有這些相關的度量指標在過去一年我們增加了非常多它主要是兩個方面一個是對本地的snapshot save這個操作的一些監測然後第二部分是對在不同節點之間傳送快照的這些發送和接收的監控然後這兩個指標的增加是用來監測pierre的健康程度一個叫scd network active pierce和disconnected pierce active非常直觀比如說我們現在有一個這個scd的機群有1 2 3組成這是一個非常健康的機群然後我們來看一下1號的matrix就可以看到它有兩個active pierce一個是2然後value是1然後還有一個是名字是3它的value也是1說明它們兩個都在健康的運行然後到一定狀態下我們開始發現這個1號的matrix變成2號的active piercevalue變成1了然後3號active piercevalue變成0了然後增加了一個叫disconnected pierce有一個3號value是1那就說明3號掛掉了是吧OK然後有3個我們又增加了3個這個度量指標它是可以反映database大小的一個狀態第一個叫做actz serverhold up back in bytes你們可能覺得有點眼熟是因為它可以通過一個叫hold up back in bytes這個flag來設置的是你們自己設置的但是again我們加了這個度量指標了以後你就可以在matrix直接得到不需要去看config不需要去看log然後在下面有這兩個可以結合在一起使用一個叫mccdb total size in bytes還有一個是total size in use in bytes就有一個out call但是它說明什麼呢這個綠顏色這一部分就是physically allocated db size然後這個黃顏色部分是in use in byte所以就是實際上in use的這些這個大小那多出來的地方是已經被碎片化的所以它告訴我們一個什麼呢如果你在這個時候做一個dfragmentation這些是你可以節省出來的這個db sizeOK好我們繼續講這個是和硬碟比較相關的一些我們新家的指標為什麼把他們group在這裡就放在一起呢就是通常情況下如果這些出了問題的話可能是你的這個磁盤比較慢我們一個講第一個它叫etcd server heartbeatsand failures total這個failure可能稍微有一點點就是誤導啊就是是怎麼樣的剛剛文嘉還講就是在一個集群之中那麼有一個節點它是leader然後leader會周期性的發出heartbeat message告訴其他人我還在那麼當接連的兩個heartbeat message的間隔超過了by default預設的值就超過了兩倍的heartbeat正常的應該的間隔的話我們就會說heartbeat send failure這個matrix就會加一那麼就是我們現在的document上面寫的是說如果你的磁盤比較慢的話你可能會看到這個heartbeat send failure不過我最近看了一下code我覺得好像這個已經這個問題應該已經被optimized已經被優化掉了就是一個慢的磁盤應該不會導致heartbeat send failures不過我覺得這個還是有待探討如果你們就是如果哪位磁盤比較慢然後你們可能並沒有看到我這個total matrix在增長的話就是可能也從側面說明它被優化掉了那麼我們再講下一個下一個server slow apply total剛剛文嘉也有提到過就是SED的做法是說它的本質是一個key value store就是一個存署把它理解為一個狀態劑的話你所有對這個key value store的操作首先都要先寫到log裡面write a headlog就要先寫到log裡面大家絕大部分人都同意了以後叫做committed logs然後所有committed logs我們再按照順序一個一個地把它apply就是把它apply到key value store上面那麼每一個本地的local node在apply raft entry的時候就是你想要做的操作不是說剛剛說過嗎先要append就是先要放到raft entry裡面去那麼在apply的過程中這個metrics就是說如果你apply的時間超過了預設值應該是100毫秒如果你超過了這個預設值的話那麼很有可能是你的磁盤比較慢這個具體的話我們後面有個例子會講它有可能有其他的原因造成了apply的速度比較慢我們現在暫時先就留到後面講吧然後下一個是back and defrag duration seconds這個就是顧名思義磁盤碎片整理的這個時間為什麼要做碎片整理呢上頁slides文嘉剛剛講過了就是ICD底層使用的它使用的包地幣就是當ICD你往裡面不停地寫東西不斷地更新你的數據的時候當它空間不夠的時候它會跟操作系統要說再給我分配點空間那麼當你釋放了ICD裡面使用的空間的時候比如說你這個時候喂ICD內部是會變得有更多可用空間因為你剛剛釋放了一些不用的空間但是這部分空間並不會釋放回給操作系統所以你在ICD外面來看從操作系統的角度來看ICD它的使用的磁盤空間會不斷地增長因為它只跟操作系統要它不會釋放回去那麼唯一釋放的方法就是做磁盤碎片整理Defragmentation這個基本上是你在做的過程中服務器本身的所有讀寫都要暫停因為它本質上是要跑到這個底下最底層的存儲的文件裡面去把你所有的key value都讀出來然後重新生成一份新的file那麼如果這個過程比較慢的話那肯定就是你的磁盤的問題比較慢後面兩個是它們差不多它們都是和剛剛那個有一點接近就是說像這個hash的話它是打開你的你存的所有的key和value然後把它們都讀出來然後做一個hashing那麼這個也是說跟磁盤的速度是比較相關的因為它是traversing就是要便利一遍你所有的key value在你的磁盤上面所以如果你看到這個時間都比較長的話證明你的磁盤比較慢好那麼下一頁是服務器端一些比較新的指標第一個etcdserverisleader就是顧名思義我這個本地的服務器是不是因為剛剛講過一個集群裡面有一個leader那麼它eader要么就是要么就不是etcdserverid這個id就是它就是一個id因為這個server本地它也有一個一個raft node然後這個raft本身是一個id的它們是用同樣的id下面兩個 health successhealth failures這個是說什麼呢就是很多人絕大部分用戶他們會使用使用一個health endpoint就是比如說localhost2379slash health用這個來監測說我這個服務器是不是健康的你每監測一次那麼返回就是要么是成功要么是失敗同時在metrics裡面我們也會記下來就是如果成功的話你看到這個metrics會加以失敗的話那麼下一個 failures會加以後面兩個是跟readindex有關的一個是readindex failed一個是readindex比較慢slow那麼可能首先得解釋一下為什麼會有readindex這個東西大概簡單來講的話就是說因為acd想要做的一件事情就是雖然我是一個集群但是當client跟我交互的時候我希望讓你看到的是一個一致的就相當於我是只有一台機器一樣的比如說你剛剛寫了一個什麼紙那麼你緊接著再來讀的話我能保證你一定能讀得到雖然可能serve你這個client的服務器並不是同一個那麼在acd3.0之前你如果要讀的話你的request如果你要做一個linearizable read就是一個by default就是用linearizable read如果你要做這樣一個read那麼這個request會要先給leader然後leader來接受你的請求3.1開始做了一個優化這也是wrapped paper上面已經有過的一個優化就是說我們服務器本地也可以來serve也可以來回應你的一個read就從我本地的key value store裡面去讀就好了但是這個時候需要確保正確性因為你可能本地並沒有更新你上一次client發出去的讀所以這個時候要做的事情就是我在serve read之前我先要問一下leader我們現在整個這個集群裡面大家已經同意到哪些操作已經大家同意說要apply到key store裡面了那麼本地當我們把那些已經同意的apply完了以後我才可以去返回這個client request我們才可以去serve這個read所以這個read index其實就是一個從我local server發送給leader的一個request我需要問一下leader我們現在同意到哪裡了大概就是這樣一個意思那麼在問的過程中你可能問的時候就發送失敗了那這個時候你會看到failed total加一那麼如果你問成功了發出去了這個時候你要等leader回給你大家同意到哪裡了那麼如果回覆的時間過長time out就超時了那你會看到slow reading index或者另外一個情況你現在問出去了然後你介紹了一個回覆這個回覆並不是你剛剛問的是可能是你之前問的一個回覆那麼這個時候他也是說明reading index比較慢你會看到這裡一回加一然後這個是我們新加的acd learner相關的metricslearner是可能要先講一下learner是什麼learner它有另外一個名字叫non-volting member它作為齊群裡面的一個成員但它並不參與volting那麼它也不參與我們剛剛所說的就是大家需要一致的同意了做什麼事情再去做就是learner不參與這一部分我看我們有沒有時間去大概再講一下就是說為什麼需要learner呢我舉一個例子吧舉一個在你做cluster reconfiguration的時候的安全性的一個例子比如說你現在的假設說你現在只有你的夫妻基群只有一個節點那麼現在你想要把它變成一個ha cluster就是high availability cluster你要變成三個節點那麼可能你第一步是要先加一個member進去從一變到兩個那麼加的過程它是分兩步的在acd裡面第一部分是靠一個api就是member add你要先加這個member先要介紹給你現有的一些成員第二步是你去真正的去開啟你的acd binary你要啟動acd的server這個server 對那麼有什麼潛在的安全性的問題呢就是你可能第一步在add的過程中因為你要提供一系列的參數這個參數不小心寫了個typal比如說我要新加一個這樣一個member但是它的api你寫錯了那麼這導致什麼樣的問題就是你新的server你並不能真的起來因為你給了一個錯的api那這個時候你沒有辦法revert就沒有辦法取消你撤銷你之前的新加這個member因為它已經加進去了這個時候如果你說我可不可以把我剛加那個member刪掉要刪掉的話因為你現在conceptual就概念上來講你的基群裡面已經有兩個節點了他們要同時就是他們要同意兩個都要同意才可以 對吧但現在你只有一個server再跑另一個server你還沒起來因為你misconfig了這個ip嘛 它起不來那這個就比較麻煩了這個相當於你就要就需要重新開一個新的cluster了就是它是一個不可逆的一個操作失誤那麼用learner的好處是什麼呢因為它並不並不真的去參與投票和參與這個一致性的決定所以在同樣的這個情形下萬一你操作失誤了misconfig了這個新的member你可以把它revert你可以把它就是撤回那麼這三個呢就是和learner相關的metrics第一個顧名思義就是我這個server我剛加的它到底是不是一個learner另外兩個和learner的Promotion相關就是一個learner被加入了以後你可以把它過一段時間以後你可以把它Promote成一個正式的member那麼它有可能成功或者失敗可能時間不太允許我們就不講具體的這個細節了如果大家感興趣的話呢可以看具體的implementation就是怎麼實現的是去看一下這個link好 下一個下一個就是簡單說一下可能我不知道有多少人會這樣用就是ICD也可以把它用作一個proxy然後它背後是一個ICD集群那麼原本的話呢如果去如果你現在這個ICD是用作proxy的它的這個IP然後port 2379然後slash matrix的話呢你看到的是它作為proxy的matrix如果你想看看它背後的ICD集群的matrix呢本來是並沒有就看不到的然後最近也是新加了一個這個flagOh sorry這個flagmatrix address你通過這裡specify就是可以告訴你通過這個address就可以看到它背後的acid cluster的matrix後面的兩頁呢都是experimental的就是實驗性的matrix這一頁呢是關於這個acid底層的bolt db的如果就是需要debugbolt db的相關的東西的話呢也提供了一些matrix下一頁呢是跟least相關的也是experimental就是實驗性的matrix可能這要提一下的就是說通常情況下我們不管是作為developer還是作為用戶在開發以及維護acid的過程中可能你會覺得也許我加這樣一個matrix會比較有用但是並不完全確定所以那麼第一步呢一個比較好的做法可能是先加一個實驗性的就是experimental matrix他們的前綴一般都是他們的前綴一般都是這樣就是帶一個debugging這樣一個字的那麼過一段時間如果大家用的比較多發現它比較穩定了可以把它promote成一個正式的matrix好 那麼我們很快地很快地舉兩個例子那麼還有多長時間很快舉兩個例子一個是最近看到比較就是可能抱怨比較多的就是在這個server log裡面很多人會看到一個warning就是說apply entry took too long就是和剛剛我們一開始提到的很像就是這個為什麼會花這麼長的時間去apply一個大家已經決定的一個change這個通常情況下你第一個要確定的是你本身request的是不是特別大比如說你這個你想要做的操作是想要讀所有的key value在你的store裡面那麼你可能已經存了非常非常多的東西那你本身返回的這個東西就可能有比如說1萬g entry或者10萬g entry本身就非常大的話那它是會花比較長的時間那這個你就不需要擔心了排除了這個以後那麼很可能就是你的磁盤速度比較慢我們一開始的時候也提到過了那麼最相關的話就是這個matrixbackend commit duration seconds通常先讓我們推薦的話這個你可以看它那個p99的時間通常我記得我們是推薦是要小於10毫秒這個本身這個warning實話是超過100毫秒就會顯示然後另外一種可能性就是你跑acd的這個machine這個machine它本身這個cpu和memory的可能就是不夠用了這個從matrix沒辦法看但是你可以login到你的machine上面然後去看一下這個cpu usagememory usage好再舉一個簡單的例子就是比較容易看到的client request timeout就是超時請求超時舉個例子的話比如說你用acd cuddle這個是command light tool然後你說我要寫一個full bar然後正常情況下它會很快的就說告訴你寫完了然後給你返回OK就是會打印出來一個OK告訴你寫完了那麼這個情況下可能等了幾秒鐘發現什麼都沒發生然後返回了一個errorcontext deadline exceeded這個就是超時了那麼可能第一件事要去查的就像文家剛才提到了就是看你的cluster是不是還能操作看看有沒有leader然後你去看一看是不是proposal failed如果沒有leader的話proposal肯定會fail然後比如說沒有leader沒有leader的話那你可能下一步要去看一下networking相關的matrix看一下是不是pr之間沒有辦法互相通信如果這些都可以的話就說明你還可以make progress就是cluster你的機群還可以接收你的新的請求但是有可能是我們剛剛提到就是這個apply速度太慢了它可能本身就已經超過了一定的時間導致你整個request就time out就是超時了其實有可能的好謝謝大家有什麼問題我在補充一個大家剛剛提到那個house就是我第一個slide講說scle的matrix的接口你可以自定義那你換了自定義的matrix接口的時候實際上matrix和house是共用同一個接口你也可以用那個接口來監控它的health好有什麼問題好像沒有什麼時間為什麼這個matrix裡面不添加就是請求的那個duration沒有這種這方面的就是你是說每一個請求我們都記錄它的時間嗎這個有點像outting是不是就是我想先說就是如果你有一個debug flagslash slash debug如果你把它打開的話其實有點像outting就是你所有的server給live server的request我們都會記錄下來這個request有多大花多長時間這個request本身是什麼比如說是個讀是個寫不過你剛剛說那個我覺得也挺有用的就是你說採樣是吧你可以加一個sd debugging的matrix你好 謝謝你的分享然後我想問一個在edcdyr裡面它有一個hddpsuccessful duration那個matrix然後v3裡面就沒有了然後我就想問一下那麼我如果想看這個duration的matrix然後v3有什麼替代的參考嗎你說的這個v2的是什麼hdtp durationhdtp successful duration這個我並不是特別熟悉像這樣比如說我有一個edcdytlget這個hdtp請求那麼那麼我有什麼可以參考的matrix現在就是說我可以知道它請求的它的好事之類的我們可能暫時沒有就是剛剛提到我的開了這個dbug的這個flag的話你是可以看到每一個request的是好多長時間OK還有一個問題就是比如說那我這個get請求的話我是不是每個請求我都會產生一條request的log然後會持久化到Wall那個文件裡面3.03.1之前就包括3.0是這樣子的就是你如果要做一個linearizable read它要先寫到request的裡面然後再等它到然後你本地再applyApply完了以後把這個結果返回給client但是3.0之後從3.1開始是做了這個優化的log裡面不會再顯示linearizable read就是說3.0以前它是會有一個持久化的就是有一個就是把你這個請求的那個持久化到我的刺盤對那其實這個時候我可以參考就是可不可以參考剛剛你提到一個很重要的指標就是f sync award對那個就是完全相關的那假如我這個get的話就像你說的就是是一個就是corum的getlinearizable那麼這個時候我會經過一個就是marble之間的一個consensus那這個指標的話我是不是可以參考就是有一個就是你們剛剛也提到的有一個pr roundtrip那個那個是其中的一部分對我覺得大概你是可以通過一些指標然後把它們就是算一下對我就是這個意思因為對可以的也就是說它這個流程請求的流程是怎麼樣就是它的flow是怎麼樣的你這個get到了local server以後它可能會先有一個request到leader然後leader返回回來之類的對我們可以後面再想它另外就是我想知道這些指標有沒有一些參考值還有對應了那個硬件的標準對應硬件標準的話是有hardware recommendation這樣的一個documentation那說參考值的話大概的範圍可能也有但是因為每一個cluster畢竟是不太一樣所以很難給出一個確定的值好謝謝謝謝大家我們可能我想說一個最後的事情就是說你們因為我們不知道每個人的use case如果你們有覺得應該要加的一些東西歡迎大家提一手和發pr你好我有一個問題就是說那個數據庫那個ETT申請數據庫只會申請不會釋放我們監控到ETT的數據庫大小會有一個突然的跳變那我們用不用說做snapshot然後把這部分申請的存儲釋放一下如果有跳變我猜測可能是它真的在使用很多就是如果你去做difragmentation它不一定能夠能夠釋放出來你可以去通過那個matrix看一下就是mvccinuse就是到底在使用了多少你可以看一下那個如果inuse和它它有兩個一個是inuse一個是沒有inuse就是說你跟操作系統要了多少另外一個是你真的用了多少你看這兩個差別有多大如果不是很大的話那麼你做difragmentation也可能就是沒辦法得獲來多少謝謝謝謝大家我們就結束了我有最後一個問題我們可以之後就是我們就是後面再聊吧