[infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

Paolo Romano
Hi,

in the last Cloud-TM's meeting in Rome we have discussed the idea of
posting a poll asking to ISPN's users which parameters they consider
more complex to tune, or which parameters they consider as more
important to be self-tuned.

Before we post the poll, however, we thought to first ask you if you
think that we could suggest also different parameters.

The current list of parameters includes:

     - size of the marshalling buffer

     - frequency with which replicationQueue (for asynchronous acks) is
processed:
         - clustering->async-> replQueueMaxElements
         - clustering->async-> replQueueInterval

     -number of max concurrent transactions  (currently this is
unbounded, but we could self-tune the multi-programming level to
maximize performance depending on the number of available cores, the
actual conflict rate among transactions etc.)

     -lock striping, also adapting size of lock pool (striping can lead
to false sharing, but reduce the memory footprint and the size of the
exchanged messages)

     -adaptive timeout for deadlock detection, based on the avg duration
of a transaction/conflict rate etc

Any suggestions?

Cheers,

     Paolo
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

Erik Salter
Rehashing timeouts! (rehashRpcTimeout)

Erik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paolo Romano
Sent: Thursday, July 21, 2011 3:21 PM
To: [hidden email]
Subject: [infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

Hi,

in the last Cloud-TM's meeting in Rome we have discussed the idea of posting a poll asking to ISPN's users which parameters they consider more complex to tune, or which parameters they consider as more important to be self-tuned.

Before we post the poll, however, we thought to first ask you if you think that we could suggest also different parameters.

The current list of parameters includes:

     - size of the marshalling buffer

     - frequency with which replicationQueue (for asynchronous acks) is
processed:
         - clustering->async-> replQueueMaxElements
         - clustering->async-> replQueueInterval

     -number of max concurrent transactions  (currently this is unbounded, but we could self-tune the multi-programming level to maximize performance depending on the number of available cores, the actual conflict rate among transactions etc.)

     -lock striping, also adapting size of lock pool (striping can lead to false sharing, but reduce the memory footprint and the size of the exchanged messages)

     -adaptive timeout for deadlock detection, based on the avg duration of a transaction/conflict rate etc

Any suggestions?

Cheers,

     Paolo
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

Paolo Romano
Thanks!

This controls the time after which data is redistributed across the
nodes following a join or leave event, is it correct?

     P

On 7/21/11 8:39 PM, Erik Salter wrote:

> Rehashing timeouts! (rehashRpcTimeout)
>
> Erik
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Paolo Romano
> Sent: Thursday, July 21, 2011 3:21 PM
> To: [hidden email]
> Subject: [infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters
>
> Hi,
>
> in the last Cloud-TM's meeting in Rome we have discussed the idea of posting a poll asking to ISPN's users which parameters they consider more complex to tune, or which parameters they consider as more important to be self-tuned.
>
> Before we post the poll, however, we thought to first ask you if you think that we could suggest also different parameters.
>
> The current list of parameters includes:
>
>       - size of the marshalling buffer
>
>       - frequency with which replicationQueue (for asynchronous acks) is
> processed:
>           - clustering->async->  replQueueMaxElements
>           - clustering->async->  replQueueInterval
>
>       -number of max concurrent transactions  (currently this is unbounded, but we could self-tune the multi-programming level to maximize performance depending on the number of available cores, the actual conflict rate among transactions etc.)
>
>       -lock striping, also adapting size of lock pool (striping can lead to false sharing, but reduce the memory footprint and the size of the exchanged messages)
>
>       -adaptive timeout for deadlock detection, based on the avg duration of a transaction/conflict rate etc
>
> Any suggestions?
>
> Cheers,
>
>       Paolo
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] poll on self-tuning ISPN / JGROUPS paramters

Manik Surtani
In reply to this post by Paolo Romano
I would also add:

* Lock acquisition timeout
* various thread pool sizes

Cheers
Manik

On 21 Jul 2011, at 20:20, Paolo Romano wrote:

> Hi,
>
> in the last Cloud-TM's meeting in Rome we have discussed the idea of
> posting a poll asking to ISPN's users which parameters they consider
> more complex to tune, or which parameters they consider as more
> important to be self-tuned.
>
> Before we post the poll, however, we thought to first ask you if you
> think that we could suggest also different parameters.
>
> The current list of parameters includes:
>
>     - size of the marshalling buffer
>
>     - frequency with which replicationQueue (for asynchronous acks) is
> processed:
>         - clustering->async-> replQueueMaxElements
>         - clustering->async-> replQueueInterval
>
>     -number of max concurrent transactions  (currently this is
> unbounded, but we could self-tune the multi-programming level to
> maximize performance depending on the number of available cores, the
> actual conflict rate among transactions etc.)
>
>     -lock striping, also adapting size of lock pool (striping can lead
> to false sharing, but reduce the memory footprint and the size of the
> exchanged messages)
>
>     -adaptive timeout for deadlock detection, based on the avg duration
> of a transaction/conflict rate etc
>
> Any suggestions?
>
> Cheers,
>
>     Paolo
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev