一次網站負載排查記錄
背景：
某天早上9.39分，nagios監控忽然報警，咱們一臺手機業務機器出現負載升高，達到60多，這臺機器僅8核心8G內存，伴隨其餘監控出現socket timeout，鏈接失敗。一看該問題就會想到會嚴重影響業務，而且問題確定會進行擴散，影響其餘業務。不出所料，沒到10分鐘，其餘同業務機器出現大面積報警，nginx出現端口連接超時，各類狀態碼監控失效.......
這種問題，不及時處理的話，客戶那邊的投訴會很快打進來的。php
排查：
一、先排查負載高的具體進程
經過top -c -d 1，查看當前有那些進行佔用CPU比較高。，因爲機器負載已經很高，中間經過堡壘機登陸花費了好幾分鐘的時間，差點就想把機器重啓了，時間等不及呀。
經過top命令查看，並未發現那個進程明顯佔用CPU比較高。前端
top - 09:39:13 up 824 days, 9:39, 4 users, load average: 4.65, 6.32, 8.26 Tasks: 854 total, 5 running, 849 sleeping, 0 stopped, 0 zombie Cpu(s): 52.4%us, 19.6%sy, 0.0%ni, 25.7%id, 0.2%wa, 0.1%hi, 1.9%si, 0.1%st Mem: 8058948k total, 7111024k used, 947924k free, 55588k buffers Swap: 8191992k total, 1906460k used, 6285532k free, 2126436k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19380 nobody 20 0 87800 32m 1700 R 18.3 0.4 87:25.36 nginx: worker process 19377 nobody 20 0 87512 32m 1704 S 18.9 0.4 87:56.77 nginx: worker process 19383 nobody 20 0 87788 32m 1700 S 13.3 0.4 88:46.35 nginx: worker process 19382 nobody 20 0 87584 32m 1700 S18.6 0.4 86:51.17 nginx: worker process 19379 nobody 20 0 87364 32m 1700 S 24.8 0.4 89:36.12 nginx: worker process 19381 nobody 20 0 87964 32m 1700 S 31.0 0.4 90:51.07 nginx: worker process 19378 nobody 20 0 88144 32m 1700 R 09.2 0.4 90:24.09 nginx: worker process 19376 nobody 20 0 87760 32m 1704 S 03.5 0.4 89:19.43 nginx: worker process 354 XXXXX 20 0 444m 21m 5828 R 3.8 0.3 13:09.36 douDiZhuServerWorker_0 392 XXXXX 20 0 442m 20m 5084 S 2.8 0.3 5:20.78 douDiZhuServerWorker_22 32655 XXXXX 20 0 2802m 14m 2248 S 2.8 0.2 10:31.01 douDiZhuServerMaster 356 XXXXX 20 0 443m 18m 4564 R 1.9 0.2 5:16.02 douDiZhuServerWorker_1 358 XXXXX 20 0 442m 18m 4560 S 1.9 0.2 5:18.09 douDiZhuServerWorker_2 369 XXXXX 20 0 445m 22m 4552 S 1.9 0.3 5:29.04 douDiZhuServerWorker_9 373 XXXXX 20 0 443m 21m 4532 S 1.9 0.3 5:16.98 douDiZhuServerWorker_11 376 XXXXX 20 0 443m 21m 4568 S 1.9 0.3 5:12.60 douDiZhuServerWorker_13 383 XXXXX 20 0 444m 18m 4564 S 1.9 0.2 5:21.64 douDiZhuServerWorker_17 387 XXXXX 20 0 442m 20m 4556 S 1.9 0.3 5:20.62 douDiZhuServerWorker_20 388 XXXXX 20 0 444m 19m 4564 S 1.9 0.2 5:15.17 douDiZhuServerWorker_21 400 XXXXX 20 0 443m 21m 4576 S 1.9 0.3 5:09.63 douDiZhuServerWorker_28
二、馬上排查佔用IO較高的進程
經過iotop命令排查有那些進程佔用IO較高的，通常佔用IO較高的，否會伴隨負載升高，同時在排查佔用負載高的時候，也要注意內存的使用和swap的使用，基本上swap被使用了，會伴隨IO迅速升高，最終會致使負載上來。ios
經過IO排查，發現有rsync，nginx進行佔用IO很高，問題基本定位在rsync上，由於從命令上一看就是用於同步數據的，只用同步數據，就要涉及到硬盤讀寫，這樣硬盤的IO就會升高，nginx進程佔用IO基本排除在外，多數都是被rsync影響的。nginx
Total DISK READ: 16.52 K/s | Total DISK WRITE: 95.80 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 12420 be/4 root 3.30 K/s 0.00 B/s 0.00 % 2.67 % [flush-8:0] 14203 be/4XXXXX 0.00 B/s 76.51 K/s 0.00 % 99.99 % rsync --server -svlogDtprze.iLs 9999 be/4 root 0.00 B/s 3.48 K/s 0.00 % 99.99 % [kswapd0] 14092 be/4XXXXX 10.43 K/s 0.00 B/s 0.00 % 99.99 % rsync --server -svlogDtprze.iLs 14252 be/4 nagios 358.22 K/s 0.00 B/s 0.00 % 90.98 % expr 8191992 - 6286700 26729 be/4 nobody 24.34 K/s 31.30 K/s 0.00 % 86.79 % nginx: worker process 14143 be/4XXXXX 24.34 K/s 0.00 B/s 0.00 % 85.31 % rsync --server -svlogDtprze.iLs 26731 be/4 nobody 17.39 K/s 38.26 K/s 0.00 % 85.23 % nginx: worker process 26727 be/4 nobody 6.96 K/s 52.17 K/s 0.00 % 85.22 % nginx: worker process 705 be/4 nobody 6.96 K/s 0.00 B/s 0.00 % 77.00 % php-fpm: pool www 12797 be/4 nobody 0.00 B/s 0.00 B/s 0.00 % 75.87 % php-fpm: pool www 26728 be/4 nobody 24.34 K/s 62.60 K/s 0.00 % 59.75 % nginx: worker process 26733 be/4 nobody 27.82 K/s 62.60 K/s 0.00 % 58.20 % nginx: worker process 353 be/4XXXXX 0.00 B/s 6.61 K/s 0.00 % 0.00 % douDiZhuServerTasker_7 354 be/4XXXXX 0.00 B/s 3.30 K/s 0.00 % 0.00 % douDiZhuServerWorker_0 358 be/4XXXXX 0.00 B/s 6.61 K/s 0.00 % 0.00 % douDiZhuServerWorker_2 360 be/4XXXXX 0.00 B/s 3.30 K/s 0.00 % 0.00 % douDiZhuServerWorker_3 361 be/4XXXXX 0.00 B/s 3.30 K/s 0.00 % 0.00 % douDiZhuServerWorker_4
三、追蹤進程與業務方對接
在上面的排查中，把方向定位在rsync這個命令上，我是不知道這個進程具體是作什麼的，因此直接和業務方（開發）對接，這個進程具體是幹什麼用。
具體和業務方對接的狀況以下：
該腳本確是用來同步數據用的，腳本是根據其餘業務方有新生成的數據就將新數據同步過來，該業務方要用到最新的數據。所以，這個腳本是個常駐腳本，每分鐘都是運行的。
按照正常業務邏輯上，若是真的是該腳本出問題了，那該腳本應該早就出現相似現象了，不該該是隻有今天出現，而且該腳本部署在同業務的多臺機器上，目前是隻有該機器出問題的。邏輯上是不通的。
不死心的態度，判斷該腳本是否出現了異常，好比說在某一分鐘內，其餘業務方產生的新數據庫過多，這邊要同步的數據量過大致使的，爲驗證這個想法，專門和開發提取 出該腳本近10天的同步數據量，然並未發現那個時間段出現數據量過大的狀況，反而在報警的時間段內同步的數據變少了，這就尷尬了
開發馬上掉頭和我說，你機器影響我業務了......................
爲了避免當背鍋俠，得繼續查緣由呀。數據庫
四、思考
整個問題的排查都是比較直觀的，直接在報警的時間段內，檢查排查，獲得的都是線上一手數據，不可能出錯，確定是本身遺漏了那些內容。 想要找到遺漏的內容，要麼從新負載重現，要麼將歷史數據拿出來，再次仔細的排查一遍。
尋找數據的規律，尋找報警異常的源頭永遠都是排查問題的重要手段及方向。api
五、排查歷史數據
由於線上出現問題，晚上通常沒法作到馬上排查問題，或爲了記錄一些短暫性報警的實時狀態，作了一個top腳本，將top、iotop等命令讓其每分鐘都執行，記錄在文件中，方便查看歷史狀態。
咱們報警是連續三分鐘達到閾值纔會報警，報警時間是在9點39分，那麼實際出現問題的時間是在37分就開始了
排查歷史記錄發現，負載呈現上升趨勢，是從36分開始增加的，所以問題的着重點要排查在36分以前出現過什麼腳本在執行，36分又出現了什麼新腳本在執行，或36分先後的異常對比緩存
（1）每分鐘的負載值運維
top - 09:32:02 up 824 days, 4:35, 1 user, load average: 7.32, 5.57, 3.50 top - 09:33:03 up 824 days, 4:36, 1 user, load average: 5.58, 5.47, 3.60 top - 09:34:02 up 824 days, 4:37, 1 user, load average: 5.81, 5.65, 3.78 top - 09:35:03 up 824 days, 4:38, 1 user, load average: 6.44, 5.84, 3.96 top - 09:36:03 up 824 days, 4:39, 1 user, load average: 14.31, 8.58, 5.04 top - 09:36:14 up 824 days, 4:39, 1 user, load average: 17.07, 9.36, 5.33 top - 09:37:03 up 824 days, 4:40, 1 user, load average: 26.44, 13.17, 6.84 top - 09:37:14 up 824 days, 4:40, 1 user, load average: 38.21, 16.13, 7.87 top - 09:37:39 up 824 days, 4:41, 1 user, load average: 56.97, 22.84, 10.37 top - 09:37:49 up 824 days, 4:41, 1 user, load average: 58.90, 24.39, 11.00 top - 09:37:57 up 824 days, 4:41, 1 user, load average: 57.39, 24.65, 11.16 top - 09:38:05 up 824 days, 4:41, 1 user, load average: 58.57, 25.94, 11.72 top - 09:38:06 up 824 days, 4:41, 1 user, load average: 58.57, 25.94, 11.72 top - 09:38:14 up 824 days, 4:41, 1 user, load average: 65.09, 28.41, 12.68 top - 09:38:23 up 824 days, 4:41, 2 users, load average: 67.81, 29.58, 13.14 top - 09:38:32 up 824 days, 4:42, 2 users, load average: 73.38, 32.03, 14.11 top - 09:38:37 up 824 days, 4:42, 2 users, load average: 76.15, 33.29, 14.62 top - 09:38:45 up 824 days, 4:42, 2 users, load average: 79.35, 35.39, 15.50 top - 09:38:51 up 824 days, 4:42, 2 users, load average: 82.12, 36.69, 16.03 top - 09:39:00 up 824 days, 4:42, 3 users, load average: 87.10, 39.25, 17.08 top - 09:39:03 up 824 days, 4:42, 3 users, load average: 87.10, 39.25, 17.08 top - 09:39:13 up 824 days, 4:42, 3 users, load average: 99.87, 43.56, 18.72 top - 09:39:24 up 824 days, 4:42, 3 users, load average: 111.69, 47.94, 20.41 top - 09:39:33 up 824 days, 4:43, 3 users, load average: 104.74, 48.55, 20.90
（2）33分的狀態
爲何這裏只放nginx佔用資源的狀態呢，由於我已經發現它的異常，其餘無異常的就不粘貼了，從nginx的佔用CPU資源上能夠看出，從33分開始到報警一直都是呈現佔用CPU資源的增加狀態socket
26726 nobody 20 0 88296 32m 1820 S 35.8 0.4 17:52.92 nginx: worker process 26730 nobody 20 0 88428 33m 1820 R 34.1 0.4 16:58.21 nginx: worker process 26731 nobody 20 0 88692 33m 1820 S 27.6 0.4 17:34.17 nginx: worker process 26733 nobody 20 0 88600 33m 1820 R 27.6 0.4 17:00.97 nginx: worker process 26729 nobody 20 0 88824 33m 1820 S 26.0 0.4 17:25.51 nginx: worker process 26728 nobody 20 0 88612 33m 1820 S 24.4 0.4 16:09.17 nginx: worker process
（3）34分的狀態ide
26727 nobody 20 0 88828 33m 1820 R 55.8 0.4 17:14.88 nginx: worker process 26730 nobody 20 0 88428 33m 1820 R 46.7 0.4 16:34.33 nginx: worker process 26733 nobody 20 0 88600 33m 1820 R 42.2 0.4 16:36.15 nginx: worker process 26728 nobody 20 0 88612 33m 1820 R 40.7 0.4 15:40.15 nginx: worker process 26729 nobody 20 0 88824 33m 1820 R 40.7 0.4 16:48.89 nginx: worker process 26731 nobody 20 0 88948 33m 1820 R 37.7 0.4 17:00.28 nginx: worker process 26726 nobody 20 0 88172 32m 1820 R 36.2 0.4 17:25.98 nginx: worker process
（4）35分的狀態
26730 nobody 20 0 88816 33m 1816 D 57.0 0.4 17:34.14 nginx: worker process 26731 nobody 20 0 88696 33m 1816 D 52.6 0.4 18:04.44 nginx: worker process 26726 nobody 20 0 88556 33m 1816 D 48.7 0.4 18:24.47 nginx: worker process 26727 nobody 20 0 88824 33m 1816 D 46.9 0.4 18:11.50 nginx: worker process 26729 nobody 20 0 88828 33m 1816 D 46.7 0.4 17:54.94 nginx: worker process 26733 nobody 20 0 88604 33m 1816 D 46.7 0.4 17:36.34 nginx: worker process 26728 nobody 20 0 88616 33m 1816 D 33.8 0.4 16:36.52 nginx: worker process 26732 nobody 20 0 88232 32m 1816 D 32.3 0.4 17:50.30 nginx: worker process
（5）36分狀態
26732 nobody 20 0 88672 33m 1720 R 80.4 0.4 18:19.66 nginx: worker process 26733 nobody 20 0 88728 33m 1720 R 77.5 0.4 18:01.45 nginx: worker process 26728 nobody 20 0 88612 33m 1720 D 53.9 0.4 16:58.75 nginx: worker process 26727 nobody 20 0 88824 33m 1720 D 44.3 0.4 18:41.69 nginx: worker process 26731 nobody 20 0 88692 33m 1720 D 44.3 0.4 18:31.20 nginx: worker process
（6）Nginx佔用IO狀況
09:35:12 5362 be/4 nobody 19.68 K/s 0.00 B/s 0.00 % 55.10 % php-fpm: pool www 09:35:12 26728 be/4 nobody 49.19 K/s 85.26 K/s 0.00 % 55.08 % nginx: worker process 09:35:12 26726 be/4 nobody 72.14 K/s 75.42 K/s 0.00 % 49.69 % nginx: worker process 09:35:12 4967 be/4 nobody 52.47 K/s 0.00 B/s 0.00 % 37.95 % php-fpm: pool www 09:35:12 26729 be/4 nobody 36.07 K/s 98.38 K/s 0.00 % 35.19 % nginx: worker process 09:35:12 12241 be/4 nobody 0.00 B/s 0.00 B/s 0.00 % 29.30 % php-fpm: pool www 09:35:12 26731 be/4 nobody 62.31 K/s 108.22 K/s 0.00 % 28.04 % nginx: worker process 09:35:12 26732 be/4 nobody 118.05 K/s 190.20 K/s 0.00 % 26.66 % nginx: worker process 09:35:12 24799 be/4 nobody 6.56 K/s 0.00 B/s 0.00 % 24.03 % php-fpm: pool www 09:35:12 11119 be/4 nobody 0.00 B/s 0.00 B/s 0.00 % 23.47 % php-fpm: pool www 09:35:12 26733 be/4 nobody 52.47 K/s 154.13 K/s 0.00 % 22.41 % nginx: worker process 09:35:12 26727 be/4 nobody 62.31 K/s 75.42 K/s 0.00 % 20.70 % nginx: worker process 09:35:12 26730 be/4 nobody 59.03 K/s 144.29 K/s 0.00 % 17.74 % nginx: worker process
（7）與zabbix覈對
六、在nginx日誌上尋找規律
在上一個排查中，發現了nginx佔用資源出現增加狀況，而且和zabbix監控進行了對比，產生吻合的現象。所以，問題定位在nginx上。
（0）日誌格式
head -n 1 /tmp/load.log access.log:[27/Sep/2018:09:34:00 +0800] [xxxxx] [222460266] [GET /tg_templates/doubleone/2016/servertime/getInfo.php HTTP/1.0] [200] [43] [-] [%E5%90%8C%E8%8A%B1%E9%A1%BA/10.00.33 CFNetwork/808.1.4 Darwin/16.1.0] [223.104.216.124, 10.99.11.9, 223.104.216.124] [0.002] [unix:/dev/shm/phpfpm5.4.socket] [0.000] [xxxxxx] [-] [/tg_templates/doubleone/2016/servertime/getInfo.php] [80] [-] []
（1）排查請求量是否異常
將報警時間段先後的日誌取出，進行獨立過濾，發現 URI：/img/ad 出現的頻率很高（爲了取出相同的URI，不過濾完整的URI），一分鐘高到一萬次。
awk -F ']' '{print $1" "$4}' /tmp/load1.log|tr -d '[' |awk -F '[: ]' '{print $3":"$4" "$9 }'|awk -F '/' '{print $1"/"$2"/"$3}' |sort |uniq -c|sort -nr |head
8781 09:29 /img/ad
8630 09:28 /img/ad
8328 09:27 /img/ad
3421 09:29 /interface/trade
3004 09:28 /interface/trade
2884 09:27 /interface/trade
1542 09:29 /tg_templates/doubleone
1492 09:28 /tg_templates/doubleone
1446 09:29 /api/index.php?action=getadlist2&platform=gphone
1393 09:27 /tg_templates/doubleone
awk -F ']' '{print $1" "$4}' /tmp/load.log|tr -d '[' |awk -F '[: ]' '{print $3":"$4" "$9 }'|awk -F '/' '{print $1"/"$2"/"$3}' |sort |uniq -c|sort -nr |head
11128 09:30 /img/ad
10965 09:31 /img/ad
10941 09:34 /img/ad
10194 09:32 /img/ad
10137 09:33 /img/ad
8181 09:35 /img/ad
6505 09:36 /img/ad
5196 09:30 /interface/trade
4783 09:34 /interface/trade
4289 09:33 /interface/trade
（2）排查慢日誌量上的異常
將請求的響應時間大於1秒以上的全部請求，所有取出來，按照時間序列進行排序。發信啊在9點35分到36分的時候，出現慢日誌最多。對比日誌量，35分和36分都是每分鐘8000屢次請求。
雖然知道了這個請求很慢，可是並不能徹底證實就是這個慢請求引發的
grep "/img/ad/indexNav/20180926" /tmp/load1.log |awk -F ']' '{print $1" "$(NF-9)}' |tr -d '[' | awk -F '[: ]' '{print $3":"$4" "$(NF)}'|awk '($NF>1){print $1}' |sort |uniq -c |sort -nr |head
57 09:27
8 09:28
5 09:29
grep "/img/ad/indexNav/20180926" /tmp/load.log |awk -F ']' '{print $1" "$(NF-9)}' |tr -d '[' | awk -F '[: ]' '{print $3":"$4" "$(NF)}'|awk '($NF>1){print $1}' |sort |uniq -c |sort -nr |head
2012 09:36
1197 09:35
565 09:30
200 09:34
70 09:33
31 09:32
19 09:31
（3）排查其餘慢請求
其餘慢請求基本沒有，排查其餘慢請求引發的。問題定位在URI:「/img/ad/indexNav/20180926」上。
grep "/interface/trade" /tmp/load.log |awk -F ']' '{print $1" "$(NF-9)}' |tr -d '[' | awk -F '[: ]' '{print $3":"$4" "$(NF)}'|awk '($NF>1){print $1}' |sort |uniq -c |sort -nr |head
6 09:36
3 09:35
2 09:30
1 09:33
（4）排查具體的慢請求時間
grep "/img/ad/indexNav/20180926" /tmp/load.log |awk -F ']' '{print $1" "$(NF-9)}' |tr -d '[' | awk -F '[: ]' '{print $3":"$4" "$(NF)}'|awk '($NF>1){print $0}' |sort|uniq -c |sort -nr |head
38 09:36 2.478
34 09:36 1.576
33 09:36 4.484
32 09:35 7.072
30 09:36 3.138
29 09:36 3.845
29 09:36 3.548
29 09:36 2.677
24 09:35 3.508
23 09:36 2.843
（5）排查具體慢請求的URL
查看完整的URL，用於定位最長出現的URI，着重排查該類URI。
grep "/img/ad/indexNav/20180926" /tmp/load.log |awk -F ']' '{print $1" "$4" "$(NF-9)}'|tr -d '['|awk -F '[: ]' '{print $3":"$9" "$8" "$(NF)}'|awk '($NF>1){print $0}' |head
09:/img/ad/indexNav/20180926/1537959962_9815.png GET 1.325
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.327
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.136
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.134
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.134
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.570
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.380
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.806
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.380
09:/img/ad/indexNav/20180926/1537960001_6674.png GET 1.386
（6）查看完整日誌
查看完整的日誌格式是爲看出各個字段上是否出現異常，從完整日誌中看到body字段，返回的body是30W左右，即300K左右，通常這個body字段只有20左右才屬於正常的。300 K明顯是不正常的。
計算一下，一分鐘1W次，每次都是300K，也就是300萬KB，除以60秒，每秒中是50M的讀盤。IO固然會高了....
問題緣由基本定位。
adm.access.log:[27/Sep/2018:09:34:00 +0800] [192.168.215.91] [363346437] [GET /img/ad/indexNav/20180926/1537960001_6674.png HTTP/1.1] [200] [294880] [-] [%E5%90%8C%E8%8A%B1%E9%A1%BA/10.30.14 CFNetwork/808.1.4 Darwin/16.1.0] [122.238.114.23] [0.004] [-] [-] [XXXXX] [-] [/img/ad/indexNav/20180926/1537960001_6674.png] [80] [-] [] adm.access.log:[27/Sep/2018:09:34:00 +0800] [192.168.205.23] [-] [GET /img/ad/indexNav/20180926/1537959962_9815.png HTTP/1.1] [200] [294880] [-] [platform=gphone&version=G037.08.330.1.32] [223.104.215.36, 10.101.8.1] [0.000] [-] [-] [XXXXX] [-] [/img/ad/indexNav/20180926/1537959962_9815.png] [80] [-] [] adm.access.log:[27/Sep/2018:09:34:00 +0800] [192.168.210.142] [-] [GET /img/ad/indexNav/20180926/1537959962_9815.png HTTP/1.1] [200] [294880] [-] [platform=gphone&version=G037.08.338.1.32] [221.215.205.170, 10.99.2.9] [0.002] [-] [-] [XXXXX] [-] [/img/ad/indexNav/20180926/1537959962_9815.png] [80] [-] []
（7）判斷是不是反爬引發
爬蟲爬取一個頁面，一分鐘進行大量爬取，即便body部分不大，機器同樣會被爆掉。況且這是一個高達300K的圖片。
固然，爬蟲基本上是不可能的，由於這臺，上線了反爬程序
grep "/img/ad/indexNav/20180926" /tmp/load.log |awk -F ']' '{print $1" "$(NF-10)}' |tr -d '[' | awk -F '[ ,]' '{print $4}' |sort |uniq -c |sort -nr |head -n 20
63 117.136.8.233
62 42.101.64.192
61 36.102.236.184
54 117.136.8.69
52 112.20.12.199
46 117.136.8.74
46 112.20.12.205
45 112.20.12.194
44 117.136.8.78
42 117.136.8.66
42 117.136.8.65
38 117.136.8.224
35 223.104.6.27
35 223.104.247.7
七、問題總結
一、爲何每次請求都要請求本地的圖片？
實際上這個問題問的就是爲何沒有對圖片作緩存，咱們前端作的緩存是100K限制，大於100K的圖片都自動不作緩存，這也是此次機器被打爆的緣由。300K大小的圖片遠遠超過了緩存的限制，因此全部請求的圖片都沒有緩存住。
根據實際要求，前端是否能夠放寬緩存大小的限制
圖片png格式，測試將其轉爲jpg格式後，僅19K，具體產品爲何要用怎麼大的圖片，多是考慮到美觀性。
二、爲何其餘時間沒有報警？
因爲業務的性質，天天上午9.30纔開市，因此流量都集中在這個點，該圖片是前一天產品剛發上去的，因此是在今天報警的，下午沒有報警的緣由是，流量變小了。
八、處理方案一、開發作好圖片大小限制，進行審覈。二、運維作好緩存，緩存的限制要根據開發這邊提供的圖片大小與業務相結合。
相關文章
- 1. 一次網站性能排查實錄
- 2. Redis高負載排查記錄
- 3. 記錄一次網站快照被劫持排查血淚史
- 4. 記一次Dubbo超時&CPU高負載問題排查
- 5. 記錄一次PostgreSQL的問題排查
- 6. 記錄一次惡意軟件排查
- 7. 一次問題排查記錄
- 8. 一次網站登錄慢故障排查
- 9. 記錄一次海外圖片加載不出來的排查
- 10. 記錄第一次玩網站玩Seo排名
- 更多相關文章...
- • ADO 添加記錄 - ADO 教程
- • ADO 更新記錄 - ADO 教程
- • Tomcat學習筆記（史上最全tomcat學習筆記）
- • 算法總結-二分查找法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. 一次網站性能排查實錄
- 2. Redis高負載排查記錄
- 3. 記錄一次網站快照被劫持排查血淚史
- 4. 記一次Dubbo超時&CPU高負載問題排查
- 5. 記錄一次PostgreSQL的問題排查
- 6. 記錄一次惡意軟件排查
- 7. 一次問題排查記錄
- 8. 一次網站登錄慢故障排查
- 9. 記錄一次海外圖片加載不出來的排查
- 10. 記錄第一次玩網站玩Seo排名