引用:
|
作者korn
emule 跟其他 P2P 軟體在檔案讀寫時不太一樣：當檔案片段下載完成時，emule 會進行「細分」(不知這名稱是否正確。但狀態是檔案條呈現綠色，內部有條黃色的細線再跑)。這動作比遇到大水管還需要更多的 I/O，若當初資料夾或檔案ˋ路徑是在用戶的系統碟，當下會很惱火。解決方式就是把 emule 獨立，另外用顆硬碟「供養」。
BT 的一些設定在安裝時預設是在系統資料夾內部的。不過除了放檔案的資料夾以外，城市設定似乎對 I/O 沒多大影響。
|
小弟也是習慣性獨立一顆硬碟，而且都是2.5"的硬碟來跑動物~
話說之前用BT下載全套的To LOVEる HDTVRip (約13G)，
開始下載不久後BT的反應突然變得很遲鈍，原本磁碟快取設定為50MB~200MB，
想說增大到128MB~512MB試試，沒想到確定按下去，BT的反應即恢復正常！
以前在XP上拖ＸＸ金剛的 HDRip (也大約10來G)
並沒有這種現象，
不過最近已很少下載大檔(根本沒時間消化...)，沒多做幾次交叉測試就是了~
引用:
|
作者korn
readyboost, page files 我還是有留著。不過 page files 則是把「系統自動分配」改成在系統槽內設置 1~2GB 空間；readyboost 則是在 8GB 隨身碟內開到 4GB (不過 4GB 好像就是上限了)。這麼作或許可以讓系統優先利用 readyboost 來取代可能與系統競爭的 pagefiles，順便也增加磁碟空間 (page files 若採用系統自動分配，竟然要 8GB。且每個磁碟都有可能出現 :stupefy...
|
如果小弟也沒記錯的話，虛擬記憶體=實體記憶體+硬碟上的置換檔(微軟上為Pagefile.sys)，
由於早期記憶體十分寶貴，因此有些程式在啟動後，會很自動的"置換"部分的資料到Pagefile.sys，
不過如今記憶體如此賤價，以現階段一般程式的記憶體使用量來看，
置換的動作便顯得有些多餘，倒不如作業系統直接"自動判斷"後把置換檔模擬在記憶體上~
萬一真的實體記憶體被吃光、發生分頁錯誤的時候，再產生個Pagefile.sys不就結了，
以前使用512MB的記憶體跑XP&禁用Pagefile.sys，遇到有人在同一網頁貼太多圖時，
記憶體被吃光後XP也會自動產生Pagefile.sys來因應分頁錯誤~ (然後硬碟開始哀嚎~ :laugh
好幾GB的Pagefile.sys...除非是那種按鍵按下去就可以睡個覺再來的多媒體類檔案編輯，
不然沒人能夠忍受好幾G的資料在硬碟上置換的速度吧，沒事自動設這麼大幹嘛~
還是說微軟當初認為4G、8G的記憶體只有美編人員才會這麼搞，
所以依然讓Vista的分頁檔保持這種策略~
