Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [TENEO] Possible performance Issue in IdentifierCacheHandler(PURGE_TRESHOLD value of 100 causes frequent concurrent purging of the cache)
[TENEO] Possible performance Issue in IdentifierCacheHandler [message #1597810] Mon, 02 February 2015 15:21 Go to next message
Lukas Zaruba is currently offline Lukas ZarubaFriend
Messages: 8
Registered: January 2010
Junior Member
Hi,

first let me thank you for the Teneo project, it is a great piece of work!

and here comes the issue:
Using Teneo under high load we have discovered (using profiling tools and thread dumps) that purging of the cache on each 100 insertions causes frequent concurrent purging of the map.

What I think happens is a thread invokes the
org.eclipse.emf.teneo.hibernate.mapping.identifier.IdentifierCacheHandler.setID(Object, Object)
method, with condition on line 115 resolving as true. It starts purging of the map.
Other threads goes in the same path and also resolves the 115 condition as true because the previous thread haven't finished the job. The second thread also starts purging...

Same scenario can happen with versions cache.

As the map is an instance of ConcurrentHashMap ConcurrentModificationException is not thrown and both threads are purging the map simultaneously. If there is a heavy load and a lot of threads hit the purging before the counter is cleared to zero (line 163), it can heat the CPUs to 100% for a long time.

Our temporary solution was to recompile the class with the configurable (by System.getProperty(String, String) value of the PURGE_TRESHOLD constant which we set to 15000. Since this change has been introduced there were no symptoms of this problem. But I don't think it is the complete solution. Probably only one thread should hit the clearing part in a some kind of the synchronized block, clear the counter and than start the purging. I believe that the configurable value of the PURGE_TRESHOLD is also a valid idea - our application has 20GB of RAM available so I don't mind having the cache of 500MB if it increases the performance.

Can you please give us some feedback on this issue - if it is valid and if maybe there is a better and cleaner solution to the described problem than the one we introduced?

Thank you!

Cheers, LZ
Re: [TENEO] Possible performance Issue in IdentifierCacheHandler [message #1602031 is a reply to message #1597810] Thu, 05 February 2015 09:22 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Lukas,
Yes purging should be single threaded for sure. Can you create a bugzilla for this, and if possible attach a patch for it?

Which version of Teneo are you using?

gr. Martin

On 02-02-15 16:21, Lukas Zaruba wrote:
> Hi,
>
> first let me thank you for the Teneo project, it is a great piece of work!
>
> and here comes the issue:
> Using Teneo under high load we have discovered (using profiling tools and thread dumps) that purging of the cache on
> each 100 insertions causes frequent concurrent purging of the map.
>
> What I think happens is a thread invokes the
> org.eclipse.emf.teneo.hibernate.mapping.identifier.IdentifierCacheHandler.setID(Object, Object) method, with condition
> on line 115 resolving as true. It starts purging of the map.
> Other threads goes in the same path and also resolves the 115 condition as true because the previous thread haven't
> finished the job. The second thread also starts purging...
> Same scenario can happen with versions cache.
>
> As the map is an instance of ConcurrentHashMap ConcurrentModificationException is not thrown and both threads are
> purging the map simultaneously. If there is a heavy load and a lot of threads hit the purging before the counter is
> cleared to zero (line 163), it can heat the CPUs to 100% for a long time.
>
> Our temporary solution was to recompile the class with the configurable (by System.getProperty(String, String) value of
> the PURGE_TRESHOLD constant which we set to 15000. Since this change has been introduced there were no symptoms of this
> problem. But I don't think it is the complete solution. Probably only one thread should hit the clearing part in a some
> kind of the synchronized block, clear the counter and than start the purging. I believe that the configurable value of
> the PURGE_TRESHOLD is also a valid idea - our application has 20GB of RAM available so I don't mind having the cache of
> 500MB if it increases the performance.
>
> Can you please give us some feedback on this issue - if it is valid and if maybe there is a better and cleaner solution
> to the described problem than the one we introduced?
>
> Thank you!
>
> Cheers, LZ


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Previous Topic:[EMFStore] Atomic Undo/Redo
Next Topic:[Teneo] EntityManagerFactoryImpl.transactionType not set
Goto Forum:
  


Current Time: Tue Mar 31 03:14:16 GMT 2020

Powered by FUDForum. Page generated in 0.02481 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top