»
遊客:
加入
|
登入
(帳號有問題請連絡TWed2k@gmail.com)
TWed2k
»
軟體求助討論區
» [討論]關於supercache開啟延遲寫入的問題
可打印版本
|
推薦給朋友
|
訂閱主題
|
收藏主題
|
純文字版
論壇跳轉 ...
主題:
[討論]
[討論]關於supercache開啟延遲寫入的問題
字型大小:
小
|
中
|
大
|
巨
←
→
badcat
銀驢友〔初級〕
壞喵
. 積分:
541
. 精華:
3
. 文章:
837
. 收花: 3874 支
. 送花: 982 支
. 比例: 0.25
. 在線: 3330 小時
. 瀏覽: 62312 頁
. 註冊:
7455
天
. 失蹤:
387
天
#1 : 2008-12-7 09:46 PM
全部回覆
送花
(9)
送出中...
引用:
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 作了最後編輯]
[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接
快速回覆
送出中...
badcat
銀驢友〔初級〕
壞喵
. 積分:
541
. 精華:
3
. 文章:
837
. 收花: 3874 支
. 送花: 982 支
. 比例: 0.25
. 在線: 3330 小時
. 瀏覽: 62312 頁
. 註冊:
7455
天
. 失蹤:
387
天
#2 : 2008-12-8 03:29 PM
全部回覆
送花
(6)
送出中...
幾位前輩說的很有道理,送花先。
壞喵 也是覺的 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 作了最後編輯]
[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接
快速回覆
送出中...
badcat
銀驢友〔初級〕
壞喵
. 積分:
541
. 精華:
3
. 文章:
837
. 收花: 3874 支
. 送花: 982 支
. 比例: 0.25
. 在線: 3330 小時
. 瀏覽: 62312 頁
. 註冊:
7455
天
. 失蹤:
387
天
#3 : 2008-12-11 04:31 PM
全部回覆
送花
(3)
送出中...
從 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 作了最後編輯]
[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接
快速回覆
送出中...
快速回覆
表情符號
更多 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