Dana, Our [UD] production environment has 37 phantoms running at once doing some heavy duty processing.
All have sleep statements of varying lengths. Several phantom programs have multiple copies running simultaneously. Each program checks a unique control item (the phantom's process pid is in the control item's id) prior to servicing its queue & will stop if the control item exists, so shutting down the phantoms is not a problem. CPU usage during phantom 'idle' periods is very low. Having a phantom start a phantom without manual intervention is something we don't do. The phantoms are re-started as part of the SA's Unidata startup script. If phantom execution is critical, consider running more than one at once, with coding to prevent them from stepping on each other. Hope this helps. Tom Cordes PS - thanks to all involved in the new list server. Awesome! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 4:06 PM To: [EMAIL PROTECTED] Subject: RE: [U2] PHANTOM forever > On Behalf Of Dana Baron > Sent: Monday, May 03, 2004 2:59 PM > To: U2-Users > Subject: RE: [U2] PHANTOM forever > > I have a Unidata Basic program (called MESSAGE_LOOP) that needs to > constantly check for messages deposited into a particular > directory. It is > an endless loop that checks for messages, processes any it > finds, sleeps for > a second, then does it again. I need to start this process up > and leave it > running forever. I found the nohup command on Tru64 that > executes a script > with the following line. > > udt PHANTOM MESSAGE_LOOP & > > Works fine for starting up the job. The problem is that the > job now gobbles > up 80% of the CPU. How can I reduce this process's hunger for > CPU so that it > can share nicely with others? Should I set the priority lower > or should I > increase the sleep time inside the program? > Increasing the sleep time is probably your best bet, but here are some suggestions that may help, if you can implement them. 1. Change the directory to a hashed file. Processing directories is significantly slower than hashed files, particularly with whole file queries such as SELECT and LIST. This would only be easy to do if the messages are being written by a UniData process. 2. Use PAUSE instead of SLEEP. PAUSE by works similarly to SLEEP, with two exceptions. The first exception is that the PAUSEd process can be awakened early by another process via the WAKE command. This means that the process writing the message could WAKE the phantom to tell it to process, therefore the PAUSE time could be very large and the phantom would only do work when needed. (The unix gurus out there know that SLEEP can also be awakened via a kill command, but that is a different beast.) The second exception is that the time of the PAUSE is not as exact as SLEEP. The time is rounded up to the next 10 second interval. This is because PAUSEs are handled by the cleanupd daemon instead of a system alarm, and cleanupd checks the pause list at intervals. The default interval is 10 seconds, but it can be changed by changing the startup command for cleanupd in the startud script. We changed ours to 3 seconds. The fact that the time is rounded up a few seconds has very little impact here because most of our paused processes are awakened before the time limit or the time limit is not critical. We have over a dozen phantom processes that are always running in the background, doing things similar to your process. Most of them are using PAUSE/WAKE, or are sleeping for 30 second intervals. HTH, Dean ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users
