System Activity/zh-cn: Difference between revisions

From KDE Wiki Sandbox
(Created page with "数据请求数和实际的读入数据并不等价 - 例如如果两个程序读取同一个文件,操作系统不需要从硬盘读取两次 - 系统会读取一次并保存...")
No edit summary
 
(11 intermediate revisions by 2 users not shown)
Line 31: Line 31:




在这个例子中,'''Firefox'''停止响应并占用了99%的CPU。要终止这个异常的进程,点击进程选定它并按下“杀死进程”按钮。系统会发送一个请求给程序,要求它关闭。
在这个例子中,'''Firefox'''停止响应并占用了99%的CPU。要终止这个异常的进程,点击进程选定它并按下 <menuchoice>结束进程...</menuchoice>按钮。系统会发送一个请求给程序,要求它关闭。


===我杀不了它 - 它不死!===
===我杀不了它 - 它不死!===


谢天谢地这种事情很少见,仅仅偶尔你会遇到。如果某个进程异常的话它有可能会忽视你的终止请求,这时我们需要直接强制这个进程终止。这样做可能会导致这个程序打开的文档等未保存就关闭。要强制终止,右击进程并选择<menuchoice>发送信号</menuchoice>,然后选择<menuchoice>Kill (KILL)</menuchoice>。
谢天谢地这种事情很少见,仅仅偶尔你会遇到。如果某个进程异常的话它有可能会忽视你的终止请求,这时我们需要直接强制这个进程终止。这样做可能会导致这个程序打开的文档等未保存就关闭,导致数据丢失。要强制终止,右击进程并选择<menuchoice>发送信号</menuchoice>,然后选择<menuchoice>Kill (KILL)</menuchoice>。


有时甚至这样也无法杀掉进程,亦或是根本没这个操作选项。这种情况在比如使用某些内核时发生。如果进程本身或是进程的某个线程引发内核 bug,最终使得其陷入不停的执行内核操作中,便处于完全无法杀掉的状态。通常除了重启机子,没其他解决方法了。
有时甚至这样也无法杀掉进程,亦或是根本没这个操作选项。这种情况在比如使用某些内核时发生。如果进程本身或是进程的某个线程引发内核 bug,最终使得其陷入不停的执行内核操作中,便处于完全无法杀掉的状态。通常除了重启机子,没其他解决方法了。
Line 50: Line 50:


内存列显示进程自身使用内存的近似数值。共享内存列显示正在或可能与其它程序共同存取的内存近似值。 举个例子,KDE 函数库被所有KDE程序使用,所以只会载入内存一次。
内存列显示进程自身使用内存的近似数值。共享内存列显示正在或可能与其它程序共同存取的内存近似值。 举个例子,KDE 函数库被所有KDE程序使用,所以只会载入内存一次。
KDE SC 4.4 之后,你可以右击进程,查看进程的<menuchoice>内存详细信息</menuchoice>获取更多准确读数。


===技术信息===
===技术信息===
Line 88: Line 86:
[[File:SystemActivity_heading_contextmenu.png|center]]
[[File:SystemActivity_heading_contextmenu.png|center]]


选择<menuchoice>显示'pid'列</menuchoice>。
选择<menuchoice>显示'PID'列</menuchoice>。
 


==系统活动能够像 iotop 一样显示硬盘的 I/O 状况吗?==
==系统活动能够像 iotop 一样显示硬盘的 I/O 状况吗?==
Line 100: Line 97:


数据请求数和实际的读入数据并不等价 - 例如如果两个程序读取同一个文件,操作系统不需要从硬盘读取两次 - 系统会读取一次并保存一小段时间。类似的,进程写入文件时,如果另外一个进程也写入同一个文件,之前写入的内容就不需要再写入硬盘了。
数据请求数和实际的读入数据并不等价 - 例如如果两个程序读取同一个文件,操作系统不需要从硬盘读取两次 - 系统会读取一次并保存一小段时间。类似的,进程写入文件时,如果另外一个进程也写入同一个文件,之前写入的内容就不需要再写入硬盘了。


==为什么有的进程变灰淡出?==
==为什么有的进程变灰淡出?==
Line 114: Line 110:
==这些用户名全是 root 并且不占用内存的进程是什么?==
==这些用户名全是 root 并且不占用内存的进程是什么?==


这些是内核线程(kernel threads)。它们只存在内核中,使得内核并行执行多个任务。
这些是内核线程。它们只存在内核中,内核使用它们并行执行多个任务。


偶尔因为它们引起高 CPU 使用率而显示它们。举例来说,处于重负载时,加上装了不合适的驱动,网卡会产生大量的中断(interrupts),导致了 ksoftirqd 内核线程(kernel thread)的高 CPU 占用。
个别时候,它们会引起高CPU使用率,程序会显示它们。例如处于重负载时,如果安装了不合适的驱动,网卡会产生大量的中断,导致了 '''ksoftirqd''' 内核线程有很高的 CPU 占用。


此外,kjournald 中的高 CPU 占用率表明硬盘的 DMA 传输特性没启用。
此外,'''kjournald''' 中的高 CPU 占用率表明硬盘的 DMA 传输特性没启用。


==为什么我的系统有那么多进程?==
==为什么我的系统有那么多进程?==


正常的一般用户系统拥有约150至200个名字稀奇古怪的进程。如果建个wiki页面概述每个进程那会非常不错,但至今没人去做。╮(╯3╰)╭
正常的一般用户系统拥有约150至200个名字稀奇古怪的进程。如果建个wiki页面概述每个进程那会非常不错,但至今没人去做。[[Image:Face-smile.png|11px]]


