groot: question about mmap use / large RSS #1019
Comments
|
It's possible I introduced mmap for (reading) performances but before I implemented the readahead mechanism. I'll have a look on Tuesday. |
|
ok, so, I dug up my old groot-bench and played a bit. here are the results: where:
there's a sizeable performance drop in terms of CPU and wall-clock. the CPU performance drop may indicate the read ahead code could be improved (and/or somewhat improved through your suggestion in #1020) |
|
one could recoup some of the original CPU perfs by increasing the read-ahead buffer (with e.g.: there's definitely some amount of heuristics to put in place. |
|
for completeness, here is a benchmark report for multiple values of the "prefetch basket": my FTR, here is the complete (w/ ROOT/C++-6.32/06, gcc-14.2.1) performance values for |
|
and here is what |
|
all the gritty details are in go-hep/groot-bench@064bccd |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forgive me if this is a stupid question, but what is the motivation for using
mmapingroot/riofsto read files, instead of just a plainos.Open? A side effect of usingmmapis that the resident set size in memory to keep growing, if the system isn't under enough pressure to drop unused pages. AFAIK this is normally a harmless accounting error, but it may become important if RSS is monitored and used for anything.Context:
I was just running some microbenchmarks comparing
ROOTI/O touproottogroot, and I noticed higher than expected RSS on thegrootside. This reminded me that in #885 there was a test commit (sbinet-hep@839e08f) whereos.Openwas used. Testing it out again, this reduces the RSS as I would naive expect, and it doesn't seem to cause any performance regressions, but linux's disk I/O cache makes this annoyingly hard to test properly. I thought I should just ask before I get too carried away trying to test it, in case I'm overlooking some need to usemmaphere.My theoretical concern is that high RSS may cause monitoring tools (like the ones used in batch systems at HEP computing sites) to incorrectly flag the program as being over its memory budget, and preemptively kill it, before the system is under enough pressure for the
mmaped pages to be dropped. Or reschedule it to a slot with a needlessly large memory allocation, leading to a less efficient use of computing resource (in a way which may be hard to detect). Usingos.Openfor regular file access, and letting the OS disk I/O cache speed up subsequent reads, may avoid triggering false positives in such cases. That being said, most batch systems probably rely on network I/O, which ideally wouldn't bemmaped (if files aren't be accessed through a FUSE mount or something), so this example may be a moot point.The text was updated successfully, but these errors were encountered: