• Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None


      NUMA hardware is becoming more common. Access to RAM that is not local to the CPU nodes is more expensive than accessing it locally. MariaDB should implement mechanisms to optimize the workload to keep CPUs of a node accessing their local memory.

      example numa architecture:

      $ numactl  --hardware
      available: 2 nodes (0,8)
      node 0 cpus: 0 8 16 24 32 40 48 56 64 72
      node 0 size: 130705 MB
      node 0 free: 80310 MB
      node 8 cpus: 80 88 96 104 112 120 128 136 144
      node 8 size: 130649 MB
      node 8 free: 81152 MB
      node distances:
      node   0   8
        0:  10  40
        8:  40  10

      Components of the implementation include:

      • A meaningful configuration that makes conflicts with existing settings obvious
      • each innodb buffer pool instances to be constrained to a NUMA node
      • SQL threads to be allocated by a user configurable map of one or more of user, connecting host, default database (based on initial connection)
      • The user SQL thread will be pinned to CPUs associated with a node
      • Innodb accesses by the SQL thread will be to/from the innodb buffer pool instances first
      • Accounting of CPU/memory utilization for the mapping identifier to enable automated or configuration based of node to this mapping identifier.
      • Innodb background threads to be per node to facilitate the innodb buffer pool instance processing locally

      (Marko, Jan, et al. please edit with important design/implementation details)

      I'm willing to mentor this (with help).


        Issue Links



              Unassigned Unassigned
              danblack Daniel Black
              1 Vote for this issue
              9 Start watching this issue



                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.