EHC ❯ CacheManager number of statistics threads is not configurable
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
cschanck
-
Reporter: mads1980
-
July 25, 2013
-
0
-
Watchers: 5
-
September 26, 2013
-
July 31, 2013
Attachments
Description
Currently each CacheManager creates a ScheduledExecutorService with Runtime.getRuntime().availableProcessors() threads. On a production server with 10 webapps, 4 CacheManagers each, and 16 processors, this translates to 640 threads, which is excessive, both because of task switching overhead and the Xss memory taken up by each thread.
The number of threads used for this purpose should be configurable.
private final ScheduledExecutorService statisticsExecutor = Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessors(), new ThreadFactory() { public Thread newThread(Runnable r) { Thread t = new Thread(r, “Statistics Thread”); t.setDaemon(true); return t; } });
Comments
Manuel Dominguez Sarmiento 2013-07-25
Manuel Dominguez Sarmiento 2013-07-26
In case anyone else runs into this while using Spring’s EhCacheManagerFactoryBean, we’ve created the attached extension class to work around this issue.
Manuel Dominguez Sarmiento 2013-07-26
I have uploaded an updated CustomEhCacheManagerFactoryBean to resolve a thread leak issue with the previous version.
Chris Schanck 2013-07-31
After much discussion, we set the default size of the statistics thread pool down to 1 thread; it is possible statistics gathering performance might lag if many caches are having stats recorded at the same time, but we shall see. In local testing it made no discernible difference.
Yakov Feldman 2013-08-16
Verified.
By the way, the guys at Liferay have found exactly the same problem. Apparently they must be overriding this using reflection:
See ehcache.cache.manager.statistics.thread.pool.size=1 https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/portal.properties