Board logo

主題: [討論] [討論]關於supercache開啟延遲寫入的問題 [打印本頁]
發表人: ROACH    時間: 2008-12-7 06:53 PM     主題: [討論]關於supercache開啟延遲寫入的問題

最近這幾天開始研究supercache
至於教學Google隨便查都有
比較完整的是這兩篇
http://tw.myblog.yahoo.com/jw!mZ ... &l=f&fid=23
http://tw.myblog.yahoo.com/jw!mZ ... &l=f&fid=23


但是每次在Google看到關於 Deferred-Write 這個設定十之八九
都是

Deferred-Write Mode 建議數值:不勾選
勾選時會啟用延遲寫入模式,也就是寫入檔案時先寫到記憶體中, 然後再在背景寫入硬碟,
好處是可以加速寫入資料的速度, 但沒UPS的電腦,一旦斷電,資料就流失了


可是玩P2P就是不希望一直對著硬碟不斷的IO讀取寫寫寫
如果集滿128m一次寫入痛一次總比痛128次好


經過詢問badcat 後
以及參考各類文章後
我先設定的如下


我把我D槽(動物跟BT跟影片還有A級影片區)
設定的如下

cache page size:32
cache size: 128m
Read - ahead: 7

開啟Deferred-Write Mode設定的15

結果用kmplayer看影片
看大約三秒會影片會頓一下每三秒都會這樣~~

後來我開啟最後面的 lazywrting 有改善一點變成大約10~15秒頓一下

把Deferred-Write Mode功能關掉
看影片就順多的都不會頓一下
這是滿怪的一件事情

給想玩supercache的朋友一點參考
發表人: killer00    時間: 2008-12-7 09:19 PM

以我自身的經驗來說，要玩這類工具，RAM、主機板、OS、軟體本身 這四者的穩定度都是必需的

RAM 沒通過 MemTest86 測試，不能保證說 RAM 沒問題

主機板就比較難歸咎是哪部份出問題，不同家的板子用的是同牌同級晶片組，一個能順利玩，另一則未必

OS 就比較簡單，越單純越穩定，非官方整合版穩定度 100% 無法經得起考驗的

軟體本身就只有靠大家測試，就說 SuperCache 好了，我從 1.1.14.0 開始玩，歷經 1.1.14.0、1.1.16.0、3.0.1.0，玩了超過三年，1.1.14.0、1.1.15.0 的不穩定，網路上三年多前的抱怨文大多是指這兩個版本；1.1.16.0 的穩定，我自身體驗兩年，確實是沒話說，週遭的朋友我都有幫忙裝，沒人出過問題。至於 3.0.1.0 我才用了三個多月，目前也都順利運作，沒出現過「藍天白字」。

所以只要多爬文，是否為軟體本身出問題也是可以判斷。

Deferred-Write 可以看成非同步寫入，就架構上看來，這功能對主機板的要求會比較嚴格(從南、北橋到硬碟 I/O 都是)，也許驅動之間相容性不佳，也許主機板穩定性有問題，亦或是磁碟重組工具的干擾，都有可能造成此功能無法順利運作。

關於此功能，我覺得把它看成買硬碟，買到地雷算自己倒霉；買到良品算自己好運。同樣的，能順利使用用此功能(如小弟自己)，也是運氣好；不能正常使用(如ROACH大)，就別強求，穩定才是最重要的。

PS：我目前能證明的是，至少在 NF7-S、A8V、EEEBOX 上，Deferred-Write 都能順利、正常運作，沒有遇到此問題。(不過在 1.1.15.0 版時我也遇過，當時主力是 NF7-S，與 ROACH 大說的情況差不多，不定時停頓，關了 Deferred-Write 就正常，直到升級至 1.1.16.0 版時才能正常使用)
發表人: ROACH    時間: 2008-12-7 09:39 PM

我的Supercache是3.030
跟版本有關係嗎

或許下一個版本就會變好的吧
發表人: badcat    時間: 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 作了最後編輯]
發表人: wugen    時間: 2008-12-7 10:14 PM

我自己的經驗是read ahead設在4-5左右最順.  cache size不用開太大(看硬碟而定).  最好是把影片區和p2p區做分離(p2p一定fragment超多, 和影片放在一起會聯帶影響到)
發表人: killer00    時間: 2008-12-8 12:03 AM

