|
|
| (5 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| This article helps understanding UNIX memory management. In UNIX a process uses basically three kinds of memory segments: '''shared memory segments''', '''code segments''' and '''data segments'''.
| | {{Moved To Community | Guidelines_and_HOWTOs/Debugging }} |
| | |
| '''Shared memory''' is used by shared libraries. This memory is shared
| |
| by all processes which use a certain library. Unfortunately there is no
| |
| easy way to determine how much shared memory is used by how many processes.
| |
| So a process can use 10Mb of shared memory, but you don't know whether this
| |
| memory is shared with 1, 2 or 10 processes. So if you have 10 processes who
| |
| each use 10Mb of shared memory this actually requires 10Mb in the best case
| |
| and 100Mb in the worst case.
| |
| | |
| '''Code segments''' contain the actual executable code of your program.
| |
| This memory is shared by all processes of this same program. If you start
| |
| your program 5 times, it needs to load the code segment of your program
| |
| only once.
| |
| | |
| '''Data segments''' contain the data of your program. This kind of memory
| |
| is very important because the data segments of a process are not shared
| |
| with other processes. Starting the same program 5 times makes that the data
| |
| segments are 5 times in memory.
| |
| | |
| The size reported by [http://man-wiki.net/index.php/Ps ps auxf] is typically just the numbers for shared, code and
| |
| data added. This is not a very accurate representation of the memory usage
| |
| of an application.
| |
| | |
| KDE applications tend to be reported as quite large because the numbers
| |
| reported include the size of the shared memory segments. This size is
| |
| added to the size of each KDE application while in practice the shared
| |
| memory segments appear in memory only once. This is rather illusive,
| |
| imagine how the output of ps would look like if it included the size of
| |
| the UNIX kernel for each process!
| |
| | |
| Instead of looking at the output of ps you get a better idea of the actual
| |
| memory usage of an application by looking at the output of
| |
| cat /proc/<pid-of-process>/status.
| |
| | |
| = Example program =
| |
| To demonstrate this, let's write a memory leaking program: | |
| | |
| '''main.cpp'''
| |
| <syntaxhighlight lang="cpp-qt">
| |
| #include <KAboutData>
| |
| #include <KApplication>
| |
| #include <KCmdLineArgs>
| |
| #include <KMessageBox>
| |
| | |
| int main (int argc, char *argv[])
| |
| {
| |
| KAboutData aboutData( "tutorial1", 0, ki18n("Tutorial 1"), "1.0",
| |
| ki18n("Displays a KMessageBox popup") );
| |
|
| |
| KCmdLineArgs::init( argc, argv, &aboutData );
| |
| KApplication app;
| |
| | |
| for ( int i=0; i<100000; i++ ) new QString();
| |
| | |
| KMessageBox::questionYesNo( 0, i18n( "Hello World" ) );
| |
| int* i;
| |
| return 0;
| |
| }
| |
| </syntaxhighlight>
| |
| '''CMakeLists.txt'''
| |
| <pre>
| |
| project (tutorial1)
| |
| find_package(KDE4 REQUIRED)
| |
| include (KDE4Defaults)
| |
| include_directories(${KDE4_INCLUDES})
| |
| set(tutorial1_SRCS main.cpp)
| |
| kde4_add_executable(tutorial1 ${tutorial1_SRCS})
| |
| target_link_libraries(tutorial1 ${KDE4_KDEUI_LIBS})
| |
| install(TARGETS tutorial1 ${INSTALL_TARGETS_DEFAULT_ARGS})
| |
| </pre>
| |
| Compile and link this program:
| |
| <pre>
| |
| cmake . && make -j4
| |
| </pre>
| |
| Run it:
| |
| <pre>
| |
| ./tutorial1 &
| |
| [3] 22733
| |
| </pre>
| |
| In this case the program gets the process ID 22733. We look at its memory consumption:
| |
| <pre>
| |
| cat /proc/22733/status
| |
| VmRSS: 19772 kB
| |
| VmData: 5776 kB
| |
| VmStk: 84 kB
| |
| VmExe: 8 kB
| |
| VmLib: 26804 kB
| |
| </pre>
| |
| If we change the "100000" in the program code to "1", we get a different picture:
| |
| <pre>
| |
| VmRSS: 16624 kB
| |
| VmData: 2652 kB
| |
| VmStk: 84 kB
| |
| VmExe: 8 kB
| |
| VmLib: 26804 kB
| |
| </pre>
| |
| So we see the heap is counted to <tt>VmData</tt> and contained in <tt>VmRSS</tt>.
| |
| | |
| == Why is it so big ==
| |
| Probably VmLib is so big because it contains all library code in memory needed for KDE. Let's see what the loader thinks are our program's dependencies:
| |
| # ldd tutorial1
| |
| linux-vdso.so.1 => (0x00007fff739f3000)
| |
| libkdeui.so.5 => /usr/local/lib64/libkdeui.so.5 (0x00007fdb6448c000)
| |
| libkdecore.so.5 => /usr/local/lib64/libkdecore.so.5 (0x00007fdb63f31000)
| |
| libQtDBus.so.4 => /usr/local/lib64/libQtDBus.so.4 (0x00007fdb63cb5000)
| |
| libQtCore.so.4 => /usr/local/lib64/libQtCore.so.4 (0x00007fdb6380b000)
| |
| [...]
| |
| We gonna remove the KDE and Qt stuff, so let's write a new main.cpp:
| |
| int main (int argc, char *argv[])
| |
| {
| |
| for ( int i=0; i<100000; i++ ) new int;
| |
| while (true);
| |
| return 0;
| |
| }
| |
| And compile and link it with the C++ libraries:
| |
| # g++ -o tutorial1 main.cpp
| |
| Why do we need the C++ libraries (g++ is basically gcc -lstdc++)? Because we have a call to the new keyword in the program. What are the dependencies now?
| |
| # ldd tutorial1
| |
| linux-vdso.so.1 => (0x00007fffd3bff000)
| |
| libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe2437a5000)
| |
| libm.so.6 => /lib64/libm.so.6 (0x00007fe24354e000)
| |
| libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe243338000)
| |
| libc.so.6 => /lib64/libc.so.6 (0x00007fe242fcb000)
| |
| /lib64/ld-linux-x86-64.so.2 (0x00007fe243aae000)
| |
| that's all.
| |
| | |
| Note that this program runs until you terminate it with CTRL_C as we are not using KDE's messagebox any more.
| |
| # cat /proc/21028/status | grep VmLib
| |
| VmLib: 2912 kB
| |
| You see - not using libraries save place in memory, but as libraries are shared, it does not make sense to deny using libraries that are in memory anyway.
| |
| | |
| = See also =
| |
| * http://www-archive.mozilla.org/projects/footprint/footprint-guide.html
| |
