1 ## Welcome to the sysstat's Frequently Asked Questions!
5 **[1. General questions](#general)**
7 [1.1.](#1_1) When I compile sysstat, it fails with the following message: `make: msgfmt: Command not found`
8 [1.2.](#1_2) When I try to compile sysstat, it fails and says it cannot find some include files.
9 [1.3.](#1_3) I don't understand why sysstat displays the time sometimes as `HH:MM:SS` and sometimes as `HH:MM:SS AM/PM`...
11 **[2. Questions related to sar, sadc and sadf](#sar)**
13 [2.1.](#2_1) The sar command complains with the following message: `Invalid system activity file: ...`
14 [2.2.](#2_2) The sar command complains with the following message: `Cannot append data to that file (...)`
15 [2.3.](#2_3) The sar command complains with the following message: `Inconsistent input data`
16 [2.4.](#2_4) I get the following error message when I try to run sar: `Cannot open /var/log/sa/sa30: No such file or directory`
17 [2.5.](#2_5) Are sar daily data files fully compatible with Sun Solaris format sar files?
18 [2.6.](#2_6) The `Average:` results from the sar command are just rubbish...
19 [2.7.](#2_7) My database (e.g. MySQL) doesn't appear to understand the time zone displayed by 'sadf -d'...
20 [2.8.](#2_8) I tried to use options -s and -e with sadf. Unfortunately, I have nothing displayed at all / the output doesn't match that of sar.
21 [2.9.](#2_9) I cannot see all my disks when I use the sar -d command...
22 [2.10.](#2_10) Do you know a tool which can graphically plot the data collected by sar?
23 [2.11.](#2_11) When I launch sadc, I get the error message: `flock: Resource temporarily unavailable`
24 [2.12.](#2_12) How should I run sysstat / sar so that I get a reading for `00:00:00`?
25 [2.13.](#2_13) The sar command complains with the following message: `Requested activities not available in file ...`
26 [2.14.](#2_14) Does sar need a lot of resources to run?
27 [2.15.](#2_15) Are the measurements gathered by sadc cumulative or instantaneous?
28 [2.16.](#2_16) Some fields are always displayed as `0.00` when I use the `sar -d` command.
29 [2.17.](#2_17) The sar command complains with the following message: `Requested activities not available`
30 [2.18.](#2_18) How can I keep sar data for more than one month?
31 [2.19.](#2_19) How can I load sar data into an Oracle database for performance analysis and capacity planning?
32 [2.20.](#2_20) The sar command displays some weird output values...
33 [2.21.](#2_21) What happened to sar's options -h, -H, -x and -X?
34 [2.22.](#2_22) What is the exact meaning of the `count` parameter for sar and sadc?
35 [2.23.](#2_23) Why doesn't sar deal with sub-second sampling/monitoring?
36 [2.24.](#2_24) Is it possible to make sadc save only some specific activities in my binary daily data files?
37 [2.25.](#2_25) The sar and/or sadf command complain(s) with the following message: `End of system activity file unexpected`
39 **[3. Questions related to iostat](#iostat)**
41 [3.1.](#3_1) I can't see all my disks when I use the iostat command...
42 [3.2.](#3_2) iostat -x doesn't report disk I/O statistics...
43 [3.3.](#3_3) Why can't iostat display extended statistics for partitions with 2.6.x kernels?
44 [3.4.](#3_4) I don't understand the output of iostat. It doesn't match what I expect it to be...
45 [3.5.](#3_5) Why values displayed by iostat are so different in the first report from those displayed in subsequent ones?
46 [3.6.](#3_6) iostat -x displays huge numbers for some fields...
48 **[4. Questions related to pidstat](#pidstat)**
50 [4.1.](#4_1) pidstat -d doesn't report task I/O statistics...
51 [4.2.](#4_2) The pidstat command complains with the following message: `Requested activities not available`
52 [4.3.](#4_3) pidstat doesn't display statistics for process (task) _xyz_...
53 [4.4.](#4_4) I noticed that the total CPU utilization for threads running on an individual CPU can exceed 100%...
57 ### 1. General questions<a name="general"></a>
59 1.1.<a name="1_1"></a> When I compile sysstat, it fails with the following message:
61 make: msgfmt: Command not found
62 make: ***[locales] Error 127
64 A: The **msgfmt** command belongs to the GNU gettext package.
65 If you don't have it on your system, just configure sysstat with NLS disabled like this:
67 $ ./configure --disable-nls
69 or answer 'y' (for "yes") to the question
71 Disable National Language Support (NLS)? (y/n) [--disable-nls]
73 if you use the Interactive Configuration script (_iconfig_),
74 then compile sysstat as usual (make ; make install).
76 Please read the _README-nls_ file included in sysstat source package to learn
77 some more about National Language Support.
80 1.2.<a name="1_2"></a> When I try to compile sysstat, it fails and says it cannot find some include files:
82 In file included from /usr/include/bits/errno.h:25,
83 from /usr/include/errno.h:36,
85 /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory
87 common.c: In function `get_kb_shift':
88 common.c:180: `PAGE_SIZE' undeclared (first use in this function)
89 common.c:178: warning: `size' might be used uninitialized in this function
90 make: *** [common.o] Error 1
92 A: Make sure that you have the Linux kernel sources installed in
93 `/usr/src/linux`. Also make sure that the symbolic link exists in the
94 `/usr/src/linux/include` directory and points to the right architecture, e.g.:
96 # ll /usr/src/linux/include/asm
97 lrwxrwxrwx 1 root root 8 May 5 18:31 /usr/src/linux/include/asm -> asm-i386
99 In fact, only the Linux kernel headers should be necessary to be able to compile sysstat.
102 1.3.<a name="1_3"></a> I don't understand why sysstat displays the time sometimes as `HH:MM:SS` and sometimes as `HH:MM:SS AM/PM`...
104 A: The time format used by sysstat tools depends on the locale of your system.
105 The locale is defined by several environment variables, among which the **LANG**
106 variable is perhaps the most widely used. See the following example:
110 Linux 2.4.9 (brooks.seringas.fr) 07/20/04
112 04:32:11 PM LINUX RESTART
114 05:00:00 PM CPU %user %nice %system %iowait %idle
115 05:10:00 PM all 0.24 0.00 89.64 0.00 10.12
116 Average: all 0.24 0.00 89.64 0.00 10.12
120 Linux 2.4.9 (brooks.seringas.fr) 20.07.2004
122 16:32:11 LINUX RESTART
124 17:00:00 CPU %user %nice %system %iowait %idle
125 17:10:00 all 0,24 0,00 89,64 0,00 10,12
126 Moyenne: all 0,24 0,00 89,64 0,00 10,12
128 As you can notice, the time format but also the date, the decimal point, and
129 even some words (like "Average") have changed according to the specified locale.
132 ### 2. Questions related to sar, sadc and sadf<a name="sar"></a>
134 2.1.<a name="2_1"></a> The sar command complains with the following message:
136 Invalid system activity file: ...
138 A: You are trying to use a file which is not a system activity file, or whose
139 format is no longer compatible with that of files created by current version of sar.
140 If you were trying to use the standard system activity files located in the
141 `/var/log/sa` directory then the solution is easy: just log in as root and
142 remove by hand all the files located in the `/var/log/sa` directory:
144 # rm /var/log/sa/sa??
146 If you are using sysstat 11.1.1 and later, you can also use the sadf command
147 to convert an old system activity binary datafile (version 9.1.6 and later) to
148 current up-to-date format. Use the following syntax:
150 $ sadf -c old_datafile > new_datafile
152 Note: Starting with sysstat version 8.1.1 and later, it is possible to
153 know which version of sar or sadc has been used to create a data file.
154 Just enter the following command:
156 $ sadf -H /your/datafile | grep sysstat
157 File created using sar/sadc from sysstat version 8.1.7
161 2.2.<a name="2_2"></a> The sar command complains with the following message:
163 Cannot append data to that file (...)
165 A: The internal structure of the data file does not allow sar to append
166 data to it. The data file may come from another machine, or the components
167 of the current box, such as the number of processors, may have changed.
168 Use another data file, or delete the current daily data file, and try again.
169 With sysstat version 10.1.3 and later, it is now possible to append data
170 to a data file even if the number of processors has changed. But first,
171 you have to make the data file aware of this change by inserting a restart
172 mark (this is typically done when sadc is called at system restart). You
173 can then append data to the data file as usual.
176 2.3.<a name="2_3"></a> The sar command complains with the following message:
178 Inconsistent input data
180 A: This error message means that sadc (the system activity data collector that
181 sar is using) is not consistent with the sar command. In most cases this is
182 because the sar and sadc commands do not belong to the same release of the
183 sysstat package. Remember that sar may search for sadc in predefined
184 directories (`/usr/local/lib/sa`, `/usr/lib/sa`, ...) before looking in the
186 With sysstat version 11.1.5 and later, enter `sar --sadc`
187 to determine which data collector is called by sar.
190 2.4.<a name="2_4"></a> I get the following error message when I try to run sar:
192 Cannot open /var/log/sa/sa30: No such file or directory
194 A: Please read the sar(1) manual page! Daily data files are created by default
195 in the `/var/log/sa` directory using the data collector (sadc) or using
196 option -o with sar. Once they are created, sar can display statistics
197 saved in those files.
198 But sar can also display statistics collected "on the fly": Just enter
199 the proper options on the command line to indicate which statistics are
200 to be displayed, and also specify `interval` and `count` numbers, e.g.:
202 # sar 2 5 --> will report CPU utilization every two seconds, five times.
203 # sar -n DEV 3 --> will report network device utilization every 3 seconds, in an infinite loop.
207 2.5.<a name="2_5"></a> Are sar daily data files fully compatible with Sun Solaris format
211 A: No, the format of the binary data files created by sysstat's sar command
212 is not compatible with formats from other Unixes, because it contains
213 data which are closely linked to Linux.
214 For the same reason, sysstat cannot work on platforms other than Linux...
217 2.6.<a name="2_6"></a> The `Average:` results from the sar command are just rubbish, e.g.:
219 11:00:00 AM CPU %user %nice %system %idle
220 11:10:00 AM all 0.54 0.00 0.89 98.57
221 11:20:01 AM all 3.02 8.05 22.85 66.08
222 11:30:01 AM all 8.15 0.00 2.31 89.54
223 11:40:01 AM all 8.03 0.00 2.42 89.55
224 11:50:01 AM all 16.04 0.00 2.81 81.16
225 12:00:00 PM all 21.11 0.00 3.23 75.66
226 03:40:01 PM all 100.01 100.01 100.01 0.00
227 04:40:00 PM all 100.00 0.00 100.00 0.00
228 04:50:00 PM all 5.87 0.00 1.26 92.87
229 05:00:00 PM all 4.70 0.00 1.48 93.82
230 05:10:00 PM all 4.93 0.00 1.29 93.78
231 Average: all 100.22 100.20 100.13 0.00
233 A: Your sar command was not installed properly. Whenever your computer
234 is restarted (as it is the case here between `12:00:00 PM` and `03:40:01 PM`),
235 the `sysstat` shell script must be called by the system, so that the
236 LINUX RESTART message can be inserted into the daily data file, indicating
237 that the relevant kernel counters have been reinitialized...
238 You can install the `sysstat` script by hand in the relevant startup
239 directory, or you can ask sysstat to do it for you during configuration
242 $ ./configure --enable-install-cron
244 Or you can answer 'y' to the question:
246 Set crontab to start sar automatically? (y/n) [--enable-install-cron]
248 if you use the Interactive Configuration script (iconfig).
249 Then compile sysstat as usual and run 'make install' as the last stage.
252 2.7.<a name="2_7"></a> My database (e.g. MySQL) doesn't appear to understand the time zone
253 displayed by 'sadf -d'...
256 A: The format includes the timezone detail in the output. This is to make
257 sure it is communicated clearly that UTC is how the data is always
258 converted and printed. Moreover we don't depend on the TZ environment
259 variable and we don't have some data converted to a different timezone
260 for any reason, known or unknown.
261 When you deal with raw accounting data you always want it in UTC.
262 Of course, you want it to all be the same when loading into a database.
263 If your database can't deal with timezones, you should write a short script
264 to strip the "UTC" characters from the data being loaded into the database.
267 2.8.<a name="2_8"></a> I tried to use options -s and -e with sadf. Unfortunately, I have
268 nothing displayed at all / the output doesn't match that of sar.
271 A: The way how options -s and -e are interpreted has changed with sysstat's
273 First if you don't have any data displayed by sadf, this is because no data
274 belong to the specified time interval! Up to sysstat version 12.1.4, the
275 time specified with options -s and -e was always considered as being given
276 in local time to be consistent with sar's default output. Yet sadf displays
277 its timestamps in UTC (Coordinated Universal Time) by default (and in local
278 time with option -T). This could lead to some misunderstandings, as if sadf's
279 options -s and -e didn't work properly.
280 So with sysstat version 12.1.5, the time specified with options -s and -e
281 is now consistent with the timestamps displayed by sadf (either in UTC by
282 default or in local time with option -T), even if the output doesn't match
286 2.9.<a name="2_9"></a> I cannot see all my disks when I use the sar -d command...
289 A: See question "I can't see all my disks when I use the iostat command" below.
292 2.10.<a name="2_10"></a> Do you know a tool which can graphically plot the data collected by sar?
295 A: You can now draw graphs with sysstat's standard tools!
296 SVG (Scalable Vector Graphics) is a new output format that has been added to
297 sadf in sysstat version 11.3.1. Read sadf(1) manual page to learn some more
298 about this new format.
299 There are other tools lying around on the internet that you can use to draw
300 some graphs. I haven't tested all of them and there must still be some
301 way for improvement... First, some of them are included in the sysstat
302 package although they are no longer maintained: isag (a Perl script) or
303 sargraph (a shell script).
304 You can also find: kSar (a Java application capable of visualizing a sar file
305 with static graphs), sarjitsu (a more sophisticated application producing
306 dynamic visualizations based on Grafana), sarvant, sar2gp, loadgraph,
307 SysStat Charts, sarplot...
308 [rrd.cgi](http://haroon.sis.utoronto.ca/rrd/scripts/) is a perl front-end for
309 rrdtool and can be used to make some graphs (see a demo [here](http://haroon.sis.utoronto.ca/perl/rrd.cgi/sar_stats/)).
310 [sysstat_mail_report](https://github.com/desbma/sysstat_mail_report) is a script
311 that automatically generates and sends an email report every day/week/month
312 with graphs generated from sysstat data.
313 I've also heard of commercial tools which use sysstat: PerfMan comes to mind,
317 2.11.<a name="2_11"></a> When I launch sadc, I get the error message:
319 flock: Resource temporarily unavailable
321 A: You are launching sadc using -L option. With this option, sadc tries to
322 get an exclusive lock on the output file. The above error message indicates
323 that another sadc process was running and had already locked the same output
324 file. Stop all sadc instances and try again.
327 2.12.<a name="2_12"></a> I have sysstat setup to run via cron:
329 0 * * * * /usr/local/lib/sa/sa1 600 6
331 so that I get an activity report every 10 minutes.
332 When I use sar to get my output, there is no reading for `00:00:00`. This
333 means that at midnight every night there is a spike, or dip, in the graphs.
334 How should I run sysstat / sar so that I get a reading for `00:00:00`?
337 A: Sysstat does get its data at midnight, but two data samples are needed to
339 When there is a "file rotation" (beginning of a new day), sadc writes its data
340 at the end of the previous daily data file (`/var/log/sa/sa<DD>`) **and** at the
341 beginning of the new one (`/var/log/sa/sa<DD+1>`). Please note that '-' must be
342 used to specify the output file for sadc to be able to detect such a file
343 rotation. So a crontab like the following one should enable you to get the
344 data for midnight at the end of each daily data file:
346 # Activity reports every 10 minutes from 01:00:00 to 22:50:00
347 0 1-22 * * * /usr/local/lib/sa/sa1 600 6
348 # Activity reports every 10 minutes from 23:00:00 to 00:00:00
349 # Reporting until 00:00:00 ensures that a file rotation will be detected
351 0 23 * * * /usr/local/lib/sa/sa1 600 7
352 # Activity reports every 10 minutes from 00:10:00 to 00:50:00
353 10 0 * * * /usr/local/lib/sa/sa1 600 5
355 Another possible crontab would be:
357 */10 1-22 * * * /usr/lib/sa/sa1 1 1
358 0,10,20,30,40 23 * * * /usr/lib/sa/sa1 1 1
359 50 23 * * * /usr/lib/sa/sa1 600 2
360 10,20,30,40,50 0 * * * /usr/lib/sa/sa1 1 1
362 Things are much easier with recent sysstat versions (12.5.1 and later): You simply have to run
363 sa1 with its option `--rotate` shortly after midnight to add a statistics record to the system
364 activity daily data file of the previous day. So your full crontab could be:
366 # Rotate file at midnight
367 0 0 * * * /usr/lib/sa/sa1 --rotate
368 # Run system activity accounting tool every 10 minutes
369 0,10,20,30,40,50 * * * * /usr/lib/sa/sa1 1 1
370 # Generate a text summary of previous day process accounting at 00:07
371 7 0 * * * /usr/lib/sa/sa2 -A
375 2.13.<a name="2_13"></a> The sar command complains with the following message:
377 Requested activities not available in file ...
379 A: This error message means that you are trying to extract non-existent activities
380 from the data file. Usually sadc reads all the available activities from the
381 system and stores them in the data file. However, to prevent data files from
382 taking too much space on disk, some activities must be explicitly set on the
383 command line to be read by sadc.
384 To tell sadc that an optional activity should be collected, use switch -S
385 followed by the keyword corresponding to that activity (see sadc(8) manual page).
386 As of this writing, optional activities are: interrupts, disks, SNMP, IPv6 and
387 power management statistics.
388 IMPORTANT NOTE: The list of activities that are saved in a file can no longer
389 be modified once the file has been created. So it is important to use the proper
390 options the first time sadc is called (whether via a crontab, a script like
391 sa1 or even the script used to insert a RESTART message when the machine is
393 NB: If the sar command complains with the error message:
395 Requested activities not available
397 (without mentioning `in file`), then see question 2.17 below.
400 2.14.<a name="2_14"></a> Does sar need a lot of resources to run?
403 A: No, sar doesn't need a lot of CPU to run, nor does it make your system slow,
404 contrary to what some people think. In the first place, it only runs every ten
405 minutes by default. Secondly, when it does run, it is over and done very
408 $ time /usr/lib/sa/sa1
410 to verify that for yourself.
411 Nor do you have to be concerned about using up all your disk space.
412 sar will use a few hundred kilobytes for a whole day's worth of data, and it
413 normally only stores one week worth (this can be configured via the HISTORY
414 variable in the `/etc/sysconfig/sysstat` file). It is entirely self limiting.
415 Moreover, you can ask sar to compress its datafiles older than a certain
416 number of days: see the COMPRESSAFTER parameter in the `/etc/sysconfig/sysstat`
420 2.15.<a name="2_15"></a> Are the measurements gathered by sadc cumulative or instantaneous values?
423 A: Each counter maintained by the kernel is cumulative since system boot. As a
424 consequence the measurements gathered by sadc are cumulative values.
425 Moreover all per-second statistics displayed by sar are average values on the
426 given time interval. So the value for counter foo at time T is calculated as:
428 foo/s = [foo(T) - foo(T-dt)] / dt
430 where dt is the interval given on the command line.
433 2.16.<a name="2_16"></a> Some fields are always displayed as 0.00 when I use the sar -d
437 A: See question 3.2 below.
440 2.17.<a name="2_17"></a> The sar command complains with the following message:
442 Requested activities not available
444 A: This error message means that you are trying to display activities that the
445 kernel itself is unable to provide.
446 When this error message is displayed while trying to save the data into an
447 existing file (`sar -o datafile ...`), this may also be because the target
448 file cannot accept the requested activities. In this case, just try to use
449 another file or create a new one. See also question 2.13 above.
452 2.18.<a name="2_18"></a> How can I keep sar data for more than one month?
455 A: By default sar saves its data in the standard system activity data file,
456 the `/var/log/sa/saDD` file, where DD is the current day in the month.
457 To prevent sar from overwriting any existing files, just set the variable
458 HISTORY in `/etc/sysconfig/sysstat` to the number of days during which data
459 must be kept. When this variable has a value greater than 28, sa1 script
460 uses a month-by-month directory structure; datafiles are named `YYYYMM/saDD`
461 and the script maintains links to these datafiles to mimic the standard
462 sar datafile structure. However please note that pre-existing datafiles
463 will be deleted as links will be created and replace them.
464 Beginning with sysstat version 11.0.0, this tree of directories is no
465 longer created. When HISTORY has a value greater than 28, sa1 now calls
466 sadc with option -D set, telling it to use `saYYYYMMDD` instead of `saDD`
467 as the name for the standard system activity daily data files, where
468 YYYY stands for the current year, MM for the current month and DD for
469 the current day. All these files are saved in the same directory
470 (`/var/log/sa` by default).
473 2.19.<a name="2_19"></a> How can I load sar data into an Oracle database for performance
474 analysis and capacity planning?
477 A: The simplest way for that is to use sadf (a command included in sysstat
478 package) with its option -d. It displays sar data in a format that can
479 easily be ingested by a relational database system (fields are separated
480 by a semicolon). It should then be easy for a tool like SQL*Loader to
481 load the data into the Oracle database.
484 2.20.<a name="2_20"></a> The sar command displays some weird CPU values, e.g.:
486 10:50:01 AM CPU %user %nice %system %iowait %idle
487 11:00:01 AM all 90.90 0.00 5.17 3.93 0.00
488 11:00:01 AM 0 39.40 0.00 2.37 2.07 56.17
489 11:00:01 AM 1 29.71 0.00 1.73 1.17 67.39
490 11:00:01 AM 2 42.69 0.00 2.34 1.11 53.85
491 11:00:01 AM 3 26.24 0.00 1.41 1.61 70.74
494 A: Sysstat may have met an overflow condition while reading CPU usage from
495 your /proc/stat file. This condition is all the more likely to happen as
496 your machine uptime is high and/or there are many processors.
497 Sysstat up to version 5.0.6 uses 32-bit integer variables to store CPU usage.
498 Then, beginning with version 5.1.1, sysstat has shifted to 64-bit variables,
499 which has fixed the problem. So try to upgrade your version of sysstat to
500 the latest stable release and check that the problem has gone.
501 Also see question 2.6 above.
504 2.21.<a name="2_21"></a> What happened to sar's options -h, -H, -x and -X?
507 A: These old options have been removed from sar because new commands have been
508 made available. You should now use the sadf command instead of sar -h or
509 sar -H, and the pidstat command instead of sar -x or sar -X. Please read
510 their manual page to learn some more about their respective options.
513 2.22.<a name="2_22"></a> What is the exact meaning of the `count` parameter for sar and sadc?
516 A: For sadc, `count` is the number of data samples collected.
517 For sar, `count` is the number of records to display (a record contains
518 the average values for counters over the given time interval - See 2.15).
521 Starting with an empty file `datafile`:
523 sadc datafile 1 6 will write 6 data samples to datafile.
524 sar -f datafile 1 6 6 is invalid because there are only 5 intervals.
526 Based on the `count` value entered for sadc the "valid" `count` values for
527 sar are 1 through 5. Any value greater than 5 for sar will give the
528 same output as 5 in this example. So entering `sar -f datafile 1 2000`
529 for a file populated with the output of `sadc 1 6 datafile` will give the
530 same output as `sar -f datafile 1 5`. Note that it all depends on the number
531 of data samples pre-existing in the data file. If the file is empty
532 when first running sadc then the above is true.
535 2.23.<a name="2_23"></a> Why doesn't sar deal with sub-second sampling/monitoring?
538 A: There are two reasons for sar to not handle sub-second intervals:
541 1) This is not sar's purpose. sar has been created to give the
542 sys admin a global overview of its machine daily utilization so
543 that when a problem happens, he has a benchmark and can compare
544 the statistics gathered by sar with those saved before. For that
545 reason an interval of 10 minutes (which is the default for sar) is
549 2) Because this is just a dumb idea to try to gather a huge amount
550 of data on a sub-second interval basis (and sar really collects
551 a lot of data). This can be resource-consuming and you are all the
552 more prone to have an influence on the data you are retrieving as
553 the interval of time is small.
556 2.24.<a name="2_24"></a> Is it possible to make sadc save only some specific activities
557 in my binary daily data files?
560 A: sadc's option -S followed by one or more keywords (DISK, SNMP...)
561 can already be used to specify which optional activities are to be
562 collected. Without this option, sadc collects a default set of
563 activities (CPU activity, memory activity, network activity, etc.)
564 Yet it is actually possible to specify explicitly which activities
565 should be collected by sadc! You have to use sadc's option -S
566 followed by the report name corresponding to the activity you want
567 to collect (enter "sar --help" to know the formal report names
569 Example: To tell sadc to collect only temperature sensors activity
570 in addition to the default set of activities, enter:
573 sadc -S A_PWR_TEMP (...)
576 followed by the other classic options (interval, count, filename...)
577 Now assume you want to collect temperature sensors activity **without**
578 the other activities collected by default,
579 add the special report name A_NULL to the list passed to sadc, e.g.:
581 sadc -S A_NULL,A_PWR_TEMP (...)
583 Of course you can enter as many report names as you want to collect
584 different activities.
585 Last you can exclude a specific activity from a list by prefixing its
586 report name with a dash. For example, to collect all possible activities
587 **except** statistics for interrupts, enter:
589 sadc -S XALL,-A_IRQ (...)
591 This way you can tell sadc to collect only the desired activities.
594 2.25.<a name="2_25"></a> The sar and/or sadf command complain(s) with the following message:
596 End of system activity file unexpected
598 A: sadc, the data collector, was unable to write all its data to the
599 system activity data file (`/var/log/sa/saDD` by default).
600 This is probably because there was no space left on the device where
601 the data file is located.
602 Make sure there is enough free space on the device. Sometimes it seems
603 there is enough free space but there may be some jobs run by crontab
604 (particularly during the night) that can temporarily consume all of
605 your free space, making sadc fail.
607 Another reason could be linked to the system activity daily data file
608 being corrupted. This could possibly happen when several instances of
609 sadc are trying to update the same data file, especially around midnight
610 when making a file rotation. See question 2.12 to know how to make such
611 a file rotation properly.
613 Last this issue can also be triggered when the system is rebooted forcibly
614 without data in cache being written to disk. You can use switch -f with sadc
615 to make sure data are written to disk immediately. Of course sync'ing each
616 data sample to disk implies a (probably slight) performance penalty.
619 ### 3. Questions related to iostat<a name="iostat"></a>
621 3.1.<a name="3_1"></a> I can't see all my disks when I use the iostat command...
624 A: Yes. This is a kernel limit. Old kernels (2.2.x for instance) used to
625 maintain stats for the first four devices.
626 The accounting code has changed in 2.4 kernels, and the result may (or
627 may not) be better for your system. Indeed, Linux 2.4 maintains the stats
628 in a two dimensional array, with a maximum of 16 devices (DK_MAX_DISK
629 in the kernel sources). Moreover, if the device major number exceeds
630 DK_MAX_MAJOR (whose value also defaults to 16 in the kernel sources),
631 then stats for this device will not be collected.
632 So, a solution may be simply to change the values of these limits in
633 linux/include/linux/kernel_stat.h and recompile your kernel.
634 You should no longer have any problem with post 2.5 kernels, since
635 statistics are maintained by the kernel for all the devices.
636 In the particular case of iostat, also be sure to use the ALL keyword
637 on the command line to display statistical information relating to
638 every device, including those that are defined but have never been used
642 3.2.<a name="3_2"></a> iostat -x doesn't report disk I/O statistics...
645 A: For `iostat -x` to be able to report extended disk I/O statistics,
646 it is better to use a recent version of the Linux kernel (2.6.x).
647 Indeed, iostat tries to read data from the `/proc/diskstats` file or
648 from the sysfs filesystem for that.
649 But iostat may also be able to display extended statistics with
650 older kernels (e.g. 2.4.x) providing that all the necessary
651 statistical information is available in the /proc/partitions file,
652 which requires that a patch be applied to the kernel (this is
653 often done on kernels included in various distros). In recent 2.4.x
654 kernels, the /proc/partitions file has all the necessary data
655 providing that the kernel has been compiled with CONFIG_BLK_STATS=y.
658 3.3.<a name="3_3"></a> Why can't iostat display extended statistics for partitions with
662 A: Because the kernel maintains these stats only for devices, and not for
663 partitions! Here is an excerpt from the document iostats.txt included in
664 the kernel source documentation:
666 There were significant changes between 2.4 and 2.6 in the I/O subsystem.
667 As a result, some statistic information disappeared. The translation from
668 a disk address relative to a partition to the disk address relative to
669 the host disk happens much earlier. All merges and timings now happen
670 at the disk level rather than at both the disk and partition level as
671 in 2.4. Consequently, you'll see a different statistics output on 2.6 for
672 partitions from that for disks.
674 Extended I/O statistics for partitions are available again with kernels
678 3.4.<a name="3_4"></a> I don't understand the output of iostat. It doesn't match what I expect it
682 A: By default iostat displays I/O activity in blocks per second. With old
683 kernels (i.e. older than 2.4.x) a block is of indeterminate size and therefore
684 the displayed values are not useful.
685 With recent kernels (kernels 2.4 and later), iostat is now able to get disk
686 activities from the kernel expressed in a number of sectors. If you take a
687 look at the kernel code, the sector size is actually allowed to vary although
688 I have never seen anything other than 512 bytes.
691 3.5.<a name="3_5"></a> Why values displayed by iostat are so different in the first report
692 from those displayed in subsequent ones?
695 A: Probably because, as written in the manual page, the first report generated
696 by iostat concerns the time since system startup, whereas subsequent ones
697 cover only the time since the previous report (that is to say, the interval
698 of time entered on the command line).
701 3.6.<a name="3_6"></a> iostat -x displays huge numbers for some fields...
704 A: Because of a Linux kernel bug, iostat -x may display huge I/O response times
705 (svctm) and a bandwidth utilization (%util) of 100% for some devices. Indeed
706 these devices have a value for the field #9 (beginning after the device name)
707 in `/proc/{partitions,diskstats}` which is always different from 0, and even
708 negative sometimes. Yet this field should go to zero, since it gives the
709 number of I/Os currently in progress (it is incremented as requests are
710 submitted, and decremented as they finish).
711 To (temporarily) fix the problem, you should reboot your system to reset the
712 counters in `/proc/{partitions,diskstats}`.
715 ### 4. Questions related to pidstat<a name="pidstat"></a>
717 4.1.<a name="4_1"></a> pidstat -d doesn't report task I/O statistics...
720 A: For pidstat -d to be able to report I/O statistics for tasks, you need
721 a recent Linux kernel (2.6.20 or later) with the option
722 CONFIG_TASK_IO_ACCOUNTING compiled in.
725 4.2.<a name="4_2"></a> The pidstat command complains with the following message:
727 Requested activities not available
729 A: This message is displayed when the pidstat command is unable to display
730 the statistics you have requested. This may happen when you try to display
731 statistics for child processes (option -T CHILD) because all options of
732 pidstat don't necessarily work for child processes. Read the manual page
733 to know which statistics are available for child processes.
736 4.3.<a name="4_3"></a> pidstat doesn't display statistics for process (task) _xyz_...
739 A: This must be because pidstat only displays statistics for active tasks
740 by default. If you don't use option -p on the command line, then pidstat
741 will display only tasks with non-zero statistics. For example, `pidstat -u`
742 will display only tasks that have actually used some CPU resources since
743 system startup. You should enter `pidstat -u -p ALL` to make sure that all
744 the processes are listed in the report.
747 4.4.<a name="4_4"></a> I noticed that the total CPU utilization for threads running on
748 an individual CPU can exceed 100%...
751 A: The CPU number displayed by pidstat is the CPU to which the task is attached
752 when the statistics are actually displayed. This doesn't mean that the task
753 has spent its whole interval of time attached to it. Hence the CPU ressource
754 used by a thread on an interval of time as displayed by pidstat may have
755 concerned several processors.
758 Sebastien Godard (sysstat at orange dot fr) is the author and the current
759 maintainer of this package.