-
Notifications
You must be signed in to change notification settings - Fork 196
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
Listing trash items is slow #9866
Comments
While trying to upload and delete thousands of files I noticed that we are still not using async metadata propgation:
without this the propagation happens in sync, which sometimes causes stale NFS handles:
after enabling the async propagation I no longer see the stale NFS error. It seems to at least take the pressure of the filesystem. In any case ... this needs to be investigated. Failing to propagate breaks the metadata. |
so on a kubernetes deploment with NFS latency kicks in: And it looks as bad as you might guess...
reading a single symlink takes 600+ ms 😞 |
now ... I don't think we need to use symlinks here ... we should be able to store the timestamp as part of the trash path. no need to use a symlink. we can just use the downside is that when listing the trash with a key we need to look for a file and ignore the timestamp in the path. and we would need a migration step ... to rewrite the symlinks |
or we think about putting dir listings in the cache ... |
hm nats can use watch to get a list of all keys using a prefix, see: nats-io/nats.go#957 keys would take the form |
On a local instance listing 10k items in the trash takes ~1s.
I instrumented the code a little...
the 256 subtrees are crawled concurrently with ~14-51ms per subtree
The text was updated successfully, but these errors were encountered: