mysql之 CentOS系統針對mysql引數優化
核心相關引數(/etc/sysctl.conf)
以下引數可以直接放到sysctl.conf檔案的末尾:
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
加快TCP連線的回收:
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
TCP連線接收和傳送緩衝區大小的預設值和最大值:
net.core.wmem_default = 87380
net.core.wmem_max = 16777216
net.core.rmem_default = 87380
net.core.rmem_max = 16777216
減少失效連線所佔用的TCP資源的數量,加快資源回收的效率
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
kernel.shmmax = 4294967295
Linux核心引數中最重要的引數之一,用於定義單個共享記憶體段的最大值。
注意:
1. 這個引數應該設定的足夠大,以便能在一個共享記憶體段下容納整個的Innodb
緩衝池的大小
2. 這個值的大小對於64位linux系統,可取的最大值為實體記憶體值-1byte,建議
值為大於實體記憶體的一半,一般取值大於Innodb緩衝池的大小即可,可以取實體記憶體-1byte
vm.swappiness = 0
這個引數當記憶體不足時會對效能產生比較明顯的影響。
Linux系統記憶體交換區:
在Linux系統安裝時都會有一個特殊的磁碟分割槽,稱之為系統交換分割槽。
使用free-m命令可以看到swap就是記憶體交換區.
作用:
當作業系統因為沒有足夠的記憶體時就會將一些虛擬記憶體寫到磁碟的交換區中
這樣就會發生記憶體交換。
在MySQL伺服器上是否要使用交換分割槽有一些爭議:
在MySQL服務所在的Linux系統上完全禁用交換分割槽。
帶來的風險:
1. 降低作業系統的效能
2. 容易造成記憶體溢位,崩潰,或都被作業系統kill掉
結論:
在MySQL伺服器上保留交換區還是很必要的,但是要控制何時使用交換分割槽。
Vm.swappiness = 0
就是告訴Linux核心除非虛擬記憶體完全滿了,否則不要使用交換區。
增加資源限制(/etc/security/limit.conf)
這個檔案實際上是Linux PAM也就是插入式認證模組的配置檔案。
開啟檔案數的限制:
soft nofile 65535
hard nofile 65535
* 表示對所有使用者有效
soft 指的是當前系統生效的設定
hard 表明系統中所能設定的最大值
nofile 表示所限制的資源是開啟檔案的最大數目
65535 限制的數量
soft不能大於hard
直接加到limit.conf檔案的末尾就可以了。
結論:把可開啟的檔案數量增加到65535個以保證可以開啟足夠多的檔案控制程式碼。
注意:這個檔案的修改需要重啟系統才能生效。
磁碟排程策略(/sys/block/devname/queue/scheduler)
cat /sys/block/devname/queue/scheduler
排程策略: noop anticipatory deadline [cfg]
noop(電梯式排程策略)
NOOP實現了一個FIFO佇列,它像電梯的工作方法一樣對I/O請求進行組織,當有一個新
的請求到來時,它將請求合併到最近的請求之後,以此來保證請求同一介質。NOOP傾向餓死讀而
利於寫,因此NOOP對於快閃記憶體裝置、RAM及嵌入式系統是最好的選擇。
deadline(截止時間排程策略)
deadline確保了在一個截止時間內服務請求,這個截止時間是可調整的,而預設讀期限
短於寫期限。這樣就防止了寫操作因為不能被讀取而餓死的現象,deadline對資料庫類應用是最
好的選擇。
anticipatory(預料I/O排程策略)
本質上與deadline一樣,但在最後一次讀操作之後,要等待6ms,才能繼續進行對其它I/O
請求進行排程。它會在每個6ms中插入新的I/O操作,而會將一些小寫入流合併成一個大寫入流,用
寫入延時換區最大的寫入吞吐量。AS適合於寫入較多的環境,比如檔案伺服器,AS對資料庫環境表
現很差。
修改排程策略:
echo <schedulername> > /sys/block/devname/queue/scheduler
如 echo deadline /sys/block/devname/queue/scheduler
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31383567/viewspace-2215229/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL優化之系統變數優化MySql優化變數
- MySQL 針對 like 條件的優化MySql優化
- (mysql優化-3) 系統優化MySql優化
- mysql 引數調優MySql
- MySQL最佳化之系統變數最佳化MySql變數
- MySQL 持久化系統變數MySql持久化變數
- MySQL 配置InnoDB配置非持久優化器統計資訊引數MySql優化
- MySQL調優之索引優化MySql索引優化
- 淺析MySQL語句優化中的explain引數MySql優化AI
- Mysql優化系列之——優化器對子查詢的處理MySql優化
- MySQL優化之索引解析MySql優化索引
- MySQL之SQL優化技巧MySql優化
- mysql優化之explain 指令MySql優化AI
- MySQL調優之查詢優化MySql優化
- MySQL之SQL語句優化MySql優化
- [玩轉MySQL之六]MySQL查詢優化器MySql優化
- centos 讓 mysql 隨系統啟動CentOSMySql
- TiDB與MySQL優化器對照TiDBMySql優化
- 《MySQL 效能優化》之理解 MySQL 體系結構MySql優化
- MySQL(二) MySql常用優化MySql優化
- mysql優化MySql優化
- Mysql 優化MySql優化
- [MySQL 優化] Explain 之 type 詳解MySql優化AI
- MySQL效能優化之索引設計MySql優化索引
- MySQL之SQL優化詳解(二)MySql優化
- MySQL之SQL優化詳解(三)MySql優化
- MySQL之SQL優化詳解(一)MySql優化
- 十七、Mysql之SQL優化查詢MySql優化
- mysql優化之讀寫分離MySql優化
- MySQL 8.x伺服器引數調優MySql伺服器
- 《MySQL 效能優化》之 InnoDB 儲存引擎MySql優化儲存引擎
- MySQL優化之覆蓋索引的使用MySql優化索引
- MySQL分優化之超大頁查詢MySql優化
- Mysql索引優化之索引的分類MySql索引優化
- MySQL優化學習筆記之explainMySql優化筆記AI
- MySQL優化學習筆記之索引MySql優化筆記索引
- 【MySQL】三、效能優化之 覆蓋索引MySql優化索引
- mysql效能優化MySql優化