linux - 为什么 64 位 Linux 进程的 VSIZE 大这么多？-6ren

linux - 为什么 64 位 Linux 进程的 VSIZE 大这么多？

转载作者：IT王子更新时间：2023-10-29 00:19:41

我的基本问题是，为什么 64 位进程的 VSIZE 比为 32 位编译的完全相同的程序的 VSIZE 大得多？

以下是 32 位进程的/proc/ /maps 文件的输出。

00148000-00149000 r-xp 00000000 00:00 0               [vdso]
00149000-002d2000 r-xp 00000000 fd:02 8914142         /lib/libc-2.12.so
002d2000-002d3000 ---p 00189000 fd:02 8914142         /lib/libc-2.12.so
002d3000-002d5000 r--p 00189000 fd:02 8914142         /lib/libc-2.12.so
002d5000-002d6000 rw-p 0018b000 fd:02 8914142         /lib/libc-2.12.so
002d6000-002d9000 rw-p 00000000 00:00 0 
005c9000-005da000 r-xp 00000000 fd:02 17059392        /tmp/vsizetest/lib/libtesting.so
005da000-005db000 rw-p 00010000 fd:02 17059392        /tmp/vsizetest/lib/libtesting.so
005db000-0061b000 rw-p 00000000 00:00 0 
00661000-00689000 r-xp 00000000 fd:02 8917713         /lib/libm-2.12.so
00689000-0068a000 r--p 00027000 fd:02 8917713         /lib/libm-2.12.so
0068a000-0068b000 rw-p 00028000 fd:02 8917713         /lib/libm-2.12.so
00694000-006ab000 r-xp 00000000 fd:02 8917680         /lib/libpthread-2.12.so
006ab000-006ac000 r--p 00016000 fd:02 8917680         /lib/libpthread-2.12.so
006ac000-006ad000 rw-p 00017000 fd:02 8917680         /lib/libpthread-2.12.so
006ad000-006af000 rw-p 00000000 00:00 0 
006e5000-00703000 r-xp 00000000 fd:00 3150403         /lib/ld-2.12.so
00703000-00704000 r--p 0001d000 fd:00 3150403         /lib/ld-2.12.so
00704000-00705000 rw-p 0001e000 fd:00 3150403         /lib/ld-2.12.so
00983000-009a0000 r-xp 00000000 fd:02 8914997         /lib/libgcc_s-4.4.5-20110214.so.1
009a0000-009a1000 rw-p 0001d000 fd:02 8914997         /lib/libgcc_s-4.4.5-20110214.so.1
00ca5000-00d86000 r-xp 00000000 fd:02 6300601         /usr/lib/libstdc++.so.6.0.13
00d86000-00d8a000 r--p 000e0000 fd:02 6300601         /usr/lib/libstdc++.so.6.0.13
00d8a000-00d8c000 rw-p 000e4000 fd:02 6300601         /usr/lib/libstdc++.so.6.0.13
00d8c000-00d92000 rw-p 00000000 00:00 0 
08048000-08049000 r-xp 00000000 fd:02 21134666        /tmp/vsizetest/bin/testvsz
08049000-0804a000 rw-p 00000000 fd:02 21134666        /tmp/vsizetest/bin/testvsz
09b8d000-09bae000 rw-p 00000000 00:00 0               [heap]
f7796000-f779c000 rw-p 00000000 00:00 0 
ff998000-ff9ae000 rw-p 00000000 00:00 0               [stack]

这导致总 VSIZE 为 3656。

以下是 64 位进程的/proc/ /maps 文件的输出。

