On Thu, 21 Apr 2005, Marc Lehmann wrote:
> On Thu, Apr 21, 2005 at 11:29:38AM +0200, Dag Wieers <[EMAIL PROTECTED]>
> wrote:
> > I can repeat this, but it's more like within the first miliseconds.
>
> Fast system with no activity :) On my dual-P3 1Ghz dstat usually needs
> around 4 seconds to start up. On my dual 600mhz p3 machine it can take up
> to 10 seconds.
Ouch, blame python :) I'm wondering if your system might slow down dstat
this badly that the job scheduling can't guarantee a near 1 second
interval. Could you try the following:
Go to the time plugin (dstat_time) and uncomment the following 2
lines:
### Nice for debugging timer
# self.format = '%13.3f'
# self.len = 14
And then use dstat -t <options>. On my system it results in:
[EMAIL PROTECTED] dstat]# ./dstat -ta
-----time----- ----total-cpu-usage---- -disk/total -net/total- ---paging--
---system-- ---load-avg---
____epoch_____|usr sys idl wai hiq siq|_read write|_recv _send|__in_
_out_|_int_ _csw_|_1m_ _5m_ 15m_
1114086817.075| 5 4 87 4 0 0| 0 0 | 0 0 | 0 0 | 0
0 |0.12 0.06 0.08
1114086818.070| 1 3 96 0 0 0| 0 0 | 0 0 | 0 0 |1053
906 |0.11 0.06 0.08
1114086819.071| 1 3 96 0 0 0| 0 0 | 0 0 | 0 0 |1082
844 |0.11 0.06 0.08
1114086820.072| 1 4 95 0 0 0| 0 0 | 0 0 | 0 0 |1061
885 |0.11 0.06 0.08
1114086821.073| 1 3 96 0 0 0| 0 0 | 0 0 | 0 0 |1082
814 |0.11 0.06 0.08
So you see a 1ms deviation per second. (about 1sec deviation after 17mins)
Now try the same when enabling the following lines:
### Increase precision if we're root (does not seem to have effect)
# if os.geteuid() == 0:
# os.nice(-20)
# sys.setcheckinterval(op.delay / 10000)
And let me know if this makes a difference for you. On all occasions it
never made a real difference for me. (ie. you may want to try this both as
root as well as a user and maybe disable the if statement)
> > I'm not sure if the proper thing to do is to import the python modules
> > within my try-block.
>
> I have no idea, either, but the proper thing to do would be not to display
> any tracebacks or anything. My biggest grief with many python programs
> (bittorrent for example) is that they love to output tracebacks without
> exiting when ^INT :)
I understand, but the code becomes more ugly :/ (ie. I have to indent a
complete block + subblocks of code...). But if it can take up to 10secs,
you're absolutely right. I'm going to look into speeding up dstat (or
slowing down my system and profiling statements, I bet some modules take
a long time and may not be necessary all the time).
> I guess the best thing is to only catching INT before initscr, as before
> there is no reaosn even to catch the signal, because catching it only adds
> time before the user gets back at his/her prompt (there is nothing to
> cleanup), although I suspect that it can't be done with python.
It can be done. But it still requires me to import the signal module :)
> > I noticed eg. that yum only imports sys before importing everything else
> > in a try-block. Which reduces the chance of being hit by this.
>
> The important thing is that it can be reproduced.
>
> However, despite me bashing on this, it really is a very very minor issue
> :)
I understand. But details matter to me too (and there are no major
problems currently). I hate tracebacks too (when there's no problem).
-- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
