How much of RAM is free?

[hoven]

but if a swap space were to obviate your freezes that would at least be an advance of knowledge.

I think you misunderstand. I was intentionally pushing the limits and actively seeking a system freeze to determine where the limit was. Once I know what the limit is and stay short of it then there isn't a freeze of that nature.

Our moderator does have a very good command of some four or more languages

And I find that very impressive, along with the time that they give the forum but this thread has taken up a great deal of words when I thought it would be answered within the first few posts.

I still think that raw figures won't help to get the question of how much RAM is free answered but currently Htop shows 212/2023MB. Firefox is the main offender (uses 50MB on two useless files allocations whereas an earlier version of Firefox happily used much less than 1MB).

Code: Select all

 free
              total         used         free       shared      buffers
  Mem:      2072572      2020124        52448            0       162736
 Swap:            0            0            0
Total:      2072572      2020124        52448

Code: Select all

cat /proc/meminfo
MemTotal:        2072572 kB
MemFree:           54604 kB
Buffers:          161768 kB
Cached:          1623728 kB
SwapCached:            0 kB
Active:          1383752 kB
Inactive:         601268 kB
Active(anon):    1131996 kB
Inactive(anon):   244136 kB
Active(file):     251756 kB
Inactive(file):   357132 kB
Unevictable:           4 kB
Mlocked:               0 kB
HighTotal:       1186160 kB
HighFree:           1960 kB
LowTotal:         886412 kB
LowFree:           52644 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        199444 kB
Mapped:            62620 kB
Shmem:           1176604 kB
Slab:              19888 kB
SReclaimable:      12772 kB
SUnreclaim:         7116 kB
KernelStack:         800 kB
PageTables:         1440 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1036284 kB
Committed_AS:    1661860 kB
VmallocTotal:     122880 kB
VmallocUsed:        4740 kB
VmallocChunk:     109572 kB
DirectMap4k:       12280 kB
DirectMap4M:      897024 kB

Code: Select all

 df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop1            248M   79M  170M  32% /initrd/pup_ro1
tmpfs                1012M   51M  961M   5% /initrd/pup_rw
tmpfs                 213M  212M  784K 100% /initrd/mnt/tmpfs
/dev/loop0            212M  212M     0 100% /initrd/pup_ro2
unionfs              1012M   51M  961M   5% /
shmfs                 450M     0  450M   0% /dev/shm
tmpfs                 1.5G  886M  643M  58% /mnt/sdzz

[Jasper]

Hi again,

So, using that published data, exactly how do you calculate 650 MB (or whatever the current number is)?

My regards

[hoven]

Hi again,

So, using that published data, exactly how do you calculate 650 MB (or whatever the current number is)?

My regards

Those figures were a bad example as there were a few numbers that by sheer coincidence were similar to others that were unrelated.

After a reboot:

Code: Select all

free
              total         used         free       shared      buffers
  Mem:      2072572       659252      1413320            0        37724
 Swap:            0            0            0
Total:      2072572       659252      1413320

Code: Select all

cat /proc/meminfo 
MemTotal:        2072572 kB
MemFree:         1462516 kB
Buffers:           36732 kB
Cached:           470080 kB
SwapCached:            0 kB
Active:           101680 kB
Inactive:         479132 kB
Active(anon):      76548 kB
Inactive(anon):   254556 kB
Active(file):      25132 kB
Inactive(file):   224576 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       1186160 kB
HighFree:         635476 kB
LowTotal:         886412 kB
LowFree:          827040 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         74000 kB
Mapped:            38460 kB
Shmem:            257104 kB
Slab:              18092 kB
SReclaimable:      11452 kB
SUnreclaim:         6640 kB
KernelStack:         792 kB
PageTables:         1004 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1036284 kB
Committed_AS:     512452 kB
VmallocTotal:     122880 kB
VmallocUsed:        4740 kB
VmallocChunk:     109516 kB
DirectMap4k:       12280 kB
DirectMap4M:      897024 kB

Code: Select all

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop1            248M   79M  170M  32% /initrd/pup_ro1
tmpfs                1012M   52M  961M   6% /initrd/pup_rw
tmpfs                 213M  212M  784K 100% /initrd/mnt/tmpfs
/dev/loop0            212M  212M     0 100% /initrd/pup_ro2
unionfs              1012M   52M  961M   6% /
shmfs                 442M     0  442M   0% /dev/shm

Htop reading 135/2023MB

The things that I believe are currently taking up RAM are:
135MB (from Htop, this will vary especially with a web-browser)
212MB (pupxxx.sfs file)
52MB (tmpfs)

So there's something like 1600MB free.

