The current SP code in the file DiscoveryFeed.cpp includes this comment:
// Remove any files unused for more than a couple of minutes. // Anything left will be orphaned, but that shouldn't happen too often.
We are finding with our 2.6.0 deployments (both CentOS 7 and Debian 8) that enough of the cache files are orphaned each day to be a nuisance. The number of orphans appears to be correlated with the load on the system. The busiest service accumulates about 10 orphan files a day. Each one is 1.5 MB in size (due to eduGAIN, these are widely federated SPs), so about 15 MB of orphaned files a day.
We are requesting an enhancement that would reap the orphan files more robustly.
A simple cron job to remove them nightly solves the issue so this is not a high priority, but it is a nuisance for an otherwise "well behaved" system.
Environment
None
Attachments
1
29 Mar 2018, 01:19 PM
Activity
Show:
Scott Cantor April 3, 2018 at 5:07 PM
That was a whole lot of work for a one character fix. Fun times.
Scott Cantor April 3, 2018 at 5:00 PM
Both of these bugs were regressions caused by the "fix" that corrected the problem with overlapping applications stepping on each others feeds, which was done in 2.5.6. So ever since that version, the original cleanup logic was broken and there's been more overhead. Fix is simple. If we have to do another security fix, I'll backport this.
This may still leave a few orphans, but nothing like it's doing now.
Scott Cantor April 3, 2018 at 4:48 PM
On top of that, I believe the entire caching mechanism was broken and not actually tracking what it was meant to be tracking, so every client without an ETag was causing the feed to be re-written to the same filename over and over, and I believe no cleanup of any files was actually ever happening.
Scott Cantor April 3, 2018 at 1:20 PM
The main bug here is that the shutdown logic isn't computing the filenames correctly, so anything not cleaned up during actual system usage gets left behind unintentionally.
Scott Cantor March 29, 2018 at 1:52 PM
I would be curious what kind of performance you see if you turn the disk caching off. It's not really ever been tested much. The feed is still "cached" in the client and I don't know how much extra overhead there is from serving it directly from shibd memory and out to the client, though I imagine at these sizes it could be noticeable.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
The current SP code in the file DiscoveryFeed.cpp includes this comment:
// Remove any files unused for more than a couple of minutes.
// Anything left will be orphaned, but that shouldn't happen too often.
We are finding with our 2.6.0 deployments (both CentOS 7 and Debian 8) that enough of the cache files are orphaned each day to be a nuisance. The number of orphans appears to be correlated with the load on the system. The busiest service accumulates about 10 orphan files a day. Each one is 1.5 MB in size (due to eduGAIN, these are widely federated SPs), so about 15 MB of orphaned files a day.
We are requesting an enhancement that would reap the orphan files more robustly.
A simple cron job to remove them nightly solves the issue so this is not a high priority, but it is a nuisance for an otherwise "well behaved" system.