I have had a number of request for help on how to use the
DBT2
tree I'm maintaining on www.iclaustron.com. There is an
extensive
set of scripts used to make it very easy to run DBT2 runs
and
to start and stop cluster nodes and MySQL Servers. I
personally
use it also to start MySQL Servers and clusters also when
not
using DBT2.
However these scripts haven't had an overall description
yet
although each component is very thoroughly documented by
using --help on the scripts (I tend to document very
heavily these things since I otherwise forget it myself).
Now I added a new README file README-ICLAUSTRON which
explains which scripts are used and their relation
and which configuration files to set-up and a
pointer to example configuration files.
Hopefully this will make it easier to use DBT2,
particularly DBT2 for MySQL Cluster. …
I thought a bit more on the adaptive send algorithm and kind of
like
the following approach:
Keep track of how many sends we are at maximum allowed to
wait
until we send in any ways. This is the state of the adaptive
send
algorithm which is adapted through the following use of
statistics
(we call this state variable max_waits):
For each send we calculate how long time has passed since
the
send that was sent max_waits sends ago. We also do the same
for
max_waits + 1. At certain intervals (e.g. every 10 milliseconds)
we
calculate the mean wait that a send would have to do, if this
lies
within half the desired maximum wait then we accept the
current
state, if also the mean value using max_waits + 1 is
acceptable
then we increase the state by one. If the state isn't
acceptable
we decrease it by one.
In the actual decision …
In the current API when sending one takes the Transporter mutex
and
then sends all the signals generated towards one or many
nodes.
There is also some handling of adaptive sends, however this
adaptive
algorithm takes care of all nodes, thus waiting for sending is
global
on all nodes.
The new design uses one mutex for the sending, however this mutex
only
controls the sending part of one socket. Also the time for
holding the
mutex is just enough to check the state, no send operations are
done
while holding the mutex.
The new adaptive algorithm will keep track of the last sent
messages on
this socket and in principle the idea is that if it's at least a
90-99%
probability that it is a good idea to wait, then it will wait
(unless
the application has provided the force send flag). It will do so
by
keeping track of the last few messages sent. …