Now after adding a large file (885MB) in tmpfs:

Code: Select all

 free
              total         used         free       shared      buffers
  Mem:      2072572      1587240       485332            0        38580
 Swap:            0            0            0
Total:      2072572      1587240       485332

Code: Select all

 cat /proc/meminfo
MemTotal:        2072572 kB
MemFree:          485024 kB
Buffers:           38580 kB
Cached:          1398580 kB
SwapCached:            0 kB
Active:           212852 kB
Inactive:        1341852 kB
Active(anon):     186196 kB
Inactive(anon):  1110560 kB
Active(file):      26656 kB
Inactive(file):   231292 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       1186160 kB
HighFree:           1712 kB
LowTotal:         886412 kB
LowFree:          483312 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        117476 kB
Mapped:            41972 kB
Shmem:           1179212 kB
Slab:              20128 kB
SReclaimable:      13136 kB
SUnreclaim:         6992 kB
KernelStack:         824 kB
PageTables:         1168 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1036284 kB
Committed_AS:    1539280 kB
VmallocTotal:     122880 kB
VmallocUsed:        4740 kB
VmallocChunk:     109516 kB
DirectMap4k:       12280 kB
DirectMap4M:      897024 kB

So should be about 700MB free.

[jpeps]

I was intentionally pushing the limits and actively seeking a system freeze to determine where the limit was. Once I know what the limit is and stay short of it then there isn't a freeze of that nature.

That would be interesting if you find a way. I added free RAM by dumping the cache during a near freeze....which never helped at all. The solution was finding which programs were mis-managing resources to begin with.
Besides flash, ff, etc., closing down tray and desktop process widgets was a big help.

[Jasper]

Hi,

Hopefully you will get a full explanation which would please me as well. If you do not; you might PM "Bruce B" since he stated that Htop does not report RAM correctly.

My regards

[hoven]

you might PM "Bruce B" since he stated that Htop does not report RAM correctly.

I don't know what "Bruce B" was referring to but like I said before, I am not aware of a reason to believe that Htop reports incorrectly, but it only reports RAM used by running processes. Puppy uses RAM for other things as well (like the contents of /tmp for example). You have to use what Htop reports plus add on what is shown in "df -h" for the tmpfs and shmfs file systems.

[Jasper]

Hi,

Your explanation has the ring of truth, thus you appear you have solved our problem - which perhaps someone may confirm.

Just a thought (as I could find no existing applications); it might be an idea for Puppies to have two tiny System Tray Graphs, perhaps showing say, the last 30 seconds of RAM and CPU usage - with on/off options if those graphs themselves use high resources.

My regards

[hoven]

as I could find no existing applications); it might be an idea for Puppies to have two tiny System Tray Graphs, perhaps showing say, the last 30 seconds of RAM and CPU usage - with on/off options if those graphs themselves use high resources.

Not sure if you are aware of Gatotray but it does a pretty good job of showing CPU and I/O load. If the system is struggling it will go nice and red.
http://murga-linux.com/puppy/viewtopic.php?t=59930

(Sadly I preferred Traytemp for temperature but it appears not to work with current Puppies anymore)

Then there is Xload, I still have no idea what it means even after using Puppy for a few years and reading the thread on it.

[jpeps]

Just a thought (as I could find no existing applications); it might be an idea for Puppies to have two tiny System Tray Graphs, perhaps showing say, the last 30 seconds of RAM and CPU usage - with on/off options if those graphs themselves use high resources.

I use a CPU bar with pwidgets, which accurately shows a resource freeze. At that point, rebooting seems to be about the only thing choice to restore functioning. I've got a ram bar also, which doesn't indicate any problem.

[gcmartin]

We must understand that Puppy is a special kind of LInux. And, because of its expected RAM based environment, it would be prudent to have a tool (either available as a PET, or built-in to the system) that actively monitors and reports RAM usage.

This is NOT going to stop the opportunity to freeze the system thru an overzealous application's(s) operation which impacts storage quickly, but, it "could" in certain situations alert and maybe avert a RAM saturation which is eminent.

Puppy is RAM based, thus Puppy's tool need is a little different than other Linuxes which are NOT operating in a RAM-centric mode. Further there are times when Puppy user might be operating on PCs that do not have SWAP partitions/file, as well as those when SWAP is available.

That's why this thread is leading all who read this to think about whether RAM based Puppy would benefit from a tool which focuses on RAM.

Not just a graph, but, to address system stability, it must ALSO product alerts!

Since persons here understand the need, who among us, can produce such a tool. And how do we work together to contribute to its requirements.

There are several things at play in Puppy when its running as a RAM basis. We have:

1. Puppy filesystem
2. System resident programs
3. staging/buffers/caches/spools/etc space requirements for normal system operations
4. Space requirements for time-slicing active programs carrying out user needs.

We don't necessarily need a report on each of these, but, it should be able to sum up all these parts to alert as the Puppy system approaches saturation.

Saturation would mean something a little different when SWAP is available on a RAM-centric distro. So, the tool may also need to take into account the "total" elements, similar to something like what is reported in the Free Linux command.

Beware that there are those among us who might not see the need, for they process skills to avoid a system freeze. But, for newbies and novices whose Linux skills are lacking, a tool like this would help them and help those of us who are trying to help them when there are problems.

So, my question, how do we get a useful helpful tool? Can/should we collaborate on it?

Hope this helps.

[jpeps]

So, my question, how do we get a useful helpful tool? Can/should we collaborate on it?

Well, I can just listen to my fan.....with 100% accuracy. It tells me it's time to reboot. After the warning, I've got about a minute left to save work before things grind to a halt. The problem was what was causing it.

[gcmartin]

... So, my question, how do we get a useful helpful tool? Can/should we collaborate on it?

Well, I can just listen to my fan.....with 100% accuracy. It tells me it's time to reboot. After the warning, I've got about a minute left to save work before things grind to a halt. The problem was what was causing it.

Yeah, that's a good useful "tool" although it wasn't intended for that.

But, that just what I'm getting at. Its not just the "alert", BUT ALSO some sort of a companion log. And. given enough warning, a chance to save that log for analysis when the Puppy is operating RAM-centric.

What this brings to mind is a RAM tool which start off addressing one aspect "alerting", say, then matures to "analysis", per say. Or vide-versa.

Thanks for that, though.

[jpeps]

Maybe something like vmstat:

http://www.linuxjournal.com/article/8178

[jpeps]

Here's a vmstat substitute: dstat -v

Needs python-2.6.6

[jpeps]

I noticed that stalling out is associated with high cpu usr activity and siq (softirq)..which I think involve second-level interrupt handlers:

"These threads sit on a run queue in the operating system until processor time is available for them to perform processing for the interrupt. SLIHs may have a long-lived execution time, and thus are typically scheduled similarly to threads and processes."

http://en.wikipedia.org/wiki/Interrupt_handler

You can have plenty of free ram while this occurs. I didn't see much if any paging or use of swap while this was happening.

[greengeek]

We must understand that Puppy is a special kind of LInux. And, because of its expected RAM based environment, it would be prudent to have a tool (either available as a PET, or built-in to the system) that actively monitors and reports RAM usage.

This is NOT going to stop the opportunity to freeze the system thru an overzealous application's(s) operation which impacts storage quickly, but, it "could" in certain situations alert and maybe avert a RAM saturation which is eminent.

Puppy is RAM based, thus Puppy's tool need is a little different than other Linuxes which are NOT operating in a RAM-centric mode. Further there are times when Puppy user might be operating on PCs that do not have SWAP partitions/file, as well as those when SWAP is available.

That's why this thread is leading all who read this to think about whether RAM based Puppy would benefit from a tool which focuses on RAM.

Not just a graph, but, to address system stability, it must ALSO product alerts!

Since persons here understand the need, who among us, can produce such a tool. And how do we work together to contribute to its requirements.

There are several things at play in Puppy when its running as a RAM basis. We have:

1. Puppy filesystem
2. System resident programs
3. staging/buffers/caches/spools/etc space requirements for normal system operations
4. Space requirements for time-slicing active programs carrying out user needs.

We don't necessarily need a report on each of these, but, it should be able to sum up all these parts to alert as the Puppy system approaches saturation.

Saturation would mean something a little different when SWAP is available on a RAM-centric distro. So, the tool may also need to take into account the "total" elements, similar to something like what is reported in the Free Linux command.

Beware that there are those among us who might not see the need, for they process skills to avoid a system freeze. But, for newbies and novices whose Linux skills are lacking, a tool like this would help them and help those of us who are trying to help them when there are problems.

So, my question, how do we get a useful helpful tool? Can/should we collaborate on it?

Hope this helps.

This thread is very interesting and does highlight the lack of a useful visual tool to alert Puppy users to how little free RAM may be left - especially in situations where there are puppy sfs files (incl adrv, zdrv etc) and expanded tempfs files in RAM due to puppy's use of layering.

GCMartins reply still deserves attention I feel.

Beem mentioned using Pup-SysInfo (not Sysinfo) to find the information and I am surprised at what that shows:

Menus, System, Pup-SysInfo, devices, memory:

Code: Select all

