1

Edit: I'm thinking about marking this question as answered since I've realized that I was pretty confused by the fact that file sizes were zero. This caused me to have a brain fart and panic. After reading the answers below I realized that I've often read these files before but it never occurred to me to check their filesizes. Therefore my question is misleading. I should have only asked why the file sizes were 0 only.

This is not a question about missing ram - but it may be a question about file sizes of 0. Am I looking at files that have zero file size because they are aliases to data in ram rather than on disk?

I understand that procinfo gathers information from the /proc directory on a linux box. But I've taken a look in that directory and can't figure out what files it actually queries. It appears as though most files are 0 bytes. What's really odd is that a particular file, kcore is listed as 128T on my system.

I've read that kcore represents the amount of ram on my system but I am sure I don't have 128T of ram (I have 12GB). I took a look at a second server that I rebooted and the file was 884M (that server has 1GB of ram).

I believe that, whether or not kcore is being used, procinfo is providing statistics based on data in ram. And I believe that is verified by procinfo's inability to keep data after a reboot.

I have two questions:

  1. Would someone care to clarify these assumptions and add some helpful observations about this performance tool?

  2. What is kcore if it's not a representation of the ram on my system (as I've read)?

Improve this question
1
  • This question will self destruct if it gets three up/down votes.
    – Patrick R
    Feb 26, 2010 at 20:39

4 Answers 4

Reset to default
2

To answer the question about why files under proc show 0 byte size:

Files under /proc aren't regular files, but simulated by the kernel. Their content can (and will change) constantly, so there's no useful notion of "file size" (as the size changes constantly). That is probably the reason why the sytem shows them as "size 0".

Improve this answer
3
  • @Patrick R: I thought it was obvious that files under /proc are not "real" (after all, many files change content constantly, or do something when you write to them. Anyway, see en.wikipedia.org/wiki/Procfs for a longer story. BTW, there are other pseudo-filesystems on Linux / Unix; e.g. devfs and sysfs (see Wikipedia as usual ).
    – sleske
    Feb 26, 2010 at 2:17
  • I often am reminded that what I think is obvious isn't to others. I'd say that the kernal is the "last" current frontier for me. I didn't realize that I had overlooked this type of behavior until I started taking a closer look at where procinfo was gathering information from. I'd still like to know if this pseudo-filesystem is an alias for data directly in ram rather than on disk.
    – Patrick R
    Feb 26, 2010 at 13:12
  • @PatrickR: Yes, whether something is obvious is usually very subjective, I already learned that in lectures at university :-). As to "alias for data directly in RAM": Usually the information in proc files is generated on-the-fly by the kernel (maybe cached a bit). I don't think any of it comes from the disk.
    – sleske
    Mar 1, 2010 at 10:39
2

Many of the files in /proc are listed by ls as having zero bytes, but if you cat them the will show some piece of information.

$ ls -l /proc/$$/status
-r--r--r-- 1 user user 0 2010-02-24 19:45 /proc/25440/status
$ cat /proc/$$/status
Name:   bash
State:  S (sleeping)
Tgid:   25440
Pid:    25440
PPid:   25439
TracerPid:      0
etc.

(where $$ is resolved by the shell to the current PID)

Improve this answer
1
  • 3
    cat /proc/meminfo is perfectly safe (and informative). cat /proc/kcore is looking at the actual contents of the system's memory. See man proc for an explanation of the proc pseudo filesystem and many of the files. Proc files are interfaces to kernel data structures. The size of the information returned could fluctuate at any time and so a size returned by ls is meaningless in most cases.
    – Dennis Williamson
    Feb 25, 2010 at 2:58
1

/proc/kcore is not being used by procinfo. Observe that a normal user can run procinfo fine, while they are normally not able to read kcore.

Are you sure you read /proc/kcore size correctly ? check the size with ls -lh , and compare with values from free

Have a look at man proc for a detailed explanation of each entry. There is a lot of redundancy, but memory usage can be extracted from /proc/meminfo, load averages from /proc/loadavg, and IRQ data from /proc/interrupts.

For your second server, there is a kernel setting on x86 "High Memory Support" that, if not enabled, will limit your physical memory to a bit more than 800MB, maybe you are affected by this ?

Improve this answer
1
  • kcore is possibly a distraction and better off in another question. I initially focused on it since it was the only file that appeared to have any size.
    – Patrick R
    Feb 24, 2010 at 23:59
0

The /poc/kcore represents the MAX-memory your system can handle. In your case, you are running a 64-bit operating system, which means you can have 128TB of mem.

Improve this answer
1
  • 1
    Do don't really answer the question!
    – slm
    Jan 24, 2013 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.