Hi all,

The swap space did not function ( usage stay 0% ) when physical memory (RAM) is full. This cause the workstation hang.

Workstation model = xw4400
Physical memory size = 4G
Swap Space size= 4G ( 2G on each HD ).

Would like your help as following :-
1. Why the swap space did not function when physical memory is full ?
2. How to activate the swap space to function when physical memory is full ?
3. Any command to clear / initialize the RAM ?




free

total used free shared buffers cached
Mem: 4095376 4011452 83924 0 48808 2469584
-/+ buffers/cache: 1493060 2602316
Swap: 4096524 0 4096524



/proc/swaps
Filename Type Size Used Priority
/dev/sdb1 partition 2048248 18760 -1
/dev/sda2 partition 2048276 0 -2


/etc/fstab

LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sdb1 swap swap defaults 0 0
/dev/sda2 swap swap defaults 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0

What distro and version are you using, and how was the drive partitioned?

I can't read your fine blue print, but it sounds like the swap space didn't get flagged as such. They need to be set as linux-swap by the partitioner.

What does the output of swapon -s give? Is the swap space actually on?

But it is used, at least /dev/sdb1:
from man fstab
So, your swap lines should read:
instead of:
with regard to the second field.

Actually, my entry differs at the fourth field as well - I have "sw" there instead of "defaults", like this:
HTH

Why do you think your RAM is "full" ?.
Why do you think your swap isn't being "used" ?.

How is any of this affecting your machines performance ?.

Hi all,

Thanks for the reply.

To dragonslayer48dx
Software : Linux Redhat 3 ( Taroon Update 7 )

HD partition :
/dev/sda
- sda1 102MB ext3
- sda2 2000MB linux-swap
- sda3 74214MB ext3
/dev/sdb
- sdb1 2000MB linux-swap
- sdb2 74316MB ext3
Note : The partition is auto partition during redhat installed with recovery disk.

To PWC101
swapon -s result is /proc/swaps file content ie.
Filename Type Size Used Priority
/dev/sdb1 partition 2048248 18760 -1
/dev/sda2 partition 2048276 0 -2

How to check whether the swap is on ?

To jomen
Did modify the fstab top portion before. It will cause all system cannot be boot up.
Only can recovered by new installation.

To syg00
Actually this workstation is used for test system.
During the program running. We open the info centre ( memory ) to do the monitoring.
We can notice the physical memory free space is slowly reduce from about 2G to 200M and then workstation hanged.
For the swap space memory. The usage is keep on 0%.
The testing speed is getting slower and slower ( from initial 20sec per test to 200sec per test ) and finally workstation hanged.



free
total used free shared buffers cached
Mem: 4095376 4011452 83924 0 48808 2469584
-/+ buffers/cache: 1493060 2602316
Swap: 4096524 0 4096524


/proc/swaps
Filename Type Size Used Priority
/dev/sdb1 partition 2048248 18760 -1
/dev/sda2 partition 2048276 0 -2


/etc/fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sdb1 swap swap defaults 0 0
/dev/sda2 swap swap defaults 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0

Your swap is active else you wouldn't see it via "swapon -s" - but it is only used for dirty anonymous (malloc'd) memory.
See if you can get these commands to run just before a hang, and post the output

Your RAM isn't "full" ... you have got almost 2.5GB
free (kind of) that Linux just uses to cache files.



Cheers,
Tink

You mean the lines pertaining to swap?
That _is_ stange then.
If an entry like
works for you, then an entry like
should work, too.
Sorry - but I highly doubt that.

The following is a simplified version of the true behavior, but explains the important issues:

Most pages in memory are unmodified copies of pages in files on disk, for example the executable code of whatever programs are running.

Many of those unmodified pages aren't even mapped into the address spaces of tasks, they are just cached because they were read fairly recently and might get read again.

When memory is "full", the system must free some pages. It tries to free pages that have not been used recently, but with some amount of bias toward freeing pages that are unmodified copies of pages on disk.

If it happens to decide to free a page that is not an unmodified copy of disk, it will need to write that page to swap space before really freeing it, and later will probably need to read it back from swap space.

If it decides to free an unmodified page, it can immediately free that page. If the page is needed in memory again later, the system can read the page again from wherever it is on disk.

Testing what?

I would need to see the output from free before and after a significant fraction of that reduction to reach any conclusions about what it means. The info you provided tells less than you think it tells.

Based on what you said so far, I would not guess anything is wrong with the swapping and I would not guess that the hang was caused by physical memory being full.

Zero swapping is probably a correct behavior under these conditions.

My guess at the leaking resource causing the problem is virtual memory, not physical memory. But without more info, that isn't more than guess and I don't know which virtual memory.

Is each test a whole run of the program start to exit? Or is it an operation within an already running program?

The second allows for very simple and common problems exhausting the virtual memory within that program. The first would require a much more drastic bug to exhaust any resource.

BTW, the info you displayed from free showing zero swap use was inconsistent with the info you displayed from other tools that showed minimal swap use. I assume that is not a symptom of any complicated issue, but just means you ran free under different conditions than the other tools.

Currently the workstation is temporary running other devices.
Already do a cron job to execute the code given for every 1 mins.
Will try to get the information once the workstation is available for debugging.


Is it mean that after the physical memory is full, it will start using cache files then swap space ?


This workstation is used for ATE ( Automatic test equipment ).
It's test wafers and IC chips.


The program ( test program )is never exist during test the IC chips.
The sequence of testing is Received IC chips --> start test --> end test --> change another chips --> start test --> end test... until finish testing all IC chips. then the program is existed.


Yes, you are correct. The "free" is ran during the program is half-way running ( approaching physical memory full ). Anyway, we are not able run the "free" when the workstation is hanged.

Well ... to find out what the memory status was at death
you could do something like this (assuming you've set-up
password-less ssh authentication for a user on the test
machine to some other Linux box):
And then watch how it goes.



Cheers,
Tink

The Linux kernel is pretty good at making guesses
what makes most sense in terms of using RAM efficiently.

Only when processes really need RAM it will take sensible
caching away. Chances are it will put some less used
code into swap before cache decreases. However, you will
not see an out of memory condition w/o having even touched
swap.



Cheers,
Tink

I now think you are running out of kernel virtual memory or some resource closely related to kernel virtual memory.

I don't know how to report on usage levels of those resources. Maybe someone else here does.

I don't think you are running out of user mode virtual memory, because you said the whole system is hung, you can't even use free.

I don't think you are running out of physical memory, because
was far short of half way to physical memory full even assuming the swapping system is broken and shows no evidence it is even on its way to physical memory full.
Plus, there is no hint (other than your unsupported guess) that anything is wrong with the swapping system. With 4GB of swap under the conditions you describe, the system would slow down gradually. There would be plenty of time to run free after the system was quite sick, but before the system was too hung to even run free.

So that leaves some kernel resource based on kernel virtual memory limits.