精华内容
下载资源
问答
  • 如果有一台Linux服务器或者运行Linux系统的计算机在运行,但是该服务器没有显示器和鼠标键盘等外设,此时需要用另外一台计算机连接到这个服务器上,在另外一台电脑上对这个服务器进行操作. 此时就需要SSH命令. SSH...

    SSH命令

    SSH是一种网络协议,用于计算机之间的加密登录。如果一个用户从本地计算机,使用SSH协议登录另一台远程计算机.

    如果有一台Linux服务器或者运行Linux系统的计算机在运行,但是该服务器没有显示器和鼠标键盘等外设,此时需要用另外一台计算机连接到这个服务器上,在另外一台电脑上对这个服务器进行操作.

     此时就需要SSH命令.

    SSH命令格式: 假定你要以用户名user,登录远程主机host

    ssh user@host

    例子:

    ssh name@192.168.90.212

    输入上述命令之后,还需要输入密码.

    通过ssh命令,在一台主机上可以阅读,编辑,执行另一台主机的文件,还可以获得另一台主机的信息;

    换句话说,通过ssh命令可以远程执行另一台主机的top,命令,得到该服务器上各个进程的内存占用率和CPU占用率.

    编写shell脚本离线获取Linux系统各进程内存占用率和CPU占用率

    #!/usr/bin/expect
    spawn ssh root@192.168.139.212 "top -b"
    expect "password" 
    send "root\r"
    interact

    通过上述脚本,可以离线获取另一台主机各进程内存占用率和CPU占用率,并且不要要输入密码.

    注: expect是一种脚本语言,它能够代替我们实现与终端的交互

    利用Python的paramiko包离线获取Linux系统各进程内存占用率和CPU占用率

     import paramiko
    
    
     def monitoring(address, name):
         # 建立远程连接
         transport = paramiko.Transport((address, 22))
         transport.connect(username=name, password=name)
    
         # 实例化SSH对象
         ssh = paramiko.SSHClient()
         ssh._transport = transport
    
         # 执行远程命令
         cmd = 'top -b -i -n 1'
         stdin, stdout, stderr = ssh.exec_command(cmd)
         for linea in stdout.readlines():
             print(line)
                
         transport.close()

    上述函数需要传入address和用户名

    展开全文
  • 前两篇文章(第一篇、第二篇),我们详细的对解析用户空间进程堆的方法进行了阐述,不过理论还需实践的检验,本篇文章,我们就接着将前面所讲的方法和理论进行评估,并将它们用于实际案例中就行检测。 结果评估本节...

    0ff35eabe02906e65b217a13be7b47e8.gif

    前两篇文章(第一篇、第二篇),我们详细的对解析用户空间进程堆的方法进行了阐述,不过理论还需实践的检验,本篇文章,我们就接着将前面所讲的方法和理论进行评估,并将它们用于实际案例中就行检测。

    196d562153ab910cc2f5c43a560be363.png结果评估

    本节描述了HeapAnalysis类及其插件的评估。

    结果验证

    结果验证是对上述所讲的方法和技术可靠性的重要验证进程,所有测试均可以在以下环境中进行,且验证进程支持不同的Glibc版本:

    1.Arch Linux 32位,×86,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

    2.Arch Linux 64位,×64,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

    HeapAnalysis类实现了多个函数,这些函数会将当前检测的数据与我们在处理内存时对每个块的期望进行比较:

    1.测试正确的标志,例如,线程arena中的块的NON_MAIN_ARENA;

    2.块的地址是否一致;

    3.大小检测(例如是否一致);

    4.分配状态测试:是否可能是任何bin或fastbin分配的一部分? 

    5.对于MMAPPED块,还要进行一些额外的测试(有关更多详细信息,请参见MMAPPED区域);

    对于MMAPPED块,还有另一个涉及malloc_par结构的验证步骤。 glibc一方面使用此结构的构建来控制某些全局设置,另一方面用于计算MMAPPED块的总大小和数量。这是通过该结构的唯一实例(名为mp_)完成的,它位于映射的Glibc库中。如果提供了mp_的偏移量,则HeapAnalysis类将使用该结构来验证所有已识别的MMAPPED块的数量和大小。如果存在任何差异,它会尝试识别隐藏的MMAPPED块,如果识别不出来,则会发出警告。此外,malloc_par结构会将所有块和堆相关结构的大小分别与相应的vm_area结构的大小和所有arena的大小进行比较。

    完整性验证

    虽然这项工作目前还无法完成全部的Glibc堆实现,但这并不妨碍开始尝试用各种步骤来识别与内存取证相关的所有相关信息和方案。我们试着开发了一套测试程序,该程序涵盖了我们所知道的所有特殊情况,以提供最完整的检测,最终,我们将使用这些测试用例自动验证我们实现的输出的完整性。为简明起见,此文我们不会对这套测试程序进行详细讲解,不过你可以在完整技术报告中看到整个细节。

    真实应用案例分析

    本章节将演示我们的插件在真实世界示例中的应用,演示过程中,请注意两个方面,一方面注意插件是否是通过描述分析进程本身来实现,另一方面注意是使用的插件还是在整个堆中进行原始搜索的特点来实现的。在下面的小节中执行的分析是使用“黑盒测试方法”完成的,这意味着,如果没有另外指定,那么没有必要预先收集来自源代码的与进程相关的细节,比如结构定义。

    zsh示例

    之前描述的Rekall和Volatility的bash插件在整个堆空间中先会搜索以标签为前缀的时间戳字符串,然后再会搜索指向时间戳的历史结构,以便识别发出的命令字符串。插件的输出是命令条目列表,每个命令条目都是由发出的命令和相应的时间戳组成。我们的目标是为zsh识别相同的信息。本节中的相应分析已在结果验证部分中列出的相同环境中完成。

    当使用history命令检测历史记录时,要分析的zsh进程在其历史记录中包含142个已执行的命令:第一个是ps aux,最后一个是#$@ &*()。分析进程的第一部分是以“黑盒测试方法”完成的,这意味着没有关于zsh如何存储命令或时间信息的内部信息是预先以任何方式收集的。这种方法的唯一信息是关于bash命令分析的现有信息,第一次检测尝试是查找以标签为前缀的时间戳字符串。然而,Zsh似乎没有以与bash相同的方式存储时间戳。于是下一步是使用heapsearch插件在块中的某处搜索已发布的命令。列表1显示了使用heapsearch搜索字符串#$@%&*()的结果,其中显示了地址0x09BCF830处所包含的感兴趣的命令块。

    66de56f6976d80cbf9ceffcba315c2b9.png

    列表1

    使用heapsearch搜索包含已发布的zsh命令的块,虽然此命令有时可以在多个块中进行识别,但每个命令似乎至少会在分配的块中识别一次,该块仅包含命令和末尾保留的一些尾随字节。列表2显示了包含已发布的zsh命令块的hexdump。

    8e15540e03cf3aed0736336809b4a1ad.png

    列表2

    包含已发布的zsh命令的块的Hexdump,由于这些块没有提供任何元信息(例如,在何时发出命令),所以下一步是再次使用heapsearch插件找到指向这些块的指针,但这次提供了包含发出命令的块的地址。你可以在单独分配的块中找到每个测试命令的一个指针,其大小为56字节(针对×86环境)。

    在检测多个块(使用heapdump插件的转储内容)之后,可以得到以下信息:

    1.字节5-8包含指向已发出命令的指针

    2.字节25-32是2个时间戳,存储为4字节整数,其中前四个字节是发出命令的开始时间,后四个字节是命令结束的时间。

    3.字节41-44包含命令计数器;

    当使用heaprefs插件检测这些块以获取引用时(参见列表3,输出已经被删除和修改),它显示字节1-4,5-8(命令指针),13-16,17 -20和33-36指向其他块。这些块的起始地址列在“注释(Comment)”列中,而包含指针的字节在“数据(Data)”列中用方括号进行了标记。

    dd0f33f32858686c4b16379828dda1f6.png

    列表3,使用heapref分析引用的块

    通过将这些信息与zsh的源代码相结合,你就会在相关的历史条目结构histent中发现两个指针:fields down(向上的字段)(字节17-20)和fields up (向下的字段)(字节13-16)。由于这些字段会用来引用上一个或下一个histent条目,因此允许可靠地遍历histent实例。由于内容条目的链接列表是循环的,所以按着一个方向遍历,就足以获得所有histent条目,其他指针对于当前的检测并不重要。

    现在,我们的最后一项任务是构建一个插件,以方便自动提取这些命令信息。为了能够遍历该histent列表,第一步是可靠地识别一个histent条目。由于命令可以包含在各种大小不同的块中,并且不提供任何可搜索的模式,所以这种方法是查找包含histent结构的块。对于×86而言,包含块的大小为56字节,对于×64架构,包含块的大小为96字节。因为还存在具有相同大小的非相关块,所以需要区分它们。由于每个histent条目都应该有一个指向包含命令的块的指针和指向下一个和上一个histent条目的指针,因此测试会包括检测这些指针是否引用已知的块。如果测试结果为正,最后一个检测则是遍历向上和向下指向下一个和上一个histent结构的指针,并测试它们的向下或向上构建是否指向当前块。如果是这种情况,则将当前块视为一个histent 结构,并使用向下构建遍历命令历史记录。

    列表4显示了zsh插件的示例输出 (输出已经删除)。

    faedae16ae7af075ac52a6007622dc6e.png

    列表4,zsh插件的示例输出

    虽然因为时间戳字符串,可以使用原始搜索重建bash历史记录,但这种方法对zsh不起作用,因为时间戳不是以带有附加标签的字符串形式保存的,而是作为一个4字节整数保存的。此外,由于在分析进程中无法识别其他可搜索的模式,因此原始搜索很可能不适用于上述分析过程,此时使用堆分析插件的优势就显示出来了。

    196d562153ab910cc2f5c43a560be363.pngKeePassX示例

    检测的第二个工具是密码管理器KeePassX(版本0.4.3),我们已在以下环境中进行了测试:

    1.Ubuntu 15.10 32位,×86,内核版本4.2.0–16-generic,Glibc2.21版本;

    2.Ubuntu 15.10 64位,×64,内核版本4.2.0-16-generic,Glibc2.21版本;

    以下分析的设置由KeePassX数据库组成,该数据库包含多个密码条目,这些密码条目已被分为两个文件夹。每个密码条目都有标题、用户名、URL和注释的值。打开数据库进行分析时,只打开第一个文件夹,同时保持第二个文件夹完全不变。

    我们的第一次尝试是在进程空间的某处找到未加密的主密码(master password )和条目密码,但找不到它们。但是,在5个带有不同密码管理器条目的测试中,我们已在3个已分配的块中成功观察到当前打开的密码条目的未隐藏密码。只要密码条目显示未隐藏的密码,这三个块就会一直存在。如果密码再次隐藏,三个块中的两个将被释放,保留其中一个进行分配。只有当输入窗口关闭时,包含密码的所有块才被释放。根据释放的块的大小,密码将在几毫秒(几分钟,甚至几个小时也有可能)内被重写。虽然释放的块(包含长度在1到40之间的密码)通常在几秒钟或几分钟内重新分配,但在某些情况下,包含同样大小密码的释放块会被合并到更大的释放块中。由于这些更大的块由于太大(例如在几百字节的范围内)不经常分配,密码可能在该块中可能保持几个小时,但也更难被找到(因为它被其他数据包围)。此外,在块数据部分的前18个字节中从未观察到实际密码,这意味着即使在释放的块被合并到大型bin中,密码也不会通过×86架构上的任何bin指针被覆盖。

    在寻找到密码字段之后,下一步是寻找更多感兴趣的字段,这个分析过程中选择的字段是标题、用户名、URL和注释。 KeePassX在数据库被打开后,会立即将完整的字段内容存储在已分配的块中。这不仅适用于标题、URL和注释等字段,还适用于用户名字段,由于在KeePassX的示例中,该字段仅在概述中以星号显示,因此不应在堆内进行再加密。综上所述,如果密码数据库被打开而未被锁定,则可以从堆中提取所有文件夹中所有密码管理器条目的概述(密码字段除外)中的所有字段。为了分析和比较来自不同块(包含字段字符串)的数据,我们已使用heapdump插件将它们转储到单独的文件中。列表5显示了一个转储数据块的十六进制转储输出,该数据块包含一个用户名(在本例中是yyyyyyyy_yyy_user5_aaaaaaaab):

    f1d3c5452f06b7c45df4c92d84c853c2.png

    列表5,包含KeePassX用户名字段的块数据部分的十六进制转储

    在比较包含来自相同类型的字符串(例如用户名)和来自其他类型的字符串的不同块之后,可以导出以下属性(对于未隐藏的密码也是如此):

    1.字符串总是由16位的endian编码;

    2.字符串并不是从块的数据部分的开头开始的,而是在18字节之后,这很可能是因为字符串是结构或对象的一部分;

    3.字节5-8和9-12分别与字符串的大小相关,而字节9-12表示正确的大小(大小是由编码的字节序列表示的字符数,而不是字节数),这两者都可能是四字节无符号整数的实例。字节4-8中的值恰好比字节9-12中的值大1倍(请参见列表5:0x19与0x18);

    4.字节13-16指向字符串的开头;

    5.该字符串后会紧跟4个空字节;

    6.根据字符串的大小,最后有一些额外的字节(某种填充字节),在大多数情况下从0到6个字节不等。然而,很少有这种情况,即这个额外的字节会达到14个字节(6加上直到下一个更大的块大小的字节数);

    字节1-4没有改变,而字节13-18和字符串结束后的字节不但变化很大,它们也没有显示出任何与某个类型或密码管理器条目的可靠一致性。

    于是,下一步我们就是使用heapsearch插件搜索任何指向字段字符串的指针。虽然搜索字符串的起始地址没有显示任何引用(包含在同一块中的引用除外),但搜索这个块的数据部分的开头处会显示出另一个块中至少有一个指针。使用heaprefs插件分析这个块时,它会显示指向其他块的12个指针,其中四个指针指向包含标题、用户名、URL和注释字符串的块。在我们分析了大量的密码条目之后,就可以合理假设出每个密码条目,其中存在着大小为96字节(在×86环境中)的块,这个块至少引用了这四个字段。这意味着,通过搜索大小相同的块并检测给定偏移量的指针,就可以收集到相同密码条目的标题、用户名、URL和注释字符串,这个信息被用来创建一个概念验证插件,具体方法就是使用HeapAnalysis类,它会自动为所有密码条目提取这四个字段。列表6显示了该插件的示例输出(输出已被删除)。

    6090e4f9cb614f6452257fa8c7ff4dc7.png

    列表6,KeePassX插件的示例输出

    此时,你应该注意,如果没有来自有关块上下文的起始地址的信息,查找字段字符串的引用将会更加困难,而在最坏的情况下,各种字符串关联到一个密码条目的可能性也会降低。

    196d562153ab910cc2f5c43a560be363.png总结

    本文重点介绍了如何在Linux进程的上下文中分析堆,其研究目的是支持研究者分析用户空间进程堆中包含的数据。首先,要对Glibc的堆实现有了深入的了解,这在Glibc分析部分中有详细的介绍。该分析侧重于从内存取证角度分析堆相关数据的存储方式和存储位置。其次,这些知识已被用于构建内存取证框架Rekall插件,该框架用于分析Linux用户空间进程的堆并提供对已识别块的访问。细节在插件实现部分中有详细说明,其中特别描述了一种识别隐藏MMAPPED块的算法。由于产生可靠的结果是计算机取证的关键要求,因此部分评估涵盖了能够验证收集到的结果的信息。为了说明研究的实用性,在真实的应用程序示例中中,我们使用了zsh和KeePassX的例子描述了用户空间应用程序的黑盒分析进程。

    196d562153ab910cc2f5c43a560be363.png本文研究结果的一些局限性

    由于交换空间在某些情况下是用户空间进程分析进程中的关键资源,到目前为止我们的研究中还未涉及到这一点。当本次研究中引入的插件用于包含堆相关数据的交换页面的进程时,它们很可能无法可靠地分析堆并提取所有块。

    本次研究的目标之一是为存储在内存中的数据提供一个类似进程的视图,不过从上述研究的结果来看,虽然我们已经搞清楚了堆在进程中所包含的详细信息(特定信息的位置及其大小),但目前还是无法提取有关数据类型的信息,根本原因是堆不存储任何数据类型信息。在已经知道数据类型和数据本身大小的情况下,仍然有一种方法可以将特定块与特定类型关联起来,通过搜索特定大小的数据块,取证人员可能能够收集特定类型的数据。然而,这种方法需要对这些块进行进一步的测试(如zsh部分所示),因为可能会有更多大小相同的块包含不同的数据。

    如上所述,对特定堆的解析要依赖特定的操作系统。在对不同的堆进行解析时,已经成功测试的方法和插件很可能都不适用。到目前为止,我们所探索的HeapAnalysis类和插件仅支持在上述架构和Glibc版本上分析Linux进程。但是,在详细的技术报告中,我们提供的信息可用于增加对更多体系结构或操作系统的支持。

    虽然可以在不提供调试信息的情况下分析用户空间进程的堆,但这种方法并不可靠。比如当任何相关结构发生变化(malloc_chunk、malloc_state或heap_info)时,插件在分析堆时肯定会失败,如果缺少指向全局变量mp_的指针,结果可能仍然不完整。如果没有mp_,则无法确定是否已发现所有MMAPPED块,另外由于在本例中,我们没有启动对隐藏MMAPPED块的搜索,因此输出中可能至少缺少一个MMAPPED块。

    除了隐藏的MMAPPED块之外,还有一种不确定性情况,就是HeapAnalysis类可能会丢失块,如果分析进程错误地将包含整个arena的vm_area_struct丢失了,虽然测试结果似乎仍然是正确的,但是却丢失了arena的块。以上所说的这种不确定性情况,可能发生的场景是这样的:解析过程中,没有提供关于main_arena位置的调试信息,并且main_arena搜索进程无法找到它,这也意味着此进程无法找到任何线程arena。由于在该场景中没有可用于任何arena的有效指针,因此可能存在未检测到的arena,这就是说有arena未被注意到。虽然这种情况在理论上是存在的,但是在我们的评估中,丢失arena的情况却未被检测到。

    196d562153ab910cc2f5c43a560be363.png未来的研究方向

    由于最重要的限制是缺少对交换空间的支持,为了全面分析进程的堆,必须确保对包含堆相关数据的所有页面的访问。因此,将交换空间集成到内存取证进程中,就是进一步分析用户空间进程的关键一步。

    为了增加HeapAnalysis类的支持,我们计划更多系统架构上测试插件,并在需要时进行适当调整。此外,对诸如jemalloc之类的进一步堆实现的分析允许分析来自诸如Firefox之类的应用程序的进程的堆分配。此外,对诸如jemalloc等其他堆实现的分析,还允许来自Firefox等应用程序的进程的堆分配。

    总而言之,本文中介绍的插件简化了分析进程,并使用模式匹配方法识别内存中无法轻易找到的信息。这些插件和内存中有关堆对象的详细信息,也可用于支持内存取证的进一步研究。此外,本文还演示了用户空间进程的分析,同时说明了在分析进程中如何获取堆的细节信息。

    eabb70702790384e59a20f14f2aac8b0.png

    f2db3e5f1647daad4a2c533c2d406752.png

    展开全文
  • linux进程内存空间分为几段,有什么作用 Linux进程可分为五部分: 代码区:存放可执行的指令操作,只能读不能写 全局区:存放未初始化的静态变量和全局变量 数据区:存放初始化的静态变量和全局变量 栈:存放...

                                                             linux进程内存空间分为几段,各有什么作用

    Linux进程可分为五部分:

    代码区:存放可执行的指令操作,只能读不能写

    全局区:存放未初始化的静态变量和全局变量

    数据区:存放初始化的静态变量和全局变量

    栈:存放临时变量,函数参数等

    堆:存放new/malloc等动态申请的变量,用户必须手动进行delete/free操作

    展开全文
  • 需要知道一台机器上面跑的java程序,占用了多少内存。 二、查看 ps -aux | grep xxx USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 可以看到RSS,也就是物理内存占用,单位是KB。RSS是常驻内存集...

    一、概述

    需要知道一台机器上面跑的java程序,各占用了多少内存。

     

    二、查看

    ps -aux | grep xxx

    USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

    可以看到RSS,也就是物理内存占用,单位是KB。RSS是常驻内存集(Resident Set Size),表示该进程分配的内存大小。RSS不包括进入交换分区的内存。RSS包括共享库占用的内存(只要共享库在内存中)RSS包括所有分配的栈内存和堆内存。

     

    输出如下:

    root    4544  7.9  8.6 3141048 705316 ?      Sl   14:49   2:37 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12002 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.userenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/tomcat_test_service_user/service-user.jar
    root      4870  0.0  0.0 103320   888 pts/0    S+   15:22   0:00 grep java
    root    6072  0.1  8.5 3141104 697052 ?      Sl   Jul18 188:59 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.meetingenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/tomcat_test_service_meeting/service-meeting.jar
    root     11257  0.0  6.5 3105424 537836 ?      Sl   Oct21  28:06 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12001 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/code/test-config-server_8762/config-server.jar
    root   17346  0.0  6.0 3132864 499504 ?      Sl   Oct21  41:46 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/tomcat_test_eureka_server/eureka-server.jar
    root   18127  0.4  7.7 3153628 632068 ?      Sl   Oct21 209:39 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12005 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.gatewayenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/tomcat_test_gateway_server/gateway-server.jar
    root   28033  0.2  7.2 3165680 591664 ?      Sl   Oct12 134:32 java -Djava.rmi.server.hostname=192.168.31.150 -Dcom.sun.management.jmxremote.port=12003 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xms512m -Xmx512m -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=256m -jar /data/tomcat_test_auth_server/auth-server.jar
    View Code

     

    RSS单位是KB,要转换为具体的MB,怎么做呢?

     

    三、单位转换

    先来看一个例子,假设有一个进程,RSS值为:103320

    #!/usr/bin/env python3
    # coding: utf-8
    
    import math
    
    def convertBytes(bytes, lst=None):
        if lst is None:
            lst=['Bytes', 'KB', 'MB', 'GB', 'TB', 'PB']
        i = int(math.floor( # 舍弃小数点,取小
                 math.log(bytes, 1024) # 求对数(对数:若 a**b = N 则 b 叫做以 a 为底 N 的对数)
                ))
    
        if i >= len(lst):
            i = len(lst) - 1
        return ('%.2f' + " " + lst[i]) % (bytes/math.pow(1024, i))
    
    if __name__ == '__main__':
        RSS = 103320
        print(convertBytes(int(RSS)*1024))

     执行输出:

    100.90 MB

    注意:因为它是KB,转换为bytes,需要*1024

     

    三、批量转换

    ps -aux | grep java 命令的输出结果,写入到一个文件 pro.txt

     

    新建一个 test.py文件,内容如下:

    #!/usr/bin/env python3
    # coding: utf-8
    
    import math
    
    def convertBytes(bytes, lst=None):
        if lst is None:
            lst=['Bytes', 'KB', 'MB', 'GB', 'TB', 'PB']
        i = int(math.floor( # 舍弃小数点,取小
                 math.log(bytes, 1024) # 求对数(对数:若 a**b = N 则 b 叫做以 a 为底 N 的对数)
                ))
    
        if i >= len(lst):
            i = len(lst) - 1
        return ('%.2f' + " " + lst[i]) % (bytes/math.pow(1024, i))
    
    if __name__ == '__main__':
        with open('pro.txt',encoding='utf-8') as f:
            for i in f:
                i = i.strip()
                cut_row = i.split()
                # print(cut_row)
                USER = cut_row[0]
                PID = cut_row[1]
                CPU  = cut_row[2]
                MEM = cut_row[3]
                VSZ = cut_row[4]
                RSS = cut_row[5]
                TTY = cut_row[6]
                STAT = cut_row[7]
                START = cut_row[8]
                TIME = cut_row[9]
                COMMAND = cut_row[10]
                JAR_NAME = cut_row[-1]
                if JAR_NAME != 'java':
                    # print(RSS)
                    print(JAR_NAME,'    ',convertBytes(int(RSS)*1024))
    View Code

     

    执行输出:

    /data/tomcat_test_service_user/service-user.jar      688.79 MB
    /data/tomcat_test_service_meeting/service-meeting.jar      680.71 MB
    /data/code/test-config-server_8762/config-server.jar      525.23 MB
    /data/tomcat_test_eureka_server/eureka-server.jar      487.80 MB
    /data/tomcat_test_gateway_server/gateway-server.jar      617.25 MB
    /data/tomcat_test_auth_server/auth-server.jar      577.80 MB

     

     将结果,直接复制到excel文件中。

     

     如果需要统计,去掉MB单位后,就可以做一下SUM计算了。

     

    本文参考链接:

    https://www.cnblogs.com/linyx/p/9766193.html

    展开全文
  • linux C进程内存知识

    2019-11-19 11:51:24
    一个可执行文件的内存分布如下: 可以使用nm 和size命令查看 可执行程序的各内存段情况
  • Linux进程结构03. 存储类型总结04. 附录 01. Linux可执行程序结构 在 Linux 下,程序是一个普通的可执行文件,以下列出一个二进制可执行文件的基本情况: 可以看出,此可执行文件在存储时(没有调入到内存前)分为...
  • 有一些命令可以用来检查 Linux 系统中的内存使用情况,下面是一些更好的命令。-- Sandra Henry-stocker(作者)有许多工具可以查看 Linux 系统中的内存使用情况。一些命令被广泛使用,比如 free、ps。而另一些命令允许...
  • 各进程通过虚拟内存空间地址来操作共享内存 进程间共享数据的最快方法 本身不提供同步机制,可通过信号量同步 子进程不继承父进程创建的共享内存,而是与父进程继续共享那块内存;在子进程中映射的虚拟地址和父进程...
  • Linux内存布局

    2020-06-05 20:20:11
    我们先来看下Linux内存布局,此图比我之前写的那篇文章写的布局更详细 在linux中,每一个进程都被抽象为task_struct结构体,称为进程描述符,存储着进程 方面的信息;例如打开的文件,信号以及内存等等;然后task...
  • Linux 内存布局

    2019-11-30 14:38:47
    我们先来看下Linux内存布局,此图比我之前写的那篇文章写的布局更详细 在linux中,每一个进程都被抽象为task_struct结构体,称为进程描述符,存储着进程 方面的信息;例如打开的文件,信号以及内存等等;然后task...
  • linux内存管理

    2017-07-24 17:49:38
    共享内存 对于共享内存(Shared ...例如Linux平台的oracle为多进程程序,SGA和PGA都是各进程共享和通信的数据区域,所有可以看到分配了很大的共享内存。而MySQL为多线程,系统级表现为一个进程,不需要共享内存
  • linux 内存占用查看

    2020-12-06 20:00:34
    2.查看各进程内存占用详细信息 top 3.查看该进程详细信息 cat /proc/[pid 进程id]/status 4.查看该进程下所有线程信息 top -H -p [pid] 5.查看线程堆栈信息 打印该线程id的十六进制表示 printf "%x\n" [pid]...
  • 当系统出OOM时,会有各进程内存信息和OOM评分,评分高的task_struct会被kill掉。 为了追踪内存泄漏是哪个进程造成,需要像OOM的信息一样,从开机的时候的内存信息,和OOM时的内存信息作比较,差量最大的进程就很大...
  • Linux 操作系统和驱动程序运行在内核空间,应用程序运行在用户空间,两者不能简单地使用指针...进程代码中的地址为逻辑地址,经过段页式地址映射后,才真正访问物理内存。段页式机制如下图。 Linux内核地址空间划...
  • Linux内存管理

    2009-09-09 13:41:00
    然后简要介绍单进程多线程的内存管理方式,主要涉及线程堆栈空间的分配;Linux内存管理Linux采用两级保护机制,隔离内核空间和用户程序空间,使用户程序无法直接访问内核,而只能通过系统调用的方式。对于32位CPU...
  • 浅析UNIX/Linux内存管理

    2019-08-08 18:12:46
    文章目录前言一、物理内存和虚拟内存二、进程与内存三、进程与虚拟内存四、内存各层管理五、内存管理API 前言   内存是linux中很重要的一块,内存不足、内存泄漏、内存溢出也是在测试项目中经常会遇到的问题。  ...
  • #!/bin/sh list=(mcms mcwts mccaches mcsagt phonegateway hw_IMS_Conference_CBU hw_IMS_Conference_CMU hw_IMS_Conference_focus hw_IMS_Confere
  • 一直以来都对进程在计算机内存中的存放位置比较模糊,这次索性查阅资料,总结后画个草图方便理解。 画图思路主要从内存划分、内存分配方式入手。 1.内存划分: ①内核:linux的内核内存管理是一个比较复杂的部分...
  • 进程A的逻辑地址空间和进程B的逻辑地址空间到物理内存的连接是不相同的 共享内存和全局变量很类似,全局变量在数据段中,被多个线程所共享,共享内存在物理内存段中,被各个进程所连接,所以它是共享资源 共享...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 908
精华内容 363
关键字:

linux内存各进程

linux 订阅