wugen 說的不錯，資料區與暫存區分離在不同硬碟上，的確能降低硬碟負載，進而增加硬碟對單一工作的效能發揮。

因為影片是可以被預讀的(雖然有 P2P 干擾)，理論上影片播放的資料量遠大於 P2P，所以 SuperCache 主力應該在影片播放上，故 Read-ahead 應是幫助播放，而不會是阻礙播放，[心得]有2G以上RAM的可以參考內也有關於 Read-ahead 的案例，該名網友使用 SuperCache(Read-ahead=0) 後玩遊戲不順，會定時 Delay，但啟用足量之 Read-ahead 後，問題就完全改善，證明 Read-ahead 加大對於可預期的資料是有加分效果。

雖然我不覺得是 Read-ahead 造成，不過 P2P 的使用是不需要預讀機制(也無從預讀起)，就長時間使用上來看， Read-ahead 還是關閉會比較適合。



3.030 版？這要看有多少人有類似問題，是不是 bug 還說不準。不然你可以試著用舊的版本，反正效能上沒有損失，但不保證問題一定解決(若主因不是 SuperCache，怎麼換也不會改善)。
發表人: Acute    時間: 2008-12-8 02:49 AM

先強調.. 我沒用過supercache

supercache 有強調, 他是block-level cache, 所謂block-level 是指他是建構在filesystem 跟實體storage device 之間. 通常OS 本身在block-level 也會有一層小小的cache 機制, 即使是早期的DOS 也有, DOS 的block-level cache 就是config.sys 裡面的BUFFER 設定.

討論cache 機制, 就得先知道電腦系統怎樣跟硬碟溝通, 還有硬碟真正的存取瓶頸在哪兒 ^^"
硬碟的存取以512 bytes (sector size) 為單位, 一次硬碟存取的動作是: 傳送讀取指令, 之後CPU 就去忙他的事情, 等待約9ms 硬碟資料準備完成, 會傳送interrupt 給CPU, 然後系統就去把資料搬到記憶體, 搬資料的時間很短, 以ATA100 的速度算, 搬4K 資料, 只需要0.04ms左右, 所以, 真正花時間都是在等待, 而不是搬資料. 一般而言, 硬碟一次可以讀取的最大資料通常都是32K, 所以, 如果一次讀取32K, 所需要的時間成本是9ms + 0.32ms, 一次讀取16K 的時間成本是9ms + 0.15ms... 以此類推.

filesystem 面對硬碟時, 當然也不會笨到每次存取512 bytes, 可是filesystem 受限於cluster 的關係, 每次讀/寫的最大容量就是一個cluster, 以NTFS 為例, 幾乎cluster size 都4K, 而FAT32 通常都是32K(除非硬碟容量很小, FAT32 才能用比較小的cluster size). 無論一個檔案在硬碟上多分散, 通常還是會連續存放, 以我自己的硬碟而言, 最慘的一個file, 大小是1.5G, 分散成將近3000個區塊, 平均起來, 一個區塊也足足有500K.

block-level 的read-ahead, 他不用管cluster size, 正常來說, 他會把讀取動作擴展到硬碟容許的最大讀取值, 如前面所說, 至少一次是32K. 就算整個多讀取的資料都浪費了, 其實浪費時間小於0.3ms(以32K 為例), 但是只要省到一次, 就是省下9ms!! 因此, 其實不用擔心read-ahead 會浪費的問題, 如果記憶體夠, read-ahead 絕對是加分的!!

可是, read-ahead 也不應該設過大, 因為只要造成硬碟多次讀取, 其實就形成一種浪費, 最好的設定法, 是配合硬碟的存取限制, 一般來說, 32K 是一個不錯的數值, 因為supercache 是根據page size 為單位設定read-ahead, 所以, 如果page size 已經是32K, 應該是設定1. 這部份我跟badcat 對於supercache 的認定不同, badcat 是認為:

引用:
badcat寫到:
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 左右。

可是我看supercache 官方資料, 我覺得, 那個數值是表示, 每次read-ahead 幾個page !!
我是從這個網頁看的:
http://www.superspeed.com/desktop/scsv-desktop_release_notes.htm
裡面提到:
The maximum value of this setting varies according to page size. For page sizes of 4, 8, 16, 32, and 64 KB, the maximum value is 15 pages. For page sizes of 128 and 256 KB, the maximum values are 7 and 3 pages, respectively.


