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
Reduce permgen use from Groovy scripts #7658
Comments
This is because the GroovyClassLoader hangs on to every class ever created in its class cache. In benchmarks, I can only load ~500 scripts into a Java7 vm with default permgen settings before OOM/permgen. I can get a few thousand in with Java8.
The following patch works for me for dynamic scripts, and I believe it shouldn't have a downside, because (1) ES has it's own Guava class cache (that actually releases classes), and (2) I can't find a codepath in ES that even indirectly uses the GroovyClassLoader's class cache.
|
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes elastic#7658
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes #7658
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes #7658
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes #7658
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes elastic#7658
Since we don't use the cache, it's okay to clear it entirely if needed, Elasticsearch maintains its own cache for compiled scripts. Adds loader.clearCache() into a listener, the listener is called when a script is removed from the Guava cache. This also lowers the amount of cached scripts to 100, since 500 is around the limit some users have run into before hitting an out of memory error in permgem. Fixes elastic#7658
Groovy scripts seem to be using more permgen than MVEL scripts do, especially when sent dynamically.
It would be nice if we reduce the amount of permgen used by these scripts, or make the permgen space recoverable in the event the script is not used.
The text was updated successfully, but these errors were encountered: