一、???????????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 quiet muma=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層來達到減輕數據庫負擔的目的。

總結

以上是生活随笔為你收集整理的每天进步一点点————MUMA架构优化和应用优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。