日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 运维知识 > linux >内容正文

linux

Linux - 生产故障、性能评估面试题

發布時間:2023/12/29 linux 31 豆豆
生活随笔 收集整理的這篇文章主要介紹了 Linux - 生产故障、性能评估面试题 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

目錄

    • 1、生產環境服務器變慢,診斷思路和性能評估談談;linux怎么查看系統負載情況
      • 一、查看cpu
      • 二、查看內存
      • 三、查看硬盤
      • 四、磁盤IO
      • 五、網絡I/O
      • 記一次真實排查經歷
    • 2、假如生產環境出現cpu占用過高,請你談談你的分析思路和定位
    • 3、Linux什么命令可以查詢java調用?!径刃M】
    • 4、linux,怎么統計一個文件的某詞的出現次數【度小滿】
    • 5、kill -9 中9的含義是啥?【度小滿】
    • 6、大日志怎么切分?【度小滿】
    • 7、怎么查看一個進程的端口號?【度小滿】
    • 8、Linux,grep命令,在大日志文件中搜索關鍵字,最后/最開始出現位置【度小滿】
    • 9、怎么動態的查看jvm內存【度小滿】
    • 9、監視虛擬機各種運行狀態信息【也可以動態的查看jvm內存】
    • 10、內存泄漏怎么排查
      • 10.1 確定頻繁Full GC現象
      • 10.2、找出導致頻繁Full GC的原因
    • 11、linux如何快速到文件底部和頭部
    • 12、某個文件夾下,查找關鍵字并上色

1、生產環境服務器變慢,診斷思路和性能評估談談;linux怎么查看系統負載情況

例子:linux上跑該java程序

import java.util.Random; public class JavaDemo02 {public static void main(String[] args) {while(true){System.out.println(new Random().nextInt(77778888));}} }

一、查看cpu

1、整機性能查看:top命令,看cpu、內存以及系統負載

[root@localhost ~]# jps -l 18734 sun.tools.jps.Jps 18687 JavaDemo02

看右上角系統的負載,3個值,分別代表系統1分鐘,5分鐘,15分鐘的平均負載,如果三個值相加,除以3,再乘以100%,高于60%,那么表示系統的負擔壓力重

按小鍵盤上的1,能查看各個cpu

2、系統性能命令的精簡版

[root@localhost ~]# uptime21:55:33 up 5 min, 2 users, load average: 0.66, 2.05, 1.10

3、查看CPU
表示每兩秒采樣一次,共計采樣三次

[root@localhost ~]# vmstat -n 2 3 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st2 0 67636 116484 0 372304 4 155 2874 396 661 2198 27 13 60 0 01 0 67636 115900 0 372388 0 0 0 0 398 3573 9 6 85 0 00 0 67636 116540 0 372380 0 0 0 0 329 554 4 3 93 0 0

procs:

  • r表示運行和等待cpu時間片的進程數,原則上1核的cpu運行隊列不要超過2,整個系統的運行隊列不能超過總核數的2倍,否則表示系統壓力過大
  • b表示等待資源的進程數,比如正在等待磁盤I/O,網絡I/O等

CPU:

  • us:用戶進程消耗cpu時間片,us值高,用戶進程消耗cpu時間多,如果長期大于50%,優化程序;
  • sy:內核進程消耗的cpu時間百分比
  • us+sy參考值為80%,如果us+sy大于80%,說明可能存在cpu不足
  • id:處于空閑的cpu百分比
  • wa:系統等待io的cpu時間百分比
  • st:來自于一個虛擬機偷取的cpu時間的百分比

4、查看所有cpu核信息

yum install sysstat [root@localhost init.d]# mpstat -P ALL 2mpstat [-P {|ALL}] [internal [count]] 參數:(1)-P {|ALL}:表示監控哪個CPU,在[0,cpu個數-1]中取值;(2)internal:相鄰的兩次采樣的間隔時間;(3)count:采樣的次數,count只能和delay一起使

如果cpu空閑率idle低于60,表示壓力來了

5、每個進程使用cpu的用來分解信息

[root@localhost init.d]# pidstat -u 1 -p 進程號

二、查看內存

1.查看系統內存情況

[root@iz2ze5pjtwp4umzvw3ikwyz /root]#free -mtotal used free shared buff/cache available Mem: 1838 1058 84 0 695 625 Swap: 0 0 0
  • 應用程序可用內存/系統物理內存>70% :表示內存充足
  • 應用程序可用內存/系統物理內存<20% :表示內存不足,需要增加內存
  • 20%<應用程序可用內存/系統物理內存<70%:基本夠用

2.查看某個進程內存占用情況
pidstat -p 進程號 -r 采樣間隔秒數

[root@localhost elasticsearch]# pidstat -p 8469 -r 2 Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 2020年09月27日 _x86_64_ (1 CPU)22時58分40秒 UID PID minflt/s majflt/s VSZ RSS %MEM Command 22時58分42秒 1000 8469 11.11 0.00 2751072 460332 24.71 java 22時58分44秒 1000 8469 0.00 0.00 2751072 460332 24.71 java 22時58分46秒 1000 8469 0.00 0.00 2751072 460332 24.71 java 22時58分48秒 1000 8469 1.02 0.00 2751072 460332 24.71 java 22時58分50秒 1000 8469 0.00 0.00 2751072 460332 24.71 java

三、查看硬盤

1.查看硬盤剩余空間數
df -h
17G用了8.9G,還剩8.2G

[root@localhost elasticsearch]# df -h 文件系統 容量 已用 可用 已用% 掛載點 /dev/mapper/centos-root 17G 8.9G 8.2G 52% / devtmpfs 898M 0 898M 0% /dev tmpfs 910M 0 910M 0% /dev/shm tmpfs 910M 11M 900M 2% /run tmpfs 910M 0 910M 0% /sys/fs/cgroup /dev/sda1 1014M 146M 869M 15% /boot tmpfs 182M 0 182M 0% /run/user/0 overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/f5351f3bc4f9c26d418e3f165980652af25638bd81f7470f393b7b2ba5ab4988/merged overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/695f41c985a99a85c9162553f5a54bcc13e7b1da72a8655935ae0ad7383b5d32/merged overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/9b6779047826249ca56e9749b07a641461a5d8ebf587e5e9bd72e320476c1ed9/merged overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/78125a7ea22936400c8eab1e6cef6d11670dfbd75f4cc44ae64e786b7f4f061f/merged overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/aaed4b469503a5616061c088502cc0c17516429328645a3b90289f3a4a17293e/merged overlay 17G 8.9G 8.2G 52% /var/lib/docker/overlay2/223efee7555b345d5096c6276dc81e8bf8e11ad86bb7368a4c7c9ec7ed74e495/merged shm 64M 0 64M 0% /var/lib/docker/containers/ee28ef78b266ba43830c7dc1f47c3467421de6140157b732ccc9f2a695549b20/shm shm 64M 0 64M 0% /var/lib/docker/containers/5ddc78779cf757486ce99c5cfa0b0e23fd3a56a1c6ce290c2e038358251ea75a/shm shm 64M 0 64M 0% /var/lib/docker/containers/60758399768fb35f0e3878976791c20fc2fc8e605155782a7c6813603591e042/shm shm 64M 0 64M 0% /var/lib/docker/containers/85eb1d8a6041af0356f599c4daf78731fd5d180e79b4000fbda31b4582cdf41a/shm shm 64M 0 64M 0% /var/lib/docker/containers/d9e048b0329d2d16649ebc3ae02a842ebfe5a873b9363d31622ebf1bcd8f035f/shm shm 64M 0 64M 0% /var/lib/docker/containers/ba18b874b3053b40ebb0f5733b5b5f05be941da47de29415f014389d7bc10e6d/shm

四、磁盤IO

系統慢,基本上,一個是cpu導致,一個是磁盤io;
磁盤io,mysql大表存儲,查詢的時候,大片的數據在磁盤上io,如果這個時候長時間的io,將會導致系統很大的問題。

1、系統整體的磁盤I/o性能評估
兩秒鐘取樣一次,取樣3次

[root@localhost elasticsearch]# iostat -xdk 2 3 Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 2020年09月27日 _x86_64_ (1 CPU)Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.17 4.07 7.89 0.93 336.40 48.89 87.41 0.01 1.05 1.00 1.48 0.59 0.52 dm-0 0.00 0.00 7.35 0.87 328.39 29.06 86.92 0.01 1.11 1.07 1.46 0.62 0.51 dm-1 0.00 0.00 0.21 4.11 1.31 16.45 8.23 0.01 1.70 0.41 1.77 0.02 0.01Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

磁盤塊設備分布:

  • rkB/s每秒讀取數據量KB
  • wkB/s每秒寫入數據量KB
  • svctm I/O請求的平均服務時間,單位毫秒
  • await I/O請求的平均等待時間,單位毫秒;值越小,性能越好
  • util 一秒中有百分幾的時間用于i/o操作。接近100%時,表示磁盤帶寬跑滿,需要優化程序或者增加磁盤; 這個指標最重要
  • rkB/s 、wkB/s根據系統應用不同會有不同的值,但有規律遵循:長期、超大數據讀寫,肯定不正常,需要優化程序讀取。
  • svctm與await 的值很接近,表示幾乎沒有i/o等待,磁盤性能好。如果await 的值遠高于svctm的值,則表示i/o隊列等待太長,需要優化程序或更換更快的磁盤。

命令參數:
-c: 顯示CPU使用情況
-d: 顯示磁盤使用情況
-N: 顯示磁盤陣列(LVM) 信息
-n: 顯示NFS 使用情況
-k: 以 KB 為單位顯示
-m: 以 M 為單位顯示
-t: 報告每秒向終端讀取和寫入的字符數和CPU的信息
-V: 顯示版本信息
-x: 顯示詳細信息
-p:[磁盤] 顯示磁盤和分區的情況

2、查看某個進程的磁盤i/o占用情況

[root@localhost elasticsearch]# pidstat -d 2 -p 8469 Linux 3.10.0-957.el7.x86_64 (localhost.localdomain) 2020年09月27日 _x86_64_ (1 CPU)23時23分02秒 UID PID kB_rd/s kB_wr/s kB_ccwr/s Command 23時23分04秒 1000 8469 0.00 0.00 0.00 java 23時23分06秒 1000 8469 0.00 0.00 0.00 java 23時23分08秒 1000 8469 0.00 0.00 0.00 java

kB_rd/s:進程每秒從磁盤讀取的數據量(以kB為單位)
kB_wr/s:進程每秒向磁盤寫入的數據量(以kB為單位)
kB_ccwr/s:任務寫入磁盤被取消的速率(KB);當任務截斷臟的pagecache的時候會發生。

3、如果不知道進程號,但是iostat -xdk 2 3,又顯示磁盤占用高,怎么找到是哪個進程占用高呢
一、通過 iotop 命令: yum install iotop 進行安裝

iotop -oP


–version 查看版本
-h, --help 查看幫助
-o, --only 只顯示有 IO 操作的進程或線程
-b, --batch 沒有交互的模式,可以當成日志直接輸出到文件記錄用。
-n NUM, --iter=NUM 循環次數,在刷新了指定的次數后,程序就退出
-d SEC, --delay=SEC 刷新的頻率,默認 1 秒一次
-p PID, --pid=PID 監視單個進程,默認監視所有。要監視多個,可以加多個 -p PID
-u USER, --user=USER 監視單個用戶,默認監視所有。
-P, --processes 只顯示進程,不顯示線程。
-a, --accumulated 在 Disk Read 和 Disk Write 列顯示的是從 iotop 啟動開始,累計的數據量。
-k, --kilobytes 使用 KB 為單位。
-t, --time 在每一行加上時間戳
-q, --quiet 退出

例如:

iotop -oP -d 3 -t -b > /root/lzhdir/iotop.log

二、通過 pidstat 命令

1 # 命令的含義:展示I/O統計,每秒更新一次 2 # pidstat -d 1

五、網絡I/O

ifstat的安裝使用: wget http://distfiles.macports.org/ifstat/ifstat-1.1.tar.gz tar xzvf ifstat-1.1.tar.gz cd ifstat-1.1 ./configure make make install

查看網絡io: ifstat 1 每秒一次

[root@localhost ~]# ifstat 1ens33 docker0 vethd199461 veth5851ec1 vethca401c0 vethec1ba70 vethabce5d0 vethbdc7e7f KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out0.06 0.42 34.88 35.76 0.00 0.00 13.29 22.54 0.00 0.00 22.54 13.22 0.00 0.00 0.00 0.000.06 0.26 0.36 0.45 0.00 0.00 0.45 0.45 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.000.06 0.26 0.51 0.55 0.00 0.00 0.29 0.26 0.00 0.00 0.26 0.29 0.00 0.00 0.00 0.000.06 0.26 2.22 2.31 0.00 0.00 1.71 0.67 0.00 0.00 0.61 1.64 0.00 0.00 0.00 0.00

記一次真實排查經歷

問題:服務器開機內存便占用過半,一段時間后,內存幾乎占用滿,但是開機以來,沒有運行過任何程序。
排查問題的過程:
1、free -m 查看內存,只能查看出系統內存占用高,但看不出是哪個進程在占用內存
2、top 查看cpu,內存以及負載,查看出負載很高,但是cpu和內存并沒有異常【忘了截圖】,還是確定不下來是哪個進程的問題
意外收獲:多次觀察下,發現了fdfs_storaged,fastdfs我并沒有啟動,怎么會有的呢
803 root 20 0 214724 67196 736 S 0.3 3.6 0:00.30 fdfs_storaged
3、iostat -xdk 2 3查看磁盤I/O,發現util指標極高
4、 pidstat -d 1 命令,查看是哪個進程導致的磁盤io高
發現了fdfs_trackerd進程占用磁盤io,結合top命令發現的fdfs_storaged進程,懷疑fastdfs是開機自啟動,于是百度了一下,如何關閉fastdfs的自啟動,意外發現fastdfs與nginx是一起工作的,直接使用命令ps -ef |grep fdfs 以及ps -ef |grep nginx,果然,這兩貨,都是自啟動,直接kill,然后在關閉自啟動,再次查看內存,發現變化不大,難道還有其他自啟動的程序?繼續觀察top,發現了mysql的進程,關了,并且自啟動也關了,好了

2、假如生產環境出現cpu占用過高,請你談談你的分析思路和定位

1、top命令,找出cpu占比高的進程
比如:進程號58814

2、ps -ef或jps -l進一步定位,得知是怎樣的一個后臺進程在惹事

[root@localhost ~]# jps -l 58934 sun.tools.jps.Jps 58814 JavaDemo02

3、定位到具體的線程或者代碼
發現是線程號位58815的線程在惹事

[root@localhost ~]# ps -mp 58814 -o THREAD,tid,time USER %CPU PRI SCNT WCHAN USER SYSTEM TID TIME root 4.8 - - - - - - 00:00:17 root 0.0 19 - futex_ - - 58814 00:00:00 root 4.7 19 - n_tty_ - - 58815 00:00:16 root 0.0 19 - futex_ - - 58816 00:00:00 root 0.0 19 - futex_ - - 58817 00:00:00 root 0.0 19 - futex_ - - 58818 00:00:00 root 0.0 19 - futex_ - - 58819 00:00:00 root 0.0 19 - futex_ - - 58820 00:00:00 root 0.0 19 - futex_ - - 58821 00:00:00 root 0.0 19 - futex_ - - 58822 00:00:00 root 0.0 19 - futex_ - - 58823 00:00:00

ps -mp 58814 -o THREAD,tid,time
-m 顯示所有的線程
-p pid進程使用cpu的時間
-o 該參數后是用戶自定義格式

4、將需要的線程id轉換為16進程格式(英文小寫格式)

[root@localhost ~]# printf "%x\n" 58815 e5bf

5、jstack 進程號 | grep tid -A60

[root@localhost ~]# jstack 58814 | grep e5bf -A60 "main" #1 prio=5 os_prio=0 tid=0x00007f5378009000 nid=0xe5bf runnable [0x00007f5381ac0000]java.lang.Thread.State: RUNNABLEat java.io.FileOutputStream.writeBytes(Native Method)at java.io.FileOutputStream.write(FileOutputStream.java:326)at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)- locked <0x00000000ed01d528> (a java.io.BufferedOutputStream)at java.io.PrintStream.write(PrintStream.java:482)- locked <0x00000000ed014fc0> (a java.io.PrintStream)at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)- locked <0x00000000ed014f78> (a java.io.OutputStreamWriter)at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)at java.io.PrintStream.write(PrintStream.java:527)- eliminated <0x00000000ed014fc0> (a java.io.PrintStream)at java.io.PrintStream.print(PrintStream.java:597)at java.io.PrintStream.println(PrintStream.java:736)- locked <0x00000000ed014fc0> (a java.io.PrintStream)at JavaDemo02.main(JavaDemo02.java:6)"VM Thread" os_prio=0 tid=0x00007f537806d800 nid=0xe5c0 runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007f53780b9000 nid=0xe5c7 waiting on condition JNI global references: 9

at JavaDemo02.main(JavaDemo02.java:6);是這行代碼惹的事

3、Linux什么命令可以查詢java調用棧【度小滿】

jstack主要用來查看某個Java進程內的線程堆棧信息。

排查死鎖:
jps -l 查看進程號
jstack 進程號> 進程號.txt 打開生成的文件,滑到最底下

4、linux,怎么統計一個文件的某詞的出現次數【度小滿】

grep -o "要統計的詞" 文件名 | wc -l 統計一個:grep -o "a" test | wc -l統計二個:grep -o "a\|b" test | wc -l

5、kill -9 中9的含義是啥?【度小滿】

-9 代表強制殺死進程。

6、大日志怎么切分?【度小滿】

方法一:head命令
head命令是用來獲取文本文件的開始n行。

head -10000 java.log > javaHead.log

方法二:tail命令
tail命令是用來獲取文本最后行。

tail -10000 java.log > javaTail.log

方法三:sed命令
sed命令可以從第N行截取到第M行。( N > 0 , M < FileLineNumber )

sed -n '1,50000p' java.log > javaRange.log

方法四:split命令
每300行切分生成一個新文件,–verbose顯示切分進度

split -l 300 java.txt javaLog --verbose

每10M切分成一個新的文件,–verbose 顯示切分進度

split -d 10m java.txt javaLog --verbose

7、怎么查看一個進程的端口號?【度小滿】

netstat -napl | grep 進程號

[root@localhost sentinel]# jps -l 27350 sentinel-dashboard-1.7.1.jar 27366 sun.tools.jps.Jps [root@localhost sentinel]# netstat -napl | grep 27350 tcp6 0 0 :::8011 :::* LISTEN 27350/java tcp6 0 0 :::8719 :::* LISTEN 27350/java unix 2 [ ] STREAM CONNECTED 111050 27350/java unix 2 [ ] STREAM CONNECTED 111039 27350/java

8、Linux,grep命令,在大日志文件中搜索關鍵字,最后/最開始出現位置【度小滿】

Linux grep 命令用于查找文件里符合條件的字符串。

-c是搜索關鍵字出現位置,并且和上下相鄰n行的結果grep -C 1 'INFO' sentinel.log |head -3 grep -C 1 'error' sentinel.log |tail -3https://www.pianshen.com/article/45201320508/

9、怎么動態的查看jvm內存【度小滿】

[root@localhost logs]# jmap -heap 27350 Attaching to process ID 27350, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.161-b12using thread-local object allocation. Mark Sweep Compact GCHeap Configuration:MinHeapFreeRatio = 40MaxHeapFreeRatio = 70MaxHeapSize = 478150656 (456.0MB)NewSize = 10485760 (10.0MB)MaxNewSize = 159383552 (152.0MB)OldSize = 20971520 (20.0MB)NewRatio = 2SurvivorRatio = 8MetaspaceSize = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize = 17592186044415 MBG1HeapRegionSize = 0 (0.0MB)Heap Usage: New Generation (Eden + 1 Survivor Space):capacity = 14614528 (13.9375MB)used = 8833496 (8.424278259277344MB)free = 5781032 (5.513221740722656MB)60.44325208450112% used Eden Space:capacity = 13041664 (12.4375MB)used = 8639416 (8.239189147949219MB)free = 4402248 (4.198310852050781MB)66.24473686793341% used From Space:capacity = 1572864 (1.5MB)used = 194080 (0.185089111328125MB)free = 1378784 (1.314910888671875MB)12.339274088541666% used To Space:capacity = 1572864 (1.5MB)used = 0 (0.0MB)free = 1572864 (1.5MB)0.0% used tenured generation:capacity = 32301056 (30.8046875MB)used = 26747672 (25.508567810058594MB)free = 5553384 (5.296119689941406MB)82.80742276661172% used19495 interned Strings occupying 2488816 bytes.

9、監視虛擬機各種運行狀態信息【也可以動態的查看jvm內存】

jstat -gcutil 進程號 1000 意思是每1000毫秒查詢一次,一直查。gcutil的意思是已使用空間站總空間的百分比

查詢結果表明:這臺服務器的新生代Eden區(E,表示Eden)使用了28.30%(最后)的空間,兩個Survivor區(S0、S1,表示Survivor0、Survivor1)分別是0和8.93%,老年代(O,表示Old)使用了87.33%。程序運行以來共發生Minor GC(YGC,表示Young GC)101次,總耗時1.961秒,發生Full GC(FGC,表示Full GC)7次,Full GC總耗時3.022秒,總的耗時(GCT,表示GC Time)為4.983秒。

內存泄漏例子:

有大量的FGC就要查詢是否有內存泄漏的問題了,圖中的FGC數量就比較大,并且執行時間較長,這樣就會導致系統的響應時間較長,如果對jvm的內存設置較大,那么執行一次FGC的時間可能會更長。

如果為了更好的證明FGC對服務器性能的影響,我們可以使用java visualVM來查看一下:

從上圖可以發現執行FGC的情況,下午3:10分之前是沒有FGC的,之后出現大量的FGC。

下圖是jvm堆內存的使用情況,下午3:10分之前的內存回收還是比較合理,但是之后大量內存無法回收,最后導致內存越來越少,導致大量的full gc。
下面我們在看看大量full GC對服務器性能的影響,下面是我用loadrunner對我們項目進行壓力測試相應時間的截圖:

從圖中可以發現有,在進行full GC后系統的相應時間有了明顯的增加,點擊率和吞吐量也有了明顯的下降。所以java內存泄漏對系統性能的影響是不可忽視的。

10、內存泄漏怎么排查

https://www.cnblogs.com/wyb628/p/8567617.html
https://www.jianshu.com/p/4548ab7f60e2
內存溢出和內存泄露的聯系,內存泄露會最終會導致內存溢出。
都會導致應用程序運行出現問題,性能下降或掛起。

10.1 確定頻繁Full GC現象

通過"監視虛擬機各種運行狀態信息"

10.2、找出導致頻繁Full GC的原因

分析方法通常有兩種:
1)把堆dump下來再用MAT等工具進行分析,但dump堆要花較長的時間,并且文件巨大,再從服務器上拖回本地導入工具,這個過程有些折騰,不到萬不得已最好別這么干。

https://blog.csdn.net/weixin_42412601/article/details/102616081

2)更輕量級的在線分析,使用“Java內存影像工具:jmap”生成堆轉儲快照(一般稱為headdump或dump文件)。

jmap命令格式:
jmap [ option ] vmid
使用命令如下:
jmap -histo:live 20954
查看存活的對象情況,如下圖所示:

按照一位IT友的說法,數據不正常,十有八九就是泄露的。在我這個圖上對象還是挺正常的。
可以看出HashTable中的元素有5000多萬,占用內存大約1.5G的樣子。這肯定不正常。

定位到代碼
定位到代碼,有很多種方法,比如前面提到的通過MAT查看Histogram即可找出是哪塊代碼?!乙郧笆鞘褂眠@個方法。也可以使用BTrace,我沒有使用過。
舉個例子:

如圖,Object有197130個引用對象,大量的teaher對象,這些teacher被ArrayList引用,導致不能被回收,這些ArrayList,存在于類HeapDemo中。
這就定位出來了,只需要到HeapDemo中,去看看代碼怎么寫的

11、linux如何快速到文件底部和頭部

gg 到文件頂部
shift+g到文件底部

12、某個文件夾下,查找關鍵字并上色

find . -type f| xargs egrep '####\(business_changed_notify\)' -A10 -B10 --color=auto

總結

以上是生活随笔為你收集整理的Linux - 生产故障、性能评估面试题的全部內容,希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯,歡迎將生活随笔推薦給好友。