Hi all,
Only few minutes after posting my question, I realized didn't ask what I
actually wanted to know.
First about atsar: AT Computing's System Activity Report. A
performance-analysis tool which has a similar structure as the standard
'sar'.For UNIX-versions with a native 'sar', the tool 'atsar' works in a
complementary way (by providing a.o. network-statistics).
For UNIX-versions without a native 'sar', the tool 'atsar' can be used for
all system-statistics (a.o. cpu, disk, memory, network).
Get atsar from:
ftp://www.atcomputing.nl/pub/tools/analysis
The reactions:
As I said, I didn't really ask what I wanted to know; the question might
seem a bit silly.
However, I could draw some conlusions from the reactions.
atsar's output is almost identical to the output of vmstat, swapon etcetera.
Regarding the output of atsar -r, the system _is_ using it's swapspace (I
made a stupid miscalculation about this 80% free: I guess this is the
correct value).
So... the system is swapping.
Assuming over 160MB (750-590) of in-use virtual memory, then that's below
the amount of phys.memory. What's left is probably being used to chache file
data in the UBC (probably so, see the high value / vmstat -P shows over
15,000 ubc pages ('managed pages break down')
Pages in the UBC are usually backed to pages in the file system that is they
are NOT 'process private' - they are waiting to be written back to files. As
such, they don't need space in the swap area (nor any space has to be
reserved).
So... The system is probably paging readonly pages from the files containing
the executables.
Regarding the 150K page-outs since uptime (less than 1 week at that
particular moment) the system needed anonymous memory for programs and there
wasn't enough real mem to do so. From this one might conclude that the
system needs more phys.memory.
About the swap mechanism; I already knew the answer: not wise to set swap to
lazy, unless the workload is VERY stable.
Because only a couple of these performance 'dips' occurred, I guess the
memory configuration is okay. Because of the high value of UBC I might have
to ask the developpers what it is that they're doing to the system...
Got reactions from: Jim Belonis, Selden Ball, Alan_at_nabeth.cxo.dec.com, John
Speno, Tom Blinn and M Selcukkaraca.
Thanks for your time!
regards,
Alex Harkema
(reactions are still welcome...)
-----Original Message-----
Hi admins,
I have a DS10 (EV6_at_463MHz) running Tru64 v4.0F.
There's 256MB phys. memory
750MB swap has been allocated. The swap mechanism is set to eager.
I saw a strange thing: atsar -r shows memory/swap usage:
# atsar -r
phy ubc free % swap free %
13:30:00 256.0M 145.4M 1.0M ( 0) 750.0M 590.9M ( 78) eager
13:35:00 256.0M 146.7M 1.4M ( 0) 750.0M 593.5M ( 79) eager
The system is almost out of phys. memory.
When in eager mode, the system reserves swapspace for each (modifyable) page
in memory, right? So, when there's only 1M left of the physical memory, why
is swap still at 80% available?
Why doesn't the system seem to start swapping when now I'm out of phys.
memory?
(vmstat/swapon show the same values as atsar)
btw: this is the vmstat output...
procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy
id
2 98 32 24K 140 6424 52M 12M 15M 2M 11M 151K 11 358 325 0 1
98
3 97 32 24K 128 6424 0 0 0 0 0 0 17 2K 344 5 1
94
2 98 32 24K 128 6424 252 13 218 0 12 0 13 9K 354 11 3
86
2 98 32 24K 128 6424 75 0 74 0 0 0 3 251 311 0 1
99
2 98 32 24K 128 6424 74 0 74 0 0 0 5 298 340 0 1
99
2 98 32 24K 128 6427 0 0 0 0 0 0 8 1K 327 7 1
91
2 98 32 24K 128 6427 151 0 150 0 0 0 3 249 317 0 1
99
any hints, ideas?
should swap be set to lazy?
Tia,
Alex Harkema
Received on Tue Apr 17 2001 - 13:53:12 NZST