国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

記一次單個服務(wù)將cpu占滿的問題排查

BetaRabbit / 2673人閱讀

摘要：一發(fā)生故障今天發(fā)現(xiàn)服務(wù)查詢一直卡住，就看了一下服務(wù)器當(dāng)時就愣住了就這一個服務(wù)就把占滿了，再看了下端口號出現(xiàn)了大量的。

一、發(fā)生故障

今天發(fā)現(xiàn)服務(wù)查詢一直卡住，就看了一下服務(wù)器：

當(dāng)時就愣住了就這一個服務(wù)就把CPU占滿了，再看了下端口號：

出現(xiàn)了大量的CLOSE_WAIT。看到這里我就只有一個想法：程序代碼有問題或者是配置的問題

二、排查

為此我先重啟了服務(wù)并加上參數(shù)用jconsole查看服務(wù)狀況：
-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=10000
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

再打印GC日志：
-verbose:gc
-Xloggc:/usr/app/ydjAgent/gc_log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps

啟動參數(shù)太長了我又把它添加到環(huán)境變量里：
vim /etc/profile

export JAVA_OPTS="-Xms1024m -Xmx4096m -Djava.rmi.server.hostname=120.0.0.1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -verbose:gc -Xloggc:/usr/app/ydjAgent/gc_log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

根據(jù)jconsole概覽和GC日志可以看的出，是因為系統(tǒng)頻繁進行GC導(dǎo)致的：

一般情況下，young gc頻繁是正常的，full gc如果非常頻繁，一般情況下有問題的就是接口查詢中的集合的數(shù)據(jù)，存起來了，一直沒刪除，導(dǎo)致gc沒有及時回收。

然后將堆信息dump下來后用Eclipse memory analyze分析了一下，發(fā)現(xiàn)char[]數(shù)組和byte[]數(shù)組占了大部分內(nèi)存。

綜上分析后查明，因為業(yè)務(wù)需要統(tǒng)計一個月內(nèi)的所有訂單中的商品以及品牌排行，因為原有表的設(shè)計的主鍵id是UUID，服務(wù)在啟動的時候只給了最大4G內(nèi)存，即使是只查詢訂單id，都占了很大一部分空間，更別說后面查詢出來的訂單信息會占用更大的內(nèi)存空間，而因為這樣，數(shù)據(jù)庫的壓力和應(yīng)用的壓力也會很大，應(yīng)用一直處于FULL GC狀態(tài)，把cpu占滿。

三、解決辦法

因為該應(yīng)用和數(shù)據(jù)庫是在同一個服務(wù)器上，所以就先把應(yīng)用部署到另一個服務(wù)器上然后用nginx通過內(nèi)網(wǎng)將請求轉(zhuǎn)發(fā)，把內(nèi)存設(shè)置8G，緩解原來服務(wù)器的CPU壓力，即便如此，在數(shù)據(jù)訪問的時候還是對數(shù)據(jù)庫造成了很大的壓力。因為我代碼寫的太爛了哈哈。。事發(fā)之后先向老板做了匯報，老板表示理解。。給我時間去重新設(shè)計原有的架構(gòu)。。。不說了寫代碼去。。。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/74324.html

相關(guān)文章

  • 記一次MongoDB高負載的性能優(yōu)化

    摘要：年月日本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化此處涉及的技術(shù)包括引擎隨著游戲?qū)肴藬?shù)逐漸增加單個集合的文檔數(shù)已經(jīng)超過經(jīng)常有玩家反饋說卡特別是在服務(wù)器遷移后從核降到核卡頓更嚴(yán)重了遂開始排查問題確認(rèn)服務(wù)器壓力首先使用命令查看總體情況此時占用不高 Last-Modified: 2019年6月13日11:08:19 本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化, 此處涉及的技術(shù)包括: MongoDB...

    huhud 評論0 收藏0

  • 記一次MongoDB高負載的性能優(yōu)化

    摘要：年月日本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化此處涉及的技術(shù)包括引擎隨著游戲?qū)肴藬?shù)逐漸增加單個集合的文檔數(shù)已經(jīng)超過經(jīng)常有玩家反饋說卡特別是在服務(wù)器遷移后從核降到核卡頓更嚴(yán)重了遂開始排查問題確認(rèn)服務(wù)器壓力首先使用命令查看總體情況此時占用不高 Last-Modified: 2019年6月13日11:08:19 本文是關(guān)于記錄某次游戲服務(wù)端的性能優(yōu)化, 此處涉及的技術(shù)包括: MongoDB...

    vibiu 評論0 收藏0

  • 串行還是并行？——記一次 AsyncTask 問題排查

    摘要：當(dāng)然，如果你的核心數(shù)夠多，到個線程的并行度不滿足的話，也可以自定義一個線程池來執(zhí)行，不過這樣的話，要注意自己維護這個線程池的初始化，釋放等等操作了。 事情起源于一個bug排查，一個AsyncTask的子類，執(zhí)行的時候發(fā)現(xiàn)onPreExecute方法執(zhí)行了，doInBackground卻遲遲沒有被調(diào)用。懂AsyncTask一些表面原理的都知道，onPreExecute方法是在主線程執(zhí)行，...

    mo0n1andin 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<