I have completed the first round of this work ... as usual the final
implementation is a little messier than first expected ...
- changing the semantics of __pmLogPutResult to allow the trailer to be
written in the same write as the header and pmResult was a little messy
- unbuffered I/O for the metadata and index files is a bad idea (see
note below)
The testing (all QA passes, so no functional regressions) reported below
shows less writes and about the same CPU burn for the typical cases ...
so resource wise a break even, but we get the better semantics. For the
extreme small logging config case there are a lot more writes and a
small increase in CPU burn ... both as a consequence of the external log
record being much smaller than the stdio buffer.
The results are less dramatic than I had expected because any change in
the metadata and the emitting of an index record forces the data stream
to be flushed.
Test cases 10,000 samples at 10msec intervals.
short - sample.colour
default - pmlogconf generated default.config
long - all linux metrics (not proc) plus sampledso
new I/O
+ unbuffered writes for the data file, one write per pmResult
(includes header, pmResult and trailer)
+ buffered writes for the metadata and the index (these have always
been fflush() synced with the data file, and making them unbuffered
adds CPU time and exposes fragmented logical records externally ...
so a loss+loss situation)
CPU #writes Avg write size
(sec) (bytes)
short - 3.9.2 1.15 142 3946
short - new I/O 1.30 10004 56
default - 3.9.2 3.77 20001 5623
default - new I/O 3.73 10004 11571
long - 3.9.2 26.5 20001 20824
long - new I/O 26.9 10004 42409
~
|