Memory Allocation:
 Total RAM: 1984 MB
 Used RAM: 1408 MB
 Free RAM: 576 MB
 Buffers: 85 MB
 Total Swap: 10604 MB
 Free Swap: 10604 MB

Looks as if I am much closer to running out of RAM than I realised. Luckily I have a large swap partition - but as Hoven pointed out in the thread - there are times where a user does not want a swap partition (or swapfile).

Does anyone know if a useful visual (coloured bargraph maybe??) exists to adequately display RAM fill in Puppy's specific environment?

EDIT : Jaspers other thread discussing this matter is also worth a read, particularly Beem's post here

EDIT 2 : Food for thought: what effect does it have on your reported RAM free figures if you load up the devx.sfs for your puppy? Should it consume exactly as much free RAM as the devx itself uses on disk? (eg approx 140MB for my Slacko 5.6 devx). I don't see the whole devx.sfs size reflected in reduction of free RAM.

Hmmmm....

EDIT 3 : see also http://blog.scoutapp.com/articles/2010/ ... oc-meminfo

[bigpup]

Memory Allocation:
Total RAM: 1984 MB
Used RAM: 1408 MB
Free RAM: 576 MB
Buffers: 85 MB
Total Swap: 10604 MB
Free Swap: 10604 MB

First, your swap is not being used.

There is one piece of info missing from this report and that is the memory cache.
Not sure why it is not being shown, or did you forget to include it?
How are you running Puppy??????

Example:
Here is my memory report for a frugal install with a save file.
16GB of memory.

Code: Select all

Memory Allocation:
 Total RAM: 15974 MB
 Used RAM: 5451 MB
 Free RAM: 10523 MB
 Buffers: 141 MB
 Cached: 4953 MB

The memory buffer and cache are set aside memory for that use, but they may not have anything in them, until something is done that uses them. They can self adjust as memory needs change.
That memory is released for other uses, as needed. Say to run a newly started program.

[greengeek]

There is one piece of info missing from this report and that is the memory cache.
Not sure why it is not being shown, or did you forget to include it?
How are you running Puppy??????.

Interesting observation. I run puppy without savefile. I have a personal sfs as my main sfs (top layer) and have changed my previous main puppy sfs to be the zdrv (bottom layer).

I wondered if the lack of caching was due to swap availability but no cache appeared after turning swap off:

Code: Select all

Memory Allocation:
 Total RAM: 1984 MB
 Used RAM: 1097 MB
 Free RAM: 887 MB
 Buffers: 83 MB
 Total Swap: 0 MB
 Free Swap: 0 MB

Maybe my system load is too light at present.

My pup-sysinfo version is 2.3
Is that the same as yours?

[8Geee]

Slacko5.7 updated security-wise to 2018 PSI version 2.4

Memory Allocation:
Total RAM: 2016 MB
Used RAM: 818 MB
Free RAM: 1198 MB
Buffers: 22 MB
Total Swap: 0 MB
Free Swap: 0 MB

Memory Stats (/proc/meminfo):
MemTotal: 2064456 kB
MemFree: 1228408 kB
Buffers: 23172 kB
Cached: 542932 kB <---- CACHE
SwapCached: 0 kB
Active: 273632 kB
Inactive: 534416 kB
Active(anon): 248880 kB
Inactive(anon): 174940 kB
Active(file): 24752 kB
Inactive(file): 359476 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 1179272 kB
HighFree: 390508 kB
LowTotal: 885184 kB
LowFree: 837900 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 242048 kB
Mapped: 42732 kB
Shmem: 181876 kB
Slab: 18984 kB
SReclaimable: 10288 kB
SUnreclaim: 8696 kB
KernelStack: 760 kB
PageTables: 1128 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1032228 kB
Committed_AS: 681896 kB
VmallocTotal: 122880 kB
VmallocUsed: 5332 kB
VmallocChunk: 115556 kB
DirectMap4k: 909304 kB
DirectMap4M: 0 kB

Basically a full report.

Regards
8Geee

[greengeek]

Thanks 8geee. When I first saw the meminfo output i felt a tad overwhelmed.
What are the chances of summarising all that info in one icon in order to alert the user that they are running low on RAM and their system is going to grind to a halt?

Somewhat daunting!

I am still confused about one thing - some websites that discuss Linux memory management say "don't worry if your free RAM is getting low - that just means that the Linux kernel is using RAM efficiently"

However - there must be a point where the memory management simply has too little resource left to manage - so how do we represent that with an icon or conky output?

How could a user know that it is time to add a swap partition or swap file - or to kill some running processes?

It would be nice to have some (possibly preprogrammable) red flags pop up as an alert.