每天进步一点点————MUMA架构优化和应用优化

一、           MUMA架构优化

         目前的商用服务器答题可以分为三类：

                   对称多处理器结构（Symmetric Multi-Processor，SMP）：在一台计算机上汇集了一组处理区（多CPU），各个CPU之间共享内存子系统和总线结构。所有的CPU都可以平等地访问内存、I/O和外设。对SMP服务器进行扩展的方式有增加内存、使用更快的CPU、增加CPU扩充I/O，以及增加更多的磁盘等。

                   非一致存储访问结构（Non-Uniform Memory Access，MUMA）：把一个服务器分成多个节点，每个节点拥有多高CPU，节点内部使用公有的内存对于本届电所有的CPU都是相同的，而对于其他节点中所有CPU都是不通的。因此每个CPU可以访问整个系统内存，但是访问本届电的内存速度最快，访问非本届电的内存速度较慢（需要经过互联模块），即CPU访问内存的速度与节点距离有关，距离成为Node Distance。

1.   显示当前NUMA节点情况。

[root@EMPBJDBServB~]# numactl --hardware

available: 8 nodes (0-7)                      ——————当前节点有8个node

node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 6869 70 71

node 0 size: 32743 MB                       ——————node0内存大约为32G

node 0 free: 18572 MB

node 1 cpus: 8 9 10 11 12 13 14 15 72 73 7475 76 77 78 79

node 1 size: 32768 MB

node 1 free: 23453 MB

node 2 cpus: 16 17 18 19 20 21 22 23 80 8182 83 84 85 86 87

node 2 size: 32768 MB

node 2 free: 23279 MB

node 3 cpus: 24 25 26 27 28 29 30 31 88 8990 91 92 93 94 95

node 3 size: 32768 MB

node 3 free: 22283 MB

node 4 cpus: 32 33 34 35 36 37 38 39 96 9798 99 100 101 102 103

node 4 size: 32768 MB

node 4 free: 23631 MB

node 5 cpus: 40 41 42 43 44 45 46 47 104105 106 107 108 109 110 111

node 5 size: 32768 MB

node 5 free: 23718 MB

node 6 cpus: 48 49 50 51 52 53 54 55 112113 114 115 116 117 118 119

node 6 size: 32768 MB

node 6 free: 22356 MB

node 7 cpus: 56 57 58 59 60 61 62 63 120121 122 123 124 125 126 127

node 7 size: 32768 MB

node 7 free: 22234 MB

node distances:

node  0   1   2  3   4   5  6   7

 0:  10  12 11  11  11 12  12  12

 1:  12  10 11  11  12 12  11  12

 2:  11  11 10  12  12 11  12  12

 3:  11  11  12  10 12  12  12  11

 4:  11  12 12  12  10 12  11  11

 5:  12  12 11  12  12 10  11  11

 6:  12  11 12  12  11 11  10  12

 7:  12  12 12  11  11 11  12  10

节点之间距离是指从1节点访问0节点上的内存需要付出的代价的一种形式。

2.   MUMA的内存分配策略有以下4种

缺省default：总是在本地节点分配（分配在当前进程运行的节点上）

绑定bind：强制分配到指定节点上

交叉interleave：在所有节点或者指定节点上交叉分配内存

优先preferred：在指定节点上分配，失败则在其他节点上分配

3.   显示当前系统NUMA策略

[root@EMPBJDBServB~]# numactl --show

policy: default

preferred node: current

physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 1213 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 3839 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 6465 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 9091 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112113 114 115 116 117 118 119 120 121 122 123 124 125 126 127

cpubind: 0 1 2 3 4 5 6 7

nodebind: 0 1 2 3 4 5 6 7

membind: 0 1 2 3 4 5 6 7

因为NUMA默认的内存分配策略是有线在进程锁在CPU的本地内存中分配，会导致CPU节点之间不均衡，当某个CPU节点内存不足时，会导致SWAP产生，而不是从远程节点分配内存，这就是SWAP INSANITY现象。

因为MySQL是但进程多线程数据库，为了防止SWAP INSANITY现象，所以如果单机只运行一个MySQL实例，可以选择关闭MUMA。关闭MUMA方式有两种：

      修改/etc/grub.conf文件，在kernel那行追加numa=off

 

[root@localhost~]# more /etc/grub.conf

# grub.conf generated by anaconda

#

# Note that you do not have to rerun grubafter making changes to this file

# NOTICE: You have a /boot partition.  Thismeans that

#         all kernel and initrd paths are relative to /boot/, eg.

