PALMisLIFE 討論區

標題: [分享] P2P軟體不應該讓系統反應變鈍 [列印本頁]

作者: lyr 時間: 2005-11-12 00:07
標題: [分享] P2P軟體不應該讓系統反應變鈍
我比較貪心，常有 BT + eMule 同時啟動的操作需求，
又沒像大家去敗個 7K60/7K100 的好物，仍然是用 X31
原來那個 4200rpm 的雞肋硬碟。雖然有 PowerBoost2K
加持，記憶體也加到 512MB，但要上個 PIL 或是 MSN
卻是常常力不從心，滑鼠鍵盤操作半天就是無法取回 focus，
常常讓對面的友人等得不耐煩。B)

偶然之間發現若將 P2P 軟體的執行優先序改為 "標準以下"
就可以解決這個惱人的現象，當場有好多小朋友獲得緩刑，
也就開心的依此法過了一陣子。|)

人不但貪心，而且很懶。

能不能讓這些程式跑起來的時候
直接就以 "標準以下" 的優先序執行呢？不然每次都要到工作
管理員去點點選選....

問過寫程式的朋友，查了MSDN，拼拼湊湊出下面這個小程式，
難登大雅之堂，算是野人獻曝吧。我是用 Dev-C++ 這個不用錢
的 compiler 編譯的，相信 VC / BC 應該也可以吧。

compile 出執行檔後，比方說叫做 P2P.exe，我就針對 BT 跟 eMule 各建了
一個捷徑，內容像這樣：
C:\tools\P2P.exe "C:\Program Files\BitComet\BitComet.exe"
C:\tools\P2P.exe "C:\Program Files\eMule\eMule.exe"
目前順利使用中，希望也對大家有幫助。  |)

----8<-------------------------------------------------------------------
#include <windows.h>
#include <stdio.h>

int main( int argc , char *argv[] )
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
FILE *stream;

   if( 1 == argc ){
        printf("Nothing to execute.\n"

;
   return(-1);
}

   if( NULL == (stream  = fopen( argv[1], "r" )) ){
        printf( "Target not found.\n" );
        return(-2);
}else{
      fclose(stream);
}

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );

// Start the child process.
if( !CreateProcess( argv[1],    // No module name (use command line).
      argv[2],                   // Command line.
      NULL,                      // Process handle not inheritable.
      NULL,                      // Thread handle not inheritable.
      FALSE,                      // Set handle inheritance to FALSE.
      BELOW_NORMAL_PRIORITY_CLASS,  // Creation flags with lower priority.
      NULL,                      // Use parent's environment block.
      NULL,                      // Use parent's starting directory.
      &si,                         // Pointer to STARTUPINFO structure.
      &pi )                      // Pointer to PROCESS_INFORMATION structure.
      ){
      printf( "CreateProcess failed, error code = %d.\n", GetLastError() );
      return(-3);
}

// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
}

作者: lyr 時間: 2005-11-12 00:12
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
咦？兩個 include 檔的檔名不見了？
我猜是被站台程式誤判了吧。

沒辦法，只好加附檔啦～

[ Last edited by lyr on 2005-11-12 at 00:15 ]

作者: lyr 時間: 2005-11-12 02:27
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
真是對不起大家，我耍笨了～
同樣的事情只需要一個指令就做完了
C:\WINDOWS\system32\cmd.exe /c start "NICE" /belownormal "c:\program files\emule\emule.exe"
C:\WINDOWS\system32\cmd.exe /c start "NICE" /belownormal "c:\program files\bitcomet\bitcomet.exe"

作者: sueboy 時間: 2005-11-12 07:26
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
用ProcessTamer會不會比較快一點。

作者: 小酒蟲 時間: 2005-11-12 07:56
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
http://www.donationcoder.com/Software/Mouser/proctamer/index.html
http://www.lovehinaplus.com/phpB ... der=asc&start=0

作者: lyr 時間: 2005-11-12 10:20
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
ProcessTamer 的討論我也曾經看過，它自動設定的好處(亦或說是自作聰明的壞處)配上多安裝一個
即時監控軟體的代價，以我的使用例子來說似乎太大材小用(多此一舉)了，所以一開始也就只有手動
調整優先序而已。。。

作者: 小酒蟲 時間: 2005-11-12 11:10
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
以我的想法來說，平常 CPU 不忙時給 P2P 多吃點資源沒差，反正它閒著也是閒著。

目前是 Process Tamer + AMD Power Monitor 兩者去自行處理 process priority 和 CPU 升降速的「小事」。

作者: achen 時間: 2005-11-20 17:29
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
老實說我對以上說法蠻存疑的

依我的使用經驗, 我不覺得 BT 或是 eMule 有佔用很多系統資源, 我在 1GHz + 256Mb RAM 的電腦上測試, 把 BT 上下傳限制都關掉, BT 有十個檔案用 50K 左右的速度在傳輸, CPU 佔用率很少超過 3%,

我的意思是說, 其他軟體被拖慢的原因可能不是因為 P2P 軟體本身的 CPU 佔用率, 而是因為所佔用的網路頻寬, 而你把 P2P 軟體的執行優先序改為 "標準以下", 或許順便達成降低上下載速度的功效, 而對其他程式造成加速的錯覺? 我說"或許"的意思就是我真的不確定...

總之我真的對 "P2P軟體讓系統反應變鈍" 的說法抱持很大的疑點...

作者: 小酒蟲 時間: 2005-11-20 17:46
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
P2P 吃 Disk I/O 很重，不過去掉這點之外，平常它不會占掉太多 CPU 時間。

作者: achen 時間: 2005-11-20 18:17
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍

Originally posted by 小酒蟲 at 2005-11-20 01:46 AM:
P2P 吃 Disk I/O 很重，不過去掉這點之外，平常它不會占掉太多 CPU 時間。

That's what I meant.

所以, 以原發文者所做的調整, 以及它所達到的效果, 是否應該與 P2P 程式的 "優先執行順序" 沒有關係呢?

作者: mayakeq 時間: 2005-11-20 18:45
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
可能...新一點的bt程式，可以選擇用硬碟i/o比較多，或是記憶體上面跑就好
所以降低等級，佔用的某些資源(ex.記憶體)會少一點

作者: lyr 時間: 2005-11-21 13:53
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
在我的機器上，的確就像 achen 兄所描述的那樣，P2P 程式所佔的 CPU 使用率並未高過 5%，
而這數字是在整個機器 "舉步維艱" 的時候看到的。

或許問題應該要這麼問：在XP中，執行優先序的設定，究竟會如何影響程式的行為。

作者: 小酒蟲 時間: 2005-11-21 13:59
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
IDE 的宿命？

作者: czh 時間: 2005-11-21 14:07
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
SATA2就是為了P2P設計的?

作者: 小酒蟲 時間: 2005-11-21 15:00
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
原來 SCSI 早就預想到了？XD

作者: lyr 時間: 2005-11-21 16:28
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
害哩跛特第四集：7K100 如何現臨人世
1.雞肋的骨----- 原來的 40GB
2.小朋友的肉 --- 據說不用一萬了是吧
3.仇人之血 --- 上面兩位八星的，來一點吧~

--- 言歸正傳，有沒有什麼比較可靠的(實驗)方法知道瓶頸發生在什麼地方呢？

作者: achen 時間: 2005-11-21 17:33
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍

Originally posted by lyr at 2005-11-21 12:28 AM:

--- 言歸正傳，有沒有什麼比較可靠的(實驗)方法知道瓶頸發生在什麼地方呢？

你要不要把 eMule 和 BT 先只開一個, 然後把速度ㄍㄧㄥ到最大 (以確保問題會出現), 然後再來根源?

作者: 小酒蟲 時間: 2006-1-12 10:11
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍
以往一直都是用 eDonkey，也沒什麼 loading 過重的問題；結果今天改試用 eMule 時，只見硬碟狂轉，桌面反應遲緩？

系統同樣是 AMD 2G + 512MB RAM + Windows XP Pro，eMule 則採安裝預設值，未做修改。

作者: achen 時間: 2006-1-12 23:27
標題: Re: [分享] P2P軟體不應該讓系統反應變鈍

Originally posted by 小酒蟲 at 2006-1-11 06:11 PM:
以往一直都是用 eDonkey，也沒什麼 loading 過重的問題；結果今天改試用 eMule 時，只見硬碟狂轉，桌面反應遲緩？

系統同樣是 AMD 2G + 512MB RAM + Windows XP Pro，eMule 則採安裝預設值，未做修改。

應該是你弟一次使用時, eMule 程式會"細切"所有檔案的緣故
讓他跑完就會恢復正常了

每次重開機或是程式新啟動的時候, 也都會做這樣的動作

歡迎光臨 PALMisLIFE 討論區 (http://f.pil.tw/)