有個(gè)客戶需要提交一個(gè)4M左右的pdf，接口里傳的是pdf字節(jié)流base64編碼后的字符串。

直接curl -XPOST -d 'json串' api接口會(huì)報(bào)? 參數(shù)過(guò)長(zhǎng)報(bào)錯(cuò)Argument list too long

網(wǎng)上搜了下解決方案把json串放到文本里然后通過(guò)@json.txt引入?yún)?shù)

這一試不要緊，差點(diǎn)兒導(dǎo)致生產(chǎn)故障。。。（因?yàn)橹氨镜卦嚵私涌谝?5秒左右，另一個(gè)同事說(shuō)可能生產(chǎn)的帶寬更好一些應(yīng)該會(huì)快的，所以昨天發(fā)版帶上去限制放大到10M（nacos配置特殊客戶才放開(kāi)，正常限制還是2M）想今天看下接口響應(yīng)時(shí)間）

curl命令行很快顯示504 gateway timeout...

很快收到某節(jié)點(diǎn)cpu飆升到90%的告警（該節(jié)點(diǎn)正好是灰度節(jié)點(diǎn)，公司內(nèi)網(wǎng)接口流量）

JAVA程序?qū)е耤pu標(biāo)高排查_(kāi)java cpu 標(biāo)高-CSDN博客

這里引用另一位同學(xué)的博客分析了下，但沒(méi)分析出jstack來(lái)，后猜想可能和自己測(cè)的大pdf有關(guān)，但為什么持續(xù)這么長(zhǎng)時(shí)間cpu高居不下？（大概有30分鐘），看cat監(jiān)控才看到gc頻率變大，時(shí)間變長(zhǎng)，一直younggc沒(méi)回收回來(lái)，最終導(dǎo)致fullgc..未完待續(xù)..（為什么younggc沒(méi)回收到合適的空間）

每天都能遇到新問(wèn)題...挖坑填坑樂(lè)此不疲。。