mysql之 CentOS系統針對mysql引數優化

張衝andy發表於2018-09-29

核心相關引數(/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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章