write cache 一直是disk cache 最恐怖的一部分, 當系統因故停擺, 所有還沒真實寫入硬碟的資料, 全部消失. 事實上現在的硬碟很多本身都有write cache 機制, 只是, 做系統的人, 打死也不願意去開啟這項功能.

啟用write cache 除了要負擔系統停擺可能資料流失的問題外, 另一個困擾其實就是ROACH遇到的問題 -- 系統在執行需要即時反應的程式! 怎麼說呢? cache memory 是有限度的, write cache 比較大的用處在於頻繁的細微改變硬碟資料, 例如資料庫程式, 可能因故不斷改變幾個特定的資料錄. 如果發生不斷的寫入硬碟資料, 然後位置都不同, write cache 用途就完全消失了, 反而造成更大的困擾, 因為當cache memory 被耗盡, cache 程式就得把記憶體內的資料真實寫入硬碟, 而且這時候, 極可能是一次大量的寫入, 所以反而造成系統瞬間被整個拉住, 如果播放影片, 後果當然就挺悽慘嚕.

Acute.
發表人: chaeung    時間: 2008-12-8 02:19 PM

個人獨斷的偏見：

首先要清楚cache/buffer的作用, cache並不是萬能的天神.
cache的定義僅僅在於將經常重覆使用到的資料保留在RAM中而不用每次去HDD讀取, 用以加速, 所以有hint rate.
buffer的定義是"一次"將許多零碎小資料寫入及從硬碟讀出資料大小, 也就是所謂緩衝的空間, 與資料是否重覆使用無關.

一般個人家用而言:

動物機需要的零碎區塊在RAM空間累積到一定大小再一次性寫入, 但除非一次只下載一個檔案且事先分配空間, 否則多檔案的各個區塊寫入對各檔案整體而言還是零碎分散的, 這是buffer的作用, buffer夠大, 就可以累積很多一次寫入.
要下載就要上傳, 要上傳就要讀資料, 外來的連線對許多檔案各區塊的要求不但多而且重覆性高, 為了降低每次讀HDD的次數就需要一個RAM空間放最常用的資料, 這是cache的作用, 通常所謂操掛硬碟關鍵在此, 動物機的硬碟寫入通常只寫一次, 但讀取次數可能成千上萬, cache夠大可有效降低重覆讀取次數, 保養硬碟.

看影片, 除非是編輯時需要經常對同一區塊反覆讀寫, 否則播放只是硬碟中的檔案從頭到尾讀一遍而已, 完全看HDD的I/O速度, cache完全沒有意義, 除非cache比影片大許多又沒有別的工作動作(影響cache的hint rate計算), 加大buffer還能有效減少讀取次數(不過也不能大到播放程式每次要停下來等大量資料讀入).

對server而言... 要tuning系統, 這計算可就複雜了, 在此略過不提.

以上
發表人: badcat    時間: 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 作了最後編輯]
發表人: ROACH    時間: 2008-12-10 10:29 PM

經過實驗
設定的 256MB / 32k * 3
Deferred-Write Mode設定的15

1.先開啟kmplayer播放同部電影看的十分鐘順的很
2.再開啟emule過五分鐘後再撥放kmplayer撥放同一部電影
   此時開始每五秒影片頓一次
3.再把emule關掉五分鐘後打開kmplayer看得十分鐘很順


再把Deferred-Write Mode功能關閉
其他設定照舊

emule開啟後再開kmplayer影片播放也很順

由此可見開Deferred-Write 15
又開p2p軟體又開kmplayer真的會造成影片的停頓

後來做一個動作開啟最後一個 lazywrting  這個是邊開emule邊看影片是最順的

如下圖


[ROACH 在  2008-12-10 10:58 PM 作了最後編輯]
發表人: badcat    時間: 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 作了最後編輯]
發表人: so8so    時間: 2008-12-17 11:23 AM


引用:
ROACH寫到:
我的Supercache是3.030
跟版本有關係嗎

或許下一個版本就會變好的吧

http://www.superspeed.com/desktop/supercache.php
裡面最新是 3.0.2 喔

之前搜尋 序號機 時 有看到
官網 3.0.3 是有釋出
但是很快就又改回 3.0.2 版
實際原因不清楚



歡迎光臨 TWed2k (http://twed2k.org/) Powered by Discuz! 4.1.0