介紹

數據庫效能是企業應用體驗最重要的組成部分之一。整個行業，無論是基於 Web 的電子商務、社交媒體、雲服務還是大多數其他企業應用程式，他們都使用資料庫。

我們編寫本指南是為了幫助在基於第三代英特爾® 至強® 可擴充套件處理器的平臺上部署MySQL*或 PostgreSQL作為後端資料庫的應用程式開發人員和資料庫管理員。

本指南假定讀者具有 Linux 作業系統和 MySQL或 PostgreSQL 的一般工作知識。我們的目的是幫助讀者在基於第三代英特爾® 至強® 可擴充套件處理器的平臺上獲得最佳資料庫效能。

但是，請注意，我們依賴使用者根據他們的具體情況仔細考慮這些設定，因為資料庫可以以多種方式部署。我們使用以下配置測試了我們的建議：

MySQL 8.0.23
PostgreSQL 13.2
Ubuntu 20.04.2 LTS
HammerDB v4.0
2-socket 3rd Generation Intel® Xeon® Scalable

第三代英特爾® 至強® 可擴充套件處理器提供業界領先的工作負載優化平臺，內建 AI 加速，提供無縫的效能基礎，幫助加速資料的變革性影響，從多雲到智慧邊緣再返回。

以下是這些新處理器的一些特性：

增強的效能，每個插槽最多 40 個核心，單核睿頻高達 3.7 GHz
通過 VNNI 增強英特爾® 深度學習加速
更多英特爾® Ultra Path 互連
提高 DDR4 記憶體速度和容量，高達 6TB 系統記憶體容量（每插槽）DRAM + Intel® Optane™ Persistent Memory 200 系列
英特爾® 高階向量擴充套件
英特爾® Security Essentials 和英特爾® 資料中心安全庫
增強型英特爾® Speed Select 技術（英特爾 SST）
支援英特爾® Optane™ 持久記憶體 (Pmem) 200 系列
英特爾® 乙太網網路介面卡 E810 系列

藉助英特爾第三代英特爾® 至強® 可擴充套件處理器和英特爾® 傲騰™ 持久記憶體 200 系列，2 插槽系統可支援高達 12 TB 的系統記憶體。

這使資料庫管理員能夠執行超大型資料庫，而無需從儲存或網路中獲取不斷的資料。此外，搭配英特爾® 3D NAND SD D7-P5510（每盤最高支援 7.68 TB）和英特爾傲騰 SSD P5800X（讀寫延遲為 5us 和 150 萬 IOPS 隨機讀取），第三代英特爾® 至強®可擴充套件平臺旨在處理最苛刻的企業資料庫，從最小到最大。

最後，藉助支援 100/50/25/10GbE 連線速度的英特爾® 乙太網網路介面卡 E810 系列，可以以閃電般的速度完成資料庫備份和恢復。

開源關聯式資料庫管理系統

關聯式資料庫管理系統 (RDBMS) 提供了企業軟體架構中一些最重要的基礎元件。基於資料的關係模型，資料庫軟體使用行業標準SQL（結構化查詢語言）來定義和查詢儲存在關係中的資料。

40 多年來，關聯式資料庫已被證明是最流行的資料儲存和檢索格式，RDS（關聯式資料庫服務）仍然是雲服務提供商提供的增長最快的服務。

DB-Engines 排名列出了最受歡迎的資料庫，其中關聯式資料庫佔總排名的 74%。

關聯式資料庫工作負載分為兩大類，OLTP（線上事務處理）和OLAP（線上分析處理），這兩種工作負載具有相當不同的特徵。

在本文中，我們專注於為兩個最受歡迎的開源 RDBMS MySQL 和 PostgreSQL 調整 OLTP 工作負載。MySQL 是最受歡迎的開源 RDBMS，已在英特爾平臺上執行超過 25 年。

最新版本 8.0.23 於 2021 年 1 月釋出。MySQL 支援使用可定義用於建立表的多個儲存引擎。為了獲得最高水平的效能，我們建議使用 InnoDB 儲存引擎升級到 MySQL 8.0.23，以從最新的 InnoDB 可擴充套件性增強中受益。

