Ubuntu壓力測(cè)試下，MySQL的CPU異常飆高？？？
問(wèn)題描述
壓力測(cè)試中，MySQL的CPU直接飆到400-600.
環(huán)境使用。
php 8.3
最新的webman
采用select驅(qū)動(dòng)
MySQL的8.0 本機(jī)安裝，沒(méi)有進(jìn)行調(diào)優(yōu)（配置文件什么都沒(méi)有改動(dòng)）。
壓測(cè)命令
wrk -t12 -c1000 http://127.0.0.1:19878/test
啟動(dòng)環(huán)境
壓測(cè)代碼
數(shù)據(jù)庫(kù)里面有 4.2w條數(shù)據(jù)（無(wú)序排列===4級(jí)省市縣鄉(xiāng)）
這一張是數(shù)據(jù)庫(kù)沒(méi)有加索引查詢。
下面是加上普通索引查詢。
壓測(cè)過(guò)程top命令查看資源消耗情況（手速?zèng)]那么快只能截圖2張了。我看了活動(dòng)監(jiān)視器CPU確實(shí)拉滿了）
在補(bǔ)一張圖通過(guò)Kimi參數(shù)解答
從你提供的 wrk 測(cè)試結(jié)果來(lái)看，這是一次針對(duì)本地服務(wù)器地址 http://127.0.0.1:19878/test 的壓力測(cè)試。下面是對(duì)測(cè)試結(jié)果的解讀：
測(cè)試持續(xù)時(shí)間：-d60 參數(shù)指定了測(cè)試持續(xù)時(shí)間為 60 秒。
線程和連接：-t12 表示使用了 12 個(gè)線程，-c100 表示每個(gè)線程有 100 個(gè)并發(fā)連接，總共 1200 個(gè)并發(fā)連接。
線程統(tǒng)計(jì)：
平均延遲 (Latency)：請(qǐng)求的平均響應(yīng)時(shí)間是 2.40 毫秒，這表示服務(wù)器處理請(qǐng)求并返回響應(yīng)的速度相當(dāng)快。
標(biāo)準(zhǔn)偏差 (Stdev)：延遲的標(biāo)準(zhǔn)偏差是 1.83 毫秒，這表明大部分請(qǐng)求的響應(yīng)時(shí)間接近平均值，但也有少數(shù)請(qǐng)求響應(yīng)時(shí)間較長(zhǎng)。
最大延遲 (Max)：最長(zhǎng)的延遲是 54.80 毫秒，這是在測(cè)試期間記錄的最長(zhǎng)響應(yīng)時(shí)間。
百分位 (+/- Stdev)：83.78% 的請(qǐng)求響應(yīng)時(shí)間在平均值加減一個(gè)標(biāo)準(zhǔn)偏差的范圍內(nèi)。
請(qǐng)求統(tǒng)計(jì)：
每秒請(qǐng)求數(shù) (Req/Sec)：平均每秒處理的請(qǐng)求數(shù)是 3.65k（即 3650 個(gè)請(qǐng)求）。
每秒請(qǐng)求數(shù)的標(biāo)準(zhǔn)偏差：請(qǐng)求數(shù)的標(biāo)準(zhǔn)偏差是 1.21k。
每秒請(qǐng)求數(shù)的最大值：在測(cè)試期間，每秒最多處理了 6.92k 個(gè)請(qǐng)求。
請(qǐng)求數(shù)的分布：63.15% 的請(qǐng)求在平均值加減一個(gè)標(biāo)準(zhǔn)偏差的范圍內(nèi)。
總體統(tǒng)計(jì)：
總請(qǐng)求數(shù)：在 1 分鐘內(nèi)共發(fā)送了 2613801 個(gè)請(qǐng)求。
總數(shù)據(jù)量：讀取了 752.82MB 的數(shù)據(jù)。
每秒平均請(qǐng)求數(shù)：Requests/sec: 43537.19 表示平均每秒處理了 43537.19 個(gè)請(qǐng)求。
每秒平均數(shù)據(jù)傳輸量：Transfer/sec: 12.54MB 表示平均每秒傳輸了 12.54MB 的數(shù)據(jù)。
這些結(jié)果可以幫助你了解服務(wù)器在高并發(fā)情況下的性能表現(xiàn)。如果需要進(jìn)一步優(yōu)化服務(wù)器性能，可以根據(jù)這些數(shù)據(jù)來(lái)分析可能的瓶頸和改進(jìn)點(diǎn)。3個(gè)回答
原文：
線程和連接：-t12 表示使用了 12 個(gè)線程，-c100 表示每個(gè)線程有 100 個(gè)并發(fā)連接，總共 1200 個(gè)并發(fā)連接。
正確的理解應(yīng)該是：
線程和連接：-t12 表示使用了 12 個(gè)線程，-c100 表示12個(gè)線程一共有 100 個(gè)并發(fā)連接，總共 100 個(gè)并發(fā)連接。
MySQL 就是這個(gè)性能，這是正常飆高。
首先，MySQL 4萬(wàn)/秒的讀消耗400-600%的CPU是正常的現(xiàn)象，換其它關(guān)系型數(shù)據(jù)庫(kù)也差不多少。
而你正常業(yè)務(wù)QPS可能就幾個(gè)，與4萬(wàn)相比如九牛一毛，也就是說(shuō)正式環(huán)境CPU消耗基本可以看作為0。
你是沒(méi)試過(guò)tp或者laravel，2000QPS就能把CPU干滿。而webman能達(dá)到4萬(wàn)已經(jīng)是逆天的成績(jī)了。
不要浪費(fèi)時(shí)間在webman框架或數(shù)據(jù)庫(kù)選型上，有那時(shí)間不如寫好SQL，做好索引，優(yōu)化業(yè)務(wù)減少SQL調(diào)用來(lái)的實(shí)在。
-
-
-
andyzu 2024-09-11我菜鳥，我想再追問(wèn)一下，舉通俗的例子來(lái)說(shuō)：也就是說(shuō)這個(gè) 4 萬(wàn)，我是否可以粗略理解為 4 萬(wàn)個(gè)用戶，同時(shí)用過(guò) webman 來(lái)訪問(wèn)數(shù)據(jù)庫(kù)，是沒(méi)什么太大問(wèn)題的？前提是 SQL 寫的不錯(cuò)，索引也有。
-
six 2024-09-11
只能說(shuō)題主測(cè)試的業(yè)務(wù)可以支持4萬(wàn)用戶同時(shí)訪問(wèn)。
但正常業(yè)務(wù)不會(huì)只有一個(gè)SQL，正常業(yè)務(wù)QPS不會(huì)這么高。
還有正常業(yè)務(wù)也不會(huì)有這么大訪問(wèn)量，能超過(guò)100就不錯(cuò)了，你們都考慮上萬(wàn)QPS是認(rèn)真的嘛？ -
andyzu 2024-09-11
我們有一個(gè)小程序在同一個(gè)時(shí)間，可能會(huì)有 1000-2000 人，同時(shí)使用，使用持續(xù)的時(shí)間在 1 分鐘內(nèi)， 1 分鐘后就沒(méi)有人用了，所以想了解 webman 的壓力測(cè)試。
-
故人重來(lái) 2024-09-12
扛得住，優(yōu)化sql語(yǔ)句。多層緩存架構(gòu)。隨便抗。SQL優(yōu)化很好，還是有點(diǎn)壓力建議走云數(shù)據(jù)庫(kù)主從，內(nèi)網(wǎng)互聯(lián)。
-
andyzu 2024-09-13
我目前的架構(gòu)是，redis + mysql 的方式，表能建索引的都建了。我們目前是一臺(tái)服務(wù)器，服務(wù)器里有 nginx + mysql ，如果后期建議走云數(shù)據(jù)庫(kù)（我們沒(méi)用過(guò)），是不是指的是云數(shù)據(jù)庫(kù)挑選比云服務(wù)器硬件配置高的就 OK ?
-
故人重來(lái) 2024-09-13
云數(shù)據(jù)庫(kù)比你們?cè)诜?wù)搭建數(shù)據(jù)性能更強(qiáng)的。畢竟是專業(yè)數(shù)據(jù)庫(kù)。而且你們突然某一個(gè)時(shí)間數(shù)據(jù)庫(kù)抗不住，也可以臨時(shí)加錢上擴(kuò)容。
-
