My Oracle Support Banner

Optimising MySQL Cluster ndbmtd with ThreadConfig (Doc ID 2497622.1)

Last updated on MARCH 02, 2020

Applies to:

MySQL Cluster - Version 7.2 and later
Information in this document applies to any platform.

Purpose

This Document will explain how configuring ThreadConfig can be beneficial and how the thread placement can have an effect on the overall cluster's stability and performance.

Scope

This example will focus on a "typical" Enterprise configuration - a dual socket server.

VMs are not in scope for this KM as they add an extra layer of complexity to the environment. They are excluded from this example to keep it as simple as possible while still showing the principles.



The Server currently has only a single socket populated with a CPU ( this will be relevant when adding a 2nd CPU later , for discussions around Non-uniform_memory_access / NUMA ), but is capable of a 2nd physical CPU.
CPU is SMT ( Simultaneous_multithreading - see below ) capable with 8 cores ( 16 threads).
Server has 64G RAM populated as 4x16G Dimms ( explicitly mentioned , again due to NUMA considerations )

Assuming the pre requisite reading has been covered, this example will cover

The scenario can be one where a cluster has been performing nominally using a conservative config.ini for a long time, satisfactorily, eg

MaxNoOfExecutionThreads=12


During a period of growth, the cluster has been identified to be periodically slowing down and it has been isolated to the ndbmtd nodes.

An investigation by the system administrator into the performance of the server has indicated that the host is not resource bound due to IO or NETWORK. There are however, high levels of CPU load seen during the slowdowns. On detailed inspection, no cores appear 100% loaded, some even appear idle, yet there are high levels of context switching seen which correlate with the timing of the slowdowns.

The conclusion here is that the CPU is not operating at 100% capacity ( evidenced by the idle and not 100% cores ) and in conjunction with the high levels of context switching indicates a problem with the cluster configuration. This points to the configuration of the ndbmtd nodes and therefore the cluster not being optimal or making full use of the host's resources.



As performance tuning is a complex process( even more so in a distributed cluster environment ), it is a prerequisite to have a solid understanding, not only of MySQL Cluster itself but also the OS and hardware on which it runs and how they interact.

 

 

Details

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Purpose
Scope
Details
 ndbmtd Variables
 Manual Pages
 Computer Science Concepts
 MaxNoOfExecutionThreads -> ThreadConfig
 A better ThreadConfig ( cpubind )
 CPU
 Explanation and theory
 Alternative Config Example

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.