So I altered sysbench and dropped the 100 char update statement down to
9 (UPDATE sbtestndb set c='14435575' where id=624923, with id = PK and c
= non-indexed column) and within 10 seconds of the 64 thread test, hit
the error. Didn't bother with 128 and 256 tests.
You say this has to do with each ndbd sending statuses/updates to each
mysqld? I've got two connected to the cluster but only running the tests
on 1.
-Matthew
> -----Original Message-----
> From: Pekka.Nousiainen@stripped [mailto:Pekka.Nousiainen@stripped]
> Sent: Tuesday, November 10, 2009 1:37 PM
> To: cluster@stripped
> Subject: Re: Send Buffers overloaded in NDB kernel
>
> On 091110, Boehm, Matthew wrote:
> > Interestingly, if I run the "update_index" bench (ie: UPDATE table
> SET
> > indexedColum=indexedColumn+1 WHERE PKcolumn=<rand>), that one runs
> just
> > fine all the way up to 256 threads.
> >
> > But if I try the update_nonindex, (ie: UPDATE table SET
> > nonIdxColum='<random 100 char string>' WHERE PKcolumn=<rand>), that
> is
> > the one that fails right away on the 64/128/256 thread bench.
>
> Updating indexed column takes lots of time (relatively speaking).
> So maybe that's what keeps the traffic low enough to not hit
> send buffer limit.
>
> If binlogging is off and you're not selecting masses of data
> to API, that leaves the update traffic. Maybe somebody else
> knows if it's possible to hit send buffer limit here.
>
> --
> Pekka Nousiainen, Software Engineer, Sun Microsystems / MySQL
>
> --
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe:
> http://lists.mysql.com/cluster?unsub=1
