-
Notifications
You must be signed in to change notification settings - Fork 967
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
Large Manifest file is repeatedly re-created #413
Comments
I think this may be fixed in #409. |
#409 doesn't fix this issue. I applied a version of that change with some logging:
The result still shows a newly-created Manifest larger than the maximum size, triggering that code branch over and over again:
By the way, this DB is from a partially synchronized Ethereum archive node which I'm presently converting to a larger options.CompactionTableSize. It is possible to work around the issue by specifying a larger MaxManifestFileSize in the geth ethdb/leveldb/leveldb.go file. |
In a large or poorly-tuned database with a very large number of files, the MANIFEST-nnnn file can grow bigger than the MaxManifestFileSize option. During compaction there are repeated calls to the commit() function in session.go which contains the code:
When the s.newManifest() replacement is unable to reclaim a meaningful amount of space, there will be a call to s.newManifest() on every call to commit(). This in turn causes a large performance degradation of the overall compaction process.
At a minimum the code could check s.manifest.Size() immediately following the s.newManifest() call and log an error message if it was already above s.o.GetMaxManifestFileSize().
Another option would be to store the size of the newly-created manifest in the session struct and then use this as a dynamic limit to avoid calling the s.newManifest() branch again until the size had grown (say) 10% beyond its previous value.
The text was updated successfully, but these errors were encountered: