linux 内存使用 java,linux中的内存使用

在Linux中用ps命令看到的每个进程使用的内存是该进程所用到的内存之和，是假定当系统只有该进程运行时，该进程使用的内存。

之所以用ps看的内存报告是“错误的”是因为Linux系统对共享库的处理。系统只装载一份共享库代码，所有使用该库的进程都可以在自己的地址空间中访问到该共享库代码。

比如ps命令报告每个Apache进程可能都用了10M内存，而实际上每个进程的边际代价为1M内存，其余9M是在所有的Apache进程之间共享的。

Understanding memory usage on Linux

This entry is for those people who have ever wondered, "Why the

hell is a simple KDE text editor taking up 25 megabytes of memory?"

Many people are led to believe that many Linux applications, especially

KDE or Gnome programs, are "bloated" based solely upon what tools like

ps report. While this may or may not be true, depending on the program,

it is not generally true -- many programs are much more memory

efficient than they seem.

What ps reports

The ps tool can output various pieces of information about a

process, such as its process id, current running state, and resource

utilization. Two of the possible outputs are VSZ and RSS, which stand

for "virtual set size" and "resident set size", which are commonly used

by geeks around the world to see how much memory processes are taking

up.

For example, here is the output of ps aux for KEdit on my computer:

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

dbunker   3468  0.0  2.7  25400 14452 ?        S    20:19   0:00 kdeinit: kedit

According to ps, KEdit has a virtual size of about 25 megabytes and

a resident size of about 14 megabytes (both numbers above are reported

in kilobytes). It seems that most people like to randomly choose to

accept one number or the other as representing the real memory usage of

a process. I'm not going to explain the difference between VSZ and RSS

right now but, needless to say, this is the wrong approach; neither

number is an accurate picture of what the memory cost of running KEdit

is.

Why ps is "wrong"

Depending on how you look at it, ps is not reporting the real

memory usage of processes. What it is really doing is showing how much

real memory each process would take up if it were the only process

running. Of course, a typical Linux machine has several dozen processes

running at any given time, which means that the VSZ and RSS numbers

reported by ps are almost definitely "wrong". In order to understand

why, it is necessary to learn how Linux handles shared libraries in

programs.

Most major programs on Linux use shared libraries to facilitate

certain functionality. For example, a KDE text editing program will use

several KDE shared libraries (to allow for interaction with other KDE

components), several X libraries (to allow it to display images and

copy and pasting), and several general system libraries (to allow it to

perform basic operations). Many of these shared libraries, especially

commonly used ones like libc, are used by many of the programs running

on a Linux system. Due to this sharing, Linux is able to use a great

trick: it will load a single copy of the shared libraries into memory

and use that one copy for every program that references it.

For better or worse, many tools don't care very much about this

very common trick; they simply report how much memory a process uses,

regardless of whether that memory is shared with other processes as

well. Two programs could therefore use a large shared library and yet

have its size count towards both of their memory usage totals; the

library is being double-counted, which can be very misleading if you

don't know what is going on.

Unfortunately, a perfect representation of process memory usage

isn't easy to obtain. Not only do you need to understand how the system

really works, but you need to decide how you want to deal with some

hard questions. Should a shared library that is only needed for one

process be counted in that process's memory usage? If a shared library

is used my multiple processes, should its memory usage be evenly

distributed among the different processes, or just ignored? There isn't

a hard and fast rule here; you might have different answers depending

on the situation you're facing. It's easy to see why ps doesn't try

harder to report "correct" memory usage totals, given the ambiguity.

Seeing a process's memory map

Enough talk; let's see what the situation is with that "huge" KEdit

process. To see what KEdit's memory looks like, we'll use the pmap

program (with the -d flag):

Address   Kbytes Mode  Offset           Device    Mapping

08048000      40 r-x-- 0000000000000000 0fe:00000 kdeinit

08052000       4 rw--- 0000000000009000 0fe:00000 kdeinit

08053000    1164 rw--- 0000000008053000 000:00000   [ anon ]

