|
Is the Web worldwide, or what?Last month's cover story draws fire. Plus: Jim Mauro and Adrian Cockcroft offer technical advice on swap space and memory, kernal locks, and "doors" |
Mail this article to a friend |
Worldwide impact
Amy,
I'm wondering who the intended audience of this article is, possibly some U.S. funding body? It is interesting that you chose to emphasize that the Internet has changed how Americans live and do business. I think by doing so you have undersold the impact of the Internet. I think the Internet has changed how the world lives and does business. I doubt it's what you intended, but I'm afraid that by playing up the U.S. impact you've belittled the actual achievement.
Donald McLachlan
Don,
Your point about how the Internet has changed how the world lives and
does business is well taken. However, the impact of the Internet was just an
underlying theme to support an article that is specifically intended to
clarify the components of two commonly misunderstood American
initiatives -- Internet2 and Next Generation Internet. While both of
these initiatives have written into their objectives collaboration
outside the U.S. (and, in fact, Internet2 has signed a formal MOU with the
Canadian CANARIE project), they are still solidly intended to first
impart change upon the U.S.
The Internet has revolutionized the global economy, culture, and society,
and many issues of Internet maintenance and research extend across U.S.
boundaries. I in no way meant to represent the Internet as a U.S.
project, or to undersell its importance. I only hoped to clarify for the
reading audience what these two initiatives, Internet2 and Next Generation
Internet, are and are not.
Amy Finley
What is this "door"?
Jim,
You've covered a lot of different file types quite well. And it's pretty obvious what the socket file type is, but what is this door? I've found two doors (.name_service_door, and .syslog_door) floating around in the /etc directory, and am rather curious about them. What exactly are they used for, and how do you create one?
Trevor
Trevor,
Doors are a very recent addition to Solaris. Simply put, doors are a
new IPC (interprocess communication) mechanism that evolved out of
an operating system known as Spring, or SpringOS. SpringOS was
a research project out of Sun Labs, and we tend to see
technology from such research pushed down over time into Sun's
standard Solaris release.
Doors provide a means of doing RPC-like
calls across processes running on the same system. A thread running
in a process can issue a door call that results in a thread in
another process executing a routine on behalf of the calling
process. A return is done to the caller with appropriate status
information.
Processes export routines by using the door_create(3X)
routine. Other processes may then issue door_call(3X) calls to make
a call to the exported routine.
For interprocess communication that does not involve passing data,
doors have proven to be much faster than traditional IPC mechanisms
(e.g. semaphores, pipes, etc.).
Currently, only two areas in Solaris implement doors --
the syslog daemon and the name service cache. The two files you
mentioned are part of the syslog and name service
implementations, and are used to synchronize door activity within
those two subsystems.
If you wish to learn more about doors, reference the man pages (section 3X)
on the various door interfaces. I will be doing a column on doors
down the road, but it's probably a couple months away.
Jim Mauro
Locked out in user land
Jim,
Occasionally, a file will get a kernel lock that is unbreakable -- whether due to some bug in lockd (most likely I should think) or some other cause I do not know. This happens most often with an NFS mounted mail spool, where files are locked and unlocked frequently and repeatedly.
Is there an easy way to free a kernel lock? One option appears to be to access the kernel file table directly and reset the flags. I'm a quick study on kernel stuff, but need to know what ioctl to start with to gain access to this table, flags, and relevant man pages if available.
Doug
Doug,
The lockd daemon exists to support file locking on NFS mounted
files. When an NFS client issues a fcntl(2) or lockf(3)
call to lock all or some portion of a file on an NFS mounted file system, the
lockd will forward the request to the NFS server so the actual file
lock operation can be performed.
I'm quite sure you're aware of what I stated above, but I did so to
illustrate that lockd deals with user-level locks, not kernel
locks. By user-level locks, I mean locks that are available to the
user/programmer. Kernel locks, such as mutex (mutual exclusion)
locks, are not available or even seen by user level code. Thus, if
your theory about an issue with kernel locks is correct, there's
nothing you can do from user land to clear the lock. There are no
ioctl(2) calls available that will give you entry into the kernel such
that you can extract kernel lock information and change lock state.
I suppose it would be possible to use a kernel debugger in write
mode, locate the file descriptor in the file table, and clear the
kernel locks. There is one kernel mutex in the file structure,
f_tlock, used to protect the various fields in the file structure.
There are other kernel locks used in the underlying file support
structures (vnode and inode) also, so clearing a file-related lock at
the file structure level without working down the hierarchy could
leave things in an inconsistent state. Unfortunately, I have never
attempted such a thing, and realistically will not have sufficient
time to try it in the next couple of months.
Jim Mauro
Let's have a look at those EJBs
Jason,
I am glad to see such a lucid presentation of architectural issues in SunWorld. Most IT shops need all the help they can get with this -- the new most important issue that developers face.
A look at Enterprise JavaBeans and the architectural issues involved in their creation and use might be interesting.
Great job!
Carlos Valcarcel
Memory leak
Adrian,
I'm trying to prove a requirement that our software uses no more than 75 percent of available physical RAM and 75 percent of virtual memory. The approach to proving the physical RAM requirement has been to allocate 25 percent of the physical RAM size in shared memory regions and SHM_LOCK them in. A strange result has been observed when doing this: The allocated RAM as reported by swap -s increases by the shared memory size, but the available RAM decreases by twice as much.
For example, on my Ultra-1 I have 128 megabytes of RAM. Initially swap -s reports:
total: 51368k bytes allocated + 14296k reserved = 65664k used, 284104k available
I then allocate 32 shm regions each 1 megabyte in size and check it again:
total: 84288k bytes allocated + 14296k reserved = 98584k used, 251440k available
The used count increases by 32 megabytes, and the available count decreases by 32 megabytes.
Now I SHM_LOCK each of the regions and check it once more:
total: 84896k bytes allocated + 14304k reserved = 99200k used, 218152k available
Now the available count has decreased by another 32 megabytes, but all else is roughly the same. Why?
I observe similar results when mlocking process memory.
Christopher Felaco
Christopher,
Available swap space equals available disk space plus available RAM.
When you lock the RAM, it is no longer available as swap, so your
available swap goes down.
The swap system is very confusing, and the instrumentation and
terminology is also inconsistent.
Swap on Solaris is more like virtual memory on a Macintosh or
Windows system. If you can't run in RAM, add some swap disk. The
total is the total of RAM plus disk. RAM that is locked down for some
other purpose is not counted. (This is known as availrmem in
Solaris).
Adrian Cockcroft
Adrian has covered swap space and memory in several past
Performance Q&A columns. If you want to brush up, check out our
archives
--Editor
|
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-05-1998/swol-05-letters.html
Last modified: