LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/24/88)
We are having a debate here, and I thought it may be a good idea to ask the wizards: What resources are tied up by an "idle" user process? Idle as in: running DCL, but the user doesn't enter any command for hours. My thoughts are that such a process is not harmfull or even wastefull. The minimum amount of memory alloted to the process will be swapped out sooner or later, and in times of large memories that doesn't matter much anyhow. Essentially everyone has a terminal in his office, so blocking the terminal is not an issue either. On the other hand, logging in every two or three hours just to do one or two commands uses a lot of resources for process creation and running all the login files. Question: Am I right or am I wrong ? If if I'm right, what is the point in having a program to forcibly terminat idle processes ?? An idle process uses some amount of physical memory even if swapped out - after all, information needed to swap it back in has to be available! - but on any modern system the memory involved is insignificant. The disk space needed for the swap files will also increase, but again that's not likely to be a major factor: A process sitting idle at a DCL prompt typically uses less than 400 pages, so you'd need a LOT of idle processes to make much of a dent on modern disks. About the only significant resource-related cost of having many swapped-out idle processes is that imposed by display programs that use GETJPI to read information that can only be obtained by swapping the process in. VMS will proceed to swap them in, causing a lot of overhead. (Note that SHOW SYSTEM deliberately avoids looking closely at swapped out processes, for just this reason. I think typical FINGER programs may cause an in-swap to read the image name, though I may be wrong about this.) The main argument for idle process killers is security: If people get into the habit of leaving their terminals logged in and walking away, in many environments you will eventually have security problems. Whether that's an issue in your environment, and whether the correct solution is an idle process killer or user education (plus perhaps a program to "lock" a terminal) is something only you can answer. Another argument for such killers is made at sites that used poorly-designed database manipulation programs. It is possible for a user to begin a trans- action, thus locking a record, then go away for a long time, leaving the record locked. Killing the program will free the record. Of course, if the program involved is poor enough that it doesn't force an idle transaction to complete by itself, it is probably poor enough that killing it will ruin the integrity of the database. Personally, I hate "idle" process killers. I have a large LOGIN.COM file that creates an extensive personal environment, and I'd rather not have to keep re-building it. I especially hate "idle" process killers that are eager but not too clever; that is, those that incorrectly classify as "idle" processes that, say, have a "kept editor" holding some context - like a file being edited - that will be destroyed when the process is killed. -- Jerry