達夢數據庫實戰

咱們國產軟件，硬件都在飛速發展。但是發展過程中，一些敢於挑戰勇敢嚐鮮 (其實誰願意做小白鼠，還不是身不由己) 的人都經歷過一些痛苦的過程，獲得了被動的成長，這裏分享給大家。

那些語法的坑兒

1. 我們應用程序持久層使用的是 JPA，使用一些 native 語法時會有不兼容問題，mysql 運行 OK 的，達夢那邊報錯。

2. 如果 JPA 框架定義 Entity 時使用了 text 作爲數據類型，就不能自動生成數據表。

併發支持

1. 放在國產化操作系統麒麟上對性能造成極大損耗也是一方面。一旦有用戶使用，估計併發量也就幾十，8 核 CPU 直接就跑滿了。爲了臨時解決問題，我申請擴容到了 24 核，竟然還是佔用率很高。而且使用率會一直有瞬時飆升的尖刺。

當時首先想到的是從架構上解決問題，因爲我們申請了兩臺服務器，想從單機更換到從主模式。結果告知先要找商務，因爲主從版本價格不一樣。我們線上用戶已經在用了，有百萬級別正式數據，要重裝，爆個粗口不過分吧。

當時的現象是 CPU 很高但是 iowait 爲 0，先說說這意味着什麼。

每個 CPU 可以處於以下狀態之一: user, sys, idle, iowait , 我們通過 iostat 工具可以看到這幾個狀態的值，它們都是以百分比的形式顯示的，CPU 是在這幾個狀態之間切換，所以這幾個值總和是 100%

需要說明一點，上圖中的 %sys, %user, %idle, %iowait 的百分比值都是針對所有的 CPU 來說的，統計的是全局的信息，並不是指單個進程的數據。

實際上我們沒有在數據庫做什麼計算操作，就是有些關聯查詢。理論上應該 IOwait 高，因爲大多數時間就是應該 CPU 空閒，等待數據庫返回處理結果，因爲結果集很大。但實際情況是 cpu 高，一般情況下產生這種情況的原因是鎖等待導致 CPU 空轉，消耗了大量 CPU。

這種處理機制和我之前遇到問題一個問題很像。之前公司其他團隊項目中遇到一個小衆的消息隊列。有個開發小哥哥調整了一個隊列參數，從原來的如果消費端去取消息時等待一段時間，如果超時還沒有數據返回再去處理別的任務，改成了線程來檢查數據有沒有，沒有則立即返回。當時週二上線沒有問題，一直到週五交易量劇增時，問題一下子爆發，當時的應急預案: 降級，將版本回退到前一天等措施都不解決問題，一直到將版本回退到週一的版本才恢復。通過故障報告的時間線都能感覺到當時團隊的絕望和無助。

數據庫連接數的調整

上週我有給我們同學講過一般業務的應用線程數在 5-8 是一個合理的數值。但是我們項目用戶一開始使用時使用默認的 8 個連接數，直接出現了用戶無法訪問，在 nginx 層出現了大量 close_wait 的情況。

這說明什麼問題呢？咱們來看看四次揮手過程：

當客戶端與服務端進行通信時，如果客戶端頻繁刷新頁面或發送請求，服務端在處理這些請求時可能會進入 CLOSE_WAIT 狀態。具體來說，當客戶端發送一個 FIN 包表示斷開連接時，服務端會回覆一個 ACK 確認收到 FIN 包，但如果服務端此時還有數據未發送完畢，就會進入 CLOSE_WAIT 狀態。

那服務端到底在幹什麼呢？在等待數據庫的返回結果。也就是說數據庫線程還沒有被釋放。咱們課堂上講過 5 到 8 個線程是建立在平均數據庫響應耗時在 5ms 以下，而達夢數據庫的性能導致數據庫返回數據時間大大延長，理論上應該增加數據庫連接線程數。

但我第一次跟首席架構師提這個問題的時候，他沒有采納。現在想他是對的，因爲那時候我們還是 8 個核，加大連接 CPU 馬上就會被打爆了。後來升到 24 核，我們的連接數就由默認的 8 升到了 100，才導致 24 核的 CPU 使用率還是很高。

我當時還建議首席架構師調整了一個 linux 系統參數: 文件句柄數。其實當時調整了這個參數後並不沒有看到明顯的改善，現在咱們來分析一下當時的調整有沒有用。

當時 lsof 命令查看結果已經超過了 ulimit 顯示的最大連接數，因爲我們調大數據庫連接數已經是在調大了操作系統文件句柄數之後，如果是之前那還真有可能因爲文件句柄數不夠操作系統關閉一些連接。

目前數據庫性能的問題已經被徹底解決了。解決方法一方面對常用的 sql 查詢進行優化，將性能提升了 10 倍。但徹底解決還是靠從架構上從之前使用單機數據庫採用主從讀寫分離架構，增加數據庫服務器的配置，用三臺做成集羣來解決的。

爲什麼改成主從讀寫分離架構能夠解決問題呢？

前面我有描述過，我們 CPU 使用率很高，本質上是讀寫鎖競爭引起的。讀和寫分離，讓讀請求讀從庫，寫請求寫主庫會有效減少鎖競爭。

另外，我們在解決問題過程中有涉及一個小知識：DNS 解析。

DNS（Domain Name System）就像一個互聯網的電話簿，當用戶在瀏覽器中輸入一個域名，如 www.example.com，計算機需要知道對應的 IP 地址才能與服務器建立連接並獲取網頁內容。DNS 解析就是在這個 “電話簿” 中查找域名對應的 IP 地址的過程。

最簡單的 DNS 解析就是 host 綁定

本質上就是告訴系統哪個域名。

一般服務器上會使用 DNS 服務，服務的配置文件裏常見的有設置 DNS 服務器 8.8.8.8 這個地址作爲代理服務器來幫助進行 DNS 解析。如果公司有策略訪問不了這個服務器呢？那如果不用別的措施，百度、騰訊這些網址就解析不出來，那就用不了了。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/W7yIJu6tW3mCjIJ5_RfiJg