<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      ext4文件系統的delalloc選項造成單次寫延遲增加的分析

      最近我們的服務進程遇到kill -15后處于Z的狀態,變為了僵尸進程,經過/proc/{thread_id}/stack查看其上線程的棧,發現是卡在了fwrite的過程中,而我們的系統中所有文件系統掛載參數都使用了delalloc參數,懷疑是這個原因:ext4掛載的時候打開了delalloc選項,然后系統在沒有分配磁盤塊的情況下寫寫寫,到page cache被回寫到磁盤時,發現磁盤已經滿了,沒辦法分配新的磁盤塊了,就Hang住了。

       

      這篇文章是淘寶內核組的劉崢同學在內部技術論壇上發表的一篇文章,但是由于劉崢同學目前沒有blog,征得本人同意,貼在我的blog上,如果大家喜歡,請去新浪微博關注他。:)

      日前線上在升級到Ext4文件系統后出現應用寫操作延遲開銷增大的問題。造成這一問題的根源目前已經查明,是由于Ext4文件系統的一個新特性——Delay Allocation造成的。(后面簡稱delalloc)

      在詳細分析這一問題之前,先來介紹一下Ext4文件系統的delalloc特性。這一特性簡要概括起來就是將以前在buffer IO中每次寫操作都會涉及的磁盤塊分配過程推遲到數據回寫時再進行。我們知道,在進行Buffer Write時,系統的實際操作僅僅是為這些數據在操作系統內分配內存頁(page cache)并保存這些數據,等待用戶調用fsync等操作強制刷新或者等待系統觸發定時回寫過程。在數據拷貝到page cache這一過程中,系統會為這些數據在磁盤上分配對應的磁盤塊。

      而在使用delalloc后,上面的流程會略有不同,在每次Buffer Write時,數據會被保存到page cache中,但是系統并不會為這些數據分配相應的磁盤塊,僅僅會查詢是否有已經為這些數據分配過磁盤塊,以便決定后面是否需要為這些數據分配磁盤塊。在用戶調用fsync或者系統觸發回寫過程時,系統會嘗試為標記需要分配磁盤塊的這些數據分配磁盤塊。這樣,文件系統可以為這些屬于同一個文件的數據分配盡量連續的磁盤空間,從而優化后續文件的訪問性能(因為傳統機械硬盤順序讀寫的性能要比隨機讀寫好很多)。

      了解完delalloc特性的工作過程后,我們開始分析線上遇到的問題。線上應用的I/O模式可以簡化為一個單線程追加寫操作的程序,每秒寫入2、3M數據,寫操作后等待系統自動將數據回寫到磁盤。在使用delalloc后,每次Buffer Write操作,系統都會去查詢數據是否分配了磁盤塊,這一過程需要獲得一把讀鎖 (i_data_sem)。由于這時還沒有觸發回寫操作,因此可以順利獲取i_data_sem,系統完成數據拷貝工作,并返回。由于僅僅是內存拷貝的過程,所以這一操作速度相當快。當系統開始進行回寫操作時,系統會成批為數據分配磁盤塊,這一過程同樣需要獲取i_data_sem,并且需要加寫鎖?以保證數據的一致性。由于使用delalloc后,需要分配的磁盤塊比nodelalloc情況下多很多(nodelalloc情況下每5秒文件系統會提交日志觸發回寫;delalloc情況下,系統會在約每30秒左右觸發一次回寫),因此這一延遲時間較長。如果這時應用程序進行一次Buffer Write,則該操作在嘗試獲得i_data_sem時會等待上述磁盤塊分配完成。由此造成寫操作等待很長時間,從而影響應用程序的響應延遲。

      在上面的分析中已經提到,delalloc是將多次磁盤塊分配的過程合并到一次中來進行,那么是否真如預想的那樣,delalloc的平均延遲會小于nodelalloc的情況呢?我們使用fio來做如下測試:設置bs=4k,單線程每秒追加寫入5M,程序運行3分鐘,我們來看一下最后fio對延遲的統計結果:

      delalloc:
      lat (usec): min=2 , max=193466 , avg= 5.86, stdev=227.91

      nodelalloc:
      lat (usec): min=3 , max=16388 , avg= 7.00, stdev=28.92

      從上面的統計結果看,寫操作的平均延遲:打開delalloc后為5.86us,關閉delalloc后為7.00us;最小延遲delalloc為2us,nodelalloc為3us;但是最大延遲delalloc為193.466ms,nodelalloc下僅為16.388ms。可見delalloc確實將多個寫操作請求集中到了一起來進行。因此在提供較低平均延遲的情況下,會造成某次寫操作的延遲較大。

      通過上面的分析可以看到,目前會受到Ext4的delalloc特性影響的應用必須具備如下條件:
      0. Buffer IO
      1. 寫操作過程中會涉及磁盤塊的分配,主要是記錄日志這類追加寫操作;
      2. 每次寫操作后沒有刷新數據,而是等待系統自動進行回寫;
      3. 對延遲有較高要求。

      解決方法:關閉delalloc
      1. mount -t ext4 -o remount,nodelalloc /${dev} /${mnt};
      2. 編輯/etc/fstab中相關mount項,添加nodelalloc掛載參數

      posted @ 2016-06-21 14:16  CobbLiu  閱讀(4606)  評論(1)    收藏  舉報
      主站蜘蛛池模板: 亚洲综合伊人五月天中文| 孕妇特级毛片ww无码内射| 精品无码人妻| 亚洲另类激情专区小说图片| 一本色道久久—综合亚洲| 麻豆国产va免费精品高清在线 | 欧美熟妇xxxxx欧美老妇不卡| 97人人模人人爽人人少妇| 欧美激情内射喷水高潮| 免费无码成人AV在线播放不卡| 日韩中文字幕国产精品| 亚洲色偷偷色噜噜狠狠99| 久久精品a亚洲国产v高清不卡| 国产情侣激情在线对白| 真实单亲乱l仑对白视频| 中文字幕人妻色偷偷久久| 55大东北熟女啪啪嗷嗷叫| 米奇亚洲国产精品思久久| 国产精品无码无卡在线播放| 人人妻人人澡人人爽人人精品av | 国产成人精品一区二区三区免费| 久久精品国产字幕高潮| 一区二区三区放荡人妻| 18成人片黄网站www| 国产乱精品一区二区三区| 97成人碰碰久久人人超级碰oo| 亚洲天堂在线观看完整版| 吉林市| 亚洲毛片多多影院| 米奇影院888奇米色99在线| 欧美嫩交一区二区三区| 欧美一区内射最近更新| 欧美亚洲一区二区三区在线| 极品蜜臀黄色在线观看| 久久精品国产亚洲AⅤ无码| 欧美乱码精品一区二区三区| 亚洲一区中文字幕第十页| 国产一区二区亚洲精品| 国产女人18毛片水真多1| 91久久久久无码精品露脸| 亚洲国产精品一区二区第一页|