在上了解有關 MySQL 的更多資訊 . PostgreSQL 是 RDBMS 中最受歡迎的增長最快的資料庫，它為許多增強型資料庫版本提供了基礎，例如 Citus*、Greenplum* 和 EnterpriseDB*。

最新的PostgreSQL 版本是 13。PostgreSQL 13 在效能和可擴充套件性方面比以前的版本有所改進，因此我們建議所有客戶儘可能遷移到此版本。

硬體調優

從CPU核數到記憶體和儲存的速度和容量，選擇最優的計算資源大小是滿足業務需求的關鍵。第三代Intel®Xeon®可擴充套件處理器支援多達40核，多達6tb的系統記憶體，每個插槽多達8個記憶體通道。

下面的表1顯示了一些可用的CPU SKU。通常，系統中的CPU核心越多，系統可以支援的併發資料庫使用者就越多。CPU頻率是另一個需要考慮的關鍵因素。

頻率越快，執行一個典型操作所需的時間就越短。 在選擇處理器時，要計劃處理資料庫的峰值負載。使用歷史資料來估計高峰時間需求——您的資料庫服務必須有多少併發使用者並且仍然滿足服務水平協議(SLA)。這將幫助您確定資料庫所需的CPU核心數。

保守的估計是每個CPU核有1-3個併發使用者。例如，如果您執行在一個具有64個CPU核心(128個硬體執行緒，並啟用了Intel Hyper-ThreadingTechnology)的系統上，那麼您可以期望支援64-192個併發使用者。

併發使用者不是系統的總使用者數，而是同時訪問資料庫的使用者數。至於記憶體，我們建議為每個通道安裝至少一個記憶體DIMM，以獲得最佳效能。

這種配置提供了向處理器提供資料的最大記憶體頻寬。我們建議每 1000 個倉庫至少有 64 GB 的記憶體，但最好有 128 GB 或更多以獲得最佳使用者體驗。

表 1. 處理器 SKU

其他重要的問題是在哪裡儲存資料、重做日誌和預寫日誌 (WAL)，以及使用哪種介質？這些問題的答案對效能有很大的影響。

對於大多數用例，資料庫預熱後資料將快取在記憶體中。因此，磁碟效能對資料表的重要性不那麼重要。英特爾® 3D NANDSSD D7-P5510 因其大容量、速度和低功耗而成為絕佳選擇。

然而，對於重做日誌和 WAL，會有寫操作流，並且可能對效能非常關鍵，尤其是在使用同步提交時。重做日誌和 WAL 是大多數使用者觀察到的最常見的效能瓶頸。因此，我們建議使用 IntelOptane SSD P5800X，因為它具有接近記憶體速度的讀/寫延遲。

最後，計劃備份和恢復。使用Intel®Ethernet NetworkAdapter E810系列連線您將進行資料庫備份和恢復的系統。通過消除網路瓶頸，這將大大減少完成該任務所需的時間。

CPU 配置

安裝 linux-tools 和 cpufrequtils 用於確保 cpu 與 turbo boost 一起正常工作。

sudo apt-get install linux-tools-generic



sudo apt-get install cpufrequtils

預設情況下，Ubuntu 將縮放調控器設定為“Powersave”模式。為了獲得最佳效能，請將縮放調節器設定為“效能”。如果以下檔案“/etc/default/cpufrequtils”不存在，則建立它，並將給定的行新增到檔案中。

sudo vi /etc/default/cpufrequtils



GOVERNOR="performance"

重新啟動 cpufrequtils 模組以將縮放調控器設定為“performance”。您還需要禁用 ondemand 模組以防止它在重新啟動時覆蓋更改。

systemctl restart cpufrequtils



systemctl disable ondemand

檢查是否已應用設定以及頻率設定是否符合預期。從以下輸出中要檢查的關鍵事項是驅動程式顯示為 intel_pstate，調節器顯示為效能，頻率範圍達到 CPU 的最大頻率，並且支援升壓狀態。

在此資料夾中查詢 Linux 工具。它將位於基於您的核心的子資料夾中：

/usr/lib/linux-tools/sudo ./cpupower frequency-info



analyzing CPU 0:



driver: intel_pstate



CPUs which run at the same hardware frequency: 0



CPUs which need to have their frequency coordinated by software: 0



maximum transition latency: Cannot determine or is not supported.



hardware limits: 800 MHz - 3.40 GHz



available cpufreq governors: performance powersave

目錄中還有另一個名為 x86_energy_perf_policy 的工具，用於確定如何使用升壓狀態。預設情況下，這設定為正常，因此您需要將其設定為效能。

sudo ./x86_energy_perf_policy performance

磁碟配置

建議使用高效能 NVMe 驅動器（Intel® Optane™ SSD DC P5800X）來儲存資料庫，以防止 I/O 限制降低資料庫吞吐量，例如寫入 WAL 檔案。在 SSD DC P5800X 上安裝資料庫將提供比使用 NAND SSD 更高的效能值。測量資料庫效能時，不建議將資料庫儲存在硬碟驅動器 (HDD) 上。

儲存容量取決於您要建造多少個倉庫。通常，1000 個倉庫佔用 400GB 的磁碟空間。

如果要對驅動器進行分割槽，則第一個分割槽的起始扇區應始終能被 4096 整除。下面是一個示例：

sudo parted /dev/nvme1n1



print



mklabel gpt



mkpart primary 2048s 100%



print



align-check opt 1



q

下面的示例截圖：

在分割槽上建立您喜歡的檔案系統並將其掛載到 MySQL 或 PostgreSQL 資料目錄，確保 mysql 或 postgres 使用者擁有該目錄的所有權，示例如下。

sudo mkfs.xfs /dev/nvme1n1p1



sudo mkdir /data



sudo mount /dev/nvme1n1p1 /data



sudo chown -R postgres:postgres /data # for postgresql



sudo chown -R mysql:mysql /data # for mysql

軟體調優

軟體配置調整是必不可少的。從作業系統到 MySQL 和 PostgreSQL 配置設定，它們都是為通用應用程式而設計的，預設設定幾乎從未針對最佳效能進行調整。

Linux 核心優化

作業系統通過使用頁面來管理記憶體。大多數 Linux 發行版的預設記憶體頁面大小為 4 KB。這意味著當使用 64GB 記憶體的資料庫執行時，作業系統必須跟蹤 16,777,216 頁。

由於 CPU 無法在內部跟蹤所有這些頁面，因此頁表儲存在記憶體中。與 CPU 相比，記憶體訪問速度非常慢，因此在 CPU 中保留了一個稱為 Translation Look-aside Buffer (TLB) 的快取，該快取將最常用的頁面儲存在 CPU 中以便快速訪問。

由於有將近 1700 萬個頁面，並且記憶體訪問分佈在其中的很大一部分上，TLB 將無法將所有使用過的頁面儲存在快取中。為了解決這種情況，大多數現代應用程式，包括 MySQL 和 PostgreSQL，都可以使用大頁面。

現代x86 CPU 可以使用每頁 2 MB 甚至高達每頁 1GB 的大頁面大小。如果 2 MB 頁面用於 64 GB 應用程式記憶體，CPU 只需要跟蹤32,768 個頁面，而不是 16,777,216 個頁面。啟用 Huge Pages 可以提高 MySQL 和 PostgreSQL 的效能。

預設情況下，hugepage 大小為 2MB，這對於 MySQL 來說很好，但對於 PostgreSQL，建議使用 1GB。這應該通過在引導引數中新增“hugepagesz=1G hugepagesz=1G”來配置。

舉個例子：

sudo vi /etc/default/grub



GRUB_CMDLINE_LINUX="rhgb default_hugepagesz=1G hugepagesz=1G"



sudo grub2-mkconfig -o /boot/efi/EFI/ubuntu/grub.cfg

需要重新啟動系統。重啟後檢查 meminfo 中的大頁面大小。

sudo cat /proc/meminfo

Hugepagesize: 1048576 kB

接下來以 root 身份將以下行新增到 /etc/sysctl.conf，稍後我們將建立 64GB 的緩衝區（在 postgres.conf 中），因此我們通過新增 vm.nr_hugepages 建立 70GB（稍微多些）的大頁區域線。

vm.swappiness = 0



kernel.sem = 250 32000 100 128



fs.file-max = 6815744



net.ipv4.ip_local_port_range = 9000 65500



net.core.rmem_default = 262144



net.core.rmem_max = 4194304



net.core.wmem_default = 262144



net.core.wmem_max = 1048576



fs.aio-max-nr = 1048576

還要編輯 /etc/security/limits.conf 並新增以下內容（假設為 PostgreSQL 資料庫建立了 postgres 使用者）：

postgres soft memlock 100000000



postgres hard memlock 100000000

現在以root身份執行命令“sysctl –p”，當資料庫執行時，您將看到從大頁面分配的記憶體。

cat /proc/meminfo

HugePages_Total: 70

HugePages_Free: 66

HugePages_Rsvd: 62

64GB 共享緩衝區應該適用於大多數情況，但您可以嘗試根據您的系統能力和記憶體容量增加它，看看是否有任何效能提升，因此您需要相應地重新配置大頁面和鎖定記憶體的限制。

建立的hugepage區域需要大於PostgreSQL共享緩衝區，並且不超過鎖定記憶體的限制。

MySQL 調優

MySQL 有許多可調引數來滿足不同的應用程式特性。以下是我們發現適用於大多數應用程式的一些方法。

在/etc/mysql/my.cnf 中建立一個 conf 檔案，如下文所示。

sudo vi /etc/mysql/my.cnf



[mysqld]



large-pages



skip-log-bin



datadir=/data



default_authentication_plugin=mysql_native_password



socket=/tmp/mysql.sock



port=3306



bind_address=localhost



# general



max_connections=4000



table_open_cache=8000



table_open_cache_instances=16



back_log=1500



default_password_lifetime=0



ssl=0



performance_schema=OFF



max_prepared_stmt_count=128000



skip_log_bin=1



character_set_server=latin1



collation_server=latin1_swedish_ci



transaction_isolation=REPEATABLE-READ



# files



innodb_file_per_table



innodb_log_file_size=1024M



innodb_log_files_in_group=32



innodb_open_files=4000



# buffers



innodb_buffer_pool_size=64000M



innodb_buffer_pool_instances=16



innodb_log_buffer_size=64M



# tune



innodb_page_size=8192



innodb_doublewrite=0



innodb_thread_concurrency=0



innodb_flush_log_at_trx_commit=0



innodb_max_dirty_pages_pct=90



innodb_max_dirty_pages_pct_lwm=10



join_buffer_size=32K



sort_buffer_size=32K



innodb_use_native_aio=1



innodb_stats_persistent=1



innodb_spin_wait_delay=6



innodb_max_purge_lag_delay=300000



innodb_max_purge_lag=0



innodb_flush_method=O_DIRECT_NO_FSYNC



innodb_checksum_algorithm=none



innodb_io_capacity=4000



innodb_io_capacity_max=20000



innodb_lru_scan_depth=9000



innodb_change_buffering=none



innodb_read_only=0



innodb_page_cleaners=4



innodb_undo_log_truncate=off



# perf special



innodb_adaptive_flushing=1



innodb_flush_neighbors=0



innodb_read_io_threads=16



innodb_write_io_threads=16



innodb_purge_threads=4



innodb_adaptive_hash_index=0



# monitoring



innodb_monitor_enable='%'

根據 HammerDB 的測量，上述建議的配置已針對在單個節點上執行的 OLTP 工作負載進行了優化，以實現最佳效能。

對於日常操作和可靠性，或在叢集模式下執行，應針對您的特定操作環境和工作負載調整 innodb_doublewrite、skip-log-bin、innodb_flush、innodb_flush_method 或 innodb_flush_log_at_trx_commit 等功能。

例如，我們發現設定innodb_page_size=8k 可為具有快速 NVMe 儲存的 OLTP 應用程式提供最佳效能。但是，如果您使用慢得多的網路儲存執行，您可能希望增加一個更大的值以減少更高延遲的影響。

池大小或日誌檔案大小等其他設定需要考慮您的應用程式的需求和您正在執行的平臺的容量。雖然應在生產環境中啟用 innodb_flush 以確保穩定性和資料完整性，但最好將其關閉以測量 CPU效能。

通常啟用 innodb_flush 會導致儲存 IO 成為瓶頸。

Apparmor 是 Ubuntu 上的一個安全模組，可防止應用程式執行指令碼、開啟埠、訪問和鎖定檔案等，以保護系統。在Ubuntu 上安裝 MySQL 時，Apparmor 會為 MySQL 建立一個配置檔案。

現在，如果您想更改預設“/var/lib/mysql”以外的資料目錄位置，Apparmor 將不允許 mysql 使用者訪問此資料目錄，即使您使用 chown 和 chmod 修改了對它的許可權。為了避免使用者定義目錄的訪問問題，我們可以編輯具有所需許可權的 MySQL 的 Apparmor 策略。編輯以下檔案並重新載入Apparmor。

sudo vi /etc/apparmor.d/local/usr.sbin.mysqld



/data/ r,



/data/** rwk,

重新載入並重新啟動 Apparmor 模組

sudo service apparmor reload



sudo service apparmor restart

MySQL 監控工具

對於基本的效能監控和故障排除，'top' 和 'perf top' 很有用。但是如果你想做資料庫級別的效能分析，innotop 是一個很好的實時監控工具，它可以為我們提供關於 MySQL 伺服器在哪裡花費時間的充足資訊。

對你有幫助的連結：

快速安裝步驟：

1.安裝依賴

sudo apt install libterm-readkey-perl libclass-dbi-perl libclass-dbi-mysql-perl

2.從GitHub獲取最新的原始碼

wget /archive/master.zip



mkdir innotop



mv master.zip innotop



cd innotop



unzip master.zip



cd innotop-master/

3.編譯安裝

sudo perl Makefile.PL



sudo make install



sudo innotop --version

這是使用 innotop 的示例。

sudo innotop

輸入 “?” for Help

查詢列表輸入 “Q”

Innodb buffer 輸入 “B”

PostgreSQL 調優

Write-ahead log (WAL) 會對效能產生很大影響。PostgreSQL 預設使用 16MB WAL 段大小。為了獲得最佳效能，我們建議將此大小增加到 1GB。

initdb -D ./data --wal-segsize=1024

您可以轉到 pg_wal 目錄並列出 wal 檔案的大小。

du -hcs pg_wal/* |more



1.0G 0000000100000A0400000002



1.0G 0000000100000A0400000003



1.0G 0000000100000A0500000000



1.0G 0000000100000A0500000001



1.0G 0000000100000A0500000002



1.0G 0000000100000A0500000003



1.0G 0000000100000A0600000000

PostgreSQL 有許多其他影響效能的引數。postgresql.conf中的以下 PostgreSQL 引數可用作參考。

cat postgresql.conf



listen_addresses = localhost # what IP address(es) to listen on;



port = 5432 # (change requires restart)



max_connections = 256 # (change requires restart)



shared_buffers = 64000MB # min 128kB



huge_pages = on # on, off, or try



temp_buffers = 4000MB # min 800kB



work_mem = 4000MB # min 64kB



maintenance_work_mem = 512MB # min 1MB



autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem



max_stack_depth = 7MB # min 100kB



dynamic_shared_memory_type = posix # the default is the first option



max_files_per_process = 4000 # min 25



effective_io_concurrency = 32 # 1-1000; 0 disables prefetching



wal_level = minimal # minimal, archive, hot_standby, or logical



synchronous_commit = on # synchronization level;



wal_buffers = 512MB # min 32kB, -1 sets based on shared_buffers



cpu_tuple_cost = 0.03



effective_cache_size=350GB



random_page_cost = 1.1



checkpoint_timeout = 1h # range 30s-1h



checkpoint_completion_target = 0.9 # checkpoint target duration, 0.0 - 1.0



checkpoint_warning = 1



log_min_messages = error # values in order of decreasing detail:



log_min_error_statement = error # values in order of decreasing detail:



autovacuum = on # Enable autovacuum subprocess? 'on'



autovacuum_max_workers = 10



autovacuum_vacuum_cost_limit = 3000



datestyle = 'iso, dmy'



lc_messages = 'en_US.UTF-8' # locale for system error message



lc_monetary = 'en_US.UTF-8' # locale for monetary formatting



lc_numeric = 'en_US.UTF-8' # locale for number formatting



lc_time = 'en_US.UTF-8' # locale for time formatting



default_text_search_config = 'pg_catalog.english'



max_locks_per_transaction = 64 # min 10



max_pred_locks_per_transaction = 64 # min 10



archive_mode=off



max_wal_senders=0



min_wal_size=8192



max_wal_size=524288

PostgreSQL 使用者指南建議 shared_buffers 的合理起始值是系統記憶體的 25%。確保相應地啟用大頁面和作業系統記憶體限制。我們還建議啟用 autovacuum 以避免在非常高的事務率下效能下降。

值得注意的是，“同步提交”指定事務提交是否會等待 WAL 記錄寫入磁碟，然後再響應客戶端。在生產資料庫環境中應該啟用同步提交。但是，在評估 CPU 效能（而不是 I/O 效能）時，您需要禁用“同步提交”以消除 I/O 效能成為瓶頸。

PostgreSQL 效能監控

對於基本的效能監控和故障排除，'top' 和 'perf top' 很有用。但是如果你需要在資料庫級別進行分析，pg_stat_statements和 pg_sentinel 是更高階的 PostgreSQL 工具。

對您有幫助的連結：

快速安裝步驟：

1. 安裝 pg_stat_statements

cd postgresql-13.0/contrib



sudo make



cd postgresql-13.0/contrib/pg_stat_statements



sudo make



sudo make install

2.安裝pgsentinel

export PATH=$PATH:/usr/local/pgsql/bin

 

git clone .git



cd pgsentinel/src



sudo make



sudo make install

3.配置

將以下內容新增到 postgres.conf，需要重新啟動資料庫。

shared_preload_libraries = 'pg_stat_statements,pgsentinel'



# Increase the max size of the query strings Postgres records



track_activity_query_size = 2048



# Track statements generated by stored procedures as well



pg_stat_statements.track = all

4. 建立擴充套件。

postgres=# create extension pg_stat_statements;



CREATE EXTENSION



postgres=# create extension pgsentinel ;



CREATE EXTENSION



postgres=# \dx

已安裝擴充套件列表

Name | Version | Schema | Description

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

pg_stat_statements | 1.6 | public | track execution statistics of all SQL statements executed

pgsentinel | 1.0b | public | active session history

plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language

5. 在 HammerDB 測試之後，立即執行以下示例語句。

postgres=#



with ash as (



select *,ceil(extract(epoch from max(ash_time)over()-min(ash_time)over()))::numeric samples



from pg_active_session_history where ash_time>=current_timestamp - interval '2 minutes'



) select round(100*count(*)/sum(count(*)) over(), 0) as "%", round(count(*)::numeric/samples,2) as "AAS",



backend_type,wait_event_type,wait_event



from ash



group by samples,

它輸出捕獲的等待事件，如下所示：

% | AAS | backend_type | wait_event_type | wait_event

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

48 | 28.00 | client backend | CPU | CPU

12 | 6.82 | client backend | LWLock | XactSLRU

11 | 6.18 | client backend | LWLock | WALInsert

9 | 5.41 | client backend | IPC | ProcArrayGroupUpdate

6 | 3.71 | client backend | Client | ClientRead

6 | 3.65 | client backend | IPC | XactGroupUpdate

5 | 2.82 | client backend | Lock | extend

2 | 0.94 | client backend | LWLock | ProcArray

1 | 0.35 | client backend | IPC | CheckpointDone

效能測試

HammerDB 是一種領先的開源關聯式資料庫負載測試和基準測試工具，許多資料庫專業人士使用它來對最流行的商業和開源關聯式資料庫進行壓力和基準測試。

HammerDB 支援使用基於行業標準規範的工作負載測試 MySQL 和 PostgreSQL，並由行業標準機構 TPC（事務處理效能委員會）託管。

HammerDB 實現了 OLTP 和 OLAP 工作負載，在本文中，我們關注稱為 TPROC-C的 OLTP 工作負載。TPROC-C 表示“源自 TPC“C”規範的事務處理基準” 並且是在 HammerDB 中實現的 OLTP 工作負載，源自 OLTP TPC-C 規範，經過修改以使執行 HammerDB 比嚴格遵守規範更簡單、更具成本效益，同時仍然提供對關聯式資料庫效能的寶貴見解。

這樣的工作負載降低了資料庫基準測試的准入門檻，使資料庫效能的比較可靠且可預測，但也廣泛可用。

HammerDB TPROC-C 測試結果產生兩個關鍵指標，每分鐘新訂單數 (NOPM) 和每分鐘交易數 (TPM)。NOPM 與僅記錄每分鐘新訂單的官方 tpmC 統計資料密切相關，並且是用於衡量不同資料庫之間的資料庫效能可比性的推薦指標。

TPM 是一種補充指標，用於衡量特定資料庫引擎的效能並將效能與該引擎生成的其他統計資訊相關聯。

在此處瞭解有關 HammerDB 的更多資訊：

。

結論

我們瞭解每個應用程式都是獨一無二的。我們分享了我們在 MySQL 和 PostgreSQL 方面的許多經驗，希望我們的一些經驗可以應用於您的特定應用程式。

兩種開源關聯式資料庫管理系統都已在英特爾平臺上進行了很好的測試。藉助3rd GenerationIntel® Xeon® 可擴充套件處理器，英特爾進一步優化了整個平臺——CPU、記憶體、儲存和網路協同工作以獲得最佳使用者體驗。

附錄 A – 安裝 HammerDB 4.0

從以下連結下載“ HammerDB-4.0-Linux.tar.gz” 。

提取檔案

cp HammerDB-4.0-Linux.tar.gz ~/home-xvzf HammerDB-4.0-Linux.tar.gz

附錄 B – 使用 MySQL 執行 HammerDB 4.0

檢查 MySQL 客戶端庫是否存在。

cd /home/HammerDB-4.0



./hammedbcli



librarycheck



exit

下面的例子。確保 MySQL 資料庫顯示“成功”

但是，如果它沒有安裝。從連結下載特定於您的作業系統和 MySQL 版本的適當 libmysqlclient ((libmysqlclient-dev_8.0.23-1ubuntu20.04_amd64.deb)

https://dev.mysql.com/downloads/mysql/ 並匯出libmysqlclient存放的路徑。下面的例子：

export LD_LIBRARY_PATH=/home/mysql:$LD_LIBRARY_PATH



chmod 644 libmysqlclient.so.21



chown mysql:mysql libmysqlclient.so.21

要執行工作負載，我們首先需要使用 schemabuild.tcl 指令碼構建模式。此指令碼將花費大約 30 分鐘來建立資料庫，具體取決於您使用的系統和驅動器。

sudo ./hammerdbcli auto schemabuild.tcl

下面的示例指令碼：

schemabuild.tcl

sudo vi schemabuild.tcl



puts "SETTING CONFIGURATION"



dbset db mysql



diset connection mysql_host localhost



diset connection mysql_port 3306



diset tpcc mysql_count_ware 1000



diset tpcc mysql_partition true



diset tpcc mysql_num_vu 256



diset tpcc mysql_storage_engine innodb



print dict



vuset logtotemp 1



vuset unique 1



buildschema



waittocomplete

要進行測試，請執行 mysqlrun.tcl 指令碼。每次測試大約需要 7 到 8 分鐘。

sudo ./hammerdbcli auto mysqlrun.tcl

下面的示例指令碼。

mysqlrun.tcl

sudo vi mysqlrun.tcl



puts "SETTING CONFIGURATION"



dbset db mysql



diset connection mysql_host localhost



diset connection mysql_port 3306



diset tpcc mysql_driver timed



diset tpcc mysql_prepared false



diset tpcc mysql_rampup 2



diset tpcc mysql_duration 5



vuset logtotemp 1



vuset unique 1



loadscript



puts "TEST STARTED"



vuset vu 64



vucreate



vurun



runtimer 500



vudestroy



puts "TEST COMPLETE"

在上面的例子中，我們模擬了 64 個併發使用者訪問資料庫。您需要調整 vuset vu 值以表示您正在測試的資料庫大小。

結果可以在指令碼末尾找到，並且還以唯一名稱記錄在 /tmp/hammerdb_*.log 中。

附錄 C – 使用 PostgreSQL 執行 HammerDB

要執行工作負載，我們首先需要使用 pgbuild.tcl 指令碼。在此示例中，這大約需要 30 分鐘，具體取決於您的系統配置。

sudo ./hammerdbcli auto pgbuild.tcl

架構構建指令碼的示例：

cat pgbuild.tcl



dbset db pg



dbset bm TPC-C



diset connection pg_host localhost



diset conection pg_port 5432



diset tpcc pg_count_ware 1000



diset tpcc pg_num_vu 180



diset tpcc pg_superuser intel



diset tpcc pg_superuserpass postgres



diset tpcc pg_storedprocs false



vuset logtotemp 1



vuset unique 1



buildschema



waittocomplete

要使用單一數量的虛擬使用者執行測試，請執行 pgtest.tcl 指令碼。

sudo ./hammerdbcli auto pgtest.tcl

測試指令碼示例：

cat pgtest.tcl



puts "SETTING CONFIGURATION"



dbset db pg



diset connection pg_host localhost



diset connection pg_port 5432



diset tpcc pg_superuser intel



diset tpcc pg_superuserpass postgres



diset tpcc pg_vacuum true



diset tpcc pg_driver timed



diset tpcc pg_rampup 2



diset tpcc pg_duration 2



diset tpcc pg_storedprocs false



vuset logtotemp 1



vuset unique 1



loadscript



puts "TEST STARTED"



vuset vu 64



vucreate



vurun



runtimer 300



vudestroy



puts "TEST COMPLETE"

結果可以在指令碼末尾找到，並且還以唯一名稱記錄在 /tmp/hammerdb_*.log 中。

Vuser 1:64 配置的活動虛擬使用者

Vuser 1：測試結果：系統從 3515684 PostgreSQL TPM 達到 1483849 NOPM

===================================

宣告和免責宣告

英特爾技術可能需要啟用硬體、軟體或服務啟用。

沒有任何產品或元件是絕對安全的。

您的成本和結果可能會有所不同。

英特爾使用代號來標識正在開發且未公開提供的產品、技術或服務。這些不是“商業”名稱，也不打算用作商標

所描述的產品可能包含稱為勘誤表的設計缺陷或錯誤，這可能導致產品偏離已釋出的規格。當前特徵勘誤表可應要求提供。

subsidiaries. Other names and brands may be claimed as the property of others.

文章來源：

https://www.intel.com/content/www/us/en/developer/articles/guide/open-source-database-tuning-guide-on-xeon-systems.html

第三代英特爾處理器與開源資料庫效能調優

介紹

開源關聯式資料庫管理系統

硬體調優

CPU 配置

磁碟配置

軟體調優

相關文章

第三代英特爾處理器與開源資料庫效能調優

介紹

開源關聯式資料庫管理系統

硬體調優

CPU 配置

磁碟 配置

軟體調優

相關文章

磁碟配置