6月11日

第一次發(fā)版，配合運(yùn)維解決線上環(huán)境問題。
操作步驟：

wget https://ftp.gnu.org/gnu/gcc/gcc-9.1.0/gcc-9.1.0.tar.gz
sudo yum install libmpc-devel mpfr-devel gmp-devel
sudo yum install zlib-devel*
tar xf gcc-9.1.0.tar.gz
cd gcc-9.1.0
./configure --with-system-zlib --disable-multilib --enable-languages=c,c++
make -j24
sudo make install
export PATH=/usr/local/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH

6月12日

服務(wù)器擴(kuò)容，新增2臺(tái)機(jī)器。
新增機(jī)器之后，開放 CPU 限制導(dǎo)致，由于 login 消息積壓，導(dǎo)致 CPU 一直滿載。

ncpu := runtime.NumCPU()
if ncpu > 2 {
  runtime.GOMAXPROCS(int(ncpu) - 2)
}

MQ 消費(fèi)問題，如何能更自然的解決積壓?jiǎn)栴}，還有積壓告警

問題：

如果沒有消費(fèi)者，生產(chǎn)者持續(xù)生成，數(shù)據(jù)會(huì)存到硬盤，過期策略，等到消費(fèi)者上線會(huì)產(chǎn)生積壓，要是新增一個(gè)消費(fèi)者，之前的數(shù)據(jù)怎么搞，那不是都有積壓，哈？

6月13日

四臺(tái)機(jī)器消費(fèi)能力正常，增加大數(shù)據(jù)提供的線上接口之后出現(xiàn)另外的問題，機(jī)器有16G的內(nèi)存，基本一小時(shí)內(nèi)打滿。

分析原因是當(dāng)前版本 resty 的遺留問題，針對(duì)類似參數(shù)多變的 URL 會(huì)進(jìn)行 Metric 監(jiān)控采集，由于 QPS 晚高峰達(dá)到 5000+ 情況下，大數(shù)據(jù)接口產(chǎn)生數(shù)據(jù)延時(shí)以及報(bào)錯(cuò)，導(dǎo)致 timer 時(shí)延進(jìn)而內(nèi)存堆積。

image.png

升級(jí) resty 解決。
增加自定義 Metric

func SetMetric(typeStr string) {
    EncryptImp.metric.Counter(typeStr, map[string]string{
        "ctype": typeStr,
    }).Inc(1)
}

服務(wù)上線前對(duì)大數(shù)據(jù)的接口沒有進(jìn)行壓測(cè)，線下沒發(fā)現(xiàn)這個(gè)問題。
調(diào)整之后目前線上服務(wù)穩(wěn)定。

總結(jié)

• MQ 消費(fèi)服務(wù)上線注意積壓?jiǎn)栴}，準(zhǔn)備解壓方案
• 對(duì)于 QPS 較高的服務(wù)進(jìn)行完整性壓測(cè)