![]() |
PCDVD數位科技討論區
(https://www.pcdvd.com.tw/index.php)
- 系統組件
(https://www.pcdvd.com.tw/forumdisplay.php?f=19)
- - 使用Ramdisk及Supercache II的感想!
(https://www.pcdvd.com.tw/showthread.php?t=797864)
|
|---|
引用:
現在的P2P軟體幾乎都有可以設定一部分空間(System Memory)來做Cache吧..!!~~ 再拿這個.. 幫助應該不會很大... 如果要評估的話.. 可以拿Process Explorer衡量IO Status.. |
引用:
我後來想了一下 除非deferred-write 有設定 Lazywrite latency有打開 讓它在存滿資料後才寫入 不然的確對P2P而言好像沒有差多少...囧 |
引用:
你完全誤解,請不要隨意把同一件事拆成兩部分來看 我前面怎麼說的? 引用:
意思是原本應該在硬碟上發生的檔案重組動作,我以 SuperCache 來當平台,這樣可以加速檔案的重組速度∼越離散的資料效果越好。 to iorittn: 不是所有的 P2P 軟體都有 Cache,像日本 P2P∼share 就沒有;像 eMule 的 file buffer 很小且有上限。SuperCache 此時就能暫代其功能。 |
emule的緩衝區最大4MB
說多不多,說少也夠用 其實我是不知BitComet設自動管理時是吃多少暫存 這方面比較有疑問 目前在試o&o clevercache 感覺上也還不錯 目前用最大化檔案快取模式 一些自訂的項目不知如何設就不用了...囧 SuperCache會讓人想每個槽都開XD RAM吃很大是真的...... |
引用:
上週用SuperCache之前也用了o&o clevercache幾天 感覺也不錯 這軟體會自動管理主記憶體省了不少容量 給家人舊的筆電記憶體才512M的使用 很滿意 跑軟體也以前主記憶體少而不會再有卡卡的感覺 建議記憶體1G以下的使用 ----------------------------------------------------------------------- SuperCache用了一週了 蠻滿意的 雖然只有開C槽 遊戲讀取條在跑時明顯快了一些 :like: 開機和開檔案都有感覺變快 :agree: 記憶體2G的也是可以只開192~256M給主系統槽 但不建議開太多槽就是了...2G開重度遊戲1G多就被吃掉了 :jolin: 或是主系統槽給個128M 主要放遊戲的槽也設128M 也是2G用戶在主記憶體拮据之下可以參考的設置組合~ (*建議虛擬記憶體要設回系統槽 才會讓SuperCache連帶發生效用) 只是不知道SuperCache和o&o clevercache 2者一起裝上去會不會有問題?....... :ase |
to iorittn:
現今常見的 BT client 應該都有加入暫存功能,大小也依使用者自行調整(BitComet 也不例外)。 至於 eMule,速度慢的人可能沒影響,像我自己使用,上傳都是150K以上,下載平均都在 200K,高的時侯會達 600K 以上,考慮 File Buffer 既要給上、下載使用,又不能忽略最大下載速度時的使用情況,那一點點的 Buffer 是不足使用的。 此外,在這個討論串中,前輩們已經說得很清楚 [心得]有2G以上RAM的可以參考 SuperCache 不適合 Ram 小的人使用,不但效果與 o&o clevercache 相差無幾,而且因為最低用量是 128MB/disk parttione,所以 C/P 值會低於 o&o clevercache。 to ss9785: SuperCache 和 o&o clevercache 混用是不會有問題的,我就是活生生的實例,用資歷長達三年以上。 要注意的是∼ o&o clevercache 的運作模式以『自動偵測-最大化主記憶體』最為有效。 理由很簡單,因為除此以外的模式,強調『檔案快取』功能功能的成份都會比較高,但 SuperCache 已經在擔任『檔案快取』的工作,o&o clevercache 再插一手,效果不但不會加強,反而可能造成「兩組檔案快取都在處理同一份資料」的狀況,這就是資源的浪費。 而且對於『檔案快取』除了使用 RAM 的空間外,還需要佔用 CPU 的處理量,同一份工作花 200% 的心力,得到的效果與花 100% 心力完全一樣,這樣是非常不划算的。 再說,o&o clevercache 的記憶體管理決策非常優秀,所以我將它定調為『記憶體管理』工具,比起現在網路上在流傳的任何一款『記憶體管理』工具要好太多。 現在網路上在流傳的任何一款『記憶體管理』工具,它們所做的事情都是∼將資料從記憶體 Swap 至硬碟,換取 Free 記憶體空間。 就因為如此,如果資料還是有用的,就會發生「記憶體 Swap 至硬碟」、「硬碟 Swap 至記憶體」的事件,其代價是降低系統效能∼這兩個動作除了佔用 CPU 處理量,也佔用硬碟,別忘了,硬碟不是全雙工的產品、速度遠比記憶體要慢(就算 SSD 也一樣),要它做多工的事,只會讓每個事的效能大大地降低。 這些軟體都是都是以『犧牲執行時間』換取『Free 記憶體空間』,所以不值得一用。 o&o clevercache 的運作方式我不清楚,但就觀察硬碟 I/O 的使用情況來看,o&o clevercache 不是使用那些軟體的處理方式,所以不用擔心執行效率會被 Swap 動作所拖累。而且,就我從『工作管理員』那邊觀察記憶體使用的情況來看,o&o clevercache 能在其它軟體關閉時,確實釋出記憶體空間,在此同時,其它軟體並不會受到影響,以致運作出現延遲。 故 o&o clevercache 就算不做『檔案快取』的管理工具,仍然有使用它的價值存在。 |
感謝killer00的解說
我也來說說這幾天用o&o clevercache的感想 不過我是設定為最大檔案快取模式來跑 之前用SuperCache時 我幾乎每一個分割區都有切 不過也因為如此 至少128MB的用量實在是有點.... 我有8個分割區 設了6個 包括遊戲、P2P之類的都設了128MB 順暢度有提昇 但在遊戲中提昇的感覺不高 我是以線上遊戲幻想戰記為實驗品 (我也只玩這個XD) 後來關掉SuperCache改開clevercache 如上說用最大檔案快取模式 開啟遊戲標頭畫面很明顯就讀取了非常久.... 但進入遊戲後順暢度居然高過開SuperCache時 後來我看clevercache的記錄 發現遊戲打開後的檔案快取量多了約200MB以上 也就是說我在遊戲分割區開的128MB是不夠用的 也因此效能打折 而打開遊戲時的龜速我認為是資料載入Cache時造成的 在該有的資料都有了之後就會很順 我是建議硬碟分割區比較少的人 可使用SuperCache並分出至少300MB以上的快取 而分割區多的話使用clevercache統一管理 或是跟killer00說的2者併用法可產生比較大的效果 |
to iorittn:
你這做法是會比較好沒錯,因為 Partition 數量多,且每個都有可能用到很大量,在記憶體又是有限的情況下,與其分散成數個小 Cache,不如統合成一個大 Cache 給大家輪流共用,效果會比較明顯。 對絕大多數使用者來說,大部份時間會 100% 專注在單一工作上,所以對於前景工作的關注會特別多,依此特性將『檔案快取』的使用優先權改為前景工作優先,而不再是大家均等,確實是高效益的作法。 o&o clevercache 它的『檔案快取』決策要比 XP 內建的『檔案快取』好很多,這點在[心得]有2G以上RAM的可以參考討論串中也已獲得證實。 比較可惜的是,o&o clevercache 沒有黑、白名單機制,不能讓服務排除或鎖定特定目標,不然搭配 SuperCache 可以做更靈活的運用。 PS:我必須說∼o&o clevercache 真的是難得一見的好工具。 |
我去找 3代 可是跟 SuperCache II v1.1.16.0
內容怎麼版本都顯示 4.1.100.1332 .... 先試試看好了 怕是假檔..... :jolin: |
引用:
感謝killer00大詳細解說~ 學到了不少比較技術面的原理 受教了 :laugh: :agree: 小弟可以放心使用了 :like: 今天也把家中小弟的電腦裝了o&o clevercache (因為只是K8單核+1G記憶體+WIN2000系統) 使用後感覺"順暢"許多 o&o clevercache用起來和其他管理記憶體程式很不一樣 如同大大所解釋的以前古早時代用過其他的記憶體管理程式 都是硬給你生出來主記憶體空間 但整理時會非常LAG 但這款明明記憶體用量小很多 但卻絲毫不會感覺停頓的現象~ :like: MS若學得這種技術WIN系列就不會那樣吃記憶體了吧........ :D -------------------------------------------------------- 但小弟還有個問題要請教killer00大 請問o&o clevercache選項當中 1.額外功能-記憶體使用-"禁止對磁碟的核心交替" 這選項的用途? 是停止虛擬記憶體的作動嗎? 還是.....? 2.還有 額外功能-處理時間 內那5個選擇要選哪個比較好? 謝謝~ |
| 所有的時間均為GMT +8。 現在的時間是07:06 PM. |
vBulletin Version 3.0.1
powered_by_vbulletin 2026。