[hibernate-dev] Pooled Optimiser Improvements
Scott Marlow
smarlow at redhat.com
Wed Dec 16 09:07:42 EST 2015
Any arguments against merging the
https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
change to master + 5.x?
I will create a jira for this change.
Any suggestions for how to specify in persistence.xml, that the
PooledThreadLocalLoOptimizer should be used? We already have
"hibernate.id.optimizer.pooled.prefer_lo", which I think can be true or
false. Should we add another another similar property? Or perhaps
allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
thread local optimizer" or "pooled-lotl"? Something like:
<property name="hibernate.id.optimizer.pooled.prefer_lo"
value="pooled-lotl"/>
On 12/15/2015 09:01 PM, Stuart Douglas wrote:
> With my original patch the intention was that that the thread local blocks were smaller than the incrementSize, so not every thread local allocation would require a DB call. Your patch changes that approach but I don't think it actually matters that much, the overall performance should still be similar, and it has the advantage of not needed an extra configuration value.
>
> Stuart
>
> ----- Original Message -----
>> From: "Scott Marlow" <smarlow at redhat.com>
>> To: "Steve Ebersole" <steve at hibernate.org>, "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>
>> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>> is looking more correct now, if others want to look at that.
>>
>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>>>
>>>
>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>>>>> I changed the new test methods a bit. [2] seems to be passed the tests
>>>>> but I am not understanding how PooledThreadLocalLoOptimizer should
>>>>> coordinate with the AccessCallback to allocate the next chunk of
>>>>> sequence numbers.
>>>>>
>>>>> We seem to be able to call AccessCallback.getNextValue() to get the next
>>>>> available sequence number but how do we reserve a block of 5000 sequence
>>>>> ids? Am I supposed to call callback.getNextValue() an extra time to get
>>>>> a range of values? Is there a separate database transaction that is
>>>>> used by the AccessCallback.getNextValue() calls? I'm missing something.
>>>>
>>>> Thinking more about this, I assume that AccessCallback.getNextValue() is
>>>> operating under a database transaction that we are probably ending
>>>> before AccessCallback.getNextValue() returns. It also sounds like the
>>>> database table is tracking the "lo" value, as mentioned in the
>>>> PooledLoOptimizer. This implies that only the application layer knows
>>>> what the range is. This seems like an important dependency to understand.
>>>>
>>>> Make sense?
>>>
>>> http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
>>> seems to explain how increment_size is used. Since the user is already
>>> configured that, will look into switching to that for
>>> PooledThreadLocalLoOptimizer.
>>>
>>>>
>>>>>
>>>>> Note that [2] also includes a test change to comment out a few lines in
>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I am seeing in
>>>>> intellij. Will need to remember to remove that change.
>>>>>
>>>>> [2]
>>>>> https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>>>>>
>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>>>>>> Those tests tend to assert the increments. We seem to agree that this
>>>>>> ThreadLocal one can skip gaps of values. I'd look there first.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow <smarlow at redhat.com
>>>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>>>
>>>>>> I'm trying to move the optimizer to PooledThreadLocalLoOptimizer
>>>>>> [1].
>>>>>> We are currently failing some new unit tests, which are cloned
>>>>>> from
>>>>>> existing PooledLoOptimizer tests which might be part of the
>>>>>> problem.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>>>>>>
>>>>>> On 12/14/2015 10:12 PM, Scott Marlow wrote:
>>>>>> >
>>>>>> >
>>>>>> > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>>>>>> >> It's hard to say without understanding the scenario where you
>>>>>> are seeing
>>>>>> >> this as a problem. I have some guesses as to what may be the
>>>>>> problem,
>>>>>> >> but without understanding more about why you see this as a
>>>>>> problem in
>>>>>> >> the first place it is hard to give you an answer. For
>>>>>> >> example,
>>>>>> I wonder
>>>>>> >> if for environments not using multi-tenancy whether the
>>>>>> >> recent
>>>>>> changes
>>>>>> >> for the generators to support multi-tenancy might be the
>>>>>> culprit. If
>>>>>> >> that is the case, and those changes are in fact the
>>>>>> >> underlying
>>>>>> cause of
>>>>>> >> the perf issues you see then I think there is actually a
>>>>>> >> better
>>>>>> >> solution. But again, its hard to say unless we understand
>>>>>> >> the
>>>>>> reason
>>>>>> >> this "shows up" as a perf problem for you.
>>>>>> >
>>>>>> > As best as I can tell from looking at the current
>>>>>> > PooledLoOptimizer,
>>>>>> > versus the proposed change (to have a chunk of ids per
>>>>>> > thread),
>>>>>> we went
>>>>>> > from accessing a contented lock, to instead using per thread
>>>>>> > memory
>>>>>> > (eliminating the contended lock on
>>>>>> > PooledLoOptimizer.generate()).
>>>>>> >
>>>>>> >>
>>>>>> >> Until we hear more I think at this stage I'd vote for a
>>>>>> >> separate
>>>>>> >> optimizer. And maybe even not one that is upstream.
>>>>>> >>
>>>>>> >> Also I agree with Scott that I am VERY leery of not cleaning
>>>>>> >> up a
>>>>>> >> ThreadLocal.
>>>>>> >
>>>>>> > My mistake, as Stuart pointed out, the TL is not static, so we
>>>>>> shouldn't
>>>>>> > introduce any leaks.
>>>>>> >
>>>>>> >>
>>>>>> >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
>>>>>> >> <smarlow at redhat.com
>>>>>> <mailto:smarlow at redhat.com>
>>>>>> >> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>>>>>> >> wrote:
>>>>>> >>
>>>>>> >> Should this be a specialized pooled optimizer that is
>>>>>> >> only
>>>>>> used in
>>>>>> >> environments that do not suffer from leaving the
>>>>>> ThreadLocal around
>>>>>> >> after the application is undeployed? In other words,
>>>>>> >> the
>>>>>> expectation is
>>>>>> >> that classloader leaks with this pooled optimizer are
>>>>>> expected (e.g.
>>>>>> >> user must restart the jvm to really undeploy the
>>>>>> >> application
>>>>>> >> completely).
>>>>>> >>
>>>>>> >> I am thinking that there are at least three typical
>>>>>> >> situations:
>>>>>> >>
>>>>>> >> 1. Applications are deployed in Java standalone
>>>>>> >> edition.
>>>>>> Generally,
>>>>>> >> when the app undeploys the jvm is shutting down.
>>>>>> >>
>>>>>> >> 2. Applications are deployed as part of some container
>>>>>> (e.g. an EE
>>>>>> >> server) and the Hibernate jars are on the global
>>>>>> classloader path (or
>>>>>> >> something like that). On each shared container thread,
>>>>>> there would be
>>>>>> >> one Optimizer for all deployed applications. I wonder
>>>>>> >> if
>>>>>> instead, we
>>>>>> >> would want one Optimizer instance per Hibernate
>>>>>> >> SessionFactory
>>>>>> >> associated with the many container threads?
>>>>>> >>
>>>>>> >> 3. Applications are deployed as part of some container
>>>>>> (e.g. an EE
>>>>>> >> server) and the Hibernate jars are deployed with the
>>>>>> application. The
>>>>>> >> ThreadLocals are associated with threads that are shared
>>>>>> >> by
>>>>>> different
>>>>>> >> deployed applications. The application classloader
>>>>>> >> contains the
>>>>>> >> Hibernate classes. Each deployed application has its own
>>>>>> Optimizer
>>>>>> >> threadlocal. On each shared container thread, there
>>>>>> >> would
>>>>>> be one
>>>>>> >> Optimizer per application (since each application has
>>>>>> >> its
>>>>>> Optimizer TL).
>>>>>> >> Like (2), there would be sharing of the same
>>>>>> >> Optimizer
>>>>>> with the many
>>>>>> >> application session factories. Should we instead have
>>>>>> >> an
>>>>>> optimizer per
>>>>>> >> session factory?
>>>>>> >>
>>>>>> >> Scott
>>>>>> >>
>>>>>> >> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>>>>> >> > Hello,
>>>>>> >> >
>>>>>> >> > I have been working on a change to the pooled
>>>>>> >> > optimizer
>>>>>> that we
>>>>>> >> have been seeing good performance results with.
>>>>>> >> Basically
>>>>>> it hands
>>>>>> >> out blocks of ID's to a thread local, rather than having
>>>>>> >> every
>>>>>> >> thread contend on the lock every time an ID is required.
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>>>> >> >
>>>>>> >> > What would I need to do to get a change like this in?
>>>>>> >> > In
>>>>>> particular:
>>>>>> >> >
>>>>>> >> > - Does it need to be a new type of optimizer, or is
>>>>>> modifying the
>>>>>> >> existing one like I have done OK?
>>>>>> >> > - How should it be configured?
>>>>>> >> >
>>>>>> >> > I am happy to do up a PR for this, but I am just not
>>>>>> really sure
>>>>>> >> what would be required to get it to a point where it
>>>>>> >> would be
>>>>>> >> acceptable for inclusion.
>>>>>> >> >
>>>>>> >> > Stuart
>>>>>> >> > _______________________________________________
>>>>>> >> > hibernate-dev mailing list
>>>>>> >> > hibernate-dev at lists.jboss.org
>>>>>> <mailto:hibernate-dev at lists.jboss.org>
>>>>>> <mailto:hibernate-dev at lists.jboss.org
>>>>>> <mailto:hibernate-dev at lists.jboss.org>>
>>>>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> >> >
>>>>>> >> _______________________________________________
>>>>>> >> hibernate-dev mailing list
>>>>>> >> hibernate-dev at lists.jboss.org
>>>>>> <mailto:hibernate-dev at lists.jboss.org>
>>>>>> <mailto:hibernate-dev at lists.jboss.org
>>>>>> <mailto:hibernate-dev at lists.jboss.org>>
>>>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> >>
>>>>>> > _______________________________________________
>>>>>> > hibernate-dev mailing list
>>>>>> > hibernate-dev at lists.jboss.org
>>>>>> > <mailto:hibernate-dev at lists.jboss.org>
>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> >
>>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
More information about the hibernate-dev
mailing list