top command
Mahmood
on SUN solaris8 , there are many users using the system from command
line,from last 3/4 months I have found that certain users are using the
"top" command extensively and mostly leave the "top" Command running
even for nights ( leaving the terminals open ),
I had removed the persmissions from /usr/bin/top to all users except
my own group using setfacl and also chown/chmod,
but now I have found that certain users have copied the /usr/local/top
binary with different names under their home directories, obviously
its too difficult to search for every binary in each users home when
the system is too large and tooo heavily utilized,
Is there any way to stop the "TOP" command , either it is run by any
other name.
I suppose that "top" binary executes some calls which can be blocked to
some users specifically.
Thanks in Advance.
Regards,
Moody
UNIX Administrator.
Thommy M.
http://developers.sun.com/solaris/articles/prstat.html
Hans
"Mahmood" <bus...@gmail.com> wrote in message
news:1141895388....@i40g2000cwc.googlegroups.com...
> hello there,
>
>
> on SUN solaris8 , there are many users using the system from command
> line,from last 3/4 months I have found that certain users are using the
> "top" command extensively and mostly leave the "top" Command running
> even for nights ( leaving the terminals open ),
>
> Is there any way to stop the "TOP" command , either it is run by any
> other name.
>
It is rather unusual for non technical people to be interested in the kind
of output that "top" supplies. Therefore, there may be a very good reason
for these guys to use it. Maybe they are developers or something.
Anyway - a better solution than raging a war against the users is perhaps to
communicate with the guys and try to work out a solution together. After
all, top can be configured to run at longer intervals and a specified number
of displays to generate less load. It may all be a matter of starting it
with different parameters etc.
Casper H.S. Dik
>Is there any way to stop the "TOP" command , either it is run by any
>other name.
No; the top command does not require privileges of any kind
and users could just download and compile it from source.
>I suppose that "top" binary executes some calls which can be blocked to
>some users specifically.
Nope. It just scans and reads /proc/*/psinfo files.
Is there any particular reason why you do not want this?
While top may accumulate some CPU use over time, it is generally
not excessive.
You could also just ban people from running top by telling them
that "running top (or prstat) is no longer allowed and disciplinary
action will be taken to those found running top".
In Solaris 10, you can prevent people from seeing other people's
processes which makes running top a lot less fun.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dexthor
platform are addicted to Top. We must appreciate opensource for putting
out tools like that.
Not thinking as a sysadmin, we must put ourselves in the shoes of the
developers or users who are sidelined by sysadmins. Being a sysadmin
myself for more than 11yrs, I realize we have to bring tools to the
users not restrict them. That is when they will find ways to work
around rules/limitations. As a sysadmin, I'd like the systems I support
better utilized by the applications and users !
Back to top. I agree with Casper, you can have a disclaimer on the
login motd which tells users what is acceptable and what is not. You
can then enforce mutually agreed upon policies. For example: logging
out tty-sessions of non-admin users if they are on the box after
business hours..
-Dexthor.
Daniel Rock
> You should tell your lusers to start using prstat instead...
> http://developers.sun.com/solaris/articles/prstat.html
For 98% of users and uses you won't notice a difference between the two.
I prefer the output layout of top over prstat.
Do you also call the users on your system "lusers" if they have other
preferences in the tools they use than you?
--
Daniel
Daniel Rock
> hello there,
>
>
> on SUN solaris8 , there are many users using the system from command
> line,from last 3/4 months I have found that certain users are using the
> "top" command extensively and mostly leave the "top" Command running
> even for nights ( leaving the terminals open ),
top isn't very CPU hungry. Per 1000 processes top requires per interval:
. ~0.08s (SPARC, 1.35 GHz)
. ~0.03s (Opteron, 2.2 GHz)
So with a default update interval of 5 seconds and 10000 processes on your
machine you would need over 100 top processes to hog one CPU.[1]
top doesn't require special privileges to be run. So instead of trying to
limit the users allowed to run top (they then will start to compile and
install their own - with THEIR preferred parameters) be nice to the
system AND the users:
- provide a system-wide top anyone can use
- compile top with an update interval of 5 seconds or longer
- build a wrapper around the real top which renices itself before starting
[1] in reality the calculation might be not that simple. I don't know if
accessing /proc scales linear.
--
Daniel
Jean-Louis Liagre
> Mahmood <bus...@gmail.com> wrote:
>> hello there,
>>
>>
>> on SUN solaris8 , there are many users using the system from command
>> line,from last 3/4 months I have found that certain users are using the
>> "top" command extensively and mostly leave the "top" Command running
>> even for nights ( leaving the terminals open ),
>
> top isn't very CPU hungry. Per 1000 processes top requires per interval:
> . ~0.08s (SPARC, 1.35 GHz)
> . ~0.03s (Opteron, 2.2 GHz)
> So with a default update interval of 5 seconds and 10000 processes on your
> machine you would need over 100 top processes to hog one CPU.[1]
>
quite different numbers here:
Daniel Rock
Hmm, what "different" numbers? I didn't compare top vs. prstat performance.
Above link also doesn't state which CPU the benchmarks have been run on.
For today's CPU I'd say: I don't care about top performance unless more than
20+ are being run at the same time.
For the record: On my system (Athlon64 2.2 GHz) I measured a total system
time of 52.7 ms for 11 updates and ~160 processes. This sums up to ~30ms per
1000 processes.
Compared to the system time the time top processes in user space is
neglebtible, so my above estimates are still valid.
And I didn't measure a huge performance gain with prstat. With the dtrace
scripts on this site I measured a system time of ~27ms per 1000 processes
for the same task with prstat.
--
Daniel
Mahmood
count them.
anyways I would surely appriciate any possile solution for that it
they are ..........
I am aware that it should be done with a compromise but whne It comes
to concerned level of high officials , then anyone may have to do the
necessary steps and we need to execute them on priority basis.
Jean-Louis Liagre
> Jean-Louis Liagre <jlli...@localhost.fr> wrote:
>> Daniel Rock wrote:
>>> Mahmood <bus...@gmail.com> wrote:
>>>> hello there,
>>>>
>>>>
>>>> on SUN solaris8 , there are many users using the system from command
>>>> line,from last 3/4 months I have found that certain users are using the
>>>> "top" command extensively and mostly leave the "top" Command running
>>>> even for nights ( leaving the terminals open ),
>>> top isn't very CPU hungry. Per 1000 processes top requires per interval:
>>> . ~0.08s (SPARC, 1.35 GHz)
>>> . ~0.03s (Opteron, 2.2 GHz)
>>> So with a default update interval of 5 seconds and 10000 processes on your
>>> machine you would need over 100 top processes to hog one CPU.[1]
>>>
>>> [...]
>> quite different numbers here:
>>
>> http://users.tpg.com.au/adsln4yb/DTrace/prstatvstop.html
>
> Hmm, what "different" numbers? I didn't compare top vs. prstat performance.
You measure 1% of CPU load with 1000 processes, this page shows 14% with 3000
processes.
> Above link also doesn't state which CPU the benchmarks have been run on.
It does, a 867 MHz i86pc.
> For today's CPU I'd say: I don't care about top performance unless more than
> 20+ are being run at the same time.
The OP is using Solaris 8 and is complaining about top overhead, I don't expect
him to have Solaris running on the latest CPUs.
> For the record: On my system (Athlon64 2.2 GHz) I measured a total system
> time of 52.7 ms for 11 updates and ~160 processes. This sums up to ~30ms per
> 1000 processes.
> Compared to the system time the time top processes in user space is
> neglebtible, so my above estimates are still valid.
>
> And I didn't measure a huge performance gain with prstat. With the dtrace
> scripts on this site I measured a system time of ~27ms per 1000 processes
> for the same task with prstat.
That's a 1% difference, the referenced page measure 33%.
I just compared top and prstat loads on my laptop and I have a 44% extra load
with top. Not negligible.
Thommy M.
> preferences in the tools they use than you?
Yes.
Daniel Rock
>> Hmm, what "different" numbers? I didn't compare top vs. prstat performance.
>
> You measure 1% of CPU load with 1000 processes, this page shows 14% with 3000
> processes.
What were the update intervals? The default update interval for top and
prstat are 5 seconds.
>> Above link also doesn't state which CPU the benchmarks have been run on.
>
> It does, a 867 MHz i86pc.
Ok, I overlooked that.
>> For the record: On my system (Athlon64 2.2 GHz) I measured a total system
>> time of 52.7 ms for 11 updates and ~160 processes. This sums up to ~30ms per
>> 1000 processes.
>> Compared to the system time the time top processes in user space is
>> neglebtible, so my above estimates are still valid.
>>
>> And I didn't measure a huge performance gain with prstat. With the dtrace
>> scripts on this site I measured a system time of ~27ms per 1000 processes
>> for the same task with prstat.
>
> That's a 1% difference, the referenced page measure 33%.
> I just compared top and prstat loads on my laptop and I have a 44% extra load
> with top. Not negligible.
Having a process using 1% or 1.5% of a CPU might be a big difference for the
process in question, but for overall system performance this difference can
be ignored.
Some additional notes:
(1) open/close overhead on MY machine is - compared to read/pread small
(measured with time.d from the web site you mentioned):
system call time with top (in nsec):
[...]
getdents 1094420
close 3129555
open 5422996
read 31918578
TOTAL: 43799647
dito, prstat:
doorfs 1068724
getdents 1098524
open 1198257
pread 32688812
TOTAL: 39272527
measured over 10 intervals. So top spends 10% more time in kernel than
prstat (44ms vs. 40ms)
(2) Performance measurements on a PrimePower 1500 (4x1350 MHz, SunOS 5.8)
all times measured with /usr/bin/timex:
prstat 1 10 (7000 procs)
real 11.17
user 0.43
sys 1.63
prstat 1 10 (7000 procs, 1024 descriptors)
real 12.61
user 0.58
sys 2.87
top (7000 procs):
real 12.47
user 0.55
sys 2.36
[top doesn't care how many descriptors are available]
With more processes the caching of opened /proc/<PID>/psinfo
might not work (more processes than open file descriptors)
If there are much more processes than avaible file descriptors
prstat performance becomes worse than top performance
(not unlikely on big iron with large number of processes and
users, so exactly the situation where performance degradation
might get perceivable, and here top suddenly performs better)
Other observation: top and prstat sleep between intervals exactly n
seconds, not (n-time processed) seconds, so top and prstat
give the system "time to breathe" between updates.
--
Daniel
Michael Laajanen
Why not make a wrapper for top which uses nice to run top!
Better maybe even to learn them to use prstat using a top wrapper that
starts prstat using nice and informing the users of the change to prstat.
Usually or maybe always when one tries to forbid people, they tend to do
the same thing but in a different way, better is to give the users what
the want in a controlled way like using nice, nobody will notice a
difference.
/michael
Thomas Schulz
I did some tests awhile back (I no longer have the exact numbers) with
top compiled with gcc and then Sun's cc. This was on an Untra 10. There
was a large difference. If you compile your own top (does Sun supply one
on Solaris 10?) and you compiled it with gcc, you would see a large reduction
in load if you could recompile it with Sun's cc.
--
Tom Schulz
sch...@adi.com
Daniel Rock
> I did some tests awhile back (I no longer have the exact numbers) with
> top compiled with gcc and then Sun's cc. This was on an Untra 10. There
> was a large difference. If you compile your own top (does Sun supply one
> on Solaris 10?) and you compiled it with gcc, you would see a large reduction
> in load if you could recompile it with Sun's cc.
Could be. But nowadays I don't think it really does matter. On current
machines (>= 1 GHz) top spends most of its time in kernel context
(30% - 95+%)
Maybe the user/system times were a little different when top used less
/proc and more /dev/kmem
On SPARC Sun's C compiler is a huge win compared to GCC. On x86 cc also is
faster than gcc most of the time, but the differences are much smaller.
This was my experience while benchmarking different programs, so YMMV.
Although I know prstat does exists and offers me more options over top
I still use top most of the time:
. I rarely need those fancy additional options
. Some output is bogus - like "prstat -J": the total memory used per project:
shared memory is counted multiple times. This gives ridiculous high
values if you are running Oracle on your server.
. I'm familiar with top's output and can parse it quickly.
esp. the prstat formatting of %CPU usage annoys me: the decimal point
should be always at the same column. But in prstat it vanishes if
%CPU is >10%
o compare prstat
42122 rock 1184K 968K cpu1 59 0 0:00:45 21% ksh/1
35264 root 12M 8328K sleep 59 0 6:48:01 0.3% Xvnc/1
^^^^
o to top
42122 rock 1 0 0 1184K 968K cpu/1 0:05 10.73% ksh
35264 root 1 53 0 12M 8328K sleep 408:00 0.37% Xvnc
. I like the first summary lines in top (esp. the phys/virt mem line)
--
Daniel
Darren Dunham
> I still use top most of the time:
> . I rarely need those fancy additional options
Best thing about prstat (for me) is 'psrstat -m'. Without that, both
'psrstat' and 'top' give the same CPU figure as 'ps'. It's a
time-weighted value that is slow to respond and doesn't ever match short
running processes.
'prstat -m' shows the value only over the last reporting interval. It'd
be great for top to do that.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Dave (from the UK)
> Daniel Rock <v20...@deadcafe.de> wrote:
>
>>I still use top most of the time:
>
>
>>. I rarely need those fancy additional options
>
>
> Best thing about prstat (for me) is 'psrstat -m'. Without that, both
> 'psrstat' and 'top' give the same CPU figure as 'ps'. It's a
> time-weighted value that is slow to respond and doesn't ever match short
> running processes.
>
> 'prstat -m' shows the value only over the last reporting interval. It'd
> be great for top to do that.
>
I guess you could hack the source!
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.
Gerry Sinkiewicz
How about buying each one of the users their own Solaris box?
If top is actually hurting performance, it would be in their best interest
to limit their own use of it.
Talk to them.
It would also be reasonable to kill any top session within a certain time
period, like off-shift/overnight.
Mahmood
I mentioned ealier that when the binary is copied with different names
to many differnt locations [ many of them were like "bottom", "my" and
same ] , I really dont have any idea how to STOP kinna "Top" command
wrapped inside a different name.
In Actual, I would reveal that I am chanllenged to get a solution to
this issue.
The system is [ solaris 8 , SUN-Fire 4800, 8CPU's SPARC-IV with 32 GB
of memory and around 4TB of SAN-Data ] , and any one can imagine that
the system is doing the ultra critical business tasks where every CPU
cycle is to be measuerd of accounting and performance.
Since when I am handed over these systems , I am given tasks much like
challenges to improve the system performance and security,
one of the issues with the systems is to avoide users from using TOP
command, I know the fraction of CPU being used by TOP command itself
and I know that I should be having sessions with users to HOW TO USE
the system, but again is there any way to stop those renamed "TOP"
commands,
think of the sytem with more than 90% of the CPU's being utilized [
purely for production] and that the system is really a matter of
concern for performance in terms of CPU usage and I can't argue my
Management for this.
Hope the guru will understand this..................
Regards,
Moody,
PTML
Dave (from the UK)
If you are the system admin, don't you have an "acceptable use policy",
or some other similar name? Surely talking to your users, asking why
they are running it so much, and then if necessary adding it to a policy
would be all it needs.
They may have copied top to bottom, so you could do an md5 checksum on
all files and find any with the md5 of top. But doing all that would
take a huge amount of cpu time, and would fail if they recompile it,
since the checksum is 99.9999% sure to change.
I'm puzzled how many users must be running it for this to impact
performance on that sort of system. How many hundreds or thousands of
copies are running? I am sure anything less than a few hundred copies
would be in the noise on a system with 8 CPUs.
Are you sure it is 'top' they have renamed, and not "doom" or something
like that!!
Dave (from the UK)
> I'm puzzled how many users must be running it for this to impact
> performance on that sort of system. How many hundreds or thousands of
> copies are running? I am sure anything less than a few hundred copies
> would be in the noise on a system with 8 CPUs.
>
> Are you sure it is 'top' they have renamed, and not "doom" or something
> like that!!
>
BTW, I've just set 200 copies of top running on my machine (Sun Ultra
80, 4 x 450 MHz UltraSPARC II), which is an antique compared to your
SUN-Fire 4800, 8CPU's SPARC-IV with 32 GB RAM.
'top' shows me I have 96.4% of the CPU time idle at the minute. So those
200 copies are not affecting this old thing at all really.
load averages: 0.25, 0.30, 0.25
13:52:25
286 processes: 118 sleeping, 167 stopped, 1 on cpu
CPU states: 96.4% idle, 1.8% user, 1.8% kernel, 0.0% iowait, 0.0% swap
Memory: 4096M real, 2769M free, 782M swap in use, 4371M swap free
PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
16778 drkirkby 3 59 0 170M 101M sleep 12:27 2.14% mozilla-bin
565 drkirkby 1 59 0 229M 111M sleep 278:54 0.81% Xsun
10176 drkirkby 2 59 0 92M 33M sleep 5:03 0.34%
gnome-terminal
844 drkirkby 21 49 0 232M 69M sleep 118:08 0.32% java
17257 drkirkby 1 49 0 3992K 1672K sleep 0:03 0.19% top
17475 drkirkby 1 59 0 3984K 1656K sleep 0:02 0.17% top
770 drkirkby 1 59 0 111M 19M sleep 51:52 0.13% metacity
17520 drkirkby 1 59 0 3984K 1664K cpu/1 0:00 0.09% top
836 drkirkby 1 49 0 71M 6056K sleep 15:51 0.03%
gnome-netstatus
808 drkirkby 1 49 0 113M 17M sleep 19:36 0.02% wnck-applet
gerryt@
Mahmood wrote:
> I mentioned ealier that when the binary is copied with different names
> to many differnt locations [ many of them were like "bottom", "my" and
> same ] , I really dont have any idea how to STOP kinna "Top" command
> wrapped inside a different name.
> In Actual, I would reveal that I am chanllenged to get a solution to
> this issue.
There is only one. Kick the offenders off.
> The system is [ solaris 8 , SUN-Fire 4800, 8CPU's SPARC-IV with 32 GB
> of memory and around 4TB of SAN-Data ] , and any one can imagine that
> the system is doing the ultra critical business tasks where every CPU
> cycle is to be measuerd of accounting and performance.
What critical business tasks?
> Since when I am handed over these systems , I am given tasks much like
> challenges to improve the system performance and security,
Sounds like you have a lot meetings to attend soon..
> one of the issues with the systems is to avoide users from using TOP
> command, I know the fraction of CPU being used by TOP command itself
> and I know that I should be having sessions with users to HOW TO USE
> the system, but again is there any way to stop those renamed "TOP"
> commands,
Not if they are being renamed. Best to remove all offending accounts
and change root password : > See below
> think of the sytem with more than 90% of the CPU's being utilized [
> purely for production] and that the system is really a matter of
> concern for performance in terms of CPU usage and I can't argue my
> Management for this.
It isnt a production system if "developers" have all kinds of free
access
to it. Generally you have admin accounts only -at most- on production
boxes. Sounds like you need a test box for the 'developers' to me.
Usually a dumbed down version of the production box for testing
is a reasonable approach. Another 6800 is no doubt out of budget but
you could substitute in what you think appropriate. Maybe a V440
or even a 420r. Good luck
Richard B. Gilbert
I think this is more a political/management issue than a technical
issue. Most shops severely restrict who is allowed to install software
on company systems. I would ask upper management for an edict to the
effect that anyone who installs unauthorized software will be
disciplined and that discipline may include termination of the
offender's employment. Then remove all copies of top from the system.
If management is not willing or not able to do this, then they must live
with the consequences!
Rich Teer
> If management is not willing or not able to do this, then they must live with
> the consequences!
Agreed. Further more, get management's wishes IN WRITING (email will do).
That way your ass is covered should it hit the fan.
But Gerry is also correct: developers shouldn't be logging into production
systems. They should have their owb development systems.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
ton...@hotmail.com
>systems. They should have their owb development systems.
This sounds great on paper, but how practical is it in real life? I
have never been in an environment where there are developers who do
nothing but "develop". They are usually DBAs and/or Application
oriented types that work on production issues as well as dev. Sooner
or later they are going to want to compare dev. with production; I
make similar comparisions as far as the OS is concerned, security,
backups, etc.
Jean-Louis Liagre
You can limit non production CPU usage with SRM.
Just give all these users a limited amount of CPU shares, and a large one to the
critical applications.
moody
the system is not intended to be open for any sort of developement, I
mean the world has some businneses as well and a thirdparty application
is already running on the system , the billing,
You guys are all correct and every reccomendation is perfectly nice,
specially all those who mentored me in the case of doing the needful.
I am about to get an upgrade of the entire system and personally I am
going to implement an RBAC on the system with a limited command set
available to the roles.
but this doesnot meant that I have made an end to my struggle against
such an issue, I would keep on trying to assess the issue , there must
be lying a solution and I am to find that out.
Very best regards to every one who responded to me and whoever.
Regards,
Moody
PTML