1.对于Linux系统，主要的监控指标有哪些？他们的各自阈值是多少？
cpu使用率：<80% load值：<cpu的核数 系统内存：使用率<80% 磁盘IO：<100%-90% 网络IO：<带宽上限
2.线程都有几种状态？哪些状态需要关注？
线程状态：runnable、waitting、timed-waitting、blocked、terminated 最影响性能的是blocked状态（阻塞，锁）的线程，timed-waitting（限时等待）
3.Jvm中持久代（方法区）中主要存放什么数据？老年代主要存放什么数据？
持久代中主要存放静态数据、常量、类的基本信息等 老年代中主要存放对象的实例和数组等
4.应用服务器cpu高和数据库服务器cpu高的分析思路是什么？
应用服务器的cpu高，先要看tps和响应时间，如果tps比较高，我们认为是正常的cpu消耗；如果tps比较低，那么往往某些代码过于消耗cpu，可以考虑使用jprofiler分析下 数据库服务器cpu高，往往是因为sql语句执行效率比较低，可以通过对数据库慢查询是监控，结合执行计划进行分析，是否是相关表没有索引或索引未生效
5.出现内存泄露的根本原因是什么？你是怎么定位内存泄露原因的？
内存泄露的根本原因是Jvm中老年代中存在着大量存活的对象，这些对象不能被GC回收掉，从而占满了整个老年代，造成Jvm一直处于FGC的状态，程序没有响应，服务器报OOM错误 内存泄露主要通过分析老年代中占用空间最大的类都有哪些，然后去代码中找对应的类的创建。通常可以使用jdk提供的jvisualvm和jmap进行堆内存的分析
6.tps压不上去，可能有哪些方面的原因？
压力机本身性能瓶颈
网络IO瓶颈
中间件（tomcat/nginx/mysql）连接数限制
Java线程的阻塞、等待
本系统资源的瓶颈（cpu、内存、磁盘、网络等）
其他外部系统响应时间过长，造成本系统的time-wait
7.测试数据怎么构造？你一般都是采用哪些方法来造数据？
调用业务接口构造数据
直接写jdbc代码造数据
存储过程造数据
8.性能场景怎么设计？一般都有哪些性能场景？
一般基本的场景包括：基准测试、单交易测试、混合测试、稳定性测试 其他场景的可选场景：高可用性测试、异常测试等，以及其他的结合各自项目业务的场景
9.什么是集合点，什么场景下需要用集合点
集合点是测试脚本中的一个标记，当每个虚拟用户执行到标记处时，会停留在标记处等待其他的虚拟用户，当达到预期设置的并发数时，标记处的所有用户同时启动执行后续的请求 集合点会产生瞬间高并发，但是也会降低平均压力。所以在压测过程中，如果有要求瞬间高并发的业务，就需要使用集合点，比如抢购，秒杀之类的业务。 没有类似业务则不需要加集合点
10.服务器的cpu使用率和load是什么关系？
通常情况下，cpu使用率和load值是正比关系，即cpu使用率越高，load值越高。但是在一些特殊情况下，也会出现cpu使用率不高，但是load值较高的情况 比如某系统只能使用CPU中的单核运行，它可以占用单核cpu100%，但从整体cpu使用率来看，只是使用了一小部分。而随着并发的增大，单核CPU的任务队列会越来 越长，造成了load值较高
11.产品就只给一个需求，需求调研的内容都不知道，也没人告诉你，怎么开展性能测试？
没有任何途径进行需求调研的情况下，可以跳过需求调研，直接开始压测。
压测完成后，可以把本次压测数据开会讨论，共同决定是否满足性能需求；
或者根据行业内的通用指标规范，比如高频接口响应时间<100ms，低频<200ms的标准来判断
12.给你一种xx协议的系统，怎么测试
先了解协议的格式，数据交互
查找压测工具是否支持本协议
如果不支持，通过自己写代码的方式发送协议包进行测试
13.云上部署的应用怎么压测？
在云上申请一台机器当做压力机，与部署应用同区域机房，这样相当于在云上内网压测
与局域网压测一样，使用通用工具Jmeter进行压测
14.出现too many open files
Linux系统中有两种文件句柄，一种是系统级的，一种是用户级的。 to many open files问题经常在使用Linux的时候出现，大多数情况下是程序没有正常关闭一些变源引起的，所以出现这种问题，我们需要先检查IO读写、套接字通信等是否正常关闭。如果检查序没有问题，那可能是Linux默认的open files值太小，不能满足当前程序的要求，例如数据库连接池的个数、Tomcat请求连接的个数等。 单个进程打开的文件句柄数量超过了系统定义的值时，也会出现too many open files的错误提示。我 们如何知道当前进程打开了多少文件句柄呢？可以使用脚本命令lsof -n|awk '{print$2}' |sort|uniq -c| sort-nr|more查看。 知道问题后，修改Linux的最大文件句柄数限制的方法如下。 (1)使用命令ulimit-n 65535,此方法在当前会话有效，用户退出或者系统重启后恢复默认值 (2)修改/etc/profile文件，在profile文件中添加ulimit -n 65535,但只对单个用户有效。 (3)修改/etc/security/limits..conf文件，在文件中添加如下内容：
soft nofile 65536#限制单个进程最大文件句柄数（到达此限制时系统报错） hard nofile 65536# 限制单个进程最大文件句柄数（到达此限制时系统报错） 其中，星号表示任何用户，soft和hard分别表示软限制和硬限制。 (4)修改/etc/sysctl,.conf文件，在文件中添加如下内容： fs.file-max=655350#限制整个系统最大文件句柄数
然后执行命令/sbin/sysctl-p使配置生效。
15.出现Out Of Memory Error
通常出现这个问题可能是由于内存泄漏（内存中的对象己经死亡，无法通过垃圾收集器进行自动回收)，我们需要找出泄漏的代码位置和原因。出现这个问题也可能是由于内存溢出（内存中的对象都必须还存活着)，这说明Java堆分配空间不足，我们需要检查堆大小设置(-Xmx与-Xms)，检查代码是否存在对象生命周期过长、持有状态时间过长的情况。 引起内存溢出的原因有很多种，常见的有以下几种：
内存中加载的数据量过于庞大，如一次从数据库取出过多数据：
在集合类中引用对象，使用完未清空，使得VM不能回收：
代码中存在死循环或循环产生过多重复的对象实体：
使用的第三方软件中存在问题：
启动参数内存值设定过小。
通常内存溢出或泄漏的解决方案如下：
修改JVM启动参数，直接增加内存：
检查错误日志，查看出现Out Of Memory Error前是否有其他异常或错误；
走查和分析代码，找出可能发生内存溢出的位置；
使用内存查看工具MAT动态查看内存使用情况。
16.数据库连接池不释放
问题现象为性能压测进行一段时间后，报连接超时的错误。排查步骤如下。 (1)在MySQL命令行中执行命令show full processlist查看应用程序与数据库的连接有多少个，比较应用程序中配置的最大连接数和执行命令输出的从应用服务器连接过来的连接数，如果数量接近，证明数据库连接池已被占满。 (2)将应用程序中的最大连接数改大一点（比如改为100），再重新进行压测，如果还是出现连接池被占满的情况，则证明问题是数据库连接池不释放造成的。 通过排查代码，我们可以得知数据库连接部分应该是有创建连接但是没有关闭连接的情况，让开发人员修改代码即可。
17.CPU利用率高
问题现象为在压测过程中，使用top命令查看服务器系统资源占用情况时，发现CPU利用率过高，且长时间超过70%。排查步骤如下。 (1)使用Top命令查看哪个进程消耗CPU资源多。 (2)找到消耗CPU资源高的线程，执行命令top -H -p 进程号(3)把线程号转换成十六进制，执行命令“printf"%x\n"线程号”。 (4)用jstack命令分析线程情况，命令格式为“jstack进程号|grep十六进制的线程号”，通过多次输出前后的线程栈信息进行比对排查。(5)通过JProfiler工具的CPU Views层层分析，可以清楚地找到造成CPU利用率高的原因
18.无论怎么压测，系统的TPS上不去
这个问题出现的原因可能有很多，常见的原因如下。
(1)网络带宽。在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，并间接导致服务器接收到的请求数达不到服务器的处理能力上限。
(2)连接池。最大连接数太小，造成请求等待。常见的连接池有服务器中间件的连接池（比如Tomcat) 和数据库的连接池（比如MySQL)。
(3)GC机制。从常见的应用服务器中间件来说，比如Tomcat,如果堆大小设置比较小，就会造成新生代的Eden区频繁地进行YGC,老年代的FGC也较频繁。这对系统TPS也是有一定影响的，因为GC时通常会暂停所有线程的工作。
(4)数据库。在高并发情况下，当请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引、没有绑定变量，或者没有主从分离、没有读写分离等，就会导致数据库事务处理过慢，影响到系统TPS。
(5)压力工具。比如JMeter 单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响系统TPS,这个时候就需要通过分布式压测来解决单机负载能力有限的问题。
(6)业务逻辑。业务解耦度较低，业务逻辑较为复杂，整个事务处理线被拉长也会导致系统TPS上不去
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
