← Back to branch summary

~ubuntu-branches/ubuntu/saucy/sysstat/saucy-proposed

« back to all changes in this revision

Viewing changes to FAQ

  • Committer: Package Import Robot
  • Author(s): Robert Luberda
  • Date: 2012-03-13 22:59:04 UTC
  • mfrom: (1.2.13)
  • Revision ID: package-import@ubuntu.com-20120313225904-s1npspja1ipyfi0l
Tags: 10.0.4-1
* New upstream (stable) version.
* Update build-dependencies on debhelper.
* Standards-Version: 3.9.3 (no changes).

Show diffs side-by-side

added added

removed removed

Lines of Context:
FAQ
53
53
2.21. The sar command displays some weird output values...
54
54
2.22. What happened to sar's options -h, -H, -x and -X?
55
55
2.23. What is the exact meaning of the <count> parameter for sar and sadc?
 
56
2.24. Why doesn't sar deal with sub-second sampling/monitoring?
56
57
 
57
58
3. QUESTIONS RELATING TO IOSTAT
58
59
 
72
73
4.2. The pidstat command complains with the following message:
73
74
      "Requested activities not available".
74
75
4.3. pidstat doesn't display statistics for process (task) xyz...
 
76
4.4. I noticed that the total CPU utilization for threads running on
 
77
     an individual CPU can exceed 100%...
75
78
 
76
79
 
77
80
1. GENERAL QUESTIONS
532
535
of data samples pre-existing in the data file. If the file is empty
533
536
when first running sadc then the above is true.
534
537
 
 
538
~~
 
539
 
 
540
2.24. Why doesn't sar deal with sub-second sampling/monitoring?
 
541
 
 
542
There are two reasons for sar to not handle sub-second intervals:
 
543
 
 
544
1) This is not sar's purpose. sar has been created to give the
 
545
sys admin a global overview of its machine daily utilization so
 
546
that when a problem happens, he has a benchmark and can compare
 
547
the statistics gathered by sar with those saved before. For that
 
548
reason an interval of 10 minutes (which is the default for sar) is
 
549
quite appropriate.
 
550
 
 
551
2) Because this is just a dumb idea to try to gather a huge amount
 
552
of data on a sub-second interval basis (and sar really collects
 
553
a lot of data). This can be resource-consuming and you are all the
 
554
more prone to have an influence on the data you are retrieving as
 
555
the interval of time is small.
 
556
 
 
557
 
535
558
3. QUESTIONS RELATING TO IOSTAT
536
559
###############################
537
560
 
658
681
system startup. You should enter "pidstat -u -p ALL" to make sure that all
659
682
the processes are listed in the report.
660
683
 
 
684
~~~
 
685
 
 
686
4.4. I noticed that the total CPU utilization for threads running on
 
687
     an individual CPU can exceed 100%...
 
688
 
 
689
The CPU number displayed by pidstat is the CPU to which the task is attached
 
690
when the statistics are actually displayed. This doesn't mean that the task
 
691
has spent its whole interval of time attached to it. Hence the CPU ressource
 
692
used by a thread on an interval of time as displayed by pidstat may have
 
693
concerned several processors.
 
694
 
661
695
--      
662
696
Sebastien Godard (sysstat <at> orange.fr) is the author and the current
663
697
maintainer of this package.