we're using debian standard kernel, which config shows:
grep NUMA /boot/config-2.6.26-2-amd64
# CONFIG_X86_NUMAQ is not set
# CONFIG_NUMA_EMU is not set
so i think numa is enabled.
Swapiness is set to vm.swapiness=1, so it should not swap, round about 12gb of ram shown
While we're trying ndbmtd, MaxNoOfExecutionThreads was set to 4 (4core cpu's are used).
Without mt were using default values.
Am 13.10.2010 um 17:06 schrieb Johan Andersson:
> Hi Martin,
> have you disabled NUMA?
> Do you have cpu cores >= MaxNoOfExecutionThreads (in config.ini)?
> Martin Probst (RobHost Support) wrote:
>> hi guys,
>> sorry for my english and phrasing, but i'm a little bit pissed of, of
> mysql-cluster today.
>> This morning we've had a full cluster restart again, sam failure as the last 3
> times (bug report is here: http://bugs.mysql.com/bug.php?id=55868).
>> So we decide to upgrade our cluster from 7.1.4 to 7.1.8 and try ndbmtd again
> (we've tried about a year ago and it was horrible, node failures and restarts every day).
> So updating the cluster was the first fail, it need's a lot of try's until it read's the
> local checkpoint from disks (a lot of the lovely 'unknown error, please report a bug'
> failures occur). About an hour later, the cluster has finished restarting and all seem's
> fine. About 30 minutes later, the cluster fails again with some missing heartbeats and a
> handful of node restarts. At the moment we're switching back to ndbd without the
>> So ok, now you'll say, show us your config, whats with the hardware et cetera.
> And this is the point, our config does not changed since a year, we've got an engineer
> from mysql which have looked over (not so cheap ;) ), we've involved percona into our
> configuration, which have said thats all fine and does not have any suggestions. Our
> hardware monitoring shows no peaks, no failures et cetera. So i'm at a point, where i
> don't understand what's wrong with this.
>> The next confusing thing is, 7.0.13 runs stable, and i mean really stable for our
> purposes (about 5 months without any failure) with the same config and hardware. So i cant
> believe, that we're the only mysql-cluster customer, which has such problems and
>> M. Probst
>> MySQL Cluster Mailing List
>> For list archives: http://lists.mysql.com/cluster
>> To unsubscribe: http://lists.mysql.com/cluster?unsub=1