1 |
* Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
|
3 |
> $free -m |
4 |
> total used free shared buffers cached |
5 |
> Mem: 5925 3334 2590 0 319 1571 |
6 |
> -/+ buffers/cache: 1443 4481 |
7 |
> Swap: 20479 0 20479 |
8 |
|
9 |
Apropos total memory: on my box w/ 4GB, it only shows up 3GB. |
10 |
On bootup, kernel (built w/ CONFIG_HIGHMEM4G=y) says: |
11 |
|
12 |
2119MB HIGHMEM available. |
13 |
887MB LOWMEM available. |
14 |
|
15 |
Who's eating up a whole GB ? BIOS ? GPU ? |
16 |
|
17 |
> Tho in my experience, even the 1.4 gigs of app usage isn't entirely |
18 |
> required. It has been awhile ago now, but at one point I was running 1 |
19 |
> gig of total RAM, with no swap. At that time, app-memory usage seemed to |
20 |
> run ~ half a gig. When I upgraded RAM to 8 gigs (I since lost a stick |
21 |
> that I've not replaced, thus the current 6 gigs), app memory usage |
22 |
> increased as well, to closer to a gig (IIRC it was about 1.2 gig after a |
23 |
> week's uptime, back then, to compare apples to apples as they say), |
24 |
> without changing what I was running or the settings. |
25 |
|
26 |
That's interesting. Which of the apps now use more memory ? |
27 |
Any database systems on your box ? |
28 |
|
29 |
> Individual app memory usage on Linux is unfortunately a rather complex |
30 |
> subject. Top is a useful app for reporting on and controlling (nicing, |
31 |
> killing, etc) other apps. Top's manpage has a nice description of the |
32 |
> various memory related stats and how they relate to each other, so I'll |
33 |
> refer you to that for some detail I'm omitting here. Meanwhile, on non- |
34 |
> swapping systems, resident memory (top's RES column) is about as accurate |
35 |
> a first-order approximation of app memory usage as you'll get, but it's |
36 |
> only reporting physical memory, so won't include anything swapped out. |
37 |
> Also, the memory one could expect to free by terminating that app will be |
38 |
> somewhat less than resident memory, due to libraries and data that may be |
39 |
> shared between multiple apps. Top has a SHR (shared) column to report |
40 |
> potentially shared memory, but doesn't tell you how many other apps (maybe |
41 |
> none) are actually sharing it. Some memory reporting apps won't count |
42 |
> shared memory as belonging to the app at all, others (like top, AFAIK) |
43 |
> report the full memory shared as belonging to each app, while still others |
44 |
> try to count how many apps are sharing what bits, and divide the shared |
45 |
> memory by the number of apps sharing it. Which way is "right" depends on |
46 |
> what information you're actually looking for. If you want the app totals |
47 |
> to match actual total memory usage, apportioned share reporting is the way |
48 |
> to go. If you want to know what quitting the app will actually free, only |
49 |
> count what's not shared by anything else. If you want to know how much |
50 |
> memory an app is actually using, regardless of other apps that may be |
51 |
> sharing it too, count all the memory it's using, shared or not. |
52 |
|
53 |
Yep, depending on the actual question you ask, you'll have to look at |
54 |
different stats. For example, if you're interested in how much memory |
55 |
usage a single process adds to the system (IOW: how much would be freed |
56 |
by killing it), you'll have to look through all its mappings and count |
57 |
off the pages that are also mapped by other process'es. |
58 |
|
59 |
BTW: does anyone know a tool for that (just too lazy to code it by myself |
60 |
right now ;-o) |
61 |
|
62 |
> Then there's swapping. Due to the way Linux works, the data available on |
63 |
> swapped out memory is limited. To get all the normal data would require |
64 |
> swapping all that data back in, rather defeating the purpose of swap, so |
65 |
> few if any memory usage reporting utils give you much detail about |
66 |
> anything that's swapped out. For people with memory enough to do so, a |
67 |
> swapoff (or simply running without swap at all) force-disables swap, thus |
68 |
> making full statistics available, but as mentioned above, to a point, many |
69 |
> apps will use more memory if it's available, conserve if it's not, so |
70 |
> running without swap on systems that routinely report non-zero swap usage |
71 |
> doesn't necessarily give a true picture of an app's memory usage with swap |
72 |
> enabled, either. |
73 |
|
74 |
BTW: does anyone know a sane way how to hand-off this to the kernel ? |
75 |
So eg. a RDBMS could ask the kernel how much buffers it should use ? |
76 |
(or somehow use the kernel's buffercache decisions) |
77 |
|
78 |
|
79 |
cu |
80 |
-- |
81 |
---------------------------------------------------------------------- |
82 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
83 |
|
84 |
phone: +49 36207 519931 email: weigelt@×××××.de |
85 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
86 |
---------------------------------------------------------------------- |
87 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
88 |
---------------------------------------------------------------------- |