系统运行占用过高

news2024/11/24 20:41:46

1、CPU过高的问题排查

示例代码：
public class Test {
static class MyThread extends Thread {
public void run() { // 死循环，消耗CPU
int i = 0;
while (true) {
i++;
}
}
}
public static void main(String args[]) throws InterruptedException {
new MyThread().start();
Thread.sleep(10000000);
}
}

(1)使用top命令查看占用CPU过高的进程

在这里插入图片描述

(2)top -p进程号 -H。查看进程59648下线程的占用情况，如下图所示

在这里插入图片描述

(3)使用如下命令将线程59663转换为16进制表示，如下：

在这里插入图片描述

(4)导出CPU占用高进程的线程59663的线程栈。命令如下：

jstack pid >> java.txt
在这里插入图片描述

(5)查看线程栈查找原因，打开文件，内容如下：

在这里插入图片描述
导出的堆栈信息有线程的状态（一般要找RUNNABLE状态）和调用堆栈结合来查找问题。线程dump分析：线程dump分析主要目的是定位线程长时间停顿的原因
jstack是一个瞬时堆栈只记录瞬时状态，实际排查问题的时候jstack建议打印5次至少3次，根据多次的堆栈内容，再结合相关代码段进行分析，定位高cpu出现的原因，高cpu可能是代码段中某个bug导致的而不是堆栈打印出来的那几行导致的。
在这里插入图片描述

(6)cpu高的情况还有一种可能的原因

假如一个4核cpu的服务器我们看到总的cpu达到了100%+，按1之后观察每个cpu的us(用户空间占用cpu的百分比)，只有一个达到了90%+，其他都在1%左右（下图只是演示top按1之后的效果并非真实场景）：
在这里插入图片描述
这种情况下可以重点考虑是不是频繁Full GC引起的。因为我们知道Full GC的时候会有Stop The World这个动作，多核cpu的服务器，除了GC线程外，在Stop The World的时候都是会挂起的，直到Stop The World结束。以几种老年代垃圾收集器为例：
Serial Old收集器，全程Stop The World
Parallel Old收集器，全程Stop The World
CMS收集器，它在初始标记与并发标记两个过程中，为了准确标记出需要回收的对象，都会Stop The World，但是相比前两种大大减少了系统停顿时间
无论如何，当真正发生Stop The World的时候，就会出现GC线程在占用cpu工作而其他线程挂起的情况，自然表现也就为某个cpu的us很高而且他cpu的us很低。

2、Java内存过高的问题排查

要详细解释内存分布及回收情况，需要简单重提下Java内存模型。Java内存模型是描述Java程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。
在Java虚拟机中，内存分为三个代：新生代（New）、老生代（Old）、永久代（Perm）。
（a）新生代New：新建的对象都存放这里
（b）老生代Old：存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。
（c）永久代Perm：是非堆内存的组成部分。主要存放加载的Class类级对象如class本身，method，field等等。
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。大概原因：
（a）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（b）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。大概原因：
（a）一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。
从代码的角度，软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常，减少不必要的对象创建，同时避免内存泄漏。

(1)堆dump分析

堆dump分析主要目的是定位OOM异常的原因；解决oom问题四部曲：
A.分析OOM异常的原因，堆溢出？栈溢出？本地内存溢出？
B.如果是堆溢出，导出堆dump，并对堆内存使用有个整体了解；
C.找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象；
D.使用辅助工具对dump文件进行分析；

注意其他几类造成OOM异常的原因

示例代码：
import java.util.ArrayList;
import java.util.List;

public class Test {
private static final int UNIT_MB = 1024 * 1024;

public static void main(String args[]) throws InterruptedException{
    List<Object> x = new ArrayList<Object>();
    int i = 0;
    while(i<1000){
        x.add(new byte[UNIT_MB]);
        i++;
    }
    Thread.sleep(1000000000);
}

}

(2)jmap dump内存快照

运行示例后，通过top命令查看占用内存高的进程ID，然后通过jmap命令，jmap dump内存快照。
jmap命令有下面几种常用的用法：
•jmap [pid]
•jmap -histo:live [pid] >a.log
•jmap -dump:live,format=b,file=xxx.xxx [pid]
用得最多是后面两个。其中，jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。
jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来，方便用专门的内存分析工具（例如：MAT）来分析。
命令行输入：
jmap -histo | head -20
就可以查看某个pid的java服务存活的对象占用内存排名前20的类，如下图所示：
在这里插入图片描述
可以看到，占用内存最多的是byte字节数组，共有41479个实例。

