Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

putMany uses as many FDs as there are entries #36

Open
magik6k opened this issue Mar 24, 2018 · 2 comments
Open

putMany uses as many FDs as there are entries #36

magik6k opened this issue Mar 24, 2018 · 2 comments

Comments

@magik6k
Copy link
Member

magik6k commented Mar 24, 2018

Current implementation of putMany seems to open as many FDs as there are entries to put, with batches few K in size this will cause too many files open errors.

https://github.com/ipfs/go-ds-flatfs/blob/master/flatfs.go#L422

@Kubuxu
Copy link
Member

Kubuxu commented Mar 25, 2018

  1. we should write files concurrently 2. we should limit number of files open at once
    It might be useful to have a separate, per datastore pool of goroutines that task would be operating on files thus solving FD the problem completely.

@MichaelMure
Copy link
Contributor

A possible strategy to address that issue could be to rework closer() (

go-ds-flatfs/flatfs.go

Lines 560 to 574 in ff6502b

closer := func() error {
for closed < len(files) {
fi := files[closed].file
if fs.sync {
if err := syncFile(fi); err != nil {
return err
}
}
if err := fi.Close(); err != nil {
return err
}
closed++
}
return nil
}
) into a closer(maxOpen int) that would be called after every writes to introduce an upper bound of open files within a single large putMany. This function would close the oldest opened files (that should already be flushed on disk by now) but also keep the youngest open to leave the kernel time to flush when it makes sense.

err := closer()
would then become closer(0), sharing the same logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants