Closed jwodder closed 2 months ago
Attention: Patch coverage is 44.31373%
with 142 lines
in your changes missing coverage. Please review.
Project coverage is 60.50%. Comparing base (
eef70d9
) to head (af6090f
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@yarikoptic FYI: I started a run with the new code in "random-outdated-asset-first" mode at 2:37 PM EDT. The script found all the Dandisets within two minutes. Currently, tests are being run on assets from Dandiset 000016 through 000036 (not all the ones in between, though), and 16 Dandisets have finished having their asset tested.
I would check on drogon later on what it is busy with and either didn't stall again
@yarikoptic I started another run yesterday at 4 PM, and it's still going now. I managed to parse out the following durations from the logfile for the tests that have completed so far:
Interestingly, despite the timeout being set to 3600 seconds, a number of tests ran for longer than that (up to over two hours for some). I'm guessing that those just stalled after they were killed at the one hour mark.
For me it is interesting that if I look at top
, I do not see any of test processes but rather busy (up to 100% CPU) mount.davfs, and without any recent logs on it
so remains unclear what davfs2 is actually doing and why IO is actually quite slow (likely slower than our dataset fuse given that I do not even see python/matlab to appear in top
)
@yarikoptic Also, many of the failed MatNWB tests emitted the error:
Error using load
Unable to read MAT-file
/home/dandi/cronlib/dandisets-healthstatus/matnwb/namespaces/core.mat. File
might be corrupt.
Error using load Unable to read MAT-file /home/dandi/cronlib/dandisets-healthstatus/matnwb/namespaces/core.mat. File might be corrupt.
heh, hinting that may be even read outs could not be trusted, or it just times out internally... who knows (no source for matlab) .
@yarikoptic The test run of this PR's code completed after 2 days and 7 hours.
Since this PR has done what it set out to do and the remaining performance problems are unrelated to it, can this PR be merged now, with the remaining performance problems left for discussion in separate issues?
As discussed in #77.
To do:
modified
dates fortest-files
Dandiset
instances created fortest-files
don't need a client (among other changes)