(3)Jmap内存文件

jmap还有一个指令可以把整个内存情况转成文件形式保存下来，如下：
jmap -dump:format=b,file=filename.hprof
执行命令如下图所示:
在这里插入图片描述
可以在JVM启动时设置，如果发生OOM，则dump出文件。命令如下：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof

(4)内存文件分析

如果快照文件不大，可以下载到本地，然后通过内存分析工具，如果快照文件很大，可以在服务器上直接分析，使用的命令是：
jhat dump.hprof
jhat也是jdk内置的工具之一。主要是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言。命令执行后如下图所示：
在这里插入图片描述
访问IP:port，访问如下图所示：
在这里插入图片描述
找到下图所示：
在这里插入图片描述
其中的Show heap histogram就会显示对象占用内在的大小。如下图所示：
在这里插入图片描述
使用内存分析工具时，有时候这个工具还会提示某个对象异常。我们可以在Histogram 页面，可以查看到对象数量排序，我们可以看到 Byte[] 数组排在了第一位，选中对象后右击选择 with incomming reference 功能，可以查看到具体哪个对象引用了这个对象。
可以通过内存分析工具分析dump的文件：
打开工具，file->Open Heap Dump，打开导出的 .hprof 文件
在这里插入图片描述
解析完成如下图：
在这里插入图片描述
点击上图处，即可查询到占用信息，如下图：
在这里插入图片描述
通过上面的步骤后，就能清楚的知道是哪里的代码有问题或者是程序哪里的配置有问题。

3、JVM的Error日志

致命错误日志文件位置可以通过 -XX:ErrorFile进行指定，相关的信息如下：
这个文件主要包含如下内容：
日志头文件
导致 crash 的线程信息
所有线程信息
安全点和锁信息
堆信息
本地代码缓存
编译事件
gc 相关记录
jvm 内存映射
jvm 启动参数
服务器信息
在日志头文件中有常见的描述是“EXCEPTION_STACK_OVERFLOW”，该描述表示这是个栈溢出导致的错误，这往往是应用程序中存在深层递归导致的

4、Full GC的排查

如果FullGC只是发生在老年代区，比较有经验的开发人员还是容易发现问题的，一般都是一些代码bug引起的。MetaSpace发生的FullGC经常会是一些诡异、隐晦的问题，很多和引入的第三方框架使用不当有关或者就是第三方框架有bug导致的，排查起来就很费时间。
YGC如果频繁，会让对象过早进入老年代，如果回收时间过长，会造成系统停顿时间长，造成服务超时等问题。系统中有许多方法可以观察到Full GC，通常有3种方法，如下：

(1)JVM配置参数

在系统中增加参数，记录相关信息，如下：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/mazhi/workspace/projectjava/projectjava01/gclog/gc.log
某一次记录的日志信息如下：
Java HotSpot™ 64-Bit Server VM (25.192-b12) for linux-amd64 JRE (1.8.0_192-b12), built on Oct 6 2018 06:46:09 by “java_re” with gcc 7.3.0
Memory: 4k page, physical 8064700k(2091464k free), swap 8276988k(8276988k free)
CommandLine flags: -XX:InitialHeapSize=129035200 -XX:MaxHeapSize=2064563200 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
0.073: [GC (System.gc()) [PSYoungGen: 634K->320K(36864K)] 634K->320K(121856K), 0.0015284 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
0.075: [Full GC (System.gc()) [PSYoungGen: 320K->0K(36864K)] [ParOldGen: 0K->258K(84992K)] 320K->258K(121856K), [Metaspace: 2473K->2473K(1056768K)], 0.0035519 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 36864K, used 1270K [0x00000000d6f80000, 0x00000000d9880000, 0x0000000100000000)
eden space 31744K, 4% used [0x00000000d6f80000,0x00000000d70bd890,0x00000000d8e80000)
from space 5120K, 0% used [0x00000000d8e80000,0x00000000d8e80000,0x00000000d9380000)
to space 5120K, 0% used [0x00000000d9380000,0x00000000d9380000,0x00000000d9880000)
ParOldGen total 84992K, used 258K [0x0000000084e00000, 0x000000008a100000, 0x00000000d6f80000)
object space 84992K, 0% used [0x0000000084e00000,0x0000000084e40b30,0x000000008a100000)
Metaspace used 2479K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 265K, capacity 386K, committed 512K, reserved 1048576K
给出的信息还是比较全面详细的，包括堆和元空间GC前与GC后的变化，当前虚拟机使用的命令等。

(2)通过监控查看，如Pinpoint APM监控工具等

(3)通过Linux命令查看

通过top命令定位到内存占用过高的进程PID后，排查该进程的GC情况，如：jstat -gc 4383 5000
即会每5秒一次显示进程号为4383的java进程的GC情况。如某次的详细信息如下图所示：
在这里插入图片描述
命令：jstat -gccause 41843 2000
即每间隔2s查询进程pid = 41843 的gc情况，gccause表示输出-gcutil提供的信息以及最后一次执行GC的发生原因和当前所执行的GC的发生原因。

当发现是Full GC频繁时，首先要知道，哪些情况下会触发Full GC，原因如下：
程序执行了System.gc();
执行了jmap命令；
大对象直接进入了老年代导致老年代内存不足，达到了GC阈值；
程序中存在内存泄露，导致老年代内存缓慢增长，且无法被回收，达到了GC阈值；
老年代存在内存碎片，导致新晋升的对象空间不足，触发GC。
对于第1个原因，如果老年代还有大量空闲空间时就触发，则有可能是调用了System.gc()。对于后面3个原因，通常需要观察Full GC之前与之后堆的内存变化来确定。可以通过GC日志或jvisualvm等图形化工具来查看，如果Full GC前与后堆回不到原来的大小并且堆大小一直增大，则可能是内存泄露，否则可能就是对象过于频繁进入老年代了，需要找出这些对象。可以通过jmap命令来dump出文件。我们可以在线上开启了 -XX:+HeapDumpBeforeFullGC。使用jvisualvm查看哪些对象占用的比较大的内存（能给出实例占用的大小和占用内存的百分比）

常用到的一些命令及图形化工具如下图所示：
在这里插入图片描述

5、其他常用命令如下：

jstat -gc 15712 5000
即会每5秒一次显示进程号为15712的java进成的GC情况。

  • S0C: Young Generation第一个survivor space的内存大小 (kB).
  • S1C: Young Generation第二个survivor space的内存大小 (kB).
  • S0U: Young Generation第一个Survivor space当前已使用的内存大小 (kB).
  • S1U: Young Generation第二个Survivor space当前已经使用的内存大小 (kB).
  • EC: Young Generation中eden space的内存大小 (kB).
  • EU: Young Generation中Eden space当前已使用的内存大小 (kB).
  • OC: Old Generation的内存大小 (kB).
  • OU: Old Generation当前已使用的内存大小 (kB).
  • MC: Permanent Generation的内存大小 (kB)
  • MU: Permanent Generation当前已使用的内存大小 (kB).
  • YGC: 从启动到采样时Young Generation GC的次数
  • YGCT: 从启动到采样时Young Generation GC所用的时间 (s).
  • FGC: 从启动到采样时Old Generation GC的次数.
  • FGCT: 从启动到采样时Old Generation GC所用的时间 (s).
  • GCT: 从启动到采样时GC所用的总时间 (s).

6、常见问题

(1)Java.lang.OutOfMemoryError: PermGen space

PermGen space全称是Permanent Generation space,是指内存的永久保存区域, 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中, 它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对 PermGen space进行清理，所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误。如果你的WEB或者APP用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息。
解决方法：
a.调整PermSize、MaxPermSize的大小；
b.减少jar重复使用，重复占用内存。

(2)java.lang.OutOfMemoryError: Java heap space

Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
在JVM中，如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
如果发现频繁的gc是因为新生代、老年代、永久代分配的大小有问题，则可以通过修改设置解决。
永久代解决方法（同上）：
a.调整PermSize、MaxPermSize的大小；
b.减少jar重复使用，重复占用内存。
新生代、老年代解决方法：
a.调整Xms -Xmx -Xmn的大小
示例及参数注解：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:PermSize=64M -XX:MaxPermSize=128M -XX:MaxTenuringThreshold=0
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存；
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右；
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5；
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6；
-XX:PermSize=64M JVM初始分配的非堆内存（永久代）；
-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配；
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1312221.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

DevOps搭建(十二)-阿里云镜像仓库的使用详解

DevOps搭建(十二)-阿里云镜像仓库的使用详解

有时候，不想在服务器自己搭建镜像仓库，那么我们可以使用阿里云镜像仓库，详细使用方法如下。 1、容器镜像服务 阿里云镜像服务地址： https://cr.console.aliyun.com/cn-hangzhou/instances 选择个人实例 2、创建命名空间 3、创建镜像仓库 考虑到安全性，仓库类型选择我…
阅读更多...
【贝叶斯分析】计算机科学专业博士作业二

【贝叶斯分析】计算机科学专业博士作业二

1 第一题 1.1 题目 已知变量A和B的取值只能为0或1&#xff0c;A⫫&#x1d469;&#xff0c;且&#x1d45d;(&#x1d434;1)0.65&#xff0c;&#x1d45d;(&#x1d435;1)0.77。C的取值与A和B有关&#xff0c;具体关系如下图所表&#xff1a; ABP(C1|A,B)000.1010.99100…
阅读更多...
使用Pytorch从零开始构建StyleGAN2

使用Pytorch从零开始构建StyleGAN2

这篇博文是关于 StyleGAN2 的&#xff0c;来自论文Analyzing and Improving the Image Quality of StyleGAN&#xff0c;我们将使用 PyTorch 对其进行干净、简单且可读的实现&#xff0c;并尝试尽可能地还原原始论文。 如果您没有阅读 StyleGAN2 论文。或者不知道它是如何工作…
阅读更多...
mysql 5.7.34升级到5.7.44修补漏洞

mysql 5.7.34升级到5.7.44修补漏洞

mysql 5.7.34旧版本&#xff0c;漏扫有漏洞&#xff0c;升级到最新版本 旧版本5.7.34在 /home/mysql/mysql中安装 备份旧版本数据还有目录 数据库备份升级 tar -xf mysql-5.7.44-el7-x86_64.tar #覆盖旧版本数据库文件 #注意看看文件是否和你起服务的用户一样 \cp -r mysql-5…
阅读更多...
开发者必备的5类AI工具，不容错过！

开发者必备的5类AI工具，不容错过！

在当今快节奏和激烈竞争的时代&#xff0c;提高工作效率和产品质量变得尤为重要。作为软件开发者&#xff0c;也必须紧跟现代化工具的步伐&#xff0c;以保持领先优势。在这篇文章中&#xff0c;笔者总结了2023年开发者必备的5类AI工具&#xff0c;这些工具将帮助您提升工作效率…
阅读更多...
【六】python观察者设计模式

【六】python观察者设计模式

6.1行为型模式简介 观察者设计模式是最简单的行为型模式之一,所以我们先简单了解一下行为型模式 创建型模式的工作原理是基于对象的创建机制的。由于这些模式隔离了对象的创建细 节&#xff0c;所以使得代码能够与要创建的对象的类型相互独立。结构型模式用于设计对象和类的结…
阅读更多...
精准运维的利器：风险控制模型

精准运维的利器：风险控制模型

导读&#xff1a; 前期在《承载运维成功之梦&#xff1a;精准运维》一文中阐述了精准运维的原理、方法和实例。所谓精准运维&#xff0c;就是通过一系列方法掌握服务对象所使用信息系统的特性及其所服务企业的业务特性&#xff0c;通过掌控信息系统运行风险、运行特点、资源调…
阅读更多...
C语言——字符函数和字符串函数（二）

C语言——字符函数和字符串函数（二）

&#x1f4dd;前言&#xff1a; 上一篇文章C语言——字符函数和字符串函数&#xff08;一&#xff09;对字符函数和字符串函数strlen&#xff0c;strcpy和strncpy&#xff0c;strcat和strncat进行了初步的讲解 这篇文章主要再讲解几个我们常用到的其他字符串函数&#xff08;附…
阅读更多...
el-tree 高亮某些节点

el-tree 高亮某些节点

:render-content"renderContent"
阅读更多...
DevOps 和人工智能 – 天作之合

DevOps 和人工智能 – 天作之合

如今&#xff0c;人工智能和机器学习无处不在&#xff0c;所以它们开始在 DevOps 领域崭露头角也毫不令人意外。人工智能和机器学习正在通过自动化任务改变 DevOps&#xff0c;并使各企业的软件开发生命周期更高效、更深刻和更安全。我们在 DevOps 趋势中简要讨论过这一问题&am…
阅读更多...
山姆·奥特曼重新掌舵OpenAI，为人工智能“保驾护航”

山姆·奥特曼重新掌舵OpenAI，为人工智能“保驾护航”

原创 | 文 BFT机器人 OpenAI首席执行官Sam Altman于2023年12月11日星期一在美国乔治亚州亚特兰大举行的全球论坛年会上发表讲话。来自40个国家的5200多名代表参加了此次会议&#xff0c;旨在重新构想全球经济&#xff0c;让大型科技企业的利益和机会惠及到所有人。 山姆奥特曼…
阅读更多...
Unity | Shader基础知识（第五集：案例＜小彩球＞)

Unity | Shader基础知识（第五集：案例＜小彩球＞)

目录 一、本节介绍 1 上集回顾 2 本节介绍 二、原理分析 1 现实中出现彩色的原因 2 软件里的彩色的原理 3 方案 三、 实现数字由【-1,1】映射为【0,1】 1 结论 2 原理 四、代码实现 1 注意事项 2 详解结构体appdata_base 3 接收数据 4 映射数据 5 输出给SV_TAR…
阅读更多...
Spring Cloud + Vue前后端分离-第5章 单表管理功能前后端开发

Spring Cloud + Vue前后端分离-第5章 单表管理功能前后端开发

Spring Cloud Vue前后端分离-第5章 单表管理功能前后端开发 完成单表的增删改查 控台单表增删改查的前后端开发&#xff0c;重点学习前后端数据交互&#xff0c;vue ajax库axios的使用等 通用组件开发:分页、确认框、提示框、等待框等 常用的公共组件:确认框、提示框、等待…
阅读更多...
eNSP中ping通不同VLAN中的计算机

eNSP中ping通不同VLAN中的计算机

以一边为例 LSW3 <Huawei>sys [Huawei]undo info en//关闭提示 [Huawei]vlan batch 13 24 [Huawei] int e0/0/2 [Huawei-Ethernet0/0/2]port link-type a [Huawei-Ethernet0/0/2] port de vlan 13 [Huawei-Ethernet0/0/2] q//退出 [Huawei] int e0/0/3 [Huawei-Ethernet0…
阅读更多...
一个非常不错的源码和教程资源下载网站整站打包代码，适合用来搭建资源网站或者知识付费网站

一个非常不错的源码和教程资源下载网站整站打包代码，适合用来搭建资源网站或者知识付费网站

找了好多资源类网站代码&#xff0c;目前发现这个不错。基于wordpress开发的&#xff0c;集成了ripro9.2的主题和一些美化的子主题样式&#xff0c;效果非常不错。更难得的是这个网站源码是全开源的&#xff0c;没有任何加密代码&#xff0c;想二次开发的话&#xff0c;非常适合…
阅读更多...
jmeter，取“临时重定向的登录接口”响应头中的cookie

jmeter，取“临时重定向的登录接口”响应头中的cookie

1、线程组--创建线程组&#xff1b; 2、线程组--添加--取样器--HTTP请求&#xff1b; 3、Http请求--添加--后置处理器--正则表达式提取器&#xff1b; 4、线程组--添加--监听器--查看结果树&#xff1b; 5、线程组--添加--取样器--调试取样器。 首先理解 自动重定向 与跟随…
阅读更多...
kubernetes 学习笔记

kubernetes 学习笔记

1. Kubernetes 介绍 1.1 应用部署方式的演变 在部署应用程序的方式上&#xff0c;主要经理了三个时代&#xff1a; 传统部署&#xff1a;互联网早期&#xff0c;会直接将应用程序部署在物理机上。虚拟化部署&#xff1a;可以在一台物理机上运行多个虚拟机&#xff0c;每个虚…
阅读更多...
一文讲清 QWidget 大小位置

一文讲清 QWidget 大小位置

一文讲清 QWidget 大小位置 前言 ​ QWidget 的位置基于桌面坐标系&#xff0c;以左上角为原点&#xff0c;向右x轴增加&#xff0c;向下y轴增加。 一、图解 ​ ​ 如上图所示&#xff0c;当窗口为顶层窗口时&#xff08;即没有任何父窗口&#xff09;&#xff0c;系统会自…
阅读更多...
一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程

一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程

MongoDB 是由C语言编写的&#xff0c;是一个基于分布式文件存储的开源数据库系统。 在高负载的情况下&#xff0c;添加更多的节点&#xff0c;可以保证服务器性能。 MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。 MongoDB 将数据存储为一个文档&#xff0c;数据结…
阅读更多...
RocketMQ 跟踪消息发送轨迹

RocketMQ 跟踪消息发送轨迹

目录 概述实践如何启用消息轨迹配置创建Topic代码测试 结束 概述 阅读此文可以解决 RocketMQ 中消息是否发送成功&#xff0c;是否消费成功。 查询消息轨迹可作为生产环境中排查问题强有力的数据支持 &#xff0c;也是研发同学解决线上问题的重要武器之一。 详细如下&#x…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023