==为什么 OpenOffice.org 没有作为图形程序显示出来?==
==为什么 OpenOffice.org 没有作为图形程序显示出来?==
Line 128: Line 124:
3.3 版本之前的 OpenOffice.org 没有正确实现窗口标准。尤其是,它们的窗口没有设定 _NET_WM_PID 来将窗口链接到进程。这个问题现在 OpenOffice.org 3.3 中被[http://www.openoffice.org/issues/show_bug.cgi?id=47904 修正] 。
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?==
==为什么 gvim 奇怪的按照图形程序显示?==


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.
这是GVim程序的问题。GVim没有正确的遵循窗口标准。为了避免堵塞执行的shell,它在启动的时候开启了一个新的进程。但是_NET_WIN_PID设置成了之前的PID。已经通知了作者,但问题还没被修复。


[[Category:系统/zh-cn]]
[[Category:系统/zh-cn]]

Latest revision as of 08:47, 22 March 2013

介绍

系统活动近似于Microsoft Window的任务管理器,Apple Mac OS X的活动监视器以及GNOME的系统监视器。按住键盘快捷键Ctrl + Esc 或点击KRunner(Alt + F2) 窗口左侧的「系统活动」图标就会弹出它。

它显示一个列表,包含当前运行的进程、各进程的的CPU占用、内存占用和多种其他方面的信息。



常用技巧

几乎界面每个部分都有工具提示,当你悬停鼠标指针足够久时,会提供更多详细信息。点击按钮可以激活“这是什么功能”,解释信息代表的意思。

例如,悬停指针到一个进程的CPU使用率上,我们会看到各种其他信息,包括这个程序总共运行了多长时间。



为什么我当前系统运行的这么慢?

一个系统会由于某个进程(程序)请求所有电脑处理能力(CPU使用)或占用所有电脑的内存而变得异常缓慢。

默认情况下,当前用户拥有的占用大量CPU或内存的进程会靠近顶部显示。这意味着异常程序应该是靠近顶部,很容易分辨。举个例子:



在这个例子中,Firefox停止响应并占用了99%的CPU。要终止这个异常的进程,点击进程选定它并按下 结束进程...按钮。系统会发送一个请求给程序,要求它关闭。

我杀不了它 - 它不死!

谢天谢地这种事情很少见,仅仅偶尔你会遇到。如果某个进程异常的话它有可能会忽视你的终止请求,这时我们需要直接强制这个进程终止。这样做可能会导致这个程序打开的文档等未保存就关闭,导致数据丢失。要强制终止,右击进程并选择发送信号,然后选择Kill (KILL)

有时甚至这样也无法杀掉进程,亦或是根本没这个操作选项。这种情况在比如使用某些内核时发生。如果进程本身或是进程的某个线程引发内核 bug,最终使得其陷入不停的执行内核操作中,便处于完全无法杀掉的状态。通常除了重启机子,没其他解决方法了。

僵尸进程

僵尸状态的进程已经死了,所以不能被杀死。系统继续保留它们直到它们的父进程注意到回收它们,通常只需要很短时间。通常看到僵尸进程表明它的父进程已经停止响应了。

选取杀死一个窗口

如果你想要杀死某个特定的已经冻结停止响应的窗口,只需按下Ctrl + Alt + Esc 。鼠标指针会变成骷髅头加十字交叉骨头图片。然后点击想杀掉的窗口。注意这会直接杀死程序,你可能会丢掉未保存的数据。

内存和共享内存有什么区别?

内存列显示进程自身使用内存的近似数值。共享内存列显示正在或可能与其它程序共同存取的内存近似值。 举个例子,KDE 函数库被所有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 SC 4.4 开始,你可以在列表中选择一个进程,右击进程,选择详细内存信息,会得到类似这样的信息:



为什么 详细内存信息 中的值跟进程列表中不一样?

「系统活动」进程列表使用的是近似值。详细内存信息给出的值更精确。

为什么'Xorg'进程占了那么多内存?

这个进程负责显示所有其他程序。它的内存占用包括了显卡中储存程序中图形映射 pixmaps 的显存。

一般来说你不用去关心Xorg的内存占用。

我怎样能看到进程的PID?

如果你想看到单个进程的PID,只要悬停鼠标指针到进程名上。PID会在工具提示中显示出来。

如果你想看到所有进程的PID,右击任意列标题,你会看到如下菜单:


选择显示'PID'列

系统活动能够像 iotop 一样显示硬盘的 I/O 状况吗?

在列标题上右击鼠标,选择显示 IO 读取列显示 IO 写入列。这样就会显示硬盘读取和写入的数据。

通过在列标题上右击鼠标,可以选择查看磁盘的读写数(默认)还是文件的读写数。

数据请求数和实际的读入数据并不等价 - 例如如果两个程序读取同一个文件,操作系统不需要从硬盘读取两次 - 系统会读取一次并保存一小段时间。类似的,进程写入文件时,如果另外一个进程也写入同一个文件,之前写入的内容就不需要再写入硬盘了。

为什么有的进程变灰淡出?

比如这个进程xclock



这意味着这个进程已经死了。显示为灰色不可用进程只是为了便于更容易分辨那些停止了的进程。CPU使用率,内存占用等的值只是该进程之前未结束时的值。一个已经终止的进程不消耗任何资源(它不占用CPU,内存等)。

这些用户名全是 root 并且不占用内存的进程是什么?

这些是内核线程。它们只存在内核中,内核使用它们并行执行多个任务。

个别时候,它们会引起高CPU使用率,程序会显示它们。例如处于重负载时,如果安装了不合适的驱动,网卡会产生大量的中断,导致了 ksoftirqd 内核线程有很高的 CPU 占用。

此外,kjournald 中的高 CPU 占用率表明硬盘的 DMA 传输特性没启用。

为什么我的系统有那么多进程?

正常的一般用户系统拥有约150至200个名字稀奇古怪的进程。如果建个wiki页面概述每个进程那会非常不错,但至今没人去做。

为什么 OpenOffice.org 没有作为图形程序显示出来?

3.3 版本之前的 OpenOffice.org 没有正确实现窗口标准。尤其是,它们的窗口没有设定 _NET_WM_PID 来将窗口链接到进程。这个问题现在 OpenOffice.org 3.3 中被修正

为什么 gvim 奇怪的按照图形程序显示?

这是GVim程序的问题。GVim没有正确的遵循窗口标准。为了避免堵塞执行的shell,它在启动的时候开启了一个新的进程。但是_NET_WIN_PID设置成了之前的PID。已经通知了作者,但问题还没被修复。