Closed xoh closed 6 years ago
Out of curiosity, was https://github.com/google/stenographer/commit/6f293479207d3f2ffd51424854cac8a149124dc5 compiled in when you saw this behavior? It was designed to fix this exact issue.
Actually, no. I compiled the latest version. Getting back after some cleanups have passed.
This actually was the issue. No cleanups larger than 2% any more. Thanks!
Awesome, thanks for checking back in and closing things out! And thanks to fming188 for pointing out the root cause in #187 :)
When the disk becomes full (as in free space is below DiskFreePercentage), too many files get deleted. The issue is tedious to reproduce, as the disk has to fill up. Irregularly monitoring used disk space, I've noticed it drops from 95% to below 80%, sometimes even lower. As far as I understand, only the last packet-file should be deleted (filesizes on my setup range from 20MB to 350MB), to provide the largest possible capture-timeframe.
I tried to trigger debug outputs like https://github.com/google/stenographer/blob/6f293479207d3f2ffd51424854cac8a149124dc5/thread/thread.go#L204 or https://github.com/google/stenographer/blob/6f293479207d3f2ffd51424854cac8a149124dc5/thread/thread.go#L229 but nothing appears in syslog/journalctl. Setting higher verbosity either failes for me:
or results in way more log messages, but none maching those of
cleanUpOnLowDiskSpace()
orpruneOldestThreadFiles()
instenographer/thread/thread.go
:Almost all logs are from .cc-Files, a few from
index.h
, some log stenoread requests. Not a single logline of journalctl and /var/log/syslog corresponds to the log-calls in stenographer/thread/thread.go.I've now setup a dirty monitoring to show the issue:
The third, sixth and seventh cleanup delete too many files.