linux_top_commander - james-gone/knowledge GitHub Wiki

为了动态的查看当前计算机的运行信息。Linux操作系统下有top工具。

在命令行shell界面，输入top启动。

在top窗口界面，输入h进入帮助页面，查看基本的命令介绍，按Esc返回。

在top窗口界面, 输入q退出top工具界面。

其它命令的方式，需要进入h帮助界面自己查看，不同版本的top工具命令会有区别。

窗口划分为两个主要区域。上边5行左右，是系统的概要信息。下边系统执行的任务的动态每个任务的信息。

• 第一行
  • top是程序名称。
  • 当前系统时间
  • up 后的时间是当前系统已经运行的时长。min是分钟。
  • 7 users, 是当前系统连接的用户数。
  • load averages 后是3个不断变化的数值。数字表示CPU队列排队的任务数，3个数字分别是1分钟内、5分钟内、15分钟内的平均值。

这个数值和当前系统的CPU运算核心数量相关, 当排队任务数值等于大于CPU运算核心数量时，表示系统比较繁忙，超出数值比较大时，连键盘输入都不能及时响应。CPU运算核心数量等于当前计算机的CPU数量乘以每个CPU是核心数乘以2（超线程方法）。

举例，服务器有2个CPU，每个CPU是8核，则CPU运算核心数量是2x8x2=32. 当load averages的数值大于32时，则系统繁忙，响应就缓慢了。

• 第二行 进程的总数，正在运行的数量，休眠的数量，停止的数量，僵死的数量。

• 第三行 CPU执行进程的特性。us 是用户进程的占比，sy是操作系统进程的占比，id是空闲的站比，wa是CPU等待I/O的占比。

• 第四行 内存的信息。 分别是总的物理内存， 已经使用的内存， 空余的内存等。

Linux系统对内存的管理继承了Unix的方式，内存的利用效率更高。对新进程的内存申请，优先从空余的内存划给。对休眠状态的进程原来的内存，不需要立即清理，因为进程的休眠和重新唤起是经常的事。当前内存空余比较少的时候，才根据一定的算法，对内存进行整理。

• 第五行 Swap，内存交换分区。和内存类似，也是总量，已经使用的量，空余的量。

Swap是在操作系统安装的时候，即从硬盘上划分一定的空间作为交换分区, 类似于Windows系统的页面缓存。当系统需要用到的内存超出部分，会调用SWAP分区的空间做临时存储数据。

早期计算机内存都比较少的时候，一般建议SWAP是内存的两倍。现在一般计算机的内存都比较多，超过4G以上的，SWAP等于内存4G也就够了。

当SWAP经常用的比较多的时候，实际是计算机的主内存缺少了。

窗口的下部分动态的按设定的排列条件显示当前比较靠前的进程的信息。 一般默认的是按CPU的占用百分比排序。

• f 可以进入列筛选和显示界面。有的top在f筛选界面内可以进行排序设定。

• 主要显示列有

  • PID 操作系统给进程分配的进程ID号。
  • USER 执行进程的操作系统用户名
  • %CPU 每个进程的CPU占用百分比。是单个计算核心的占用量。
  • %MEM 每个进程的内存占用量。
  • TIME和TIME+ 都是进程的CPU占用时间。
  • PPID 启动该进程的父进程的ID。比如所有tcserver的父进程是，magrstart 的java程序进程.
  • COMMAND 进程的启动执行命令。
  • DATA 进程占用的内存空间用量。
  • SWAP 进程占用的交换空间的硬盘用量。

• 现象

  • TC客户端不定期的出现登录连接问题，在下午16点时出现大量的不能登录的情况
  • 查看top界面发现，pool server 服务器的 load average的负载会升高超过30多，最高看到1分钟的均值超过70多。
  • 内存总是用的比较高，剩余内存不多。
  • SWAP交换分区用量超过一半以上。

• 监控 持续跟踪查看一定时间后发现以下规律

  • 当内存用量少于200MB时，
  • CPU 的负载持续升高，系统响应逐渐缓慢
  • CPU wa等待IO的百分比增高波动,有超过50%以上
  • SWAP的用量不断发生变化
  • 进程中有tcserver的进程用量超过G以上，最高看到有24G的1次，16G的2次。

• 初步分析

  • 分析初步认为是因为物理内存总量不是很充足，有大数据量进程时，由于当前空余内存比较少，需要调用SWAP交换空间进行数据交换，影响到CPU的等待时间，进而导致整体系统负载增高。
  • 系统负载增高后，响应慢，导致用户的登录时间超时，大面积不能登录。

• 追踪大内存量进程的过程。

  • 从tcserver进程的PID进程号，在pool_manager的管理的server列表界面上搜索到对应的连接
  • 查看到具体的用户，联系了解用户的操作。
  • 同步按PID号，在服务器的/tmp临时目录下，搜索找到tcserverPID.syslog 的log日志。
  • 了解到有两个用户都是在执行搜索，系统较长时间没有响应的时候，直接关闭了tc的胖客户端。

• 问题跟进的结果

  • 初步处理方式，对能确定的已经停止响应的客户端，在pool_manager内关闭对应的进程。
  • 数据量大的进程关闭后，内存量释放，CPU wa 不再有很多的等待IO时间。
  • 可以观察到 CPU 的load average 负载会逐步降低到合适的数值。

• 最后问题的原因

  • 同一时期，客户端用户在流程审批过程中有一些错误信息，有的错误报错比较明显，提示数据库管理系统有问题。
  • 请数据库专家查看后，发现数据库的表空间紧张。
  • 处理完成后，流程可以正常执行。
  • 数据库问题解决后，持续观察一段poo server的top情况，发现进程运行和内存的用量涨落都比较正常, 也没有出现大于G级以上的进程，负载没有再超过瓶颈。
  • 可能原因，当数据库的表空间比较紧张时，大数据量的操作不能及时运行出结果，客户端直接关闭，而pool_server上的进程还在持续运行，占用内存异常增加。
  • 其它1个连续审批流程的进程观察到内存最多用到700多MB。大量的进程内存用量都是小于300MB的。