This is a scratchpad used to collect useful information and notes on the perfpusher.
This could be considered a (uncomplete) documentation.
This could be considered a (incomplete) documentation.
Intro
DCDB is a database to collect various (sensor-)values of a datacenter for further anlysis.
For harvesting the data various pushers are available.
Perfpusher is tasked with collecting data from the CPUs various performance counters (PMUs) as configured in the config file.
Perfpusher is tasked with collecting data from the CPUs various performance counters (PMUs) as configured in the
config file.
Running perfpusher
An working installation of DCDB is required. Simply compile Perfpusher by running the given makefile. Run Perfpusher by executing the binary and specifying a config file.
A working broker is required to which Perfpusher can send its messages. Simply compile Perfpusher by running the
given makefile. Run Perfpusher by executing the binary and specifying a config file. NOTE: Access to some PMUs is
restricted, if the value in /proc/sys/kernel/perf_event_paranoid is too high (see sections "Access PMUs").
Config-file
The config-file consists of a number of mandatory and optional values. The structure a config-file should follow can be seen in the example config-file "perfpusher.conf" which is provided in the repository.
The config-file consists of a number of mandatory and optional values. An example config-file "perfpusher.conf" is
provided in the repository.
The various parameters shall be explained in the following ([m] = mandatory, [o] = optional):
global { [m]
...
...
@@ -24,33 +28,40 @@ global { [m]
perfpusher
mqttprefix /XXXXXXX [m] // to not rewrite a full mqtt-topic for every counter one can specify here the
consistend prefix
threads N [o] // specify how many threads should be created to collect values. If one configures
more counters than one thread can handle in time values are not guaranteed to be
consistent anymore. Default value of threads is 1. Note that the MQTTPusher
always starts an extra thread. So the actual number of started threads is always
N+1.
threads N [o] // specify how many threads should be created to collect values. Default value of
threads is 1. Note that the MQTTPusher always starts an extra thread. So the
actual number of started threads is always N+1.
}
CounterTemplate { [m] // Here one can define template counters which then can be referenced further below
counter A {...} [o] by a real sensor. This field is mainly for convenience reasons. One is not
counter B {...} [o] obligated to define any template sensors. However it is required to at least
... [o] define an empty CounterTemplate {} structure.
... [o] define an empty CounterTemplate {} structure. A template counter is defined
similiar to the normal counters as described below.
}
counters { [m] // Wrapper structure where the "real" counters are specified.
counter c_name { // Every counter has to be announced with the word "counter" followed by a freely
selectable name.
default defC_name [o] // Specify name of default template sensor which values should be used as default.
All values can be overwritten by specifying them again here.
default A [o] // Specify name of default template sensor which values should be used as default.
All default values can be overwritten by specifying them here.
interval 1000 [o] // Time in [ms] between two reads. Default is 1000ms = 1s.
mqttsuffix 0000 [m] // MQTT-suffix to append to the global prefix to obtain a full MQTT-topic.
Perfpusher uses a separate MQTT-topic for every CPU. For every found CPU the
mqttsuffix is increased by one. The user has to make sure that the ranges of the
mqtt-suffixes do not overlap!
Example:
For counter A the mqttsuffix 00A8 is given and the system on which perfpusher is
run has 8 cores. Then perfpusher uses the mqtt-suffixe
00A8, 00A9, 00AA, 00AB, 00AC, 00AD, 00AE, 00AF for the 8 cores.
As they are already used by counter A, any other counter must not use those.
Counter B can e.g. start with mqttsuffix 00B0.
minValues 1 [o] // Number of values which the counter should read before they are pushed to the
broker. Default (if not specified) is 1.
type XX [m] // TODO explain different types
config YY [m] // TODO explain different configs per type
broker. Default (if not specified) is 1. Main purpose is to reduce MQTT-overhead
type XX [m] // Type of which the counter should be. Each type determines different possible
values for the config-field. Possible type-values are described below.
config YY [m] // Together with the type-field config determines which performance counter should
be read. Possible values and what they measure are listed below.
}
counter c_name2 {
...
...
@@ -59,3 +70,62 @@ counters { [m] // Wrapper structure where the "real" counters
...
}
Access PMUs
Cited from "http://man7.org/linux/man-pages/man2/perf_event_open.2.html":
The perf_event_paranoid file can be set to restrict access to the performance counters.
2 allow only user-space measurements (default since
Linux 4.6).
1 allow both kernel and user measurements (default
before Linux 4.6).
0 allow access to CPU-specific data but not raw trace‐
point samples.
-1 no restrictions.
The existence of the perf_event_paranoid file is the offi‐
cial method for determining if a kernel supports
perf_event_open().
type + config
(see "http://man7.org/linux/man-pages/man2/perf_event_open.2.html" for more detailed explanations)
type = PERF_TYPE_HARDWARE // generalized hardware CPU events
config = PERF_COUNT_HW_CPU_CYCLES // total cycles (affected by frequency scaling)
