自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

解決Java/MySQL性能問(wèn)題的思路

開發(fā) 后端
千萬(wàn)別在論壇、群里問(wèn),我的機(jī)器好慢怎么回事?我的機(jī)器內(nèi)存泄露了怎么回事?這類大而空的問(wèn)題一點(diǎn)意義都沒(méi)有,其實(shí)誰(shuí)都不知道。你要做的是用下面的思路、方法、工具去定位它

千萬(wàn)別在論壇、群里問(wèn),我的機(jī)器好慢怎么回事?我的機(jī)器內(nèi)存泄露了怎么回事?

這類大而空的問(wèn)題一點(diǎn)意義都沒(méi)有,其實(shí)誰(shuí)都不知道。你要做的是用下面的思路、方法、工具去定位它

解決問(wèn)題思路

Java程序問(wèn)題(運(yùn)行慢)

先通過(guò) top 查看整個(gè)CPU資源使用情況;

通過(guò)top -Hp pid查看java進(jìn)程的每一個(gè)線程占用CPU的情況;

如果有一個(gè)線程占用CPU過(guò)高,有兩種可能:

沒(méi)有內(nèi)存了,Java垃圾回收線程不停地運(yùn)行嘗試回收內(nèi)存,但是每次無(wú)法收回,確認(rèn):

jstat -gcutil pid 1s 觀察10多秒鐘就能發(fā)現(xiàn)了,看是不是內(nèi)存使用率接近100%了

類似于死循環(huán)(hash沖突攻擊),就是一個(gè)線程一直占用一個(gè)核的所有CPU資源(其實(shí)一個(gè)線程總是暫用一個(gè)核超過(guò)50%的資源都是不太正常的),解決:

用我課堂的checkPerf腳本,定位這個(gè)線程具體執(zhí)行的任務(wù)(能具體到某一行),對(duì)應(yīng)看代碼解決。

如果有很多線程,每個(gè)線程占用的CPU都不多,那基本是正常的。

如果死鎖:

jstack -l pid 多執(zhí)行幾次,統(tǒng)計(jì)一下stack中總是在等待哪些鎖,可以對(duì)鎖id進(jìn)行排序統(tǒng)計(jì)(sort uniq grep)

上面列出來(lái)的都是明顯的瓶頸,最可怕的是哪里都沒(méi)有明顯的瓶頸,哪里都要偷一點(diǎn)點(diǎn)資源走,這是可以試試JProfiler這樣更專業(yè)一點(diǎn)的工具,同時(shí)要配合自己對(duì)業(yè)務(wù)的了解來(lái)解決。

Java內(nèi)存的問(wèn)題,如果有內(nèi)存泄露(就是執(zhí)行完fgc/old gc后不能回收的內(nèi)存不斷地增加):

快速解決:jmap -histo:live pid 來(lái)統(tǒng)計(jì)所有對(duì)象的個(gè)數(shù)(String/char/Integer/HashEntry 這樣的對(duì)象很多很正常,主要是盯著你們公司的包名下的那些對(duì)象)

每隔一分鐘執(zhí)行一次上面的命令,執(zhí)行5次以上,看看你們公司報(bào)名下的對(duì)象數(shù)量哪個(gè)在一直增加,那基本上就是這個(gè)對(duì)象引起了泄露;

用課堂上的工具HouseMD來(lái)動(dòng)態(tài)監(jiān)控創(chuàng)建這個(gè)對(duì)象的地方(一般來(lái)說(shuō)很多時(shí)候創(chuàng)建了這些對(duì)象把他們丟到一個(gè)HashMap然后就不管了),分析一下有沒(méi)有釋放!

上面的方法實(shí)在沒(méi)法定位就用: jmap -dump 導(dǎo)出整個(gè)內(nèi)存(耗時(shí)間,需要很大的內(nèi)存的機(jī)器才能對(duì)這個(gè)導(dǎo)出文件進(jìn)行分析,會(huì)將JVM鎖住一段時(shí)間)

在Eclipse的插件EMA中打開這個(gè)文件(2G的物理文件需要4G以上的內(nèi)存,5G以上的需要將近20G的內(nèi)存來(lái)分析了)

盯著你們公司報(bào)名的那些對(duì)象,看看引用關(guān)系,誰(shuí)拿著這些對(duì)象沒(méi)釋放(是否是必要的)

MySQL 數(shù)據(jù)庫(kù)的性能問(wèn)題

大部分情況下是磁盤IO的問(wèn)題(索引沒(méi)建好、查詢太復(fù)雜);

索引問(wèn)題的話分析慢查詢?nèi)罩?,explain 他們挨個(gè)解決。

偶爾也有數(shù)據(jù)庫(kù)CPU不夠的情況,如果并發(fā)高CPU不夠很正常,如果并發(fā)不高,那很可能就是group by/order by/random之類的操作嚴(yán)重消耗了數(shù)據(jù)庫(kù)的CPU

mysql -e “show full processlist” | grep -v Sleep | sort -rnk6 查看那些SQL語(yǔ)句執(zhí)行的太長(zhǎng)

拿出這個(gè)SQL語(yǔ)句分析他們的執(zhí)行計(jì)劃: explain SQL 然后改進(jìn);

分析慢查詢?nèi)罩?,統(tǒng)計(jì)top10性能殺手的語(yǔ)句,挨個(gè)explain他們,然后改進(jìn)(具體改進(jìn)辦法具體分析,這里只談思路)

總結(jié)一下數(shù)據(jù)庫(kù)問(wèn)題就只有這三招:show full processlist/分析慢查詢?nèi)罩?explain(然后建好聯(lián)合索引)

原文鏈接:http://database.ctocio.com.cn/66/12654066.shtml

責(zé)任編輯:陳四芳 來(lái)源: 博客
相關(guān)推薦

2019-07-05 17:40:24

MySQL并發(fā)數(shù)據(jù)庫(kù)

2018-05-04 15:15:37

數(shù)據(jù)庫(kù)MySQL并發(fā)場(chǎng)景

2022-07-15 08:52:03

Linux優(yōu)化

2022-11-16 21:55:51

Redis數(shù)據(jù)庫(kù)

2023-10-08 13:10:00

Redis數(shù)據(jù)庫(kù)

2017-08-23 08:28:45

數(shù)據(jù)庫(kù)SQLMySql

2023-10-13 12:05:55

RedisBig Key

2013-02-26 10:37:56

服務(wù)器閃存服務(wù)器閃存

2011-05-27 15:11:04

DB2

2018-03-09 16:27:50

數(shù)據(jù)庫(kù)Oracle同步問(wèn)題

2024-03-04 08:00:00

Java開發(fā)

2024-06-12 12:59:16

2024-12-09 09:10:00

2021-06-08 08:38:36

MySQL數(shù)據(jù)庫(kù)死鎖問(wèn)題

2011-03-22 16:09:33

MySQL 5.0.1亂碼

2022-09-06 15:30:20

緩存一致性

2010-11-25 11:15:11

MySQL查詢超時(shí)

2022-03-02 11:13:50

Web前端開發(fā)

2019-06-21 14:40:52

緩存系統(tǒng)性能操作系統(tǒng)

2018-11-22 15:07:17

代碼github程序
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)