RSS   



  可打印版本 | 推薦給朋友 | 訂閱主題 | 收藏主題 | 純文字版  


 


 
主題: [討論] [討論]關於supercache開啟延遲寫入的問題   字型大小:||| 
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7455
 . 失蹤: 387
#1 : 2008-12-7 09:46 PM     全部回覆 引言回覆


引用:
ROACH寫到:
(...前略)
cache page size:32
cache size: 128m
Read - ahead: 7
(後略...)


Read-ahead: 7 有點多,建議壓低到 5 以下。
開過高的 Read-ahead,SuperCache 會每次「預讀」過多的資料量,會造成「預讀」時間過久。對「連續」的資料量處理會有幫忙,但對「隨機」的資料處理幫助就不大,也造成 CPU、記憶體和 SuperCache 花太多時間在預讀上。


喵 之前看過 PCDVD 的文章,
cache page size:32
cache size: 128MB
Read-ahead: 5 (Read-ahead 的建議值是 5,)

cache size / cache page * Read-ahead 數 = 每次預讀資料量 Byte(s)
128MB / 32k * 5 = 20480 Bytes = 20kB
256MB / 32k * 3 = 24576 Bytes = 24kB
384MB / 32k * 2 = 24576 Bytes = 24kB
即 無論多少 ???MB Cache,Read-ahead 的量都壓低在 20kB 左右。


若 KMPlayer 播放時會遲滯。
將 Read-ahead : 0。(去除掉 Read-ahead 的影響。)
必要時可試著把 SuperCache 關掉再播。(除掉 SuperCache 的因素影響。)
若還是會延遲,那就不是 SuperCache 之罪。

[badcat 在  2008-12-7 09:47 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7455
 . 失蹤: 387
#2 : 2008-12-8 03:29 PM     全部回覆 引言回覆

幾位前輩說的很有道理,送花先。

壞喵 也是覺的 Read-ahead 應該不太會影響作業效率,尤其是讀影片這種循序的檔案。
但如果關掉 Deferred-Write Mode 就會正常運作,會不會是 BT or eMule or SuperCache 的「讀寫動作」影響了播放程式的讀取。

應如 wugen & killer00 兩位所言
ROACH 版大可以試試
先將 BT & eMule 等 P2P 分享關閉,再來播放影片。
若這樣就能看出明顯的改善遲滯,那就可證明 BT & eMule 會和 播放軟體 搶「硬碟讀寫資源」。
再來就調整 SuperCache 要怎麼設定才會保持平衡?
若真的都不行,那就如同 wugen 所言,可能就要把 影片 和 P2P 檔案分離到不同的「實體硬碟」。

不過 壞喵 是沒遇到這樣的問題啦!貓的 AMD Duron 700Mhz 動物機 (夠遜吧?),利用 SuperCache + 100MB 區域網路 分享「網路共用目錄」在別的電腦來播放影片,都很順啊!(貓 比較懶,影片 和 P2P 檔案都放在同一台硬碟沒整理,壞習慣啊!)

[badcat 在  2008-12-9 11:09 AM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7455
 . 失蹤: 387
#3 : 2008-12-11 04:31 PM     全部回覆 引言回覆

從 ROACH 版大的測試,壞喵 得出一個結論:

因為 eMule 累積了 15 秒的「寫入」資料量已經很多,所以當「寫入」時,勢必會影響同一台硬碟的「讀寫」。(Ex:  同時 KMPlayer 也在讀 or 寫。)

要嘛就減少該碟的 Cache RAM 大小,順勢就減少寫入的資料量。(這是笨方法。)
要嘛就減少 Lazywrite latency: 5 seconds,寫入時間,順勢也會減少寫入的資料量。(但也會減少寫入的效能。)
要嘛就 Suspend lazywriting : on (無限延遲到有空寫入),但這樣斷電或當機時,資料損失就會很嚴重。
要嘛就 Deferred-write mode : off,關閉整個「寫入快取」,自然就不會累積大量的寫入動作而影響其它程式。(但就得不到「延遲寫入」的好處,SuperCache 官方預設值就是「off」,因為「安全第一」。)


ROACH 版大您 SuperCache 的設定為:
Deferred-write mode : on
Suspend lazywriting : on


壞喵 想問:「您有 UPS [不斷電系統] 嗎?」(您心臟真強!)

壞喵 有 UPS [不斷電系統],也只敢開:
Deferred-write mode : on
Lazywrite latency: 15 seconds (預設值)

至於 Suspend lazywriting : on,壞喵沒這個膽量開啟。(開啟了此項,壞喵 的系統有時也會怪怪的,加上沒這麼強的心臟,所以也不想開啟「延遲至閒置時才寫入」這麼危險的選項。)

[badcat 在  2008-12-11 05:42 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記

   

快速回覆
表情符號

更多 Smilies

字型大小 : |||      [完成後可按 Ctrl+Enter 發佈]        

溫馨提示:本區開放遊客瀏覽。
選項:
關閉 URL 識別    關閉 表情符號    關閉 Discuz! 代碼    使用個人簽名    接收新回覆信件通知
發表時自動複製內容   [立即複製] (IE only)


 



所在時區為 GMT+8, 現在時間是 2024-11-26 01:55 PM
清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明
Discuz! 0.1 | Processed in 0.019695 second(s), 7 queries , Qzip disabled