#         root (hd0,0)

#         kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root

#         initrd /initrd-[generic-]version.img

#boot=/dev/sda

default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Red Hat Enterprise Linux(2.6.32-358.el6.x86_64)

       root (hd0,0)

       kernel /vmlinuz-2.6.32-358.el6.x86_64 roroot=/dev/mapper/VolGroup-lv_root rd_NO_LUKS rd_NO_MDrd_LVM_LV=VolGroup/lv_swap crashkernel=128M LANG=zh_CN.UTF-8 rd_LVM

_LV=VolGroup/lv_root  elevator=deadline KEYBOARDTYPE=pc KEYTABLE=usrd_NO_DM rhgb quietmuma=off

       initrd /initramfs-2.6.32-358.el6.x86_64.img

 

 

或者通过mumactl命令将NUMA内存分配策略修改为interleave。

修改mysqld_safe启动脚本，在cmd="$NOHUP_NICENESS"后添加如下信息

cmd="/usr/bin/numactl--interleave all $cmd"

，启动MySQL时指定内存分配策略为interleave

 

 

                   海量并行处理结构（Massive Parallel Processing，MPP）：解决了NUMA架构增加CPU并不能线性提升性能的问题，由于MPP由多个SMP服务器通过一定的节点互联网进行连接，每个节点值访问子集的本地资源（内存、存储等），不防问其他节点的资源，是一种share nothing的架构，因而理论上可以无线扩展。MPP架构中，每个节点的CPU不能访问其他节点的内存，此时节点之间的信息交换是通过节点互联网络实现的，这个过程称为data redistribution。但是MPP服务器需要复杂的机制来调度和平衡各个节点的负载和并行处理。目前基于MPP技术的服务器通过例如数据库软件等系统软件来屏蔽底层的复杂性。

二、           应用优化

1.   使用连接池

         对于访问数据库来说，简历连接的代价比较昂贵，因此，我们要有必要建立“连接池”以提供高性能访问的性能。

2.   减少对MySQL的访问

避免对同一数据做重复检索

         应用中需要理清对数据库的访问逻辑。能够一次连接就能图去除所有结果，就不用两次连接，这样可以大大减少对数据库无谓的重复访问。

 

使用查询缓存

         MySQL的查询缓存是在4.1版本后新增的功能，它的作用是存储select查询的文本以及相应的结果。如果随后收到一个相同的查询，服务器会从查询缓存中重新得到查询结果，而不再需要解析和执行查询。

         查询缓存的使用对象是更新不频繁的表，当表更改后，查询缓存值的相关条目被清空。

 

查询缓存相关的参数主要有以下几个：

         mysql> show variables like'%query_cache%';

+------------------------------+---------+

| Variable_name                | Value   |

+------------------------------+---------+

| have_query_cache             | YES     | ——在服务器上安装时是否已经配置了高速缓存

| query_cache_limit            | 1048576 |

| query_cache_min_res_unit     | 4096   |

| query_cache_size             | 1048576 |——表明缓存大小，单位MB

| query_cache_type             | OFF     |——变量值从0到2，含义分别为：0或者off（缓存关闭）、1或者on（缓存打开，使用SQL_NO_CACHE提示的select除外）、2或者demand（只有带SQL_CACHE的SELECT语句提供高速缓存）

| query_cache_wlock_invalidate | OFF     |

+------------------------------+---------+

6 rows in set (0.00 sec)

 

MySQL查询缓存的性能监控参数

mysql> show status like 'Qcache%';

+-------------------------+---------+

| Variable_name           | Value   |

+-------------------------+---------+

| Qcache_free_blocks      | 1      |                        ——查询缓存的空闲内存空间总数

| Qcache_free_memory      | 1031368 |                     ——查询缓存的空闲内存数

| Qcache_hits             | 0       |                      ——缓存采样数数目

| Qcache_inserts          | 0       |                       ——被加入到缓存中的查询数目

| Qcache_lowmem_prunes    | 0      |                   ——因为缺少内存而被从缓存中删除的查询数目

| Qcache_not_cached       | 2      |                     ——没有被缓存的查询数目（不能或者由于QUERY_CHACHE_TYPE）

| Qcache_queries_in_cache | 0       |                          ——在缓存中已注册的查询数目

| Qcache_total_blocks     | 1      |                         ——查询缓存中块的总数目

+-------------------------+---------+

8 rows in set (0.00 sec)

增加cache层

在应用中，我们可以在应用端加CHACHE层来达到减轻数据库负担的目的。