Revised oomparser to not use all the cpu

[kateknister]

No description provided.

[rjnagal]

Do we know if watching is better? For many systems, /var/log/messages gets updated more than once per second.

[kateknister]

Do you mean there might be a backlog of IN_MODIFY notices to the watcher if there are many changes to the file all at once?

[rjnagal]

/var/log/messages gets debug logs from many sources. The watcher might get invoked more than once per second.

Were we doing a periodic poll earlier? Can we just check once every 10s and keep an open fd?
(Sorry, I haven't looked at all details of oom-parser. But I feel like watching might not help some of the machines).

[kateknister]

Oomparser on with 100ms delay for every loop call: (average: 0.010 cores), 9.785 MB of memory

No oomparser: (average: 0.008 cores), 9.753 MB of memory

The delay minimizes the effect of the oomparser but there is a bit of difference.

[vmarmol]

can we move this logic to analyzeLines instead?

[vmarmol]

This code is getting a bit hard to read, let's try to simplify it. We will never break out of this loop so lets make it an infinite loop with a read at the beginning. We should also only wait while the error is EOF:

var line string
var err error
for true {
    // Wait for more content to show up in the file.
    for line, err = ioreader.ReadString('\n'); err != nil && err == io.EOF; {
        time.Sleep(100 * time.Millisecond)
    }

    // Do work...
}

[vmarmol]

LGTM