Hi Ed
I'm always interested in the whys and wheres....
I'm on z/VM 5.2 and my stack is 32MB (I did have to up it from the earlier
release).
However, my "res=" from indicate user, shows 1,313 pages used.
I do know about the 5 MB hit, due to LE. Which I thought was a hit to clients,
and not the stack.
I was wondering what your "res" usage was for your 64 MB machine?
Now that we have vswitch, TCPIP does quite a bit less here. Very seldom does
it pop up in the performance monitor <G>.
I'm really the only CMS user (and using TN3270).
But I have some 66 service machines, VSE guests and still some Linux guests
(that haven't been migrated over to the IFL), with the guests using TCP/IP (but
not the TCPIP stack).
Not that virtual storage costs much (anything), but what caused you to go to 64
MB?
Thanks
Tom Duerbusch
THD Consulting
(trying to head off a rude awaking if 32 MB isn't sufficient)
FELINE PHYSICS:
Law of Cat Inertia
A cat at rest will tend to remain at rest, unless acted upon by
some outside force - such as the opening of cat food, or a nearby
scurrying mouse.
>>> "Edward M. Martin" <[EMAIL PROTECTED]> 9/17/2007 3:33 PM >>>
Hello Mike,
I am working on upgrading to z/VM5.3 from z/VM 4.3. In the
process, I am reading lots of info.
The program directory indicates that with Host/domain name resolution
being performed by LE you need a minimum of
16m of virtual storage.
And for 5.3 most server machines will need 32 meg and probably
more.
I have our z/VM 4.3 TCPIP at 64m already.
Ed Martin
Aultman Health Foundation
330-588-4723
[EMAIL PROTECTED]
ext. 40441
________________________________
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Bodenstein
Sent: Monday, September 17, 2007 4:01 PM
To: [email protected]
Subject: Re: zVM 5.3 TCPIP memory problem
Mike,
Thanks for the information. I work with Jim and am also trying to
understand the differences in memory use of the z/VM 5.3 TCP/IP clients
compared to the z/VM 4.4 ones.
The web page you reference talks about C sockets library changes, but
says these were already present in z/VM 4.4. The difference we're
seeing is between 4.4 and 5.3. So does this apply? I also wonder
because we're seeing this with ftp and telnet, which aren't mentioned on
your web page as using the C socket library. (Do they?)
I've done some more testing, and find that the 5MB or so additional
memory use that we're seeing only happens when there is a DNS lookup
involved. So if I do "ftp cornellc.cit.cornell.edu" I see the
additional memory use, but if I do "ftp 132.236.98.12" I don't.
Similarly "ftp loopback" doesn't cause the additional memory use. I see
the same thing for lpr: lpr profile exec (p raw at
cornellc.cit.cornell.edu causes the additional memory use, while lpr
profile exec (p raw at 132.236.98.12 does not.
So what is there about DNS lookup that causes this memory use, while
otherwise the clients don't suck up virtual storage?
Thanks,
Mark Bodenstein ([EMAIL PROTECTED])
Cornell University
At 01:08 PM 9/14/2007, you wrote:
Jim,
There are several reasons for the increased use of virtual storage when
running
the TCP/IP functions and utilities. You can read about some of these at
http://www.vm.ibm.com/devpages/donovanm/zvmle.html
and specifically look at
http://www.vm.ibm.com/devpages/donovanm/zvmle.html#LEstor
The 5M "feechur" you mention is an unfortunate artifact of sockets being
defined
as POSIX file descriptors in the Byte File System client code. "Fixing"
this
involves a significant rewrite of a BFS client storage management and
will
most likely not happen any time soon.
Mike Donovan
---
zVM 5.3 TCPIP memory problem
I remember back in zVM 5.1 or 5.2 days seeing on the list that there
were memory problems or memory size issues. I probably didn't follow it
because I was using 4.4 and probably just thought it would be fixed.
Now I see that it wasn't fixed. I've just been told by IBM it's a
"feechur". I'm seeing it with the TCPIP clients, FTP and LPR. They
grab about 5M and don't release it. I didn't see it in putting the
release together because whoever runs the MAINT id in installation with
a small machine size.
Does anyone have any ideas or a solution or is that just the way it is?
Jim
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
