Hi All,
Not sure if I have landed in right place for this question :).
Problem Faced
I have 30-40 heavy load (Memory operations on heap) processor running with each having 30-40 threads. In one of the thread (of each process), I have file locking operation as explained below (say in thread T1)
Step 1 - Lock the file using fcntl(SETWLK) on file f1, Basically using wait lock.
Step 2 - Read/write data from another file f2.
Step 3 - unlock the file f1.
As the memory occupied by process increased, the swap area used will reduce - this continues for a long amount of period. When the free swap space is reduced to 100 MB free out of 2 G and VIRT reduces to 120MB free out of 17G, for T1 thread, Step 3 is not scheduled for more than 300 seconds after Step 1 and 2.
I want to understand why this behavior is present - as per my understanding scheduling will occur within micro-seconds and we can expect that the T1 thread of all process should be scheduled without too much delay.
Additional Infomation
Machine Info :
(uname -a), Linux linux 2.6.16.46-0.12-smp#1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 GNU/Linux
Memory Info :
Total Memory is 16GB + Swap Memory is 2GB
I want to know why this behavior is observed in SUSE.
Thanks for your help in advance.
Hi, welcome here.
You came to the right place, but, looking at your kernel version, with quite an old openSUSE release, 10.1 I suppose. Not many of us will be still running that, since it’s no longer supported. Hence I suspect you won’t get many reactions. If you’re working on some kind of development where you met this assumed issue, please post in the Programming/Scripting subforum.
On 06/13/2011 09:06 AM, kumar m kiran wrote:
>
> (uname -a), Linux linux 2.6.16.46-0.12-smp#1
is this SUSE Enterprise Linux Server (or Desktop) version 11?
–
dd
http://is.gd/bpoMD
kumar m kiran wrote:
> Not sure if I have landed in right place for this question :).
Quite. What does it have to do with install, boot or login? The
programming forum sounds more likely, or perhaps the applications or the
hardware. You haven’t given enough information to know.
> -Problem_Faced-
> I have 30-40 heavy load (Memory operations on heap) processor running
Do you mean processes rather than processors?
> with each having 30-40 threads. In one of the thread (of each process),
> I have file locking operation as explained below (say in thread T1)
>
> Step 1 - Lock the file using fcntl(SETWLK) on file f1, Basically using
> wait lock.
> Step 2 - Read/write data from another file f2.
> Step 3 - unlock the file f1.
>
> As the memory occupied by process increased, the swap area used will
> reduce - this continues for a long amount of period. When the free swap
> space is reduced to 100 MB free out of 2 G and VIRT reduces to 120MB
> free out of 17G, for T1 thread, Step 3 is not scheduled for more than
> 300 seconds after Step 1 and 2.
>
> I want to understand why this behavior is present - as per my
> understanding scheduling will occur within micro-seconds and we can
> expect that the T1 thread of all process should be scheduled without too
> much delay.
>
> -Additional Infomation-
> -Machine Info :-
> (uname -a), Linux linux 2.6.16.46-0.12-smp#1 SMP Thu May 17 14:00:09
> UTC 2007 x86_64 x86_64 GNU/Linux
>
> -Memory Info :-
> Total Memory is 16GB + Swap Memory is 2GB
Hmm, on first sight, this sounds simply like a normal symptom of running
out of virtual memory. I’d guess that the 300 seconds are taken up with
flushing the cached writes out to disk. You haven’t told us enough about
your system or the application to be able to say much. Nor have you told
us what you’ve done to investigate the problem.
It sounds like you’re overloading the system. Don’t load it so it has to
use swap - reduce the number of processes or threads, or add more
memory, or buy faster disks, or change the algorithm etc etc.
Or another possibility is what happens if you just add another few GB of
swap? Does that make it better or worse?
On 2011-06-13 09:06, kumar m kiran wrote:
> As the memory occupied by process increased, the swap area used will
> reduce - this continues for a long amount of period. When the free swap
> space is reduced to 100 MB free out of 2 G and VIRT reduces to 120MB
> free out of 17G, for T1 thread, Step 3 is not scheduled for more than
> 300 seconds after Step 1 and 2.
Not surprising. Increase swap.
Ask in the programming subforum
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)