GFS2 maintains statistics that can help track what is going on within the file system. This allows you to spot performance issues.
GFS2 maintains two counters:
dcount, which counts the number of DLM operations requested. This shows how much data has gone into the mean/variance calculations.
qcount, which counts the number of
syscall level operations requested. Generally
qcount will be equal to or greater than
In addition, GFS2 maintains three mean/variance pairs. The mean/variance pairs are smoothed exponential estimates and the algorithm used is the one used to calculate round trip times in network code. The mean and variance pairs maintained in GFS2 are not scaled, but are in units of integer nanoseconds.
srtt/srttvar: Smoothed round trip time for non-blocking operations
srttb/srttvarb: Smoothed round trip time for blocking operations
irtt/irttvar: Inter-request time (for example, time between DLM requests)
A non-blocking request is one which will complete right away, whatever the state of the DLM lock in question. That currently means any requests when (a) the current state of the lock is exclusive (b) the requested state is either null or unlocked or (c) the "try lock" flag is set. A blocking request covers all the other lock requests.
Larger times are better for IRTTs, whereas smaller times are better for the RTTs.
Statistics are kept in two
glstats file. This file is similar to the
glocks file, except that it contains statistics, with one glock per line. The data is initialized from "per cpu" data for that glock type for which the glock is created (aside from counters, which are zeroed). This file may be very large.
lkstats file. This contains "per cpu" stats for each glock type. It contains one statistic per line, in which each column is a cpu core. There are eight lines per glock type, with types following on from each other.