40000000      84 r-x-- 0000000000000000 0fe:00000 ld-2.3.5.so

40015000       8 rw--- 0000000000014000 0fe:00000 ld-2.3.5.so

40017000       4 rw--- 0000000040017000 000:00000   [ anon ]

40018000       4 r-x-- 0000000000000000 0fe:00000 kedit.so

40019000       4 rw--- 0000000000000000 0fe:00000 kedit.so

40027000     252 r-x-- 0000000000000000 0fe:00000 libkparts.so.2.1.0

40066000      20 rw--- 000000000003e000 0fe:00000 libkparts.so.2.1.0

4006b000    3108 r-x-- 0000000000000000 0fe:00000 libkio.so.4.2.0

40374000     116 rw--- 0000000000309000 0fe:00000 libkio.so.4.2.0

40391000       8 rw--- 0000000040391000 000:00000   [ anon ]

40393000    2644 r-x-- 0000000000000000 0fe:00000 libkdeui.so.4.2.0

40628000     164 rw--- 0000000000295000 0fe:00000 libkdeui.so.4.2.0

40651000       4 rw--- 0000000040651000 000:00000   [ anon ]

40652000     100 r-x-- 0000000000000000 0fe:00000 libkdesu.so.4.2.0

4066b000       4 rw--- 0000000000019000 0fe:00000 libkdesu.so.4.2.0

4066c000      68 r-x-- 0000000000000000 0fe:00000 libkwalletclient.so.1.0.0

4067d000       4 rw--- 0000000000011000 0fe:00000 libkwalletclient.so.1.0.0

4067e000       4 rw--- 000000004067e000 000:00000   [ anon ]

4067f000    2148 r-x-- 0000000000000000 0fe:00000 libkdecore.so.4.2.0

40898000      64 rw--- 0000000000219000 0fe:00000 libkdecore.so.4.2.0

408a8000       8 rw--- 00000000408a8000 000:00000   [ anon ]

... (trimmed) ...

mapped: 25404K    writeable/private: 2432K    shared: 0K

I cut out a lot of the output; the rest is similar to what is

shown. Even without the complete output, we can see some very

interesting things. One important thing to note about the output is

that each shared library is listed twice; once for its code segment and

once for its data segment. The code segments have a mode of "r-x--",

while the data is set to "rw---". The Kbytes, Mode, and Mapping columns

are the only ones we will care about, as the rest are unimportant to

the discussion.

If you go through the output, you will find that the lines with the

largest Kbytes number are usually the code segments of the included

shared libraries (the ones that start with "lib" are the shared

libraries). What is great about that is that they are the ones that can

be shared between processes. If you factor out all of the parts that

are shared between processes, you end up with the "writeable/private"

total, which is shown at the bottom of the output. This is what can be

considered the incremental cost of this process, factoring out the

shared libraries. Therefore, the cost to run this instance of KEdit

(assuming that all of the shared libraries were already loaded) is

around 2 megabytes. That is quite a different story from the 14 or 25

megabytes that ps reported.

What does it all mean?

The moral of this story is that process memory usage on Linux is a

complex matter; you can't just run ps and know what is going on. This

is especially true when you deal with programs that create a lot of

identical children processes, like Apache. ps might report that each

Apache process uses 10 megabytes of memory, when the reality might be

that the marginal cost of each Apache process is 1 megabyte of memory.

This information becomes critial when tuning Apache's MaxClients

setting, which determines how many simultaneous requests your server

can handle (although see one of my past postings for another way of

increasing Apache's performance).

It also shows that it pays to stick with one desktop's software as

much as possible. If you run KDE for your desktop, but mostly use Gnome

applications, then you are paying a large price for a lot of redundant

(but different) shared libraries. By sticking to just KDE or just Gnome

apps as much as possible, you reduce your overall memory usage due to

the reduced marginal memory cost of running new KDE or Gnome

applications, which allows Linux to use more memory for other

interesting things (like the file cache, which speeds up file accesses

immensely).

阅读(548) | 评论(0) | 转发(0) |