Find the answer to your Linux question:
Results 1 to 6 of 6
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    top command memory question


    I run the command "top" and was wondering why so much memory is used. Following is a snapshot :
    11:43am up 4 days, 1:29, 4 users, load average: 0.00, 0.00, 0.05
    59 processes: 58 sleeping, 1 running, 0 zombie, 0 stopped
    CPU0 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
    CPU1 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
    Mem: 2064172K av, 2048696K used, 15476K free, 0K shrd, 362856K buff
    Swap: 2040244K av, 0K used, 2040244K free 1530488K cached

    32408 gdm 15 0 17084 16M 6100 S 0.0 0.8 0:01 gdmgreeter
    957 root 5 -10 137M 9980 2556 S < 0.0 0.4 24:10 X

    I've used the "M" option to sort the processes in order of memory usage. My Question is : why is (2064172K av, 2048696K used)? What could account for this large memory usage?

    Thanks for any comments!

  2. #2
    Linux Guru
    Join Date
    Oct 2001
    Täby, Sweden
    Don't worry; it's supposed to be that way. The reason is that the reported used memory isn't just the memory that is in use by programs, but it also includes all memory that the kernel uses for block caching and stuff. Here's how it works:
    Suppose that you run "ls /". What the kernel does then (after some processing), is that it requests the hard disk sectors that make up the root directory, and then it makes the ls process sleep until those sectors are received. While the hard drive is looking up those sectors, the system does some other things that don't require hard drive access. The hard drive then puts the sectors that it found in your RAM, and reports back to the kernel that the operation completed. Then the kernel continues with the ls process, which outputs what you wanted to see. After that, the kernel has two choices:

    1. It could discard the sectors loaded from the hard drive.
    2. It could keep the sectors in memory.

    Now, if we look carefully at option number 1, which at the first glance might seem like a good thing, since it apparently makes that memory usable again, we see that it would require those sectors to be loaded once again whenever a process wants to look in the root directory. Since many files that are opened are opened with absolute path names, there are many root directory accesses in the system. If the sectors would have to be loaded each time a process accesses the root directory, the system would be slow, since the hard drive is slow. Therefore, the kernel keeps the sectors in memory. The memory used this way is what you see in the "cached" entry. That allows for extremely fast disk access, since all sectors that have once been accessed don't have to be reloaded from the physical disk.
    Now, you might think that that's an extreme waste of memory, but if you do, you're very wrong. You see, the block caches are low-priority pages, which essentially means that they are free to be used be processes, should they need the memory. Every time a process needs an extra memory page and there isn't already one free, a page used for block buffering is freed by the kernel and put into the process' addressing space for the process to use in whatever way it see fit. Together with some intelligently designed algorithms for choosing which cache page to be freed, this all allows for really fast disk access.

    If you would a some point also wonder why memory doesn't appear to have been freed when a process exits, it has similar reasons. First, there are shared libraries. For example, libraries like libc or Xlib, that are used by many applications, are just loaded into memory once, and then the pages which they are loaded into are mapped into all processes that need them. For example, if a processes indicates that it uses 2 MBs, the majority of that memory may very well be libc, and just because that process exits, those memory pages are still in use by many other processes, and therefore cannot be freed. In the old days, when all libraries were statically linked, each and every process would have its own copy of libc, which made everything very memory demanding. That was a really long time ago, though.
    Similarly, the actual binary file that makes up the program that was started might only be used by that process no else. Anyway, when that program was loaded, it was also cached. The cache pages are the same pages that are mapped into the process' memory space. So the caches are also shared with the process itself. When the process exits, those pages aren't freed, they are just remarked from cached+used to only cached. That way they are made low priority, but they aren't freed until its actually necessary. After all, why would they be?
    The only memory that gets freed when a process exits is the data memory it used. That's different for different programs; some use almost no data memory, others use very much.

    So what it all comes down to is this: If you want to know how much memory is really available to your applications, add the "buff" and "cached" fields to the "free" field, and you'll have it. In this case, that's 1908820 KBs, which I think is pretty impressive.

    A word of caution: Since you have more than 960 MBs of RAM, make sure that you have your kernel compiled with High Memory Support, or the memory won't be used optimally.

  3. #3


    wow.. haha.. hey, what's your major? OS or hardware archi?

  4. $spacer_open
  5. #4
    Linux Guru
    Join Date
    Oct 2001
    Täby, Sweden
    I wish... Had I had that kind of education I might have had a nice computer related job right now...
    It sucks that it's so hard to get a computer job without a formal education for it. Oh, well; I've complained enough now. =)

  6. #5
    Linux Enthusiast
    Join Date
    Jun 2002
    San Antonio
    That was a good guess though, those concepts came up in 2 classes at our college. One was Operating Systems, the other was Computer Architecture. I think a lot of these concepts come easily if you just think of the most "reasonable" way to do things. I don't know, maybe that is why I do decently well, because the things just seem reasonable. Whatever. Also, Dolda, you should be able to get a job without a formal education, it is more about knowing who to talk to, and what to say, than it is getting an education.
    I respectfully decline the invitation to join your delusion.

  7. #6
    Linux Guru
    Join Date
    Oct 2001
    Täby, Sweden
    Why of course it's reasonable. Why ever would you just throw away the caches when you can keep them? I mean, sure, you wouldn't have to hash them and stuff, but somehow it seems worth it to hash it all. It sure seems like Windows throws them anyway. Maybe it's just that I'm overreacting, but while my system hardly even reacts to hard drive activity, it seems to me as if a Windows system becomes close to unusable as soon as the hard drive is being used (OK, now that wasn't cache related, but I did mention DMA, too, didn't I? And Windows certainly has caching issues as well...).
    I would imagine that it's a bit confusing for users who haven't thought of it before that caches are counted as "used" memory, though. I was a little surprised the first time I found out, too.

    Also, while I might have been able to get a job normally, there are some special, quite local, circumstances here right now. You see, things haven't been going optimally for Ericsson the last year, so they've recently fired aroung 10000 software engineers/sysadmins/programmers/anything in the Stockholm area (in which I live). So, you can't really say that there's an emergency need for IT people in my living area right now. I'd certainly say that it would've been better if I had had an education. With all the applications that managers probably get right now, they probably don't even look into it (normally, of course there are exceptions), unless you can prove to be educated. But I don't really know; I must admit that I don't have that much experience. I was planning on applying for different jobs after the next week.
    Anyway, that wasn't _really_ important... =)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts