MariaDB / MySQL 使用大量執行緒/記憶體
我一直在設置一個新的 VPS，並想試用 MariaDB。我使用的是 MariaDB 10.0.1，據我了解，它相當於 MySQL 5.6。
自 MariaDB/MySQL 5.5 以來，執行緒的執行緒處理是否發生了巨大變化？這是我在舊伺服器（CentOS 5.9，MySQL 5.5）上看到的：
在帶有 MariaDB 10 (MySQL 5.6) 的 Centos 6.3 上：
以下是事實清單：
在伺服器 A（CentOS 5.9、MySQL 5.5）上：
- 大約有 15 個數據庫連接到各種網站和服務
- Plesk 已安裝
- MySQL 進行了最低限度的調整：
/etc/my.cnf
[mysqld] local-infile=0 query_cache_type = 1 query_cache_size = 32M datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Misc vars key_buffer_size=32M join_buffer_size=512K tmp_table_size=32M max_heap_table_size=32M thread_cache_size=4 table_cache=300 # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # InnoDB vars innodb_buffer_pool_size=96M innodb_additional_mem_pool_size=500K innodb_log_buffer_size=500K innodb_thread_concurrency=2在伺服器 B（CentOS 6.3，MariaDB 10）上：
- 有 3 個數據庫，其中只有一個目前“正在使用”並連接到低流量站點。
- 沒有 Plesk。
- MariaDB 最小調整：
/etc/my.cnf.d/server.cnf
[mysqld] # threads thread_concurrency=2 thread_cache_size=1 thread_handling=one-thread-per-connection thread_pool_size=4 thread_pool_max_threads=4 thread_pool_idle_timeout=60 thread_stack=240K # Limit Connections? # max_connections=5 skip-external-locking key_buffer_size=64M max_allowed_packet=1M table_open_cache=128 sort_buffer_size=1M read_buffer_size=1M read_rnd_buffer_size=4M net_buffer_length=8K myisam_sort_buffer_size=32M query_cache_size=16M # innodb settings innodb_buffer_pool_size=32M innodb_additional_mem_pool_size=2M innodb_flush_log_at_trx_commit=1 innodb_lock_wait_timeout=30 innodb_thread_concurrency=0為什麼會有這麼多執行緒？我嘗試了許多設置來嘗試將程序執行緒的數量降低到合理的水平，但我似乎無法影響它。它總是使用 20 或 21 個執行緒。我可以通過調整來減少記憶體使用量
innodb_buffer_pool_size，但是 32M 並不是一個執行 10 多個站點的合理值，所以我將它增加到 96M 或 128M。在這些值下，mysql 使用的記憶體超過 750-850M 記憶體。如果這只是我必須忍受的事情，那很好（我在新的 VPS 上擁有更多的記憶體，YOLO），但我只是好奇為什麼記憶體使用量會有如此巨大的差異。
另外值得一提的是，如果我在兩個 VPS 上都關閉了 mysql，我使用的記憶體幾乎相同——A 約 300M，B 約 260M。
MySQL 應該使用盡可能多的可用記憶體。這種規模的執行緒數量非常少，不會影響記憶體使用。執行緒共享相同的虛擬記憶體空間。他們只使用幾 KB 的執行緒元數據。
新 MySQL 上的記憶體使用量實際上比以前要小。它在虛擬記憶體空間中分配了 1.1GB，但在物理記憶體中只有 60MB。
在尋找優化 MySQL 時，首先嘗試將瓶頸從磁碟 I/O 轉移到記憶體訪問。還優化查詢（重寫它們，索引） - 啟用 MySQL 慢查詢日誌。
有時你達到了硬體限制，唯一的優化就是升級硬體。對於 MySQL，第一件事是添加更多 RAM、更快的磁碟，然後是更多的 CPU。