ceph 作為軟體定義儲存的代表之一，最近幾年其發展勢頭很猛，也出現了不少公司在測試和生產系統中使用 ceph 的案例，儘管與此同時許多人對它的抱怨也一直存在。特別是進行效能測試。我們在進行效能測試時經常會發現效能資料不穩定的現象，尤其是伺服器使用的是帶有cache的raid卡。比如在使用30個7.2k sata盤搭建的onestor ceph集群 （使用hp smart array p840raid卡，cache快取大小4g）測試4k randwrite時，單個客戶端iops可以達到4k以上，低的時候單個客戶端iops基本在1k左右，為此，我們就去尋找導致這種現象出現的主要原因。
1、 當效能資料達不到預期，而且資料跳到比較大的時候。首先要考慮的就是raid卡和硬碟是否有故障。一般伺服器都有檢視自己硬體狀態的頁面，首先要確定硬體都是完好的，我們才可以繼續玩下去。另外，我們可以用ceph osd perf檢視集群中是否有某些硬碟比較不給力。通過
osd perf
可以提供磁碟
latency
的狀況，同時在運維過程中也可以作為監控的乙個重要指標。
正常效能測試時使用osd perf檢視的結果應該不會有差別：
如果發現某個硬碟或者某個節點下的所有硬碟延時很高，就需要考慮將該
osd剔除出集群。
2、 排除了硬體的故障以後，我們再來看看其他的影響。測試過程中發現在使用fio 4k randwrite進行效能測試時，使用iostat 檢視硬碟使用情況，卻時不時會有大量讀存在，而且出現讀的時候硬碟的使用率基本到100%。如果你的集群剛做完資料恢復，或者在虛擬檔案系統中的/proc/sys/vm/drop_caches寫入2或3來清除快取，下一次進行randwrite效能測試時該現象是必現的。比如用iostat看到的：
那問題就好找了，原因就基本鎖定在了drop_caches時清除的inodes上，首先來了解一下inodes。
我們知道使用free 命令可以檢視到記憶體的使用情況，包括了buffer和cache。 linux核心會將它最近訪問過的檔案頁面快取在記憶體中一段時間，這個檔案快取被稱為pagecache。
inode是linux/unix作業系統中的一種資料結構，包含了各檔案相關的一些重要資訊。在建立檔案系統時，就會同時建立大量的inode。一般inode表會占用檔案系統磁碟空間的1%。
理解inode，要從檔案儲存說起：
檔案儲存在硬碟上，硬碟的最小儲存單位叫做"扇區"（sector）。每個扇區儲存512位元組（相當於0.5kb）。作業系統讀取硬碟的時候，不會乙個個扇區地讀取，這樣效率太低，而是一次性連續讀取多個扇區，即一次性讀取乙個"塊"（block）。這種由多個扇區組成的"塊"，是檔案訪問的最小單位。"塊"的大小，最常見的是4kb，即連續八個 sector組成乙個 block。
檔案資料都儲存在"塊"中，那麼很顯然，我們還必須找到乙個地方儲存檔案的元資訊，比如檔案的建立者、檔案的建立日期、檔案的大小等等。這種儲存檔案元資訊的區域就叫做inode，中文譯名為"索引節點"。每乙個檔案都有對應的inode，裡面包含了與該檔案有關的一些資訊。，為了加快對索引節點的索引，linux又引入了inode緩衝區。就是把從硬碟讀取到的inodes資訊儲存在快取中。
我們可以用slabtop工具檢視快取中inodes的使用情況。核心的模組在分配資源的時候，為了提高效率和資源的利用率，都是透過slab來分配的。我們可以使用slabtop命令檢視slab記憶體分配機制。這個應用能夠顯示快取分配器是如何管理linux核心中快取的不同型別的物件。這個命令類似於top命令，區別是它的重點是實時顯示核心slab快取資訊，例如：
如果看到的xfs_inode和radix_tree_node使用的太多或者剛被清除，這時候就要特別注意inodes的影響了。
如何判斷是否有inodes的影響？在進行效能測試過程中盡量使用iostat 檢視硬碟的使用情況。如果在進行隨機寫效能測試時，隨機寫效能比較低。可以使用iostat –x 1 檢視硬碟資訊，如果硬碟的util很高，同時又有大量的讀存在，這時候基本說明系統正在從硬碟讀取大量的inodes，硬碟資源很大部分被讀inodes給占用了。
當然，觸發它進行讀取inodes的原因有很多：
1、使用了drop_caches的方式釋放了inodes和dentry。就是在/proc/sys/vm/drop_caches裡寫入2或者3 都會drop inodes和dentry。
2、有過其他大量的讀寫操作，比如增刪過硬碟、主機等只要有過大量資料恢復，資料恢復之後再進行效能測試就會觸發需要重新讀inodes。這時效能資料會很長時間維持在很低的狀態，因為從快取讀inodes的命中率很低，甚至連續寫幾個小時或更長的時候都會效能很低。
3、記憶體使用太多。如果slab cache占用過多屬於正常問題，並且當記憶體到達系統最低空閒記憶體限制的話，會自動觸發kswapd程序來**記憶體。
從測試的角度來看，目前效能測試資料乎高乎低基本原因就是讀取inodes造成 的。（不排除還有其他原因），要讓測試隨機寫時，盡量高的提公升從快取讀取inodes的命中率，目前有如下方法：
1、 fio測試時盡量使用小塊進行測試，目前來看如果使用100g的塊，就不太受inodes的影響，效能資料比較高
2、 盡量不使用做過異常測試的集群進行效能測試
3、 隨機寫效能測試時使用iostat檢視硬碟狀態，如果此時有大量讀，盡量讓測試時間長一點 ，多寫一會後停止fio後再重新測試。直到基本不出現讀時再記錄測試結果
4、 在/etc/sysctl.conf核心引數檔案中配置
vm.vfs_cache_pressure = 50
該配置表示核心**用於directory和inode cache記憶體的傾向；預設值100表示核心將根據pagecache和swapcache，把directory和inode cache保持在乙個合理的百分比；降低該值低於100，將導致核心傾向於保留directory和inode cache；增加該值超過100，將導致核心傾向於**directory和inode cache。
5、 目前個人認為在 ceph**和linux系統配置上這一塊應該還存在很大的優化空間，需要具體分析其它提公升方法
穩定與不穩定
1 氣泡排序 氣泡排序就是把小的元素往前調或者把大的元素往後調。比較是相鄰的兩個元素比較，交換也發生在這兩個元素之間。所以，如果兩個元素相等，我想你是不會再無聊地把他們倆交換一下的 如果兩個相等的元素沒有相鄰，那麼即使通過前面的兩兩交換把兩個相鄰起來，這時候也不會交換，所以相同元素的前後順序並沒有改...
穩定與不穩定排序
首先，排序演算法的穩定性大家應該都知道，通俗地講就是能保證排序前2個相等的數其在序列的前後位置順序和排序後它們兩個的前後位置順序相同。在簡單形式化一下，如果ai aj，ai原來在位置前，排序後ai還是要在aj位置前。其次，說一下穩定性的好處。排序演算法如果是穩定的，那麼從乙個鍵上排序，然後再從另乙個...
網路不穩定 網路不穩定，天氣來背鍋
王者上星 深夜吃雞，那些影響你上分的因素，除了不靠譜的隊友外，你可曾知道 天氣也在偷偷影響你？不知道大家有沒有這樣一種感覺，一到下雨天，家裡wifi的網速就明顯變慢！是的，這不是你的錯覺。空氣濕度對wifi訊號有很大的影響，水分子對2.45g頻段電磁波的吸收加熱作用尤為明顯，而家用微波爐和wifi用...