标签: atop

我的生产服务器有atop1.23 版，我有一个由它编写的数据文件，我需要从中提取进程的完整命令行。

很遗憾：

• 此版本atop不会显示超出显示第 80 列的数据
• 水平滚动仅在 1.27 中引入
• 新版本拒绝读取旧版本写入的数据文件
• 文件本身是压缩的，所以简单的strings搜索是行不通的

有什么办法可以从我的数据文件中恢复完整的命令行吗？

1. sudo dd if=/dev/sda of=/dev/null bs=1M iflag=direct
2. atopsar -d 5 # in a second terminal
3. top # in a third terminal

结果来自atopsar：

19:18:32  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_
...
19:16:50  sda             18%  156.5  1024.0     0.0     0.0   5.0   1.15 ms
19:16:55  sda             18%  156.3  1024.0     0.0     0.0   4.9   1.15 ms
...

为什么报告的磁盘利用率（“忙”）远低于 100%？

据top，该dd进程仅使用 3% 或更少的 CPU。 top还提供系统 CPU 的硬件和软件中断 (hi和si) 使用情况的总体报告，显示低于 1%。我有四个 CPU（2 个内核，每个内核 2 个线程）。 …

when I run the atop -r /var/log/atop/...

I see from the atop screen this

 PAG | scan  641376 |  steal 635209 | stall

the PAG is colored with red

can someone explain what PAG explain from the atop , and what this problem means ?

有一段时间，我在我的 Debian 网络服务器（VPS/虚拟机）上遇到了 RAM 短缺的问题。如果它们经常发生，这不会不寻常。但他们没有。这是穆宁的图表：

为了解决这些谜语，我使用atop. 这是 7:00AM 和 9:00AM 的两个快照 - 在 RAM 短缺期间和之后（使用该-m选项查看内存相关信息）：

ATOP - <snip>                           2014/09/10  07:00:02                           ------                             10m0s elapsed
<snip>
MEM |  tot     2.0G |  free   79.1M  | cache 102.4M  |  dirty   0.1M |  buff   53.2M  |  slab   90.8M |                |               |
SWP |  tot     2.0G |  free    2.0G  |               |               |                |               |  vmcom 748.1M  | vmlim   3.0G  |
DSK |           sda |  busy      1%  | read     917  |  write   1695 …

我正在atopUbuntu 机器上进行事后登录，我可以查看

atop -r

问题是日志文件以 10 分钟的间隔显示t和Shift+t，而我更喜欢 1 分钟的间隔。当当前时间用 改变时b，它被量化到最接近的 10 分钟点。

我在 中有一行/etc/init.d/atop，但我不确定它是否会影响这里的任何内容：

INTERVAL=60

如何atop使用t和使日志以 1 分钟的精度浏览Shift+t？

这 10 分钟间隔之间的信息是否已经丢失？

如果这是不可能的，有哪些可能的解决方法？

我一直在测试 Linux 4.18.16-200.fc28.x86_64。根据free -h.

我有vm.dirty*sysctl 的默认值。 dirty_background_ratio是 10，现在dirty_ratio是 20。根据我读过的所有内容，我希望 Linux 在达到 RAM 的 10% 时开始写出脏缓存：0.77G。当脏缓存达到 RAM 的 20%：1.54G 时，缓冲的 write() 调用应该阻塞。

我跑过去dd if=/dev/zero of=~/test bs=1M count=2000看着dirty田野atop。当dd命令运行时，该dirty值稳定在 0.5G 左右。这明显低于脏背景阈值（0.77G）！怎么会这样？我错过了什么？

dirty_expire_centisecs是 3000，所以我认为这不是原因。我什至尝试降低dirty_expire_centisecs到 100 和dirty_writeback_centisecs10，看看这是否是限制dirty。这并没有改变结果。

作为调查的一部分，我最初写下了这些观察结果：为什么在 2013 年报告了“USB 记忆棒停顿”问题？为什么现有的“No-I/O 脏节流”代码没有解决这个问题？

我知道在两个阈值之间的中间 - 15% = 1.155G - write() 调用开始在曲线上受到限制（延迟）。但是在这个天花板之下时不会增加延迟；允许生成脏页的进程“自由运行”。

据我了解，节流旨在将脏缓存保持在 15% 或以上，并防止达到 20% 的硬限制。它并不为每种情况提供保证。但我正在用一个dd命令测试一个简单的案例；我认为它应该简单地限制 write() 调用以匹配设备实现的写出速度。 …

我atop在 Ubuntu 12.04 服务器上安装了1.26 版。默认情况下，其采样间隔为 10 分钟。怎么改成1分钟？

另外，如何设置日志路径？当前日志位于/var/log/，但我注意到atop添加了一个文件夹/var/log/atop/（空）。如何设置要保存在此文件夹中的日志？

我已经安装atop在只有 40MB 的 OrangePi/RaspberryPi 上/var/log。

它很快就把我的分区填满了 100%，然后我清除了它apt purge atop以删除它及其配置文件。

• atop二进制文件不存在
• 它的文件/etc/init.d不存在
• 没有调用 systemd 服务atop

然而，重新启动后，该/var/log/atop文件夹将充满旧的顶部文件。

• 我怎样才能彻底彻底删除它？

编辑：

$ ls /var/log/atop/
atop_20200822  atop_20200826  atop_20200830  atop_20200903  atop_20200907  atop_20200911  atop_20200915  atop_20200919
atop_20200823  atop_20200827  atop_20200831  atop_20200904  atop_20200908  atop_20200912  atop_20200916  atop_20200920
atop_20200824  atop_20200828  atop_20200901  atop_20200905  atop_20200909  atop_20200913  atop_20200917  atop_20200921
atop_20200825  atop_20200829  atop_20200902  atop_20200906  atop_20200910  atop_20200914  atop_20200918  atop_20200922

我删除了2020/09/22最后一个文件。每次重新启动后，它都会一次又一次地重新生成包含相同文件的相同文件夹。

在文件夹和文件之上：

# find . -type d -name  *atop*
./usr/share/doc/libatopology2
./var/log.hdd/atop
./var/log/atop
./var/cache/atop.d

# …

我们可以看到每天都会创建 atop 日志，并且占用大量空间

ls -l /var/log/atop/
total 1634632
-rw-r--r-- 1 root root 127992086 Aug 30 01:49 atop_20180829
-rw-r--r-- 1 root root 262277153 Aug 31 00:00 atop_20180830
-rw-r--r-- 1 root root 321592670 Sep  1 00:00 atop_20180831
-rw-r--r-- 1 root root 330041977 Sep  2 00:00 atop_20180901
-rw-r--r-- 1 root root 269040388 Sep  3 00:00 atop_20180902
-rw-r--r-- 1 root root 274807097 Sep  4 00:00 atop_20180903
-rw-r--r-- 1 root root  85426960 Sep  4 06:03 atop_20180904
-rw-r--r-- 1 root root         0 Sep  4 06:03 daily.log …