为什么进程在 4GB 时被杀死? [英] Why the process is getting killed at 4GB?

查看:28
本文介绍了为什么进程在 4GB 时被杀死?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我编写了一个处理大量数据的程序.我的 CPU 和操作系统(Ubuntu)都是 64 位的,我有 4GB 的内存.使用top"(%Mem 字段),我看到进程的内存消耗上升到大约 87%,即 3.4+ GB,然后它被杀死了.

I have written a program which works on huge set of data. My CPU and OS(Ubuntu) both are 64 bit and I have got 4GB of RAM. Using "top" (%Mem field), I saw that the process's memory consumption went up to around 87% i.e 3.4+ GB and then it got killed.

然后我使用uname -m"检查进程可以访问多少内存,结果是无限".

I then checked how much memory a process can access using "uname -m" which comes out to be "unlimited".

现在,由于操作系统和 CPU 都是 64 位并且存在交换分区,操作系统应该总共使用虚拟内存,即 [>3.4GB + yGB from swap space ],并且只有当进程需要更多时内存,它应该被杀了.

Now, since both the OS and CPU are 64 bit and also there exists a swap partition, the OS should have used the virtual memory i.e [ >3.4GB + yGB from swap space ] in total and only if the process required more memory, it should have been killed.

所以,我有以下问题:

  1. 一个进程理论上可以在 64 位 m/c 上访问多少物理内存.我的答案是 2^48 字节.
  2. 如果物理内存少于 2^48 字节,那么操作系统应该使用虚拟内存,对吗?
  3. 如果对上述问题的回答是 YES,那么操作系统也应该使用 SWAP 空间,为什么它甚至在不使用它的情况下杀死了进程.我认为我们不必使用某些特定的系统调用来编写我们的程序来实现这一点.

请提出建议.

推荐答案

检查 fileldd 您的可执行文件确实是 64 位.

Check with file and ldd that your executable is indeed 64 bits.

还要检查资源限制.从进程内部,您可以使用 getrlimit 系统调用(和 setrlimit 以在可能的情况下更改它们).在 bash shell 中,尝试 ulimit -a.从 zsh shell 尝试 limit.

Check also the resource limits. From inside the process, you could use getrlimit system call (and setrlimit to change them, when possible). From a bash shell, try ulimit -a. From a zsh shell try limit.

还要检查您的进程是否确实占用了您认为它确实消耗的内存.如果它的 pid 是 1234 你可以试试 pmap 1234.从进程内部,您可以读取 /proc/self/maps/proc/1234/maps(您可以从终端读取).还有 /proc/self/smaps/proc/1234/smaps/proc/self/status/proc/1234/status/proc/self/ 中的其他文件 ...

Check also that your process indeed eats the memory you believe it does consume. If its pid is 1234 you could try pmap 1234. From inside the process you could read the /proc/self/maps or /proc/1234/maps (which you can read from a terminal). There is also the /proc/self/smaps or /proc/1234/smaps and /proc/self/status or /proc/1234/status and other files inside your /proc/self/ ...

使用 free 检查您是否获得了您认为的内存(和交换空间).您可以使用 swapon/tmp/someswapfile 添加一些临时交换空间(并使用 mkswap 对其进行初始化).

Check with  free that you got the memory (and the swap space) you believe. You can add some temporary swap space with swapon /tmp/someswapfile (and use mkswap to initialize it).

几个月(和几年)前,我经常能够在 Gnu/Linux/Debian/Sid/AMD64 下运行 7Gb 进程(一个巨大的 cc1 编译),在具有 8Gb RAM 的机器上.

I was routinely able, a few months (and a couple of years) ago, to run a 7Gb process (a huge cc1 compilation), under Gnu/Linux/Debian/Sid/AMD64, on a machine with 8Gb RAM.

您可以尝试使用一个小型测试程序,例如使用 malloc 分配几个内存块,例如每个 32Mb.不要忘记在里面写入一些字节(至少每兆字节).

And you could try with a tiny test program, which e.g. allocates with malloc several memory chunks of e.g. 32Mb each. Don't forget to write some bytes inside (at least at each megabyte).

传闻像 std::mapstd::vector 这样的标准 C++ 容器消耗的内存比我们通常想象的要多.

standard C++ containers like std::map or std::vector are rumored to consume more memory than what we usually think.

如果需要,购买更多内存.这些天很便宜.

Buy more RAM if needed. It is quite cheap these days.

这篇关于为什么进程在 4GB 时被杀死?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