9:20 p.m.
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
9:39 p.m.
Rehashing timeouts! (rehashRpcTimeout)
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Paolo Romano
Sent: Thursday, July 21, 2011 3:21 PM
To: infinispan-dev(a)lists.jboss.org
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
infinispan-dev(a)lists.jboss.org
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.
9:48 p.m.
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: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Paolo Romano
Sent: Thursday, July 21, 2011 3:21 PM
To: infinispan-dev(a)lists.jboss.org
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
infinispan-dev(a)lists.jboss.org
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:47 p.m.
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
4678
days inactive
4684
days old
infinispan-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Erik Salter -
Manik Surtani -
Paolo Romano