Too many open files error

[WilderLavington]

Hello,

I was recently interested in setting up individual replay buffers which each correspond to a specific initial condition. There are a decent number of initial conditions (maybe 500-1000), but I was hoping to do this to make uniform sampling a little bit easier. When generating this set of replay buffers, I ran into the following error:

File "cpprb/PyReplayBuffer.pyx", line 988, in cpprb.PyReplayBuffer.ReplayBuffer.__cinit__
  File "cpprb/PyReplayBuffer.pyx", line 530, in cpprb.PyReplayBuffer.dict2buffer
  File "cpprb/PyReplayBuffer.pyx", line 509, in cpprb.PyReplayBuffer.dict2buffer.zeros
  File "/usr/local/lib/python3.8/dist-packages/numpy/core/memmap.py", line 267, in __new__
    mm = mmap.mmap(fid.fileno(), bytes, access=acc, offset=start)
OSError: [Errno 24] Too many open files

My question is, is this a bug or a feature? In the sense that the system wants to keep all of these files open for quick access, or are they just going to be temporarily open after being created. I could potentially increase my open file limit to avoid this, but I would have to increase is ~10x to run my current application. Do you have a recommendation to get around this? I could potentially use PER to approximate the sampling distribution I am interested in but just having separate buffers per initial condition would be easier. Any insight would be useful!

[ymd-h]

@WilderLavington

This is not a bug.

If you enable Memory Mapped File (mmap),
each data maps on a separate file instead of physical memory,
so that these files are kept opened (probably until the program finishes).

Theoretically speaking, this can be solved
by first creating a large memory mapped file then allocating data at the sub-area of the file.
However, it requires a lot of modification in cpprb and there are some difficulties in its design.

If you need to create so many replay buffers, you might have to disable mmap feature.
In the case, all the data are allocated on physical memory.

[WilderLavington]

This is kind of what I expected, but wanted to make sure. Thank you for your response!

Given the size of memory I am trying to allocate, I don't think I can force everything onto physical memory. I could however keep track of where certain examples lay within the buffer try to directly sample them following my own sampling scheme. Meaning instead of ReplayBuffer.sample(1) I would request a specific index from the buffer which I externally know is associated with initial condition n which I was interested in sampling. Is this possible to do without calling

ReplayBuffer.get_all_transitions()[index_of_interest]

and instead directly grabbing a specific transition, something like:

ReplayBuffer.get_transition(index_of_interest)

[ymd-h]

@WilderLavington

I think you can use private (but almost stable) method _encode_sample(idx).

Please see: #27 (comment)

[WilderLavington]

_encode_sample seems to work well, though if there are any specific caveats I should be aware of let me know, otherwise thanks for the info! We will have to see the order of slowdown I get during training doing this, but at least it seems like there is a way to force a specific sampling distribution. Thanks for your help!