System Activity/zh-tw: Difference between revisions

From KDE Wiki Sandbox
m (Created page with "==一般提示==")
(Updating to match new version of source page)
 
(48 intermediate revisions by 2 users not shown)
Line 3: Line 3:
== 介紹 ==
== 介紹 ==


'''System Activity''' is akin to the Microsoft Windows' '''Task Manager''', Apple's Mac OS X's '''Activity Monitor''' and Gnome's '''System Monitor'''.  It pops up when you press the keyboard shortcut <keycap>Ctrl + Esc </keycap> or from the '''System Activity''' icon,[[File:SystemActivity_krunner_launch.png]], in a [[Special:myLanguage/KRunner|KRunner]] <keycap>(Alt + F2)</keycap> window.
'''系統活動'''近似於Microsoft Window的'''任務管理器''',Apple Mac OS X'''活動監視器'''以及GNOME的'''系統監視器'''。按住鍵盤快捷鍵<keycap>Ctrl + Esc </keycap>或點擊 [[Special:myLanguage/KRunner|KRunner]]<keycap>(Alt + F2)</keycap>)視窗左側的[[File:SystemActivity_krunner_launch.png]]「系統活動」圖示就會彈出它。


It shows a list of currently running processes, along with their CPU usage, Memory usage, and various other pieces of information.
它顯示當前運行進程的列表,外帶它們的CPU佔用,記憶體佔用和多種其他部分的信息。




Line 13: Line 13:
==一般提示==
==一般提示==


Almost every part of the UI displays a tooltip, when you hover the mouse over it for long enough, to provide more detailed information, and "WhatsThis" functionality, activated by clicking the [[File:Whatsthis.png]] button, to explain what the information means.
幾乎介面每個部分都有工具提示(當你懸停鼠標指針足夠久時)來提供更多詳細信息,“這是什麼功能”(點擊[[File:Whatsthis.png]]按鈕激活)解釋信息代表的意思。


For example, hovering over the CPU usage for a process we can see various other bits of information including how much time the program has been running for in total.
例如,懸停指針到一個進程的CPU使用率上,我們會看到各種其他信息,包括這個程式總共運行了多長時間。




Line 21: Line 21:




==Why is my system currently running slowly?==
== 為什麼我當前系統運行的這麼慢? ==


A system can be running unusually slow because a process (program) is demanding all of the computer's processing power (CPU usage) or is using all of the computer's memory.
一個系統會由於某個進程(程式)請求所有電腦處理能力(CPU使用)或占用所有電腦的記憶體而變得異常緩慢。


By default, processes owned by the current user that are using a lot of CPU or memory are near the top.  This means that any misbehaving programs should be near the top and easily visible.  For example:
默認情況下,當前用戶擁有的進程中佔用大量CPU或記憶體的進程會靠近頂部。這意味著異常程式應該是靠近頂部,很容易分辨。舉個例子:




Line 31: Line 31:




In this example, '''Firefox''' has stopped responding and is using 99% of CPU.
<span class="mw-translate-fuzzy">
To end the process that is misbehaving, click on the process to select it and press the <menuchoice>Kill Process...</menuchoice> button.  This will send a polite request to the program, asking it to close.
在這個例子中,firefox停止響應並佔用了99%的CPU。要終止這個異常的進程,點擊進程選定它並按下<menuchoice>殺死進程</menuchoice> 按鈕。它會發送一個請求(a polite request)給程式,要求它關閉。
</span>


===I can't kill it - it just won't die!===
===我殺不了它 - 它不死! ===


Thankfully it's fairly rare, but just occasionally you may meet this.  If the process is misbehaving it may ignore your request to end, so we may need to force the program to end immediately.  Doing this may result in any documents etc that the program had opened but not saved.  To do this, right click on the process and choose <menuchoice>Send Signal</menuchoice> then choose <menuchoice>Kill (KILL)</menuchoice>.
<span class="mw-translate-fuzzy">
謝天謝地這種事情很少見,僅僅偶爾你會遇到。如果某個進程異常的話它有可能會忽視你的終止請求,這時我們需要直接強制這個進程終止。這樣做可能會導致這個程式打開的文檔等未保存就關閉。要強制終止,這樣做,右擊進程並選擇“發送信號”,然後選擇<menuchoice>殺掉(殺掉)</menuchoice>
</span>


Sometimes even this will not kill the process, or the option will not be given.  This can happen, for example, in '''vuze''' with certain kernels.  If the process or one of its threads gets caught in a kernel bug then it can end up being stuck trying to execute a kernel operation and being completely unkillable.  Often there is no solution to this other than rebooting the machine.
有時甚至這樣也無法殺掉進程,亦或是根本沒這個操作選項。這種情況在比如使用某些內核時發生。如果進程本身或是進程的某個線程引發內核bug,最終使得其陷入不停的執行內核操作中,便處於完全無法殺掉的狀態。通常除了重啟機子,沒其他解決方法了。


===Zombie processes===
===殭屍進程===


Processes which are in a Zombie state are already dead, and so cannot be killed.  The system keeps them around until their parent process notices, which is usually a very short amount of time.  Seeing a Zombie process usually indicates that the parent process has stopped responding.
殭屍狀態的進程已經死了,所以不能被殺死。系統繼續保留它們直到它們的父進程注意到回收它們,通常只需要很短時間。通常看到殭屍進程表明它的父進程已經停止響應了。


===Targeting a window to kill===
===選取殺死一個視窗===


If you want to kill a particular window that has frozen up, simply press <keycap>Ctrl + Alt + Esc</keycap> at any time.  The mouse cursor should turn into an image of a skull and cross bones.  Now click the window that you want to kill.  Note that this will kill the application immediately, and you may lose any unsaved data.
如果你想要殺死某個特定的已經凍結停止響應的視窗,任意時刻簡單的按下 <keycap>Ctrl + Alt + Esc</keycap> 。鼠標指針會變成骷髏頭加十字交叉骨頭圖片'''(好可怕)'''。現在去點擊那個想殺掉的視窗。注意這會直接殺死程式,你可能會丟掉未保存的數據。


==What's the difference between Memory and Shared Memory?==
==記憶體和共享記憶體有什麼區別? ==


The Memory column shows approximately the amount of memory (RAM) that the process is using by itself, privately.  The Shared Memory column is approximately the memory that is, or could be, shared with other programs.  For example, the KDE libraries are used by all KDE programs and so are loaded into memory only once.
「記憶體列」近似顯示進程本身大約使用的存儲器(RAM)數量。 「共享記憶體列」是,或可以說,近似被其他多個程式分享存取的存儲器。舉個例子,KDE 函數庫(libraries)被所有KDE程式使用,所以只會載入記憶體一次。


From KDE SC 4.4, you can right-click on a process and view the <menuchoice>Detailed Memory Information</menuchoice> for the process to get more accurate readings.
===技術信息===


===Technical Information===
「記憶體列」顯示的是VmRSS - Shared 的值,所以通常低於''top'' 命令等顯示的值。這個值不包括被I/O 頁面支持(backed)的記憶體,被x server 佔用用於存儲程式使用的位圖的記憶體。這個值經常被叫作Unique RSS size,或URSS。接近''詳細記憶體信息''中顯示的私有記憶體使用(Private memory usage)的值。


The "Memory" column shows the value of VmRSS - Shared, and so is generally lower than the values shown by '''top''' etc.  This does not include memory backed I/O pages, and does not include memory used by the x server to store any pixmaps used by the application.  This value is often called the Unique RSS size, or URSS.  This approximates the value shown as Private memory usage in the <menuchoice>Detailed Memory Information</menuchoice>.
「共享記憶體列」與top 命令中的SHR 列一樣,會有少許不准確。接近<menuchoice>詳細記憶體信息</menuchoice>中顯示的共享記憶體使用(Shared memory usage)的值。


The Shared memory is the same as the SHR column in top and can be somewhat inaccurate.  This approximates the value shown as Shared memory usage in the <menuchoice>Detailed Memory Information</menuchoice>.
尤其是''進程表''解析的是<code>/proc/pid/stat</code> 而 <menuchoice>詳細記憶體信息 </menuchoice>對話框解析的是<code>/proc/pid/smaps</code> .


Specifically the process list parses <code>/proc/pid/stat</code> whereas the <menuchoice>Detailed Memory Information</menuchoice> dialog parses <code>/proc/pid/smaps</code>.
==如何查看一個進程記憶體的更多詳細信息? ==


==How do I view more Detailed Memory Information about a process?==
在 現在的 KDE 正式版中還未完成。在KDE SC 4.4 中,你可以在列表中選擇一個進程,右擊進程,選擇 <menuchoice>詳細記憶體信息 </menuchoice>,隨後便會得到類似這樣的信息:


From KDE SC 4.4 you will be able to select a process in the table, right click on the process, and choose <menuchoice>Detailed memory Information</menuchoice>, and get something like:


[[File:Ksysguard detailed2.png|center|500px]]


[[File:Ksysguard detailed2.png|center|500px]]


==為什麼''詳細記憶體信息'' 中的值跟進程列表中不一樣? ==
「系統活動」進程列表使用的是近似值。<menuchoice>詳細記憶體信息</menuchoice>給出的值更精確。
==為什麼'Xorg'進程佔了那麼多記憶體? ==
這個進程負責顯示所有其他程式。它的記憶體佔用包括了顯卡中使用的用於儲存來自程式的圖形映射pixmaps(圖片)的顯存。


==Why do values in Detailed Memory Information not match the process list?==
一般來說你不用去關心Xorg的記憶體佔用。


The process list in System Activity is using an approximation to gather the values.  The <menuchoice>Detailed Memory Information</menuchoice> gives more accurate values.
==我怎樣能看到進程的PID? ==


==Why is the "Xorg" process using so much memory?==
如果你想看到單個進程的''PID'',只要懸停鼠標指針到進程名上。 ''PID''會在工具提示中顯示出來。


This is the process that displays all the other applications.  Its memory usage includes all the memory used on the video card to store all the pixmaps (images) from applications.
如果你想看到所有進程的''PID'',右擊任意列標題,你會看到如下菜單:


In general you do not need to worry about the memory usage of Xorg.


==How do I see the PID of a process?==
[[File:SystemActivity_heading_contextmenu.png|center]]


If you want to see the ''PID'' of a single process, hover the mouse cursor over the name of the process.  The PID will be shown in the tooltip.
<span class="mw-translate-fuzzy">
選擇<menuchoice>顯示列'進程號' </menuchoice>。
</span>


If you want to see the PID of all the processes, right click on any column heading and you will see the menu:
==系統活動能顯示了硬碟I / O的使用情況嗎?如iotop那樣的==


Right click on the column headings, and choose <menuchoice>Show Column IO Read</menuchoice> and again for <menuchoice>Show Column IO Write</menuchoice>.  It will now show the amount of data being sent to or from the hard disk.


[[File:SystemActivity_heading_contextmenu.png|center|300px]]
[[File:Systemactivity_io.png|center|500px]]


By right clicking on the column header you can choose whether you want to view the actual amount of data being written or read from the hard disk (the default), or whether you are interested in seeing how much data the application is sending or requesting from a file.


Choose <menuchoice>Show Column 'pid'</menuchoice>.
Data requested and actual data read from the hard disk are not equivalent - for example, if two applications read from the same file the operating system does not need to read from the actual hard disk twice  - it can just read it once and remember it for a short while.  Similarly, if one process writes to a file, but then another process writes over the top of that same file, there's no point writing the first version of the file to the actual hard disk.


==Why are some processes grayed out?==
==為什麼有的進程變灰淡出? ==


For example the process '''xclock''':
比如這個進程'''xclock'''




Line 100: Line 112:




This means that the process has already died.  It is shown as a disabled
這意味著這個進程已經死了。顯示為灰色不可用進程只是為了便於更容易分辨那些停止了的進程。CPU使用率,記憶體佔用等的值只是該進程之前未結束時的值。一個已經終止的進程不消耗任何資源(它不佔用CPU,記憶體等)。
process just for convenience to make it easier to see processes that are quit.
The values for the CPU usage, Memory usage, etc are just the values from when the process was last seen alive.  A process that has ended does not take up any resources (it uses no CPU, memory etc).


==What are all of these processes owned by root and taking up no memory?==
==這些用戶名全是root 並且不佔用記憶體的進程是什麼? ==


These are kernel threads.  They exist only inside the kernel, and exist to allow the kernel to perform multiple tasks in parallel.
這些是內核線程(kernel threads)。它們只存在內核中,使得內核並行執行多個任務。


They are shown because occasionally they can be a cause of heavy CPU usage.  For example, under a heavy load, and with bad drivers, a network card can produce a huge number of interrupts, resulting in a high CPU usage in the '''ksoftirqd''' kernel thread.
<span class="mw-translate-fuzzy">
偶爾因為它們引起高CPU 使用率而顯示它們。舉例來說,處於重負載時,加上裝了不合適的驅動,網卡會產生大量的中斷(interrupts),導致了ksoftirqd 內核線程(kernel thread)的高CPU 佔用。
</span>


Likewise, a high CPU usage in '''kjournald''' can indicate that DMA transfer is not enabled on the hard disk.
此外,kjournald 中的高CPU 佔用率表明硬盤的DMA 傳輸特性沒啟用。


==Why do I have so many processes?==
==為什麼我的系統有那麼多進程? ==


A normal average-user system has around 150 to 200 processes with strange sounding names.  It would be nice to setup a wiki page giving a short description of each of these processes, but so far nobody has done this. [[Image:Face-smile.png|11px]]
正常的一般用戶系統擁有約150至200個名字稀奇古怪的進程。如果建個wiki頁面概述每個進程那會非常不錯,但至今沒人去做。 ╮(╯3╰)╭


==Why is OpenOffice.org not showing up as a graphical program?==
==為什麼OpenOffice.org 沒有作為圖形程式顯示出來? ==


Before version 3.3, OpenOffice.org did not correctly implement the window standards. Specifically, their windows did not set _NET_WM_PID to link the windows to the process. This is now [http://www.openoffice.org/issues/show_bug.cgi?id=47904 fixed] in OpenOffice.org 3.3.
3.3 版本之前的OpenOffice.org 沒有正確實現視窗標準。尤其是,它們的視窗沒有設定_NET_WM_PID 來將視窗鏈接到進程。這個問題現在OpenOffice.org 3.3 中被[http://www.openoffice.org/issues/show_bug.cgi?id=47904 修正]


==Why is gvim showing up strangely as a graphical program?==
==Why is gvim showing up strangely as a graphical program?==
Line 124: Line 136:
This is a fault with the GVim program.  GVim does not correctly implement the window standards.  Specifically, when it starts up it forks a new process to avoid hanging the shell that it ran from.  But it sets the _NET_WIN_PID property to the previous PID.  The authors have been notified but have not fixed this yet.
This is a fault with the GVim program.  GVim does not correctly implement the window standards.  Specifically, when it starts up it forks a new process to avoid hanging the shell that it ran from.  But it sets the _NET_WIN_PID property to the previous PID.  The authors have been notified but have not fixed this yet.


[[Category:System]]
[[Category:系統/zh-tw]]

Latest revision as of 07:18, 2 February 2013

介紹

系統活動近似於Microsoft Window的任務管理器,Apple Mac OS X的活動監視器以及GNOME的系統監視器。按住鍵盤快捷鍵Ctrl + Esc 或點擊 KRunner(Alt + F2))視窗左側的「系統活動」圖示就會彈出它。

它顯示當前運行進程的列表,外帶它們的CPU佔用,記憶體佔用和多種其他部分的信息。



一般提示

幾乎介面每個部分都有工具提示(當你懸停鼠標指針足夠久時)來提供更多詳細信息,“這是什麼功能”(點擊按鈕激活)解釋信息代表的意思。

例如,懸停指針到一個進程的CPU使用率上,我們會看到各種其他信息,包括這個程式總共運行了多長時間。



為什麼我當前系統運行的這麼慢?

一個系統會由於某個進程(程式)請求所有電腦處理能力(CPU使用)或占用所有電腦的記憶體而變得異常緩慢。

默認情況下,當前用戶擁有的進程中佔用大量CPU或記憶體的進程會靠近頂部。這意味著異常程式應該是靠近頂部,很容易分辨。舉個例子:



在這個例子中,firefox停止響應並佔用了99%的CPU。要終止這個異常的進程,點擊進程選定它並按下殺死進程 按鈕。它會發送一個請求(a polite request)給程式,要求它關閉。

我殺不了它 - 它不死!

謝天謝地這種事情很少見,僅僅偶爾你會遇到。如果某個進程異常的話它有可能會忽視你的終止請求,這時我們需要直接強制這個進程終止。這樣做可能會導致這個程式打開的文檔等未保存就關閉。要強制終止,這樣做,右擊進程並選擇“發送信號”,然後選擇殺掉(殺掉)

有時甚至這樣也無法殺掉進程,亦或是根本沒這個操作選項。這種情況在比如使用某些內核時發生。如果進程本身或是進程的某個線程引發內核bug,最終使得其陷入不停的執行內核操作中,便處於完全無法殺掉的狀態。通常除了重啟機子,沒其他解決方法了。

殭屍進程

殭屍狀態的進程已經死了,所以不能被殺死。系統繼續保留它們直到它們的父進程注意到回收它們,通常只需要很短時間。通常看到殭屍進程表明它的父進程已經停止響應了。

選取殺死一個視窗

如果你想要殺死某個特定的已經凍結停止響應的視窗,任意時刻簡單的按下 Ctrl + Alt + Esc 。鼠標指針會變成骷髏頭加十字交叉骨頭圖片(好可怕)。現在去點擊那個想殺掉的視窗。注意這會直接殺死程式,你可能會丟掉未保存的數據。

記憶體和共享記憶體有什麼區別?

「記憶體列」近似顯示進程本身大約使用的存儲器(RAM)數量。 「共享記憶體列」是,或可以說,近似被其他多個程式分享存取的存儲器。舉個例子,KDE 函數庫(libraries)被所有KDE程式使用,所以只會載入記憶體一次。

技術信息

「記憶體列」顯示的是VmRSS - Shared 的值,所以通常低於top 命令等顯示的值。這個值不包括被I/O 頁面支持(backed)的記憶體,被x server 佔用用於存儲程式使用的位圖的記憶體。這個值經常被叫作Unique RSS size,或URSS。接近詳細記憶體信息中顯示的私有記憶體使用(Private memory usage)的值。

「共享記憶體列」與top 命令中的SHR 列一樣,會有少許不准確。接近詳細記憶體信息中顯示的共享記憶體使用(Shared memory usage)的值。

尤其是進程表解析的是/proc/pid/stat詳細記憶體信息 對話框解析的是/proc/pid/smaps .

如何查看一個進程記憶體的更多詳細信息?

在 現在的 KDE 正式版中還未完成。在KDE SC 4.4 中,你可以在列表中選擇一個進程,右擊進程,選擇 詳細記憶體信息 ,隨後便會得到類似這樣的信息:



為什麼詳細記憶體信息 中的值跟進程列表中不一樣?

「系統活動」進程列表使用的是近似值。詳細記憶體信息給出的值更精確。

為什麼'Xorg'進程佔了那麼多記憶體?

這個進程負責顯示所有其他程式。它的記憶體佔用包括了顯卡中使用的用於儲存來自程式的圖形映射pixmaps(圖片)的顯存。

一般來說你不用去關心Xorg的記憶體佔用。

我怎樣能看到進程的PID?

如果你想看到單個進程的PID,只要懸停鼠標指針到進程名上。 PID會在工具提示中顯示出來。

如果你想看到所有進程的PID,右擊任意列標題,你會看到如下菜單:


選擇顯示列'進程號'

系統活動能顯示了硬碟I / O的使用情況嗎?如iotop那樣的

Right click on the column headings, and choose Show Column IO Read and again for Show Column IO Write. It will now show the amount of data being sent to or from the hard disk.

By right clicking on the column header you can choose whether you want to view the actual amount of data being written or read from the hard disk (the default), or whether you are interested in seeing how much data the application is sending or requesting from a file.

Data requested and actual data read from the hard disk are not equivalent - for example, if two applications read from the same file the operating system does not need to read from the actual hard disk twice - it can just read it once and remember it for a short while. Similarly, if one process writes to a file, but then another process writes over the top of that same file, there's no point writing the first version of the file to the actual hard disk.

為什麼有的進程變灰淡出?

比如這個進程xclock



這意味著這個進程已經死了。顯示為灰色不可用進程只是為了便於更容易分辨那些停止了的進程。CPU使用率,記憶體佔用等的值只是該進程之前未結束時的值。一個已經終止的進程不消耗任何資源(它不佔用CPU,記憶體等)。

這些用戶名全是root 並且不佔用記憶體的進程是什麼?

這些是內核線程(kernel threads)。它們只存在內核中,使得內核並行執行多個任務。

偶爾因為它們引起高CPU 使用率而顯示它們。舉例來說,處於重負載時,加上裝了不合適的驅動,網卡會產生大量的中斷(interrupts),導致了ksoftirqd 內核線程(kernel thread)的高CPU 佔用。

此外,kjournald 中的高CPU 佔用率表明硬盤的DMA 傳輸特性沒啟用。

為什麼我的系統有那麼多進程?

正常的一般用戶系統擁有約150至200個名字稀奇古怪的進程。如果建個wiki頁面概述每個進程那會非常不錯,但至今沒人去做。 ╮(╯3╰)╭

為什麼OpenOffice.org 沒有作為圖形程式顯示出來?

3.3 版本之前的OpenOffice.org 沒有正確實現視窗標準。尤其是,它們的視窗沒有設定_NET_WM_PID 來將視窗鏈接到進程。這個問題現在OpenOffice.org 3.3 中被修正

Why is gvim showing up strangely as a graphical program?

This is a fault with the GVim program. GVim does not correctly implement the window standards. Specifically, when it starts up it forks a new process to avoid hanging the shell that it ran from. But it sets the _NET_WIN_PID property to the previous PID. The authors have been notified but have not fixed this yet.