Closed oterocoronel closed 1 year ago
oterocoronel
commented
1 year ago Eventually, the run shown above crashed because it ran oom. However, after restarting the kernel, the issue is fixed and it is using little RAM... Maybe it was just something due to a buggy initialization? Probably safe to close this issue
alihaydaroglu
commented
1 year ago Thanks for sharing the log as well. This commit should have fixed this issue: https://github.com/alihaydaroglu/suite2p/commit/874df9fc88698ed0f61326369a72d2e58e315dfa
If you have already updated and are still running into let me know, if not I'll close the issue for now
alihaydaroglu
commented
1 year ago FYI if your registration step fails, you can restart at a specific batch using the 'start_batch_idx' param on job.register so you don't re register all the batches before the crash
alihaydaroglu
commented
1 year ago I reopen this because it seems like you were already on the latest version, confirmed by the print statements. It seems like the two lines shmem_mov.close(); shmem_mov.unlink() didn't work as intended in this case. The expected behaviour is that the registration uses a constant amount of memory throughout, it shouldn't accumulate.
It doesn't happen for me, and it seems not to have happened after re-running it, but please let me know if you encounter the issue again.
alihaydaroglu
commented
1 year ago issue with RAM going up seems fixed, but other memory considerations are continued in #39 , so closing this on
I am trying to process an LBM recording with 15 planes, so I changed some stuff during data-loading but I don't think that should affect this.
This is from the log: