丨案例為什么參數(shù)化數(shù)據(jù)會(huì)導(dǎo)致tps突然下降

2020-02-28 進(jìn)入課20:15大小在性能測(cè)試中，參數(shù)化數(shù)據(jù)是少有的每個(gè)性能測(cè)試工程師都會(huì)用得到，卻經(jīng)常出現(xiàn)問(wèn)題的技術(shù)點(diǎn)之一。從我的角度來(lái)說(shuō)，究其原因，大部分是因?yàn)閷?duì)性能參數(shù)化數(shù)據(jù)的理解不足。導(dǎo)致的結(jié)果就是用了參數(shù)化，但和真實(shí)的用戶場(chǎng)景不一致，從而使得整個(gè)性能測(cè)試場(chǎng)景都失去了意義。這樣的例子不在少數(shù)一個(gè)項(xiàng)目開始之初，由于沒(méi)有歷史沉淀的數(shù)據(jù)，所以我們需要造一些數(shù)據(jù)來(lái)做性能測(cè)試。造多少呢？并不是按未來(lái)生產(chǎn)的容量來(lái)造，而是按性能場(chǎng)景中需要的數(shù)據(jù)量級(jí)來(lái)造。這種錯(cuò)誤的做法是很多項(xiàng)目中真實(shí)出現(xiàn)的事情。那么性能測(cè)試參數(shù)化數(shù)據(jù)的獲取邏輯到底是什么呢？我們來(lái)看一個(gè)圖用戶輸入的數(shù)據(jù)同時(shí)在數(shù)據(jù)庫(kù)中已存在用戶輸入的數(shù)據(jù)同時(shí)在數(shù)據(jù)庫(kù)中不存在據(jù)分布。當(dāng)我們使用數(shù)據(jù)庫(kù)中不存在的數(shù)據(jù)時(shí)，就必須考慮輸入是否符合真實(shí)用戶的輸入在一次壓力測(cè)試的過(guò)程中，出現(xiàn)了如下所示的TPS數(shù)據(jù)（本篇文章中一些截圖會(huì)有在下圖中，我們可以看到，在壓力測(cè)試過(guò)程中，出現(xiàn)了TPS陡減到底的情況。這顯然是不程數(shù)降低，觀察TPS的趨勢(shì)，結(jié)果從300到100到50到10，最后到1，發(fā)現(xiàn)都會(huì)出現(xiàn)這樣的TPS陡減到底的情況，只是時(shí)間長(zhǎng)度不同而已。首先，仍然是畫一個(gè)架構(gòu)圖在這個(gè)圖中，我們可以看到，JMeter是連接到第一層服務(wù)（這里是有兩個(gè)Tomcat實(shí)例），再到第二層服務(wù)（這里是也有兩個(gè)Tomcat例），然后再連到DB。這個(gè)DB是一個(gè)互聯(lián)網(wǎng)金融DB（通過(guò)MySQL改造來(lái)的）。了解了架構(gòu)圖之后，現(xiàn)在就開始查看下性能數(shù)據(jù)查操作先看一下操作系統(tǒng)的性能數(shù)從top中，我們可以看到這個(gè)應(yīng)用服務(wù)器沒(méi)啥壓力，在這樣的狀態(tài)中，你可能都不用再去查應(yīng) 從這個(gè)圖中可以看到的是，這個(gè)應(yīng)用使用CPU實(shí)很低，并且堆也沒(méi)用多少。其實(shí)在這一步，我查了四個(gè)Tomcat的狀態(tài)，只是截了一個(gè)圖而已。應(yīng)用CPU使用率（橙色CPU線）確實(shí)是太低了，才15%左右。這和前面的top也是能對(duì)得上的。JavaGC乎沒(méi)占CPU（藍(lán)色CPU），也就是說(shuō)Tomcat這里沒(méi)壓從堆曲線的趨勢(shì)上來(lái)看，1G的堆才到了400M多一點(diǎn)，并且回收一直都非常正常。怎么判斷這個(gè)“正?！蹦?？首先，年輕代、年老代回收很有規(guī)律，并且沒(méi)消耗什么CPU；其次，每次FullGC都能回到150M左右，非常平穩(wěn)?？梢娺@個(gè)內(nèi)存使用沒(méi)啥問(wèn)題。當(dāng)然到了這里，我當(dāng)時(shí)也是查了網(wǎng)絡(luò)的，只是也沒(méi)什么壓力，所以沒(méi)做具體的記錄（從這可以看出，如果你在做性能測(cè)試的時(shí)候，要想記錄性能瓶頸的分析過(guò)程，一定要記得把數(shù)記全了，不然以后你可能都想不起來(lái)當(dāng)時(shí)做了什么事情）查既然上面都沒(méi)啥問(wèn)題，DB是一個(gè)MySQL，所以這里，我先手動(dòng)執(zhí)行了幾個(gè)常規(guī)的查詢語(yǔ)句。在DB中查看如下信息。查processlist、innodb_trx、innodb_locks、innodb_lock_waits。在沒(méi)有工具時(shí)，這幾個(gè)是我經(jīng)常在MySQL數(shù)據(jù)庫(kù)檢查的表，因?yàn)閿?shù)據(jù)庫(kù)如果慢的話，基本上會(huì)processlist看當(dāng)然數(shù)據(jù)庫(kù)中的session并且也會(huì)把正在執(zhí)行的SQL出來(lái)，快速刷新幾次，就可以看到是不是有SQL一直卡在那里。innodb_trx是正在執(zhí)行的SQL事務(wù)表，這個(gè)表很重innodb_locks和innodb_lock_waits是為了看有沒(méi)有鎖等拿一條業(yè)務(wù)SQL執(zhí)行一下，看看在壓力之中會(huì)不會(huì)慢。這是在沒(méi)有數(shù)據(jù)庫(kù)時(shí)，快速判斷業(yè)務(wù)的方法。因?yàn)檫@個(gè)業(yè)務(wù)很單一，用的SQL也單一，所以我在這里可以這樣做。執(zhí)行了之后，并沒(méi)有發(fā)現(xiàn)業(yè)務(wù)SQL慢。由此基本判斷DB沒(méi)什么問(wèn)題注意，判斷到了這里，其實(shí)已經(jīng)出現(xiàn)了不完整產(chǎn)生的方向偏離陷入困局之后的更悲催的是這個(gè)業(yè)務(wù)系統(tǒng)的日志記錄的非常“簡(jiǎn)潔”，連時(shí)間消耗都沒(méi)有記錄下來(lái)。想來(lái)想去，在這么簡(jiǎn)單的一個(gè)架構(gòu)中，沒(méi)什么可查的東西了吧，除非網(wǎng)絡(luò)中有設(shè)備導(dǎo)致了這個(gè)問(wèn)題的出現(xiàn)？在沒(méi)有其它工具的情況下，當(dāng)時(shí)我們上了最傻最二最基礎(chǔ)又最有效的時(shí)間拆分：抓抓包其實(shí)是個(gè)挺需要技巧的活，不止是說(shuō)你能把包抓出來(lái)，還要能分析出來(lái)時(shí)間消耗在誰(shuí)那里。這時(shí)我提醒一下，當(dāng)你學(xué)會(huì)抓包工具的使用時(shí)，不要在每個(gè)場(chǎng)景下都想露一手你的抓包能力，通過(guò)抓的包分析響應(yīng)時(shí)間的消耗點(diǎn)。在我的工作中，只有萬(wàn)般無(wú)奈時(shí)才會(huì)祭出“抓包”這樣的，并不是因?yàn)槲覍?duì)網(wǎng)絡(luò)不夠了解。恰恰是因?yàn)榱私獾米銐蚨嗟模也沤ㄗh不要隨便抓包。因?yàn)榈苍趹?yīng)用層有工具可以分析響應(yīng)時(shí)間，都會(huì)比抓網(wǎng)絡(luò)層的包來(lái)得更加簡(jiǎn)單直觀。經(jīng)過(guò)一段段的分析之后，在數(shù)據(jù)庫(kù)的一個(gè)主機(jī)上看到了如下信看到這里的TCPsegmentofareassembledPDU沒(méi)有？它之上是ACK。放大一下，看看到?jīng)]有，這里有兩秒的時(shí)間才發(fā)數(shù)據(jù)，那它是在干嗎這里就要說(shuō)明一下TCPsegmentofareassembledPDU了，PDUProtocolDataUnit。以下高能燒腦，不喜可跳過(guò)它是指在TCP接收到應(yīng)用層發(fā)的非常大的數(shù)據(jù)之后，需要將數(shù)據(jù)大刀闊斧地砍成幾段之后再發(fā)出去。就是這個(gè)砍數(shù)據(jù)的過(guò)程消耗了2秒的時(shí)間?？墒菫槭裁碩CP要干這個(gè)事呢？上層應(yīng)用給了你一大塊數(shù)據(jù)包，你直接往外扔不就行了嗎？還要自己reassemble（重新裝配），費(fèi)勁。這其實(shí)TCP的一個(gè)參數(shù)來(lái)決定的，它就是MSS（ umSegmentSize）。在TCP一開始打招呼的時(shí)候（就是握手的過(guò)程），已經(jīng)通過(guò)MSS這個(gè)可選項(xiàng)告訴對(duì)方自己能接收的1460字節(jié)的，為啥是1460呢？因?yàn)榧由蟃CP頭的20個(gè)字節(jié)和IP頭的20個(gè)字節(jié)，剛好不大不小1500字節(jié)當(dāng)你看到1500字節(jié)的時(shí)候，是不是有一種似曾相識(shí)的感覺？它就是現(xiàn)在普遍設(shè) umTransmissionUnit）的大小呀這時(shí)你可能會(huì)說(shuō)了，那我可以把MTU大嘛?？墒悄阕约涸O(shè)置不行呀，別人（各主機(jī)和網(wǎng)絡(luò)設(shè)備）都得跟著你設(shè)置才行，要不然到了MTU不大的地方，還得分包，還是要費(fèi)時(shí)而接收端呢？接數(shù)據(jù)時(shí)接到這些包的ACK序號(hào)都是一樣的，但SequenceNumber不同，并且后一個(gè)SequenceNumber前SequenceNumber+文大小的值，那接收端就可以判斷這是一個(gè)TCPSegment了。 PDU。至于嗎？不就是過(guò)來(lái)查個(gè)數(shù)據(jù)嗎？考慮了一下業(yè)務(wù)特征，這就是根據(jù)客戶ID查一個(gè)帳戶的一個(gè)月或三個(gè)月的記錄信息，通常是100條左右，最多也就200條，也不至于有這這就是我前面說(shuō)的查DB的時(shí)候，由于不全導(dǎo)致了分析思路的偏差。因?yàn)槲沂謩?dòng)執(zhí)行了這個(gè)語(yǔ)句的時(shí)候并不慢，只要10幾毫秒，所以，那時(shí)候我覺得數(shù)據(jù)庫(kù)不是問(wèn)題點(diǎn)。但是經(jīng)過(guò)了抓包之后，發(fā)現(xiàn)問(wèn)題還是出在DB上。有時(shí)候真不能那么自信呀，容易給自己挖接著分析那我們肯定要接著看DB上的信息了，既然數(shù)據(jù)量大，SQL執(zhí)行得慢，那就先撈出慢日志查看如下負(fù)載信息1#234#RankQueryResponse5#====6172839410511912131415 16<72你可以看到確實(shí)有四個(gè)SQL消耗了的時(shí)間，并且時(shí)間還不短。這是明顯的性能問(wèn)題，但是我把這SQL拿出來(lái)執(zhí)行過(guò)呀，并不慢。怎么回事呢我讓做數(shù)據(jù)庫(kù)運(yùn)維的人把DBproxy層的所有SQL日志拿出來(lái)分析一遍。為什么我要DBproxy層的數(shù)據(jù)呢？因?yàn)檫@一段會(huì)把所有執(zhí)行的SQL都記錄下來(lái)，而慢日志記錄的是1s以上的（取決于DB中的配置）。首先是把timecost大于200ms的SQL都拉出來(lái)，結(jié)果發(fā)現(xiàn)，真的在TPS下降的那個(gè)時(shí)間段，出現(xiàn)了SQL執(zhí)行超長(zhǎng)的情況，并且和我執(zhí)行的，還是同樣的業(yè)務(wù)SQL。怎么辦？既然到這個(gè)層面了，這些執(zhí)行的SL只有一點(diǎn)區(qū)別，那就是查詢條件。慢的SL的查詢條件，我拿回來(lái)試了，果然是慢，查出來(lái)的數(shù)據(jù)也是完全不一樣的，居然能查出幾萬(wàn)條數(shù)據(jù)來(lái)。前面說(shuō)了，這個(gè)語(yǔ)句是根據(jù)客戶D查出記錄數(shù)的，那么就根據(jù)客戶ID，做一次roupy，看下數(shù)據(jù)量為啥有這么多大差別。于是得到了如下的結(jié)果123456789客戶ID,數(shù)'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它'這一列只是客戶id，無(wú)它從這個(gè)結(jié)果可以看到，不同客戶ID的記錄條數(shù)差別太大了。這是誰(shuí)干的好事？！我們一開到這里，問(wèn)題基本上就明確了，查一下參數(shù)化的數(shù)據(jù)，里面有10條數(shù)據(jù)，而取到記錄數(shù)在五六萬(wàn)左右的客戶ID的時(shí)候，才出現(xiàn)了響應(yīng)時(shí)間長(zhǎng)的問(wèn)題。而我之前的執(zhí)行的SQL，恰好試了多次都是數(shù)據(jù)量少下面怎么辦呢？先做個(gè)最規(guī)矩的實(shí)驗(yàn)，把5萬(wàn)條往后的數(shù)據(jù)全都刪掉！場(chǎng)景再執(zhí)行一遍。問(wèn)題完美解決可是問(wèn)題怎么出現(xiàn)的呢經(jīng)過(guò)詢問(wèn)負(fù)責(zé)產(chǎn)生基礎(chǔ)數(shù)據(jù)的人，最后得知，一開始數(shù)據(jù)庫(kù)里的基礎(chǔ)數(shù)據(jù)不夠。由于我在項(xiàng)目中要求基礎(chǔ)數(shù)據(jù)量和參數(shù)化數(shù)據(jù)量要達(dá)到生產(chǎn)級(jí)別。于是把這個(gè)工作安排給了一個(gè)同事，就是造出每個(gè)客戶都和生產(chǎn)環(huán)境中差不多量級(jí)的記錄。當(dāng)時(shí)是用壓力做客戶ID的參數(shù)化，然后用執(zhí)行壓力的方式造的數(shù)據(jù)。本來(lái)這個(gè)事情在做的時(shí)候，應(yīng)該是把每個(gè)客戶ID都加到差不多的記錄的。但是這個(gè)人在做之后，覺得每個(gè)客戶ID上都有了一些數(shù)據(jù)量之后，自己做了個(gè)決定，把客戶ID減少到只哭笑不得的感覺有沒(méi)有但很多時(shí)候，在真實(shí)的場(chǎng)景中，很多性能問(wèn)題連原因都沒(méi)有分析出來(lái)，連啼笑皆非的機(jī)會(huì)都沒(méi)有，就開始尋找規(guī)避的