> It's not bad habit on Solaris. top is somewhat bad > habit when you have a lot of users on some system > using it in one time ;-) > > http://www.brendangregg.com/DTrace/prstatvstop.html
ISTR reading that "top" does what it does intentionally - so that it can handle more processes than the per-process file descriptor limit. (What's not said is that when the number of processes get high enough, "top" scales badly enough that being _potentially_ able to handle an arbitrary number of processes may not be worth as much as it sounds like.) Something else I saw in the link above, about "sync; sync; sync; reboot" being an "admin myth": back in v7 Unix, there wasn't really a reboot command, you just used some means outside the OS to break back to firmware (or more likely, a smart console, so that you could use your DECwriter rather than toggle switches). In that situation, where there is no "reboot" to flush and quiesce everything, one needed to: * stop all processes other than the single-user shell (and init) * sync * wait awhile, since sync only schedules flushing of buffers, but doesn't actually wait for it to complete * halt or reboot by whatever external means Three "sync"s were about as good as one sync and wait five seconds or so. So while it wasn't strictly necessary (one sync followed by a few seconds waiting and/or listening for the washing machine sided drives to stop thumping around, if the machine room wasn't too noisy to tell, would also have done the job), it was certainly better than sync immediately followed by whatever key sequence would escape from the OS. Nowadays however, where "reboot" is by default clean, I very much doubt it serves any useful purpose. So I wouldn't so much call it a myth as a poorly understood practice that survives in tradition long past its useful time. Although some might argue that many other sorts of myths have a similarly disconnected basis in fact, making my distinction a bit pointless... -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
