1PCPINTRO(1) General Commands Manual PCPINTRO(1)
2
6 PCPIntro - introduction to the Performance Co-Pilot (PCP)
7
9 The Performance Co-Pilot (PCP) is an SGI toolkit designed for monitor‐
10 ing and managing system-level performance. These services are distrib‐
11 uted and scalable to accommodate the most complex system configurations
12 and performance problems.
13 PCP supports many different platforms, including (but not limited to)
15 Linux, MacOSX, IRIX, AIX, Solaris and Windows. From a high-level PCP
16 can be considered to contain two classes of software utility:
17 PCP Collectors
19 These are the parts of PCP that collect and extract performance
20 data from various sources, e.g. the Linux /proc pseudo filesys‐
21 tem. These are available under GPL/LPGL from
22 http://oss.sgi.com/projects/pcp.
23 PCP Monitors
25 These are the parts of PCP that display data collected from
26 hosts (or archives) that have the PCP Collector installed.
27 Many monitor tools are available as part of PCP under GPL/LPGL
28 from http://oss.sgi.com/projects/pcp. Other (typically graphi‐
29 cal) monitoring tools are available separately in the PCP GUI
30 package.
31 This manual entry describes the high-level features and options common
33 to most PCP utilities available on all platforms.
34
36 The PCP architecture is distributed in the sense that any PCP tool may
37 be executing remotely. On the host (or hosts) being monitored, each
38 domain of performance metrics, whether the kernel, a service layer, a
39 database management system, a web server, an application, etc.
40 requires a Performance Metrics Domain Agent (PMDA) which is responsible
41 for collecting performance measurements from that domain. All PMDAs
42 are controlled by the Performance Metrics Collector Daemon (pmcd(1)) on
43 the same host.
44 Client applications (the monitoring tools) connect to pmcd(1), which
46 acts as a router for requests, by forwarding requests to the appropri‐
47 ate PMDA and returning the responses to the clients. Clients may also
48 access performance data from a PCP archive (created using pmlogger(1))
49 for retrospective analysis.
50 The following performance monitoring applications are primarily console
52 based, are typically run directly from the command line, and are all
53 part of the base PCP package.
54 Each tool or command is documented completely in its own reference
56 page.
57 pmstat Outputs an ASCII high-level summary of system performance.
59 pmie An inference engine that can evaluate predicate-action rules to
61 perform alarms and automate system management tasks.
62 pminfo Interrogate specific performance metrics and the meta data that
64 describes them.
65 pmlogger
67 Generates PCP archives of performance metrics suitable for
68 replay by most PCP tools.
69 pmval Simple periodic reporting for some or all instances of a perfor‐
71 mance metric, with optional VCR time control.
72 If the PCP GUI package is installed then the following additional tools
74 are available.
75 pmchart
77 Displays trends over time of arbitrarily selected performance
78 metrics from one or more hosts.
79 pmtime Time control utility for coordinating the time between multiple
81 tools (including pmchart and pmval).
82 pmdumptext
84 Produce ASCII reports for arbitrary combinations of performance
85 metrics.
86
88 There is a set of common command line arguments that are used consis‐
89 tently by most PCP tools.
90 -a archive
92 Performance metric information is retrospectively retrieved from
93 the Performance Co-Pilot (PCP) archive, previously generated by
94 pmlogger(1). The -a and -h options are mutually exclusive.
95 -a archive[,archive,...]
97 An alternate form of -a for applications that are able to handle
98 multiple archives.
99 -h hostname
101 Unless directed to another host by the -h option, or to an ar‐
102 chive by the -a option, the source of performance metrics will
103 be the Performance Metrics Collector Daemon (PMCD) on the local
104 host. The -a and -h options are mutually exclusive.
105 -n pmnsfile
107 Normally the distributed Performance Metrics Name Space (PMNS)
108 is used, however if the -n option is specified an alternative
109 local PMNS is loaded from the file pmnsfile.
110 -s samples
112 The argument samples defines the number of samples to be
113 retrieved and reported. If samples is 0 or -s is not specified,
114 the application will sample and report continuously (in real
115 time mode) or until the end of the PCP archive (in archive
116 mode).
117 -z Change the reporting timezone to the local timezone at the host
119 that is the source of the performance metrics, as identified via
120 either the -h or -a options.
121 -Z timezone
123 By default, applications report the time of day according to the
124 local timezone on the system where the application is executed.
125 The -Z option changes the timezone to timezone in the format of
126 the environment variable TZ as described in environ(5).
127
129 Most PCP tools operate with periodic sampling or reporting, and the -t
130 and -A options may be used to control the duration of the sample inter‐
131 val and the alignment of the sample times.
132 -t interval
134 Set the update or reporting interval.
135 The interval argument is specified as a sequence of one or more
137 elements of the form
138 number[units]
139 where number is an integer or floating point constant (parsed
140 using strtod(3C)) and the optional units is one of: seconds,
141 second, secs, sec, s, minutes, minute, mins, min, m, hours,
142 hour, h, days, day and d. If the unit is empty, second is
143 assumed.
144 In addition, the upper case (or mixed case) version of any of
146 the above is also acceptable.
147 Spaces anywhere in the interval are ignored, so 4 days 6 hours
149 30 minutes, 4day6hour30min, 4d6h30m and 4d6.5h are all equiva‐
150 lent.
151 Multiple specifications are additive, e.g. ``1hour 15mins
153 30secs'' is interpreted as 3600+900+30 seconds.
154 -A align
156 By default samples are not necessarily aligned on any natural
157 unit of time. The -A option may be used to force the initial
158 sample to be aligned on the boundary of a natural time unit.
159 For example -A 1sec, -A 30min and -A 1hour specify alignment on
160 whole seconds, half and whole hours respectively.
161 The align argument follows the syntax for an interval argument
163 described above for the -t option.
164 Note that alignment occurs by advancing the time as required,
166 and that -A acts as a modifier to advance both the start of the
167 time window (see the next section) and the origin time (if the
168 -O option is specified).
169
171 Many PCP tools are designed to operate in some time window of interest,
172 e.g. to define a termination time for real-time monitoring or to define
173 a start and end time within a PCP archive log.
174 In the absence of the -O and -A options to specify an initial sample
176 time origin and time alignment (see above), the PCP application will
177 retrieve the first sample at the start of the time window.
178 The following options may be used to specify a time window of interest.
180 -S starttime
182 By default the time window commences immediately in real-time
183 mode, or coincides with time at the start of the PCP archive log
184 in archive mode. The -S option may be used to specify a later
185 time for the start of the time window.
186 The starttime parameter may be given in one of three forms
188 (interval is the same as for the -t option as described above,
189 ctime is described below):
190 interval
192 To specify an offset from the current time (in real-time
193 mode) or the beginning of a PCP archive (in archive mode)
194 simply specify the interval of time as the argument. For
195 example -S 30min will set the start of the time window to
196 be exactly 30 minutes from now in real-time mode, or
197 exactly 30 minutes from the start of a PCP archive.
198 -interval
200 To specify an offset from the end of a PCP archive log,
201 prefix the interval argument with a minus sign. In this
202 case, the start of the time window precedes the time at
203 the end of archive by the given interval. For example -S
204 -1hour will set the start of the time window to be
205 exactly one hour before the time of the last sample in a
206 PCP archive log.
207 @ctime To specify the calendar date and time (local time in the
209 reporting timezone) for the start of the time window, use
210 the ctime(3C) syntax preceded by an at sign. For example
211 -S '@ Mon Mar 4 13:07:47 1996'
212 -T endtime
214 By default the end of the time window is unbounded (in real-time
215 mode) or aligned with the time at the end of a PCP archive log
216 (in archive mode). The -T option may be used to specify an ear‐
217 lier time for the end of the time window.
218 The endtime parameter may be given in one of three forms (inter‐
220 val is the same as for the -t option as described above, ctime
221 is described below):
222 interval
224 To specify an offset from the start of the time window
225 simply use the interval of time as the argument. For
226 example -T 2h30m will set the end of the time window to
227 be 2 hours and 30 minutes after the start of the time
228 window.
229 -interval
231 To specify an offset back from the time at the end of a
232 PCP archive log, prefix the interval argument with a
233 minus sign. For example -T -90m will set the end of the
234 time window to be 90 minutes before the time of the last
235 sample in a PCP archive log.
236 @ctime To specify the calendar date and time (local time in the
238 reporting timezone) for the end of the time window, use
239 the ctime(3C) syntax preceded by an at sign. For example
240 -T '@ Mon Mar 4 13:07:47 1996'
241 -O origin
243 By default samples are fetched from the start of the time window
244 (see description of -S option) to the end of the time window
245 (see description of -T option). The -O option allows the speci‐
246 fication of an origin within the time window to be used as the
247 initial sample time. This is useful for interactive use of a
248 PCP tool with the pmtime(1) VCR replay facility.
249 The origin argument accepted by -O conforms to the same syntax
251 and semantics as the starttime argument for the -T option.
252 For example -O -0 specifies that the initial position should be
254 at the end of the time window; this is most useful when wishing
255 to replay ``backwards'' within the time window.
256 The ctime argument for the -O, -S and -T options is based upon the cal‐
258 endar date and time format of ctime(3C), but may be a fully specified
259 time string like Mon Mar 4 13:07:47 1996 or a partially specified time
260 like Mar 4 1996, Mar 4, Mar, 13:07:50 or 13:08.
261 For any missing low order fields, the default value of 0 is assumed for
263 hours, minutes and seconds, 1 for day of the month and Jan for months.
264 Hence, the following are equivalent: -S '@ Mar 1996' and -S '@ Mar 1
265 00:00:00 1996'.
266 If any high order fields are missing, they are filled in by starting
268 with the year, month and day from the current time (real-time mode) or
269 the time at the beginning of the PCP archive log (archive mode) and
270 advancing the time until it matches the fields that are specified. So,
271 for example if the time window starts by default at ``Mon Mar 4
272 13:07:47 1996'', then -S @13:10 corresponds to 13:10:00 on Mon Mar 4,
273 1996, while -S @10:00 corresponds to 10:00:00 on Tue Mar 5, 1996 (note
274 this is the following day).
275 For greater precision than afforded by ctime(3C), the seconds component
277 may be a floating point number.
278 Also the 12 hour clock (am/pm notation) is supported, so for example
280 13:07 and 1:07 pm are equivalent.
281
283 The number of performance metric names supported by PCP in IRIX is of
284 the order of a few thousand. There are fewer metrics on Linux, but
285 still a considerable number. The PCP libraries and applications use an
286 internal identification scheme that unambiguously associates a single
287 integer with each known performance metric. This integer is known as
288 the Performance Metric Identifier, or PMID. Although not a require‐
289 ment, PMIDs tend to have global consistency across all systems, so a
290 particular performance metric usually has the same PMID.
291 For all users and most applications, direct use of the PMIDs would be
293 inappropriate (e.g. this would limit the range of accessible metrics,
294 make the code hard to maintain, force the user interface to be particu‐
295 larly baroque, etc.). Hence a Performance Metrics Name Space (PMNS) is
296 used to provide external names and a hierarchic classification for per‐
297 formance metrics. A PMNS is represented as a tree, with each node hav‐
298 ing a label, a pointer to either a PMID (for leaf nodes) or a set of
299 descendent nodes in the PMNS (for non-leaf nodes).
300 A node label must begin with an alphabetic character, followed by zero
302 or more characters drawn from the alphabetics, the digits and character
303 `_´ (underscore). For alphabetic characters in a node label, upper and
304 lower case are distinguished.
305 By convention, the name of a performance metric is constructed by con‐
307 catenation of the node labels on a path through the PMNS from the root
308 node to a leaf node, with a ``.'' as a separator. The root node in the
309 PMNS is unlabeled, so all names begin with the label associated with
310 one of the descendent nodes below the root node of the PMNS, e.g. ker‐
311 nel.percpu.syscall. Typically (although this is not a requirement)
312 there would be at most one name for each PMID in a PMNS. For example
313 kernel.all.cpu.idle and disk.dev.read are the unique names for two dis‐
314 tinct performance metrics, each with a unique PMID.
315 Groups of related PMIDs may be named by naming a non-leaf node in the
317 PMNS tree, e.g. disk.
318 There may be PMIDs with no associated name in a PMNS; this is most
320 likely to occur when specific PMIDs are not available in all systems,
321 e.g. if ORACLE is not installed on a system, there is no good reason to
322 pollute the PMNS with names for all of the ORACLE performance metrics.
323 Note also that there is no requirement for the PMNS to be the same on
325 all systems, however in practice most applications would be developed
326 against a stable PMNS that was assumed to be a subset of the PMNS on
327 all systems. Indeed the PCP distribution includes a default local PMNS
328 for just this purpose.
329 The default local PMNS is located at $PCP_VAR_DIR/pmns/root however the
331 environment variable PMNS_DEFAULT may be set to the full pathname of a
332 different PMNS which will then be used as the default local PMNS.
333 Most applications do not use the local PMNS, but rather import parts of
335 the PMNS as required from the same place that performance metrics are
336 fetched, i.e. from pmcd(1) for live monitoring or from a PCP archive
337 for retrospective monitoring.
338 To explore the PMNS use pminfo(1), or if the PCP GUI package is
340 installed the New Chart and Metric Search windows within pmchart(1).
341
343 In configuration files and (to a lesser extent) command line options,
344 metric specifications adhere to the following syntax rules.
345 If the source of performance metrics is real-time from pmcd(1) then the
347 accepted syntax is
348 host:metric[instance1,instance2,...]
349 If the source of performance metrics is a PCP archive log then the
351 accepted syntax is
352 archive/metric[instance1,instance2,...]
353 The host:, archive/ and [instance1,instance2,...] components are all
355 optional.
356 The , delimiter in the list of instance names may be replaced by white
358 space.
359 Special characters in instance names may be escaped by surrounding the
361 name in double quotes or preceding the character with a backslash.
362 White space is ignored everywhere except within a quoted instance name.
364 An empty instance is silently ignored, and in particular ``[]'' is the
366 same as no instance, while ``[one,,,two]'' is parsed as specifying just
367 the two instances ``one'' and ``two''.
368 As a special case, if the host is the single character ``@'' then this
370 refers to a PM_CONTEXT_LOCAL source, see pmNewContext(3).
371
373 Since PCP version 2, version information has been associated with
374 pmcd(1) and PCP archives. The version number is used in a number of
375 ways, but most noticeably for the distributed pmns(4). In PCP version
376 1, the client applications would load the PMNS from the default PMNS
377 file but in PCP version 2, the client applications extract the PMNS
378 information from pmcd(1) or a PCP archive. Thus in PCP version 2, the
379 version number is used to determine if the PMNS to use is from the
380 default local file or from the actual current source of the metrics.
381
383 Since PCP version 3, the pmcd(1) hostname specification has been
384 extended to allow an optional pmcd port number, and also optional
385 pmproxy(1) hostname and port number. These supercede (and override)
386 the old-style PMCD_PORT, PMPROXY_HOST and PMPROXY_PORT environment
387 variables.
388 The following are valid hostname specifications that specify connec‐
390 tions to pmcd on host nas1.servers.com with/without a list of ports and
391 with/without a pmproxy(1) connection through a firewall.
392 $ pcp -h nas1.servers.com:44321,4321@firewall.servers.com:44322
394 $ pcp -h nas1.servers.com:44321@firewall.servers.com:44322
395 $ pcp -h nas1.servers.com:44321@firewall.servers.com
396 $ pcp -h nas1.servers.com@firewall.servers.com
397 $ pcp -h nas1.servers.com:44321
398
400 In addition to the PCP run-time environment and configuration variables
401 described in the PCP ENVIRONMENT section below, the following environ‐
402 ment variables apply to all installations.
403 PCP_DERIVED_CONFIG
405 When set, this variable defines the path to a file that contains
406 definitions of derived metrics as per the syntax described in
407 pmLoadDerivedConfig(3). Derived metrics may be used to extend
408 the available metrics with new (derived) metrics using simple
409 arithmetic expressions.
410 If PCP_DERIVED_CONFIG is set, the derived metric definitions are
412 processed automatically as each new source of performance met‐
413 rics is established (i.e. each time a pmNewContext(3) is called)
414 or when requests are made against the PMNS.
415 PCP_STDERR
417 Many PCP tools support the environment variable PCP_STDERR,
418 which can be used to control where error messages are sent.
419 When unset, the default behavior is that ``usage'' messages and
420 option parsing errors are reported on standard error, other mes‐
421 sages after initial startup are sent to the default destination
422 for the tool, i.e. standard error for ASCII tools, or a dialog
423 for GUI tools.
424 If PCP_STDERR is set to the literal value DISPLAY then all mes‐
426 sages will be displayed in a dialog. This is used for any tools
427 launched from the a Desktop environment.
428 If PCP_STDERR is set to any other value, the value is assumed to
430 be a filename, and all messages will be written there.
431 PCP_USE_STDERR
433 This environment variable, previously used by pmlaunch(5),
434 pmgsys(1), pmview(1) and the pmview(1) front-end scripts (such
435 as mpvis(1)), has been deprecated from the PCP 2.0 release
436 onward and replaced by PCP_STDERR.
437 PMCD_CONNECT_TIMEOUT
439 When attempting to connect to a remote pmcd(1) on a machine that
440 is booting, the connection attempt could potentially block for a
441 long time until the remote machine finishes its initialization.
442 Most PCP applications and some of the PCP library routines will
443 abort and return an error if the connection has not been estab‐
444 lished after some specified interval has elapsed. The default
445 interval is 5 seconds. This may be modified by setting
446 PMCD_CONNECT_TIMEOUT in the environment to a real number of sec‐
447 onds for the desired timeout. This is most useful in cases
448 where the remote host is at the end of a slow network, requiring
449 longer latencies to establish the connection correctly.
450 PMCD_RECONNECT_TIMEOUT
452 When a monitor or client application loses a connection to a
453 pmcd(1), the connection may be re-established by calling a ser‐
454 vice routine in the PCP library. However, attempts to reconnect
455 are controlled by a back-off strategy to avoid flooding the net‐
456 work with reconnection requests. By default, the back-off
457 delays are 5, 10, 20, 40 and 80 seconds for consecutive recon‐
458 nection requests from a client (the last delay will be repeated
459 for any further attempts after the fifth). Setting the environ‐
460 ment variable PMCD_RECONNECT_TIMEOUT to a comma separated list
461 of positive integers will re-define the back-off delays, e.g.
462 setting PMCD_RECONNECT_TIMEOUT to ``1,2'' will back-off for 1
463 second, then attempt another connection request every 2 seconds
464 thereafter.
465 PMCD_REQUEST_TIMEOUT
467 For monitor or client applications connected to pmcd(1), there
468 is a possibility of the application "hanging" on a request for
469 performance metrics or metadata or help text. These delays may
470 become severe if the system running pmcd crashes, or the network
471 connection is lost. By setting the environment variable
472 PMCD_REQUEST_TIMEOUT to a number of seconds, requests to pmcd
473 will timeout after this number of seconds. The default behavior
474 is to be willing to wait 10 seconds for a response from every
475 pmcd for all applications.
476 PMCD_WAIT_TIMEOUT
478 When pmcd(1) is started from $PCP_RC_DIR/pcp then the primary
479 instance of pmlogger(1) will be started if the configuration
480 flag pmlogger is chkconfig'ed on, some key applications from the
481 pcp.sw.base subsystem are installed and pmcd is running and
482 accepting connections.
483 The check on pmcd's readiness will wait up to PMCD_WAIT_TIMEOUT
485 seconds. If pmcd has a long startup time (such as on a very
486 large system), then PMCD_WAIT_TIMEOUT can be set to provide a
487 maximum wait longer than the default 60 seconds.
488 PMNS_DEFAULT
490 If set, then interpreted as the the full pathname to be used as
491 the default local PMNS for pmLoadNameSpace(3). Otherwise, the
492 default local PMNS is located at $PCP_VAR_DIR/pcp/pmns/root for
493 base PCP installations.
494 PCP_COUNTER_WRAP
496 Many of the performance metrics exported from PCP agents have
497 the semantics of counter meaning they are expected to be mono‐
498 tonically increasing. Under some circumstances, one value of
499 these metrics may smaller than the previously fetched value.
500 This can happen when a counter of finite precision overflows, or
501 when the PCP agent has been reset or restarted, or when the PCP
502 agent is exporting values from some underlying instrumentation
503 that is subject to some asynchronous discontinuity.
504 The environment variable PCP_COUNTER_WRAP may be set to indicate
506 that all such cases of a decreasing ``counter'' should be
507 treated as a counter overflow, and hence the values are assumed
508 to have wrapped once in the interval between consecutive sam‐
509 ples. This ``wrapping'' behavior was the default in earlier PCP
510 versions, but by default has been disabled in PCP release from
511 version 1.3 on.
512 PMDA_PATH
514 The PMDA_PATH environment variable may be used to modify the
515 search path used by pmcd(1) and pmNewContext(3) (for PM_CON‐
516 TEXT_LOCAL contexts) when searching for a daemon or DSO PMDA.
517 The syntax follows that for PATH in sh(1), i.e. a colon sepa‐
518 rated list of directories, and the default search path is
519 ``/var/pcp/lib:/usr/pcp/lib'', (or ``/var/lib/pcp/lib'' on
520 Linux, depending on the value of the $PCP_VAR_DIR environment
521 variable).
522 PMCD_PORT
524 The TPC/IP port(s) used by pmcd(1) to create the socket for
525 incoming connections and requests, was historically 4321 and
526 more recently the officially registered port 44321; in the cur‐
527 rent release, both port numbers are used by default as a transi‐
528 tional arrangement. This may be over-ridden by setting
529 PMCD_PORT to a different port number, or a comma-separated list
530 of port numbers. If a non-default port is used when pmcd is
531 started, then every monitoring application connecting to that
532 pmcd must also have PMCD_PORT set in their environment before
533 attempting a connection.
534 The following environment variables are relevant to installations in
536 which pmlogger(1), the PCP archive logger, is used.
537 PMLOGGER_PORT
539 The environment variable PMLOGGER_PORT may be used to change the
540 base TCP/IP port number used by pmlogger(1) to create the socket
541 to which pmlc(1) instances will try and connect. The default
542 base port number is 4330. When used, PMLOGGER_PORT should be
543 set in the environment before pmlogger is executed.
544 PMLOGGER_REQUEST_TIMEOUT
546 When pmlc(1) connects to pmlogger(1), there is a remote possi‐
547 bility of pmlc "hanging" on a request for information as a con‐
548 sequence of a failure of the network or pmlogger. By setting
549 the environment variable PMLOGGER_REQUEST_TIMEOUT to a number of
550 seconds, requests to pmlogger will timeout after this number of
551 seconds. The default behavior is to be willing to wait forever
552 for a response from each request to a pmlogger. When used,
553 PMLOGGER_REQUEST_TIMEOUT should be set in the environment before
554 pmlc is executed.
555 If you have the PCP product installed, then the following environment
557 variables are relevant to the Performance Metrics Domain Agents
558 (PMDAs).
559 PMDA_LOCAL_PROC
561 Use this variable has been deprecated and it is now ignored. If
562 the ``proc'' PMDA is configured as a DSO for use with pmcd(1) on
563 the local host then all of the ``proc'' metrics will be avail‐
564 able to applications using a PM_CONTEXT_LOCAL context.
565 The previous behaviour was that if this variable was set, then a
567 context established with the type of PM_CONTEXT_LOCAL will have
568 access to the ``proc'' PMDA to retrieve performance metrics
569 about individual processes.
570 PMDA_LOCAL_SAMPLE
572 Use this variable has been deprecated and it is now ignored. If
573 the ``sample'' PMDA is configured as a DSO for use with pmcd(1)
574 on the local host then all of the ``sample'' metrics will be
575 available to applications using a PM_CONTEXT_LOCAL context.
576 The previous behaviour was that if this variable was set, then a
578 context established with the type of PM_CONTEXT_LOCAL will have
579 access to the ``sample'' PMDA if this optional PMDA has been
580 installed locally.
581 PMIECONF_PATH
583 If set, pmieconf(1) will form its pmieconf(4) specification (set
584 of parameterized pmie(1) rules) using all valid pmieconf files
585 found below each subdirectory in this colon-separated list of
586 subdirectories. If not set, the default is $PCP_VAR_DIR/con‐
587 fig/pmieconf.
588
590 /etc/pcp.conf
591 Configuration file for the PCP runtime environment, see
592 pcp.conf(4).
593 $PCP_RC_DIR/pcp
594 Script for starting and stopping pmcd(1).
595 $PCP_PMCDCONF_PATH
596 Control file for pmcd(1).
597 $PCP_PMCDOPTIONS_PATH
598 Command line options passed to pmcd(1) when it is started
599 from $PCP_RC_DIR/pcp. All the command line option lines
600 should start with a hyphen as the first character. This file
601 can also contain environment variable settings of the form
602 "VARIABLE=value".
603 $PCP_BINADM_DIR
604 Location of PCP utilities for collecting and maintaining PCP
605 archives, PMDA help text, PMNS files etc.
606 $PCP_PMDAS_DIR
607 Parent directory of the installation directory for Dynamic
608 Shared Object (DSO) PMDAs.
609 $PCP_RUN_DIR/pmcd.pid
610 If pmcd is running, this file contains an ascii decimal rep‐
611 resentation of its process ID.
612 $PCP_LOG_DIR/pmcd
613 Default location of log files for pmcd(1), current directory
614 for running PMDAs. Archives generated by pmlogger(1) are
615 generally below $PCP_LOG_DIR/pmlogger.
616 $PCP_LOG_DIR/pmcd/pmcd.log
617 Diagnostic and status log for the current running pmcd(1)
618 process. The first place to look when there are problems
619 associated with pmcd.
620 $PCP_LOG_DIR/pmcd/pmcd.log.prev
621 Diagnostic and status log for the previous pmcd(1) instance.
622 $PCP_LOG_DIR/NOTICES
623 Log of pmcd(1) and PMDA starts, stops, additions and
624 removals.
625 $PCP_VAR_DIR/config
626 Contains directories of configuration files for several PCP
627 tools.
628 $PCP_VAR_DIR/config/pmcd/rc.local
629 Local script for controlling PCP boot, shutdown and restart
630 actions.
631 $PCP_VAR_DIR/pmns
632 Directory containing the set of PMNS files for all installed
633 PMDAs.
634 $PCP_VAR_DIR/pmns/root
635 The ASCII pmns(4) exported by pmcd(1) by default. This PMNS
636 is be the super set of all other PMNS files installed in
637 $PCP_VAR_DIR/pmns.
638 In addition, if the PCP product is installed the following files and
639 directories are relevant.
640 $PCP_LOG_DIR/NOTICES
641 In addition to the pmcd(1) and PMDA activity, may be used to log
642 alarms and notices from pmie(1) via pmpost(1).
643 $PCP_PMLOGGERCONTROL_PATH
644 Control file for pmlogger(1) instances launched from
645 $PCP_RC_DIR/pcp and/or managed by pmlogger_check(1) and pmlog‐
646 ger_daily(1) as part of a production PCP archive collection set‐
647 up.
648
650 Environment variables with the prefix PCP_ are used to parameterize the
651 file and directory names used by PCP. On each installation, the file
652 /etc/pcp.conf contains the local values for these variables. The
653 $PCP_CONF variable may be used to specify an alternative configuration
654 file, as described in pcp.conf(4).
655
657 pmcd(1), pmie(1), pmie_daily(1), pminfo(1), pmlc(1), pmlogger(1),
658 pmlogger_daily(1), pmstat(1), pmval(1), pcp(1), pcp.conf(4),
659 pcp.env(4), and pmns(4).
660 If the PCP GUI package is installed, then the following entries are
662 also relevant:
663 pmchart(1), pmtime(1), and pmdumptext(1).
664 Also refer to the books Performance Co-Pilot User's and Administrator's
666 Guide and Performance Co-Pilot Programmer's Guide which can be found at
667 http://techpubs.sgi.com.
668Performance Co-Pilot SGI PCPINTRO(1)