00400000-00401000 r-xp 00000000 fd:02 21134667              /tmp/vsizetest/bin64/testvsz
00600000-00601000 rw-p 00000000 fd:02 21134667              /tmp/vsizetest/bin64/testvsz
02301000-02322000 rw-p 00000000 00:00 0                     [heap]
3b7c800000-3b7c820000 r-xp 00000000 fd:00 661349            /lib64/ld-2.12.so
3b7ca1f000-3b7ca20000 r--p 0001f000 fd:00 661349            /lib64/ld-2.12.so
3b7ca20000-3b7ca21000 rw-p 00020000 fd:00 661349            /lib64/ld-2.12.so
3b7ca21000-3b7ca22000 rw-p 00000000 00:00 0 
3b7cc00000-3b7cd86000 r-xp 00000000 fd:00 661350            /lib64/libc-2.12.so
3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350            /lib64/libc-2.12.so
3b7cf86000-3b7cf8a000 r--p 00186000 fd:00 661350            /lib64/libc-2.12.so
3b7cf8a000-3b7cf8b000 rw-p 0018a000 fd:00 661350            /lib64/libc-2.12.so
3b7cf8b000-3b7cf90000 rw-p 00000000 00:00 0 
3b7d000000-3b7d083000 r-xp 00000000 fd:00 661365            /lib64/libm-2.12.so
3b7d083000-3b7d282000 ---p 00083000 fd:00 661365            /lib64/libm-2.12.so
3b7d282000-3b7d283000 r--p 00082000 fd:00 661365            /lib64/libm-2.12.so
3b7d283000-3b7d284000 rw-p 00083000 fd:00 661365            /lib64/libm-2.12.so
3b7d800000-3b7d817000 r-xp 00000000 fd:00 661352            /lib64/libpthread-2.12.so
3b7d817000-3b7da16000 ---p 00017000 fd:00 661352            /lib64/libpthread-2.12.so
3b7da16000-3b7da17000 r--p 00016000 fd:00 661352            /lib64/libpthread-2.12.so
3b7da17000-3b7da18000 rw-p 00017000 fd:00 661352            /lib64/libpthread-2.12.so
3b7da18000-3b7da1c000 rw-p 00000000 00:00 0 
3b7e000000-3b7e007000 r-xp 00000000 fd:00 661361            /lib64/librt-2.12.so
3b7e007000-3b7e206000 ---p 00007000 fd:00 661361            /lib64/librt-2.12.so
3b7e206000-3b7e207000 r--p 00006000 fd:00 661361            /lib64/librt-2.12.so
3b7e207000-3b7e208000 rw-p 00007000 fd:00 661361            /lib64/librt-2.12.so
3b87000000-3b87016000 r-xp 00000000 fd:00 664219            /lib64/libgcc_s-4.4.6-20110824.so.1
3b87016000-3b87215000 ---p 00016000 fd:00 664219            /lib64/libgcc_s-4.4.6-20110824.so.1
3b87215000-3b87216000 rw-p 00015000 fd:00 664219            /lib64/libgcc_s-4.4.6-20110824.so.1
3d44c00000-3d44ce8000 r-xp 00000000 fd:00 3019214           /usr/lib64/libstdc++.so.6.0.13
3d44ce8000-3d44ee8000 ---p 000e8000 fd:00 3019214           /usr/lib64/libstdc++.so.6.0.13
3d44ee8000-3d44eef000 r--p 000e8000 fd:00 3019214           /usr/lib64/libstdc++.so.6.0.13
3d44eef000-3d44ef1000 rw-p 000ef000 fd:00 3019214           /usr/lib64/libstdc++.so.6.0.13
3d44ef1000-3d44f06000 rw-p 00000000 00:00 0 
7f30ab397000-7f30ab39c000 rw-p 00000000 00:00 0 
7f30ab39c000-7f30ab3ad000 r-xp 00000000 fd:02 21127804      /tmp/vsizetest/lib64/libtesting.so
7f30ab3ad000-7f30ab5ac000 ---p 00011000 fd:02 21127804      /tmp/vsizetest/lib64/libtesting.so
7f30ab5ac000-7f30ab5ad000 rw-p 00010000 fd:02 21127804      /tmp/vsizetest/lib64/libtesting.so
7f30ab5ad000-7f30ab5ee000 rw-p 00000000 00:00 0 
7f30ab606000-7f30ab609000 rw-p 00000000 00:00 0 
7fff69512000-7fff69528000 rw-p 00000000 00:00 0             [stack]
7fff695ff000-7fff69600000 r-xp 00000000 00:00 0             [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0     [vsyscall]

这导致 VSIZE 为 18480。

这两个映射之间的主要区别在于 64 位数据中的以下条目:

3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350             /lib64/libc-2.12.so
3b7d083000-3b7d282000 ---p 00083000 fd:00 661365             /lib64/libm-2.12.so
3b7d817000-3b7da16000 ---p 00017000 fd:00 661352             /lib64/libpthread-2.12.so
3b7e007000-3b7e206000 ---p 00007000 fd:00 661361             /lib64/librt-2.12.so
3b87016000-3b87215000 ---p 00016000 fd:00 664219             /lib64/libgcc_s-4.4.6-20110824.so.1
3d44ce8000-3d44ee8000 ---p 000e8000 fd:00 3019214            /usr/lib64/libstdc++.so.6.0.13
7f30ab3ad000-7f30ab5ac000 ---p 00011000 fd:02 21127804       /tmp/vsizetest/lib64/libtesting.so

其中占18480个VSIZE中的14316个。

其他程序的其他实验似乎表明，在 64 位中，您似乎为进程使用的每个共享库获得了这些私有(private)的、不可读的、不可写的、不可执行的内存块之一，而在 32 位中几乎没有这些 block 。

有谁知道这些内存块是什么？

注意:根据对类似问题的一些回答，What these memory regions for, from a Linux process? ，这不是一个多线程进程，它已经编译为 -fPIC。

最佳答案

VSIZE 的主要区别在于共享库的 PROT_NONE 映射(模式“---p”)在 32 位和 64 位版本中是如何完成的。

这些正是您发现的产生差异的映射。

一般来说，对于每个加载的共享库，我们会有四个映射:

3b7cc00000-3b7cd86000 r-xp 00000000 fd:00 661350            /lib64/libc-2.12.so
3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350            /lib64/libc-2.12.so
3b7cf86000-3b7cf8a000 r--p 00186000 fd:00 661350            /lib64/libc-2.12.so
3b7cf8a000-3b7cf8b000 rw-p 0018a000 fd:00 661350            /lib64/libc-2.12.so

第一个是具有可执行权限的代码段，第二个是PROT_NONE(模式---)映射(页面可能无法访问)，最后两个是数据段(只读部分和读写)。

PROT_NONE 的大小为 MAXPAGESIZE，因此它在 32 位和 64 位版本中的创建方式不同。在 32 位版本的情况下，它有 4KB 大小(i386 的 MAXPAGESIZE)，在 64 位版本的情况下为 2MB(x86_64 系统的标准 MAXPAGESIZE)。

应该注意的是，这个内存实际上并没有被消耗(它只是消耗了地址空间的地址)，如下所示:

http://www.greenend.org.uk/rjk/tech/dataseg.html

“这个额外的东西不会花费你任何 RAM 或交换空间，只是每个进程中的地址空间，这在 64 位平台上供应充足。根本原因是为了保持库的有效共享，但实现有点奇怪。”

最后一个技巧，我发现使用 pmap 实用程序检查内存映射比解析映射文件并生成更易于读取的输出更容易:

基本信息:

pmap <PID>

扩展信息:

pmap -x <PID>

关于linux - 为什么 64 位 Linux 进程的 VSIZE 大这么多？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14371490/

文章推荐： android - 如何使用 ADB shell 查找进程正在使用的端口？

文章推荐： linux/libusb 获取usb设备路径

文章推荐： php - 如何使用 PHP 将所有字符转换为等效的 html 实体

文章推荐： php - 无法在 MySQLi 中通过引用传递参数

linux - 如何通过 STIME 终止 linux 进程(悬空 svnserve 进程)
我是 Linux 的新手，并且继承了保持我们的单一 Linux 服务器运行的职责。这是我们的SVN服务器，所以比较重要。原来在我之前维护它的人有一个 cron 任务，当有太多 svnserve 进程
Nodejs极简入门教程（三）：进程
Node 虽然自身存在多个线程，但是运行在 v8 上的 JavaScript 是单线程的。Node 的 child_process 模块用于创建子进程，我们可以通过子进程充分利用 CPU。范例：
ubuntu - Jenkins 进程
Jenkins 有这么多进程处于事件状态是否正常？我检查了我的设置，我只配置了 2 个“执行者”... htop http://d.pr/i/RZzG+ 最佳答案您不仅要限制 Master 中的执
带管道的 Scala 进程
我正在尝试在 scala 中运行这样的 bash 命令: cat "example file.txt" | grep abc Scala 有一个特殊的流程管道语法，所以这是我的第一个方法: val f
循环和文件输出中的 Java 进程
很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开，visit the help center . 关闭 1
multithreading - 进程、线程和并发编程
我需要一些帮助来理解并发编程的基础知识。事实上，我读得越多，就越感到困惑。因此，我理解进程是顺序执行的程序的一个实例，并且它可以由一个或多个线程组成。在单核CPU中，一次只能执行一个线程，而在多核CP
testing - 在集成测试期间如何运行服务器(进程)？
我的问题是在上一次集成测试后服务器进程没有关闭。在integration.rs中，我有: lazy_static! { static ref SERVER: Arc> = {
Scala 进程 - 捕获标准输出和退出代码
我正在使用 Scala scala.sys.process图书馆。我知道我可以用 ! 捕获退出代码和输出 !!但是如果我想同时捕获两者呢？我看过这个答案 https://stackoverflow
c++ - 使用共享库同步两个C++进程
我正在开发一个C++类(MyClass.cpp)，将其编译为动态共享库(MyClass.so)。同一台Linux计算机上运行的两个不同应用程序将使用此共享库。它们是两个不同的应用程序。它不是多线程
c - 查找UDP数据包的源IP/进程
我在我的 C 程序中使用 recvfrom() 从多个客户端接收 UDP 数据包，这些客户端可以使用自定义用户名登录。一旦他们登录，我希望他们的用户名与唯一的客户端进程配对，这样服务器就可以通过数据包
C、进程、fork
如何更改程序，以便函数 function_delayed_1 和 function_delayed_2 仅同时执行一次: int main(int argc, char *argv[]) {
c - 操作系统 - 进程
考虑这两个程序: //in #define MAX 50 int main(int argc, char* argv[]) { int *count; int fd=shm
linux - 如何同时打开三个终端(进程)
请告诉我如何一次打开三个终端，这样我的项目就可以轻松执行，而不必打开三个终端三次然后运行三个exe文件。请问我们如何通过脚本来做到这一点，即打开三个终端并执行三个 exe 文件。最佳答案在后台运行
远程计算机上的 C# 进程
我编写了一个监控服务来跟踪一组进程，并在服务行为异常、内存使用率高、超出 CPU 运行时间等时发出通知。这在我的本地计算机上运行良好，但我需要它指向远程机器并获取这些机器上的进程信息。我的方法，在
c# - 进程、线程和线程池
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。想改进这个问题？将问题更新为 on-topic对于堆栈溢出。 8年前关闭。 Improve this qu
c# - 后台线程/进程
我有一个允许用户上传文件的应用程序。上传完成后，必须在服务器上完成许多处理步骤(解压、存储、验证等...)，因此稍后会在一切完成后通过电子邮件通知用户。我见过很多示例，其中 System.Compo
linux - 什么时候将虚拟地址分配给程序/进程？
这个问题对很多人来说可能听起来很愚蠢，但我想对这个话题有一个清晰的理解。例如:当我们在 linux(ubuntu, x86) 上构建一个 C 程序时，它会在成功编译和链接过程后生成 a.out。 a.
java - 在linux中如何识别一个进程是java还是c或c++进程？
ps -eaf | grep java 命令在这里不是识别进程是否是 java 进程的解决方案，因为执行此命令后我的许多 java 进程未在输出中列出。最佳答案简答(希望有人写一个更全面的): 获
内核与系统中的 Windows 进程
我有几个与内核态和用户态的 Windows 进程相关的问题。如果我有一个 hello world 应用程序和一个暴露新系统调用 foo() 的 hello world 驱动程序，我很好奇在内核模式下
具有不受信任完整性级别的 Windows 进程
我找不到很多关于 Windows 中不受信任的完整性级别的信息，对此有一些疑问: 是否有不受信任的完整性级别进程可以创建命名对象的地方？ (互斥锁、事件等) 不受信任的完整性级别进程是否应该能够打开一

IT王子

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

linux - 为什么 64 位 Linux 进程的 VSIZE 大这么多？