性能监控分析
服务器性能监控与分析
一、通过vmstat深挖服务器性能问题（获取服务器资源的监控数据）
vmstat 命令的基本语法如下：
vmstat [options] [delay [count]]options：可选参数，用于指定要显示的信息类型和格式。delay：可选参数，指定两次报告之间的时间间隔（以秒为单位）。count：可选参数，指定要显示的报告数量。
一些常用的 vmstat 选项包括：
-a：显示活跃和非活跃内存。-f：显示从系统启动至今的fork数量，包括fork、vfork和clone。-m：显示slabinfo信息，即内核缓存信息。-n：在首次输出后，不重新显示标题。-s：显示各种事件计数器和内存统计信息。-d：显示磁盘统计信息。-p：显示特定分区的详细I/O统计信息。
vmstat 的输出通常包括以下列：
procs：进程信息，包括运行队列中的进程（r）和等待I/O的进程（b）。memory：内存使用情况，包括空闲内存（free）、缓冲区（buff）和缓存（cache）。swap：交换空间使用情况，包括空闲交换空间（free）和使用的交换空间（si，so）。io：磁盘I/O信息，包括块设备读写（bi，bo）。system：系统信息，包括中断（in）和上下文切换（cs）。cpu：CPU使用情况，包括用户时间（us）、系统时间（sy）、空闲时间（id）、等待I/O时间（wa）、硬中断时间（hi）和软中断时间（si）。
例如，要每秒显示一次系统状态，可以使用以下命令：
vmstat 1
要显示5次报告，每次间隔2秒，可以使用：
vmstat 2 5
vmstat输出范例如下
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 256 123456 23456 765432 0 0 10 20 100 200 5 3 85 7 0
0 0 256 123456 23456 765432 0 0 5 15 1000 2000 5 3 85 7 0
1 0 256 123456 23456 765432 0 0 10 25 100 200 5 3 85 7 0
各列的含义如下：
r：等待运行的进程数。如果发现这个数据超过了服务器的cpu的核数，就有可能出现cpu瓶颈（在判断时需要结合cpu使用的百分比来一起来看，也就是最后5列的数据指标）b：处于不可中断睡眠状态的进程数。（系统等待资源而阻塞运行的指令个数，比如因为等待i/o、内存交换、cpu等资源而早成的阻塞。如果改数值过高，就需要检查服务器上i/o\内存、cpu等资源是不是出现了瓶颈）swpd：使用的虚拟内存大小。（swpd指服务器的无力内存不够用时，会把无服务物理内存中部空间释放出来，以供急需物理内存来运行的程序使用，而哪些物理内存释放出来的内容一般是一些长时间内有实际运行的程序，这些程序内容就黑保存到swpd中，等这些程序需要运行时再从swpd恢复到物理内存中。swpd一般使用都是磁盘的空间，而磁盘的i/o读写一般会比物理内存慢。如果存在大量的swpd读写交换，将会影响程序运行的性能。swpd的数值大于0并不表示服务器的无力内存不够用需要结合si和so的指标来一起分析，如果si和so还维持在0,那么服务器的无力内存还是够用的）free：空闲内存大小。（free的值是不包含buff和cache这两列数值在内的）buff：用作缓冲区的内存大小。（单位k,,一般对块设备的读写才需要缓冲区，一般内存很大的服务器，这个值比较大，操作系统会根据服务器的无力内存去调整缓冲区使用内存的大小，以提高读写的速度）cache：用作缓存的内存大小。（表示用来给已经打开文件作为缓存的内存大小，cache直接用来缓存我们打开的文件，把空闲的物理内存的一部分哪来用做文件和目录的缓存，这是为了提高程序的执行性能，当程序使用内存时，buff/cache会被很快使用；当空闲的物理内存不足时，这些缓存的占用的内存就会被释放出来）si：从磁盘交换到内存的数据量（每秒的千字节数）。（每秒从磁盘（虚拟内存swpd）读入到内存中的数据或内容的大小，如果这个值长期大于0，表示物理内存可能已经不够用了）so：从内存交换到磁盘的数据量（每秒的千字节数）（每秒从物理内存写入磁盘（虚拟内存swpd）的数据或内容大小，so刚好和si相反，so是将磁盘空间调入内存，si是将内存数据写入磁盘）。bi：从块设备接收的块数（读取，每秒的块数）（表示数据块block设备每秒读取的块数量【从磁盘读取数据，这个值一般表示每秒读取了磁盘的多少个block】,这里的块设备是指系统上所有的磁盘和其他块设备，默认块的大小是1024字节）。bo：发送到块设备的块数（写入，每秒的块数）。（表示数据块block设备每秒写入的块数量【从磁盘写入数据，这个值一般表示有多少个block写入磁盘】，在随机磁盘读写时，bi和bo这两个值越大（如超出了1024k）,cpu在i/o的等待的值也会变大）in：每秒的中断数，包括时钟中断。cs：每秒的上下文切换次数。（列如我们调用系统函数，就会导致系统上下文切换、包括线程的切换和进程的上下文切换，这个值越小越好，太大了要考虑调低线程或进程的数量；列如:在apache或nginx这汇总web服务器 中到底配置多少个线程和进程的数量呢？一般做性能压测时会进行几千甚至几万的并发调用，配置web服务器的进程数可以有进程或者线程的峰值一直慢慢下调，都知道性能压测时发现cs到一个比较小的值，这个进程和线程数就是一个比较合适的值了，系统调用也是，每次调用系统函数，我们的代码会就如内核空间，导致上下文切换，这个很耗资源，也要尽量避免频繁调用系统函数，上下文切换次数过多表示cpu大部分运行实践朗威在上下文切换操作还是那个了，导致cpu干正经事的时间少了，cpu没有充分利用。如果观察到in和cs这两个指标非常高，那就需要对系统进行性能调优了）us：用户CPU时间。（用户模式使用cpu的百分比，这个数值越高说明cpu被正常利用的越好）sy：系统CPU时间。（系统内核进程执行时间的百分比，sy的值高说明系统内核消耗的cpu资源越多，这并不是服务器性能好的表现，通常in、cs、i/o的频繁操作,都会引起sy的指标过高）id：空闲CPU时间。（cpu空闲时间的占比，一般来说id+us+sy=100,通常可以认为id是空闲cpu使用率，us是用户cpu使用率，sy是系统cpu使用率）wa：等待I/O的CPU时间。（i/o等待时间百分比，wa值比较高说明i/o等到比较严重 随机访问说造成，也可能是磁盘出现瓶颈【块操作非常频繁】）st：被虚拟机偷走的CPU时间（在物理机中，该值一般维持为0；一般一台物理机上有很多台虚拟机，st就是等待时间占cpu时间的占比，如果该值一直持续很高，表示虚拟服务需要等待cpu,运行在改服务器上的引用程序的性能会收到直接影响）。
二、通过mpstat分析服务器的性能指标（监控服务器整体性能指标）
mpstat 是一个用于报告每个处理器的统计信息的命令行工具，它通常用于多处理器系统中，可以显示每个CPU的性能指标。mpstat 是 sysstat 包的一部分，该包还包括其他一些有用的性能监控工具，如 sar、iostat 和 pidstat。
mpstat 命令的基本语法如下：
mpstat [options] [interval [count]]
options：可选参数，用于指定要显示的信息类型和格式。interval：可选参数，指定两次报告之间的时间间隔（以秒为单位）。count：可选参数，指定要显示的报告数量。
一些常用的 mpstat 选项包括：
-P ALL：显示所有处理器的统计信息。-P {cpu_number}：显示特定处理器的统计信息，其中{cpu_number}是处理器编号（从0开始）。
mpstat 的输出通常包括以下列：
CPU：处理器编号。%usr：用户模式下CPU使用率。和vmstat中us的数据基本一致%nice：具有nice优先级的用户模式下CPU使用率。%sys：系统模式下CPU使用率。（该值越高，说明系统内核消耗的cpu资源局越多和vmstat中的sy数据已基本一致）%iowait：等待I/O完成时CPU空闲的时间百分比。（该值越高就说明i/o等待月严重和vmstat中的wa的数据基本一致）%irq：用于处理硬件中断的CPU时间百分比。（和vmstat中的in基本一致，in越高，一般%irq也会越高）%soft：用于处理软件中断的CPU时间百分比。%steal：在虚拟化环境中，被其他虚拟CPU偷走的时间百分比。（和vmstat中的st基本一致）%guest：运行虚拟CPU的时间百分比。%idle：CPU空闲时间百分比。（和vmstat中的id基本一致）
例如，要每秒显示一次所有处理器的统计信息，可以使用以下命令：
mpstat 1
要显示特定处理器（例如，处理器0）的统计信息，可以使用：
mpstat -P 0 1
要显示所有处理器的统计信息，每次间隔2秒，共显示5次，可以使用：
mpstat -P ALL 2 5
输出范例
Linux 4.15.0-54-generic (ubuntu) 05/07/2023 _x86_64_ (8 CPU)
07:35:01 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:35:01 PM all 5.10 0.00 2.20 0.75 0.00 0.15 0.00 0.00 0.00 91.80
07:35:01 PM 0 6.10 0.00 3.10 1.20 0.00 0.30 0.00 0.00 0.00 89.30
07:35:01 PM 1 4.80 0.00 1.90 0.50 0.00 0.10 0.00 0.00 0.00 92.70
07:35:01 PM 2 5.60 0.00 2.50 0.80 0.00 0.20 0.00 0.00 0.00 90.90
07:35:01 PM 3 5.00 0.00 2.10 0.70 0.00 0.10 0.00 0.00 0.00 92.10
07:35:01 PM 4 4.90 0.00 1.80 0.60 0.00 0.00 0.00 0.00 0.00 92.70
07:35:01 PM 5 5.20 0.00 2.30 0.90 0.00 0.10 0.00 0.00 0.00 91.50
07:35:01 PM 6 5.30 0.00 2.40 0.85 0.00 0.25 0.00 0.00 0.00 91.20
07:35:01 PM 7 5.10 0.00 2.20 0.75 0.00 0.15 0.00 0.00 0.00 91.80
三、通过pidstat发现性能问题（针对系统中某个进程进行资源监控）
下面是一些常用的 pidstat 选项：
-h：显示帮助信息。-u：显示CPU使用情况。-r：显示内存使用情况。-d：显示磁盘I/O使用情况。-s：显示堆栈使用情况 (仅限于某些版本)。-v：显示虚拟内存使用情况。-w：显示任务切换统计信息。-l：显示命令名称和所有参数。-p {pid}：监视指定PID的进程
使用示例
-
查看所有进程的CPU使用情况
pidstat -u -
显示特定进程的资源使用情况
pidstat -urd -p <PID> -
按间隔和次数显示进程信息
pidstat 5 3
输出范例
Linux 4.15.0-54-generic (ubuntu) 05/07/2023 _x86_64_ (8 CPU)
07:40:01 PM UID PID %usr %system %guest %wait %CPU CPU Command
07:40:01 PM 0 1234 0.00 0.20 0.00 0.00 0.20 2 nginx
07:40:01 PM 0 2345 0.10 0.10 0.00 0.00 0.20 3 sshd
07:40:01 PM 0 3456 0.00 0.00 0.00 0.00 0.00 1 bash
07:40:01 PM 0 4567 0.00 0.00 0.00 0.00 0.00 0 pidstat
07:40:01 PM 0 5678 0.00 0.00 0.00 0.00 0.00 7 cron
07:40:01 PM 0 6789 0.00 0.00 0.00 0.00 0.00 6 syslogd
07:40:01 PM 0 7890 0.00 0.00 0.00 0.00 0.00 5 kswapd0
07:40:01 PM 0 8901 0.00 0.00 0.00 0.00 0.00 4 kjournald
07:40:01 PM 0 9012 0.00 0.00 0.00 0.00 0.00 3 ksoftirqd/0
07:40:01 PM 0 9123 0.00 0.00 0.00 0.00 0.00 2 ksoftirqd/1
在这个输出中，每一行代表一个进程的统计信息：
UID：进程所有者的用户ID。PID：进程ID。%usr：用户模式下CPU使用百分比。%system：系统模式下CPU使用百分比。%guest：运行虚拟机时CPU使用百分比。%wait：进程等待CPU时间百分比。%CPU：总的CPU使用百分比。CPU：处理该进程的CPU编号。Command：进程对应的命令名。
四、losf命令（列出当前系统打开了哪些文件，系统中某个进程打开了哪些文件等信息）
losf命令必须运行在root用户下。
lsof（List Open Files）是一个用来列出当前系统打开文件的工具。在Linux系统中，一切皆文件，因此 lsof 不仅能够列出常规的文件，还能列出网络连接、设备、管道等。lsof 对于系统管理员和开发人员来说是一个非常有用的工具，尤其是在诊断系统问题、查看进程打开的文件、检查网络连接等方面。
常用选项
下面是一些常用的 lsof 选项：
-i：列出所有网络连接。-p <PID>：列出指定进程ID打开的文件。-u <username>：列出指定用户打开的文件。-c <command>：列出指定命令打开的文件。-d <fd>：列出指定文件描述符的文件。+D <directory>：递归列出指定目录下被打开的文件。-t：只输出进程ID，不输出其他信息，常用于脚本中。
使用示例
-
列出所有网络连接
lsof -i这将显示系统中所有打开的网络连接。
-
列出特定端口的网络连接
lsof -i :80这个命令将显示所有使用80端口的网络连接。
-
列出特定进程打开的文件
lsof -p 1234这将显示PID为1234的进程打开的所有文件。
-
列出特定用户打开的文件
lsof -u root这将显示用户名为root的用户打开的所有文件。
-
列出特定命令打开的文件
lsof -c sshd这将显示命令名为sshd的进程打开的所有文件。
五、free看懂内存的真实使用
free 是一个用于显示系统内存使用情况的命令行工具。它提供了关于系统物理内存和交换空间（swap space）的使用信息，包括已用内存、空闲内存、缓冲区和缓存等。free 命令对于监控系统内存使用情况和诊断内存相关问题非常有用。
下面是一些常用的 free 选项：
-h：以人类可读的格式（例如，使用GB、MB而不是字节）显示内存大小。-m：以MB为单位显示内存大小。-g：以GB为单位显示内存大小。-t：显示总计行，包括物理内存和交换空间的总和。-s <秒数>：持续监视内存使用情况，每隔指定的秒数刷新一次输出。-c <次数>：在退出前显示指定次数的内存使用情况。
-
显示内存使用情况
-
free这将显示系统的内存使用情况，包括物理内存和交换空间。
-
以人类可读的格式显示内存使用情况
free -h这个命令将以GB或MB为单位显示内存大小，使得输出更加易读。
-
持续监视内存使用情况
free -s 5这将每5秒刷新一次内存使用情况的输出。
-
显示内存使用情况的总计行
free -t这个命令将在输出的最后一行显示物理内存和交换空间的总和。
free 命令的输出通常包括以下几列：
total：系统总的物理内存或交换空间大小。Kused：已使用的内存或交换空间大小。Kfree：空闲的内存或交换空间大小。Kshared：被多个进程共享的内存大小。Kbuff/cache：被内核缓冲区或文件系统缓存占用的内存大小。K(buff在操作系统中指的缓冲区，负责磁盘块设备的读写缓冲，会直接占用系统的物理内存；cache指操作系统中page缓存，这个缓存linux内核实现磁盘缓存，就是将磁盘中的数据缓冲到物理内存中，以减少i/o读写操作这样磁盘的访问的编委对物理内存的访问，从而提高系统对磁盘的读写速度)available：可用于启动新应用程序的内存大小，通常比free列的值要大，因为它还包括了可以被回收的缓存和缓冲区。K（通常available=free+buff/cache）
六、通过top发现问题（定位服务器消耗的问题）
基本用法
直接在终端中输入 top 并回车，即可启动实时的系统监控界面。
主要显示区域
- 系统概况区：显示系统运行时间、登录用户数、系统负载等信息。
- 任务概况区：显示当前进程的总数、运行的进程数、休眠的进程数、已停止的进程数和僵尸进程数。
- CPU 概况区：显示 CPU 使用情况，包括用户空间占用比例、系统空间占用比例、空闲比例等。
- 内存概况区：显示物理内存和交换空间的使用情况。
常用操作和选项
- 排序进程：在
top运行时，按<字段标识符>（例如，M用于按内存使用量排序，P用于按 CPU 使用率排序）对进程列表进行排序。 - 查找进程：在
top运行时，按L进入搜索模式，可以根据进程名查找进程。 - 杀死进程：在
top运行时，按k，然后输入想要结束的进程 ID（PID）和信号（通常是 9），可以杀死进程。 - 更新频率：启动
top命令时，可以通过-d <秒数>参数设置屏幕刷新的时间间隔。
示例命令
-
启动
top并设置更新间隔为 2 秒：top -d 2 -
显示特定用户的进程：
top -u <用户名>
七、网络流量如何监控iftop
iftop不是系统自带命令需要下载安装
下载完成后执行./configure命令进行安装前的自动安装配置检查
配置安装检查通过后，执行make&&make install命令对源码进行编译然后再 进行安装
安装完成后，你可以通过在终端中输入 iftop 来启动它。通常，你需要使用 root 权限来运行 iftop，因为它需要读取网络接口的数据。
sudo iftop常用选项
-i <interface>：指定要监控的网络接口。-B：以字节为单位显示流量（默认以比特为单位）。-n：直接显示 IP 地址，不进行 DNS 解析。-N：显示端口号而不是服务名称。-P：显示端口和主机信息。-F <ip>：监控特定的 IP 网络。
示例
-
监控 eth0 接口：
sudo iftop -i eth0 -
以字节为单位显示流量，不进行 DNS 解析：
sudo iftop -B -n -
显示端口和主机信息：
sudo iftop -P
界面说明
iftop 的界面通常分为几个部分：
- 顶部：显示当前的带宽使用情况，包括峰值、平均值和当前值。
- 中间：列出当前的网络连接，包括本地和远程 IP 地址、端口号、流量方向和带宽使用情况。
- 底部：提供一些快捷键，如切换排序方式、显示帮助信息等
八、nmon对服务器的真题性能监控
安装完成后，只需在终端输入 nmon 命令即可启动。启动nmon 后，它会以一个交互式界面显示系统状态。
主要功能
- 实时监控：在交互式界面中，实时显示系统各项性能指标。
- 数据捕获：可以将监控数据保存到一个文件中，稍后可以使用其他工具进行分析。
- 多重显示：可以同时监控CPU、内存、磁盘和网络的性能。
常用命令键
在运行 nmon 的过程中，可以使用以下按键激活不同的监控视图：
- c：显示CPU使用情况。
- m：显示内存使用情况。
- d：显示磁盘I/O信息。
- k：显示内核信息和运行队列。
- n：显示网络信息。
- V：显示虚拟内存统计。
- r：显示资源限制。
web中间件的性能分析与调优
nginx的性能分析与调优
nginx负载均衡策略的介绍与调优
负载均衡策略
Nginx 支持多种负载均衡方法，以下是一些主要的策略：
- 轮询（Round Robin）：默认的负载均衡方法，按顺序把请求分配给每个服务器，如果服务器宕机，则自动剔除故障机器。
- 最少连接（Least Connections）：把请求发送到连接数最少的服务器，适用于处理时间不等的请求。
- IP哈希（IP Hash）：根据客户端的 IP 地址进行哈希计算，然后分配给一个固定的后端服务器，这种方式可以确保来自同一客户端的请求总是发到同一服务器，常用于会话保持。
- 权重（Weighted）：与轮询结合使用，给不同的服务器分配不同的权重，根据权重比例分配请求，权重高的服务器承担更多的请求。
- Generic hash：自定义键值（比如URL或者头部）来分配请求，更加灵活。
- 随机（Random）：可以选择带权重的或不带权重的随机分配方法。
配置实例
http {
upstream backend {
least_conn; # 使用最少连接数负载均衡策略
server backend1.example.com weight=3;
server backend2.example.com weight=2;
server backend3.example.com weight=5;
keepalive 32; # 后端连接的keepalive数
}
server {
listen 80;
server_name your_domain.com;
# SSL 配置
listen 443 ssl;
ssl_certificate /path/to/your_certificate.pem;
ssl_certificate_key /path/to/your_private_key.key;
ssl_session_cache shared:SSL:10m; # SSL会话缓存
ssl_session_timeout 10m; # SSL会话超时时间
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Connection ""; # 启用连接复用
proxy_buffering on;
proxy_cache my_cache; # 启用缓存
proxy_cache_valid 200 1d; # 200响应缓存1天
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
# 超时设置
proxy_connect_timeout 10s;
proxy_send_timeout 10s;
proxy_read_timeout 10s;
}
}
# 缓存路径配置
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
# 安全加固
server_tokens off; # 不显示nginx版本号
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
}
解释
- upstream配置：使用了最少连接数 (
least_conn) 负载均衡策略，并且为后端服务器设置了不同的权重，并启用了连接复用。 - SSL配置：提供了SSL证书的配置，启用了SSL会话缓存，减少了SSL握手时间。
- proxy设置：设置了一系列的
proxy_set_header指令，确保后端服务器可以接收到正确的HTTP头信息。启用了HTTP 1.1和连接复用来提高效率。启用并配置了缓存，以及定义了代理的超时设置。 - proxy_cache_path：指定了缓存的路径、大小、过期时间等。
- 安全加固：关闭了服务器版本号的显示，增加了几个安全相关的响应头，以增强应用的安全性。
nginx进程数的配置调优
Nginx 使用一个 master 进程和多个 worker 进程的架构模式。
master 进程主要负责读取和评估配置文件、管理 worker 进程等；而实际处理客户端请求的任务则是由 worker 进程完成的。合理配置 worker 进程的数量，可以让 Nginx 充分利用系统资源，提高并发处理能力。
master进程：可以控制nginx服务的启动、停止、重启、配置文件的重新加载
worker进程：处理用户请求信息，将收到的用户请求转发到后端的应用服务器上
worker进程的个数可以在配置文件nginx.conf中进行配置
events {
worker_connections 1024;
}
http {
worker_processes auto;
...
}
在这个配置中：
worker_processes被设置为auto，Nginx 将根据 CPU 核数自动决定 worker 进程数量。worker_connections被设置为 1024，这意味着每个 worker 进程可以同时处理 1024 个连接。
调优建议
-
计算最大并发连接数：最大并发连接数应该是
worker_processes和worker_connections的乘积。服务器的最大并发连接能力应该与这个数值一致。 -
考虑 Linux 系统的文件描述符限制：确保系统的文件描述符限制数（
ulimit -n）足够高，至少要大于 Nginx 的worker_connections值。如果文件描述符的数量太低，即使你在 Nginx 中设置了较高的worker_connections，也无法打开更多的连接。 -
使用多核优势：如果服务器有多个 CPU 核心，合理配置
worker_processes可以让你充分利用多核的优势，提高并发处理能力。 -
调整
multi_accept和use指令：在events块中，可以设置multi_accept为on，使得每个 worker 在接受新连接时一次性接受多个连接。同样，use指令可以设置事件模型（如epoll），以适合你的系统。
nginx事件处理模型的分析与调优
ginx 是高性能的 HTTP 和反向代理服务器，它使用异步非阻塞事件驱动的方法来处理请求，这使得 Nginx 在处理高并发连接时非常高效。Nginx 支持多种事件处理模型，包括 select, poll, kqueue, epoll, /dev/poll, eventport 等。不同的模型在不同的操作系统和服务器架构上表现也不同。
Nginx常用的事件处理模型：
-
epoll:
- 适用系统: Linux
- 描述: epoll 是 Linux 特有的高效 I/O 事件通知机制，特别适合处理大量并发连接。它是 Nginx 在 Linux 系统上默认使用的事件模型。
-
kqueue:
- 适用系统: FreeBSD, OpenBSD, NetBSD (以及 macOS，虽然 macOS 的实现有所不同)
- 描述: kqueue 是一个高性能的基于事件的通知接口，适用于高并发环境。在 BSD 系统中，它是 Nginx 的首选事件模型。
-
select:
- 适用系统: 跨平台，但效率较低
- 描述: select 是一个传统的 I/O 多路复用机制，但由于其性能限制（通常支持的文件描述符数量较少），在现代高并发服务器中使用较少。
-
poll:
- 适用系统: 跨平台
- 描述: poll 与 select 类似，但提供了更好的性能，尤其是在处理大量文件描述符时。然而，它仍然不如 epoll 或 kqueue 高效。
-
/dev/poll:
- 适用系统: Solaris, Unix
- 描述: /dev/poll 是 Solaris 和一些 Unix 系统上的高级 I/O 多路复用机制，提供了比 select 和 poll 更好的性能。
-
eventport:
- 适用系统: Solaris
- 描述: eventport 是 Solaris 10 及以上版本提供的事件处理机制，旨在解决 /dev/poll 的一些限制。
-
iocp:
- 适用系统: Windows
- 描述: iocp（Input/Output Completion Port）是 Windows 系统上的一个高效的异步 I/O 模型，Nginx 在 Windows 上使用此模型来处理事件。
调优事件模型
在 nginx.conf 文件的 events 块中，可以设置事件模型：
events {
use epoll; # 仅在 Linux 系统有效
worker_connections 1024; # 设置每个 worker 进程可以打开的最大连接数
multi_accept on; # 指示 worker 一次性接受所有新连接
}
调优事件处理模型的时候，要考虑以下几个方面：
-
选择合适的模型：默认情况下，Nginx 会选择适合当前系统的最佳事件模型。通常不需要手动设置，除非你确定某个模型在你的特定场景下更有效。
-
增加
worker_connections：调整worker_connections值来增加你的服务器可以处理的并发连接数。这个值应小于或等于系统的文件描述符限制。 -
使用
multi_accept：启用multi_accept可以使得每个 worker 在一个操作中接受所有新连接，这在高流量时可以减少系统调用的次数。 -
监控
worker_connections使用情况：可以通过 Nginx 的状态模块或日志来监控worker_connections的使用情况，以确保配置得当。 -
调整
sendfile,tcp_nopush, 和tcp_nodelay：这些设置不是直接关联到事件模型，但它们会影响 I/O 操作，从而影响性能。sendfile开启高效文件传输，tcp_nopush和tcp_nodelay调整了 TCP 的行为以优化网络传输。 -
优化 SSL：如果使用 SSL/TLS，考虑使用
ssl_session_cache和ssl_session_tickets来减少握手时的资源消耗。 -
操作系统调整：确保操作系统层面的设置，如
file descriptors limit（文件描述符限制）和tcp_fin_timeout（TCP FIN超时）等，与 Nginx 的设置相匹配。
nginx中文件传输的性能优化
在 Nginx 中，文件传输的性能优化通常涉及以下几个关键参数和指令（通常在nginx.conf文件中修改）：
1. **`sendfile`**:
- 描述: 启用或禁用使用 `sendfile()` 系统调用来传输文件。`sendfile` 允许数据从文件系统直接传输到网络套接字，减少了数据在内核空间和用户空间之间的复制。（默认是sendfile off）
- 配置示例:
sendfile on;2. **`tcp_nopush`**:
- 描述: 启用或禁用 TCP_NOPUSH（或 TCP_CORK）选项，这通常与 `sendfile` 一起使用。当设置为 `on` 时，Nginx 会等待完整的 HTTP 响应头和数据块一起发送，这可以提高网络效率。（默认是tcp_nopush off）
- 配置示例:
tcp_nopush on;3. **`tcp_nodelay`**:
- 描述: 启用或禁用 TCP_NODELAY 选项，这会影响 Nagle 算法。当设置为 `on` 时，Nginx 会立即发送小数据包，减少延迟，适合于实时性要求高的应用。（默认是tcp_nopush on）
- 配置示例:
tcp_nodelay off;4. **`output_buffers`**:
- 描述: 设置从磁盘读取响应时的缓冲区大小。合理设置可以减少磁盘 I/O 操作。
- 配置示例:
output_buffers 1 128k;5. **`sendfile_max_chunk`**:
- 描述: 限制每个 `sendfile` 调用传输的最大数据块大小。这可以防止单个文件传输占用过多的工作进程资源。
- 配置示例:
sendfile_max_chunk 2m;6. **`gzip`**:
- 描述: 启用或禁用 Gzip 压缩。压缩可以减少传输的数据量，但会增加服务器和客户端的 CPU 使用。
- 配置示例:
gzip on;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/javascript;7. **`expires`**:
- 描述: 设置缓存控制头，允许客户端缓存静态资源。这可以减少对相同资源的重复请求。
- 配置示例:
location ~* \.(jpg|jpeg|gif|png|css|js)$ {
expires 30d;
}8. **`ssl_session_cache` 和 `ssl_session_timeout`**:
- 描述: 配置 SSL 会话缓存和超时时间，以减少 SSL/TLS 握手的开销。
- 配置示例:
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;9. **`keepalive_timeout`**:
- 描述: 设置与客户端的持久连接超时时间。持久连接可以减少每次请求时的握手开销。
- 配置示例:
keepalive_timeout 65;10. **`keepalive_requests`**:
- 描述: 设置单个持久连接上允许的最大请求数。
- 配置示例:
keepalive_requests 100;这些参数和指令可以根据具体的应用场景和性能需求进行调整。通常，最佳实践是在实际环境中进行测试，以确定哪些设置最适合你的特定情况。
nginx中FastCGI配置的分析与调优
在 Nginx 中，通过 FastCGI 与后端的 PHP 或其他语言编写的应用程序进行通信。FastCGI 的配置和调优可以显著影响动态内容的性能。以下是一些关键的 FastCGI 参数和调优策略：
1. **`fastcgi_buffering`**:
- 描述: 控制 Nginx 是否缓冲 FastCGI 服务器发送的响应。在高负载时，启用缓冲可以减少后端服务器的负载。
- 配置示例:
fastcgi_buffering on;2. **`fastcgi_buffers` 和 `fastcgi_buffer_size`**:
- 描述: 控制用于缓冲来自 FastCGI 服务器响应的内存区域的数量和大小。不当设置可能会导致缓冲区溢出或内存浪费。
- 配置示例:
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;3. **`fastcgi_connect_timeout`**:
- 描述: 设置与 FastCGI 服务器建立连接的超时时间。
- 配置示例:
fastcgi_connect_timeout 60s;4. **`fastcgi_send_timeout` 和 `fastcgi_read_timeout`**:
- 描述: 设置发送请求到 FastCGI 服务器、读取响应的超时时间。在处理大型请求或响应时，可能需要增加这些值。
- 配置示例:
fastcgi_send_timeout 90s;
fastcgi_read_timeout 90s;5. **`fastcgi_busy_buffers_size`**:
- 描述: 设置服务器忙时用于响应缓冲的内存大小。这应大于单个 `fastcgi_buffers` 的大小。
- 配置示例:
fastcgi_busy_buffers_size 24k;6. **`fastcgi_temp_file_write_size`**:
- 描述: 设置写入临时文件的数据块大小。大数据块可以减少磁盘 I/O 操作。
- 配置示例:
fastcgi_temp_file_write_size 256k;7. **`fastcgi_intercept_errors`**:
- 描述: 控制是否允许 Nginx 处理来自 FastCGI 服务器的错误响应。
- 配置示例:
fastcgi_intercept_errors on;8. **`fastcgi_index`**:
- 描述: 设置 FastCGI 服务器的默认索引文件。
- 配置示例:
fastcgi_index index.php;9. **`fastcgi_param`**:
- 描述: 设置传递给 FastCGI 服务器的参数，例如脚本文件名、查询字符串等。
- 配置示例:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;10. **`fastcgi_split_path_info`**:
- 描述: 设置正则表达式，用于解析 PATH_INFO 从请求 URI。
- 配置示例:
fastcgi_split_path_info ^(.+\.php)(/.+)$;11. **`fastcgi_cache` 和相关缓存指令**:
- 描述: 控制对 FastCGI 响应的缓存行为。使用 FastCGI 缓存可以显著提高性能，减少后端服务器的压力。
- 配置示例:
fastcgi_cache my_cache;
fastcgi_cache_valid 200 60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";进行 FastCGI 的配置和调优时，应该根据实际的应用负载和服务器资源来进行配置。通过观察服务器的性能指标（如CPU、内存使用率、响应时间等），逐步调整参数，并不断地进行测试和监测以找到最佳配置。
nginx的性能监控
Nginx 的性能监控是确保服务器稳定运行和优化性能的关键部分。以下是一些常用的工具和方法来监控 Nginx 的性能：
1. **Nginx 状态模块 (`ngx_http_stub_status_module`)**:
- 描述: 这是一个内置模块，提供基本的 Nginx 运行状态信息，如活跃连接数、处理中的请求数、请求处理速率等。
- 配置示例:
location /nginx_status {
stub_status on;
access_log off;
allow 192.168.1.102;
deny all;
}（allow 192.168.1.102;：代表允许访问监控页面的ip地址）
配置完成后通过执行nginx-sreload来重新加载配置信息
- 访问方法: 通过浏览器或命令行工具访问 `http://your_server_ip/nginx_status`。
2. **第三方监控工具**:
- **Nagios**: 一个广泛使用的开源监控系统，可以监控 Nginx 的状态和性能指标。
- **Zabbix**: 另一个功能强大的开源监控解决方案，支持自定义监控项和触发器。
- **Prometheus**: 一个开源的监控和警报工具集，通过 Nginx 的 Prometheus 导出器来收集指标。
- **Grafana**: 一个可视化工具，可以与 Prometheus 等后端集成，创建动态的监控仪表板。
3. **Nginx 的 Prometheus 导出器**:
- 描述: 这是一个第三方工具，可以将 Nginx 的运行时数据转换为 Prometheus 可抓取的格式。
- 安装和配置: 需要单独安装并配置，以便 Prometheus 可以定期抓取指标。
4. **Nginx Plus**:
- 描述: Nginx Plus 是 Nginx 的商业版本，提供了更全面的监控和分析功能，包括实时活动监控、请求处理图表等。
- 功能: 包括 API 监控、负载均衡监控、会话持久性监控等。
5. **日志分析**:
- 描述: 分析 Nginx 的访问日志和错误日志可以提供关于请求模式、错误率和性能瓶颈的洞察。
- 工具: 使用如 `awk`、`grep`、`logrotate` 等命令行工具，或更高级的日志分析工具如 ELK Stack（Elasticsearch, Logstash, Kibana）。
6. **性能测试工具**:
- **Apache JMeter**: 用于测试 Nginx 的负载和性能。
- **ab (Apache Benchmark)**: 一个简单的命令行工具，用于测试 Nginx 的性能。
- **wrk**: 一个现代的高性能基准测试工具。
7. **系统监控工具**:
- **top**, **htop**: 监控系统资源使用情况，如 CPU 和内存。
- **iostat**, **vmstat**: 监控磁盘和内存的性能。
- **netstat**: 监控网络连接和端口使用情况。
进行 Nginx 性能监控时，应关注的关键指标包括但不限于：
- 活跃连接数
- 请求处理速率
- 响应时间
- 错误率
- 系统资源使用情况（CPU、内存、磁盘 I/O、网络带宽）
通过这些工具和方法，可以有效地监控 Nginx 的性能，及时发现并解决潜在的问题，确保服务的稳定性和高效性。
apache的性能分析与调优
apache的工作模式选择和进程数调优
apache的工作模式主要是apache在运行时内存分配、cpu、进程以及线程的使用管理和请求任务的调度等。apache的工作模式选择和进程数调优比较稳定的工作模式有prefork模式、worker模式、event 模式；apache默认使用prefork模式，一般可以在编译安装apache时通过--with-mpm来制定安装后使用的工作模式，可以通过httpd -V命令来产看当前apache当前的使用的工作模式。
-
prefork MPM
- 特点：非线程化，每个请求由一个单独的进程处理。适用于不支持线程的环境或需要与其他不支持线程的模块（如 PHP）一起使用的情况。
- 优点：稳定，兼容性好。
- 缺点：资源消耗较大，不适合高并发环境。
-
worker MPM
- 特点：使用多个子进程，每个子进程包含多个线程。线程比进程轻量，可以处理更多的并发连接。
- 优点：资源利用率高，适合高并发环境。
- 缺点：需要支持线程的操作系统和库，可能存在线程安全问题。
-
event MPM
- 特点：类似于 worker，但包括一个特殊的线程来处理保持活动连接，即使在处理长连接时也能保持高性能。
- 优点：在处理大量并发连接时效率高，特别是在使用保持活动连接时。
- 缺点：较新，可能不如其他模式稳定。
调优：
Apache HTTP Server 支持多种工作模式，称为多处理模块（MPM），每种模式都有其特定的用途和性能特点。选择合适的工作模式和调整进程数是提高 Apache 性能的关键步骤。
### 工作模式选择
1. **prefork MPM**
- 特点：非线程化，每个请求由一个单独的进程处理。适用于不支持线程的环境或需要与其他不支持线程的模块（如 PHP）一起使用的情况。
- 优点：稳定，兼容性好。
- 缺点：资源消耗较大，不适合高并发环境。
2. **worker MPM**
- 特点：使用多个子进程，每个子进程包含多个线程。线程比进程轻量，可以处理更多的并发连接。
- 优点：资源利用率高，适合高并发环境。
- 缺点：需要支持线程的操作系统和库，可能存在线程安全问题。
3. **event MPM**
- 特点：类似于 worker，但包括一个特殊的线程来处理保持活动连接，即使在处理长连接时也能保持高性能。
- 优点：在处理大量并发连接时效率高，特别是在使用保持活动连接时。
- 缺点：较新，可能不如其他模式稳定。
### 进程数调优
选择合适的工作模式后，需要根据服务器的硬件资源和预期的负载来调整进程数。以下是一些基本的调优建议：
1. **prefork MPM**
- `StartServers`: 初始启动的服务器进程数。
- `MinSpareServers`: 最小空闲服务器进程数。
- `MaxSpareServers`: 最大空闲服务器进程数。
- `MaxRequestWorkers` (或 `MaxClients`): 允许的最大并发请求数。
- `MaxConnectionsPerChild`: 每个子进程在其生命周期内允许处理的最大连接数。
示例配置：
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxRequestWorkers 150
MaxConnectionsPerChild 10000
</IfModule>2. **worker MPM**
- `StartServers`: 初始启动的服务器进程数。
- `MinSpareThreads`: 最小空闲线程数。
- `MaxSpareThreads`: 最大空闲线程数。
- `ThreadsPerChild`: 每个子进程的固定线程数。
- `MaxRequestWorkers` (或 `MaxClients`): 允许的最大并发请求数。
- `MaxConnectionsPerChild`: 每个子进程在其生命周期内允许处理的最大连接数。
示例配置：
<IfModule worker.c>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 10000
</IfModule>3. **event MPM**
- 配置类似于 worker MPM，但还包括 `MaxRequestsPerChild` 和 `ServerLimit`。
示例配置：
<IfModule event.c>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 10000
</IfModule>event 工作模式的配置参数几乎与worker模式一样，因为event模式本身就是对worker模式的一种升级改进
apache的mod选择与调优
----------------------------待续--------------------------------------
apache的KeepAline调优
http请求找那个开启KeepAline选项相关与长连接的作用，多次http请求共用一个tcp连接来完成，这样可以节约网络和系统资源。一般开启KeepAline适用于以下如下情况：
- 如果有较多的青苔资源（如js、css、图片等）需要访问，则建议开启长连接
- 如果并发需求非常大，频繁的出现连接建立和连接关闭，则建议开启长连接
- 如果出现这种情况可以考虑关闭KeepAline选项：服务器内存较少并且存在大量动态请求或者文件访问，则建议关闭长连接以节省系统内存和提高apache访问的稳定性。
KeepAlive 相关的主要配置项：
-
KeepAlive: 这个指令允许你开启或关闭持久连接。通常应该设置为
On以启用持久连接。 -
KeepAliveTimeout: 这个指令设置了服务器将等待另一个请求的时间，在这段时间内，客户端可以在同一连接上发送多个请求。超时时间过长会导致服务器资源（如内存和线程）被不必要地占用，而设置得太短可能会导致连接频繁地开启和关闭。一个常用的起点是 5 秒，但是根据你的具体场景进行调整。
-
MaxKeepAliveRequests: 设置在一个持久连接上允许的最大请求数。一旦这个限制被达到，服务器将关闭连接。设置为较高的值可以在一个连接上服务更多的请求，但是太高的值可能会导致服务器资源被长时间占用。一个常见的值是 100，但是你应该根据你的实际需求进行调整。
调优建议：
-
开启 KeepAlive: 对大多数网站来说，开启 KeepAlive 都会带来明显的性能提升。如果你的网站有很多静态资源，这将是非常有用的。
-
调整 KeepAliveTimeout: 对于忙碌的站点，将
KeepAliveTimeout设置得稍微偏低些（比如 2-5 秒）可以帮助释放连接，使得新的请求能够更快被处理。对于流量较低的站点，可以将此值设置得稍高一些，但通常不建议超过 15 秒。 -
平衡 MaxKeepAliveRequests: 将
MaxKeepAliveRequests设置为一个合理的值（如 100 或 150）可以确保连接被有效利用，而不至于过度占用服务器资源。如果你的网站主要是静态内容，可以设置得更高一些；如果是动态内容较多，可能需要设置得低一些。
示例配置：
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
apache的ab压力测试工具
Apache HTTP server 提供了一个名为 `ab`（ApacheBench）的轻量级压力测试工具。这个命令行工具可以用来运行针对 Web 服务器的基准测试，它能够模拟多个并发请求，并收集关于服务器性能的数据。
### ab 工具的基本用法如下：
ab -n 100 -c 10 http://www.example.com/在这个例子中：
- `-n 100` 表示运行测试以执行总共 100 个 HTTP 请求。
- `-c 10` 表示并发执行的请求数量为 10。
ab 工具的常见参数包括：
- `-k`：启用 HTTP KeepAlive 特性，即在一个 HTTP 会话中发送多个请求。
- `-t`：测试持续的最长时间（秒），默认情况下，ab 测试会运行直到所有的请求都完成。
- `-p`：允许你指定一个包含要 POST 的数据的文件。
- `-T`：当使用 `-p` 发送 POST 请求时，你需要用这个选项指定内容类型。
- `-H`：添加自定义的请求头，例如：`-H "X-Test-Header: 123"`。
- `-X`：指定一个代理服务器来发送请求通过，例如：`-X 127.0.0.1:8888`。
- `-A`：添加基本的 WWW 认证，格式为 `username:password`。
示例：执行带有 KeepAlive 的测试
ab -n 1000 -c 50 -k http://www.example.com/这个命令会发送 1000 个请求，以 50 的并发量，并且每个连接会尝试使用 KeepAlive 功能。
高级用法：
使用 POST 请求进行测试：
ab -n 100 -c 10 -p postdata.txt -T 'application/x-www-form-urlencoded' http://www.example.com/form.php在这个例子中，`postdata.txt` 包含了要提交的数据，`-T` 指定了数据的内容类型。
警告和注意事项：
1. **测试目标**：只在你有权限测试的服务器上使用 ab。在未经授权的服务器上运行压力测试可能被视为攻击。
2. **服务器负载**：ab 可以产生大量请求，在生产服务器上运行可能会对服务造成影响。理想情况下，在一个与生产环境相似的测试环境中运行 ab。
3. **结果解读**：ab 提供了多种性能指标，包括每秒完成的请求数（RPS）、每个请求的平均时间、总体传输速率等。理解这些指标对于解读测试结果至关重要。
4. **资源监控**：在运行 ab 时，你还应该监控服务器的资源利用情况，如 CPU、内存和网络使用情况，以获得全面的性能画面。
5. **安全性**：确定服务器和网络配置可以处理高并发请求，以防止潜在的拒绝服务（DoS）条件。
通过对结果的分析，你可以了解服务器在特定负载下的行为，并据此进行配置优化或硬件升级，以提高应对高流量的能力。
apache的性能监控
apache自身自带了状态监控页面，但是默认是关闭的，可以通过httpd.conf中增加如下配置来打开监控页面
<Location "/server-status">
SetHandler server-status
Order Deny,Allow
Allow from all
</Location>
增加如上配置后，就可以通过访问http://ip:port/server - status来查看监控页面了。
（版本不同，命令有说不同，上方版本为apache2.2）
应用中间件的性能分析与调优
tomcat的组件以及工作原理
tomcat容器Connector性能参数调优
Tomcat容器中的Connector组件是负责处理进来的网络请求，并将这些请求传送到Servlet容器进行处理的组件。适当地调整Connector的性能参数可以提高Tomcat的处理能力和响应速度。下面是一些关于如何调优Tomcat Connector的性能参数的建议。
1. 线程池（Executor）
Tomcat使用线程池来处理传入的连接请求。通过优化线程池参数，可以提高并发处理能力和响应时间。
- `maxThreads`：表示线程池中最大的工作线程数量，应依据服务器的CPU和内存资源以及应用程序的具体需求进行调整。
- `minSpareThreads`：表示线程池中保持空闲的最小线程数，以便能够迅速响应新的请求。
- `maxIdleTime`：线程空闲等待新任务的最长时间，在此时间后，线程会被回收。
2. 连接数限制
- `acceptCount`：当所有可以使用的处理请求的线程数都被使用时，还可以在队列中放置的请求数。超过这个数值后，新的连接会被拒绝。
- `maxConnections`：这个参数限制了同时能够打开的最大连接数。它可以帮助控制Tomcat服务器上的负载。
3. I/O模式
- NIO（Non-Blocking IO）或NIO2：Tomcat 8及以上版本中，默认使用NIO作为IO模式。NIO提供了非阻塞的IO操作，适用于连接数多但每个连接上的请求处理时间较短的场景。
- APR（Apache Portable Runtime）：使用本地代码库（例如，在Linux上是EPOLL），可以提供更高的网络性能，但需要额外安装本地库。
4. 超时设置
- `connectionTimeout`：连接超时时间，如果超过这个时间客户端没有发送数据，则连接会被关闭。
- `keepAliveTimeout`：当客户端与服务器保持长连接时，这个参数定义了服务器在关闭这个连接前等待下一次请求的超时时间。
5. 其他优化
- `compression`：如果带宽是瓶颈，可以开启压缩。这个设置允许Tomcat压缩某些MIME类型的数据。
- `useSendfile`：对于静态文件传输，如果设置为`true`，Tomcat将使用操作系统级别的sendfile功能来提高传输效率。
- `disableUploadTimeout`：对于上传大文件，可以禁用与上传相关的超时时间。
示例配置
以下是在`server.xml`中配置Connector的一个示例：
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxThreads="150"
minSpareThreads="25"
acceptCount="100"
enableLookups="false"
compression="on"
compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript"
useSendfile="true"/>重要提示：在进行任何性能调整时，都应该先在测试环境进行测试，以确保这些调整不会对系统稳定性造成负面影响。调优是一个逐步迭代的过程，可能需要多次调整和测试才能找到最佳配置。同时，系统的监控也是至关重要的，它能帮助你理解调整的效果，并在必要时做出调整。
tomcat容器I/O分析与调优
1. 同步阻塞I/O（BIO）
- 原理：在同步阻塞模式下，服务器为每个请求创建一个新的线程。线程在处理I/O（如读取输入、发送输出）时会阻塞，即线程暂停执行直到I/O完成。
- 应用场景：适用于连接数较少且持续时间短的应用。因为每个连接都需要一个线程，过多的连接会导致线程过多，增加上下文切换的成本，从而影响性能。
2. 同步非阻塞I/O（NIO）
- 原理：同步非阻塞模式下，服务器使用一个或少数几个线程来处理多个连接。当线程发起一个I/O操作后，如果数据未准备好，线程会继续执行其他任务，不会阻塞在那里等待。
- 应用场景：适用于连接数多但单个连接的活跃度不是特别高的场景。非阻塞模式可以减少线程数量，节省资源，但编程模型比阻塞模式复杂。
3. 异步非阻塞I/O（AIO）
- 原理：异步非阻塞I/O模型中，I/O操作会立即返回，不会等待数据准备完成。当数据准备好后，系统会通知应用程序进行处理。
- 应用场景：适用于高并发且I/O操作非常频繁的应用，如大规模聊天服务器。AIO可以帮助应用程序实现高效的并发处理，减少资源占用。
4. I/O多路复用
- 原理：I/O多路复用是一种通过单一或少数几个线程来监视多个I/O流的准备情况的技术。常见的实现有select、poll、epoll等。线程在一个循环内部不断查询每个I/O流是否有数据就绪，一旦检测到I/O事件，相应的处理函数就会被触发。
- 应用场景：适用于需要高效处理大量连接的场景。尤其是当连接数非常高，而每个连接上的实际数据传输并不频繁时，I/O多路复用可以显著减少系统资源的使用，提高系统的扩展性和效率。
Tomcat中的实现
在Tomcat中，BIO是早期版本的默认模式，而从Tomcat 8开始，NIO成为了默认的I/O处理方式。Tomcat也支持通过配置使用NIO2（AIO的一种实现）和APR（一种使用本地代码库，如Apache Portable Runtime实现多路复用的方式）来进一步优化处理性能。
wildfly的性能分析与调优
----------------------------待续--------------------------------------
java应用程序的性能分析与调优
jvm的基础知识
jvm简介
Java虚拟机（JVM）是一个允许Java程序运行在任何设备或操作系统上的抽象计算机。它是Java平台的核心组成部分，负责执行Java字节码，提供了一个跨平台的运行环境，这使得Java程序能够被编译一次，然后在任何安装了JVM的设备上运行，符合Java的“一次编写，到处运行”（Write Once, Run Anywhere, WORA）理念。
主要功能
- 执行Java字节码：将Java程序编译成平台无关的字节码，由JVM在执行时转换为特定平台的机器语言。
- 内存管理：包括类实例和数组的分配、垃圾收集等，确保有效利用内存并且回收不再使用的内存。
- 安全性：通过类加载器和字节码验证器提供安全运行环境，阻止恶意代码破坏系统。
- 跨平台：JVM为Java程序提供了一个与硬件无关的运行环境，实现了程序的跨平台运行。
- 多线程：JVM原生支持多线程执行，允许同时执行多部分代码，提高了程序的执行效率。
组件
- 类加载器：负责加载类文件到JVM。
- 运行时数据区：存储了程序运行期间所需要的数据。
- 执行引擎：将字节码转换为机器码执行。
- 本地接口库：为JVM提供与操作系统交互的接口。
- 垃圾收集器：自动管理和回收JVM内存中的垃圾对象。
工作流程
- 加载：JVM通过类加载器读取.class文件。
- 链接：验证读取的类文件格式是否正确，准备为类变量分配内存，并解析符号引用到直接引用。
- 初始化：执行类构造器<clinit>方法的过程。
- 使用：执行程序代码。
- 卸载：当类不再需要时，JVM会进行类的卸载。
类加载器
类加载器（Class Loaders）是Java虚拟机（JVM）的一个核心组成部分，负责按需加载类（.class文件）到JVM中。Java类加载机制允许类在首次使用时才加载到JVM，而不是在JVM启动时一次性加载所有的类，这有助于减少内存占用，并缩短程序启动时间。类加载器通过一个称为“委派模型”的机制来工作，其基本原则是：尝试将类的加载工作委托给父加载器去完成，只有在父加载器加载失败时，才由自己来直接加载。
类加载器的类型
Java中主要有三种类型的类加载器：
-
引导类加载器（Bootstrap Class Loader）：这是最顶层的加载器，负责加载JVM基础核心类库（如java.lang.*），用于提供JVM自身需要的类。引导类加载器通常不是Java类，而是由JVM实现的。
-
扩展类加载器（Extension Class Loader）：这个加载器由
sun.misc.Launcher$ExtClassLoader（不同的JVM实现可能会有所不同）实现，负责加载JVM扩展库中的类。这些类库位于JDK的jre/lib/ext目录或者由系统属性java.ext.dirs指定的任何其他目录中。 -
应用程序类加载器（Application Class Loader）：这是与开发者最相关的加载器，由
sun.misc.Launcher$AppClassLoader实现（不同的JVM实现可能会有所不同）。它负责加载环境变量classpath或系统属性java.class.path指定路径中的类库。
类加载过程
类加载的过程通常包括以下几个步骤：
-
加载（Loading）：找到对应的字节码文件，并从这些文件中创建类的原始数据结构。
-
链接（Linking）
- 验证（Verification）：确保被加载的类满足JVM的安全标准。
- 准备（Preparation）：为类的静态变量分配内存，并将其初始化为默认值。
- 解析（Resolution）：将符号引用转换为直接引用。
-
初始化（Initialization）：对类的静态变量进行初始化和Java代码的执行。
自定义类加载器
在某些情况下，开发者可能需要通过继承ClassLoader类来创建自己的类加载器，以实现一些特定的加载逻辑，例如从一个特定的网络位置加载类，或者对加载的类进行某些加密/解密操作。自定义类加载器在开发复杂的Java应用程序时非常有用，特别是在需要动态加载、更新和卸载类的场景中。
类加载器是Java平台的基石之一，它们使得Java应用能够以灵活和动态的方式加载类和接口，是Java动态加载和运行时链接能力的关键所在。
java虚拟机栈和原生方法栈
Java虚拟机栈 （JVM Stack）
每当一个新线程被创建时，JVM都会为这个线程创建一个虚拟机栈。这个栈会随着线程的运行而动态地创建和销毁栈帧（Stack Frame）。每个栈帧对应着一个方法调用；所有的局部变量、部分结果以及方法返回值都在栈帧中处理。主要特点包括：
- 局部变量表：存储方法参数和局部变量。
- 操作数栈：作为执行字节码指令的工作区。
- 动态链接：每个栈帧内部包含一个指向运行时常量池的引用，用于支持动态方法调用。
- 方法返回地址：每当一个方法调用完成后，程序控制权需要返回到方法被调用的位置，返回地址用于帮助恢复调用者的执行状态。
在Java中，如果线程请求的栈深度超过JVM允许的深度，将会抛出StackOverflowError。如果虚拟机栈可以动态扩展，但无法申请到足够的内存时，则会抛出OutOfMemoryError。
本地方法栈（Native Method Stack）
本地方法栈用来支持本地方法的执行。本地方法是使用非Java语言编写的方法，比如C或C++，并且通过Java的本地接口（Java Native Interface, JNI）调用。与Java虚拟机栈的用途相似，本地方法栈也是线程私有的，其主要功能是为本地方法服务：
- 存储本地方法的状态。
- 在调用本地方法时，记录程序的执行位置。
和JVM栈一样，本地方法栈也可能会抛出StackOverflowError和OutOfMemoryError。
主要区别
- 用途：虚拟机栈服务于Java方法的调用，而本地方法栈服务于本地方法调用。
- 语言：Java虚拟机栈用于Java语言编写的方法，本地方法栈用于非Java语言编写的本地方法。
- 内存分配：在某些JVM实现中，本地方法栈和虚拟机栈可能是相互独立的，但在其他实现中，两者可能是混合在一起的，这取决于JVM的架构设计。
在Java虚拟机规范中，并没有强制要求本地方法使用一个独立的栈。实际上，在某些JVM实现中，本地方法和Java方法共享同一个栈。这种设计细节因JVM的实现而异。
方法区与元数据区
在Java虚拟机（JVM）中，方法区是一个所有线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量，以及即时编译器编译后的代码等数据。从Java 8开始，传统的方法区的概念经过了重大改变，被一个称为元数据区（Metaspace）的区域所取代。
方法区（Method Area）
在Java 8之前，方法区通常是指永久代（PermGen，Permanent Generation）。这部分区域位于Java堆的外部，它有固定的大小限制，容易出现OutOfMemoryError如果加载了大量的类或者大量的反射操作导致的内存泄漏。
方法区的主要职责包括：
- 存储每一个类的结构，如运行时常量池、字段和方法数据、构造函数和普通方法的字节码内容。
- 保存所有的静态变量。
- 保存JIT编译器编译后的代码缓存。
元数据区（Metaspace）
从Java 8开始，永久代被移除，转而使用元数据区。元数据区的实现位于本地内存中，而不是虚拟机内存。这意味着它不再受JVM堆的大小限制，而受制于本地内存的大小。由于本地内存通常比JVM堆大得多，因此元数据区能够存储更多的类元数据，减少了因类加载量巨大导致的内存溢出。
元数据区的主要职责：
- 存储JVM加载类的元数据信息。
- 替换了永久代，避免了固定大小带来的内存溢出问题。
- 可通过参数
-XX:MetaspaceSize和-XX:MaxMetaspaceSize来调整初始空间大小和最大空间大小。
总的来说，元数据区的引入优化了方法区的内存管理，使其更加灵活。虽然元数据区的默认大小是无限的，但实际使用中仍然需要监控和调整，以避免不必要的本地内存消耗和潜在的OutOfMemoryError。
对于开发者而言，理解方法区和元数据区的区别有助于更好地理解Java 8及之后版本中的类加载机制，并合理地配置JVM参数以优化应用性能。
堆区
在Java虚拟机（JVM）中，堆（Heap）是内存中最大的一块区域，主要用于存储Java应用程序创建的对象实例和数组。堆是所有线程共享的内存区域，这意味着任何线程都可以访问堆中的数据。由于堆存储的是对象实例，因此它是垃圾收集器（Garbage Collector）管理的主要区域。
堆的特点
-
对象实例存储：所有通过
new关键字创建的对象实例和数组都存储在堆中。 -
垃圾收集：堆是垃圾收集器进行垃圾回收的主要区域。垃圾收集器负责回收堆中不再被引用的对象所占用的内存空间。
-
线程共享：堆内存是所有线程共享的，这意味着堆中的对象可以被所有线程访问。
-
动态分配：堆内存的分配和回收是动态进行的，随着程序的运行，堆中的对象会不断地被创建和销毁。
堆的结构
堆内存通常可以分为几个部分：
-
年轻代（Young Generation）：新创建的对象首先被分配到年轻代。年轻代又分为三个部分：Eden空间和两个Survivor空间（通常称为From和To或S0和S1）。大多数对象在Eden空间中创建，当Eden空间满时，会触发一次Minor GC（次要垃圾收集），将存活的对象移动到Survivor空间。
-
老年代（Old Generation）：在年轻代中存活了足够长时间的对象会被移动到老年代。老年代的垃圾收集称为Major GC或Full GC，通常比年轻代的垃圾收集更慢，因为涉及的对象更多。
-
永久代/元数据区（PermGen/Metaspace）：这部分区域在Java 8之前用于存储类的元数据信息，如方法和字段信息等。从Java 8开始，永久代被元数据区（Metaspace）取代，元数据区使用本地内存来存储这些信息。
堆的配置
JVM提供了多种参数来调整堆的大小和垃圾收集行为，例如：
-Xms：设置堆的初始大小。-Xmx：设置堆的最大大小。-Xmn：设置年轻代的大小。-XX:NewRatio：设置年轻代和老年代的比例。-XX:SurvivorRatio：设置Eden空间和Survivor空间的比例。
合理配置堆的大小和垃圾收集策略对于Java应用程序的性能至关重要。过小的堆可能导致频繁的垃圾收集，影响性能；而过大的堆则可能导致垃圾收集时间过长，同样影响性能。因此，根据应用程序的具体需求和硬件资源，调整堆的大小和垃圾收集策略是Java性能调优的重要部分。
程序计数器
程序计数器（Program Counter, PC）是计算机体系结构中的一个关键组成部分，它在不同的上下文中有不同的含义和功能。在Java虚拟机（JVM）的上下文中，程序计数器是一个较小的内存区域，它是一个抽象的概念，用于存储当前线程执行的字节码指令的地址（或称为位置）。
程序计数器在JVM中的作用
-
指令跟踪：程序计数器记录了下一条需要执行的指令的位置。在JVM中，这通常是指向当前线程执行的字节码的地址。
-
线程隔离：每个线程都有自己的程序计数器，这是一个线程私有的内存区域。这意味着每个线程都有自己的执行位置记录，互不干扰。
-
多线程切换：当线程执行的时间片用完，或者由于I/O操作、同步操作等原因被挂起时，程序计数器会记录当前的执行位置。当线程恢复执行时，可以从程序计数器记录的位置继续执行。
-
异常处理：在遇到异常或错误时，程序计数器可以帮助JVM确定异常处理代码的起始位置。
程序计数器的特点
- 线程私有：每个线程都有自己的程序计数器，用于存储该线程的执行位置。
- 不会溢出：在JVM规范中，程序计数器被定义为不会发生内存溢出的区域。
- 只存储指令地址：程序计数器通常只存储指令的地址或偏移量，不存储其他数据。
程序计数器与硬件PC的关系
在硬件层面，程序计数器（PC）是CPU中的一个寄存器，用于存储下一条要执行的指令的内存地址。在执行指令时，CPU会根据PC的值从内存中读取指令，然后更新PC以指向下一条指令。这与JVM中的程序计数器有相似的功能，但具体实现和细节可能有所不同。
总结来说，程序计数器在JVM中是一个关键的组件，用于跟踪每个线程的执行位置，确保线程可以正确地恢复执行，并支持多线程环境中的并发执行。
垃圾回收
Java虚拟机（JVM）的垃圾回收（Garbage Collection，GC）是自动管理内存的过程，它负责识别和删除不再被程序使用的对象，从而释放内存空间供新对象使用。垃圾回收是JVM的一个重要组成部分，它极大地简化了开发人员对内存管理的负担。
垃圾回收的基本原理
-
标记-清除（Mark-Sweep）：
- 标记阶段：GC遍历所有可达对象，并将它们标记为活动的。
- 清除阶段：GC清理未被标记的对象，即不可达对象，并回收它们占用的内存空间。
-
复制（Copying）：
- 将内存分为两个半区，每次只使用其中一个。
- 当进行垃圾回收时，将当前半区中的活动对象复制到另一个半区，然后清空当前半区。
-
标记-整理（Mark-Compact）：
- 类似于标记-清除，但在清除阶段，它不是简单地回收内存，而是将所有活动对象移动到内存的一端，从而消除内存碎片。
-
分代收集（Generational Collection）：
- 基于对象生命周期的不同，将堆内存分为几个代（通常是新生代和老年代）。
- 新生代使用复制算法，老年代使用标记-清除或标记-整理算法。
并行与并发
并行（Parallelism）在JVM中
并行指的是多个GC线程同时工作，以并行的方式清理内存中的垃圾对象。这种模式目的在于缩短垃圾收集的时间，因为多个处理器或核心同时执行任务，处理能力得到了显著提升。
并行垃圾回收器示例：
- Parallel GC（也称为Throughput Collector）：它是HotSpot JVM的默认垃圾回收器之一，特别适用于多核服务器。在Minor GC和Major GC阶段都会使用所有可用的CPU核心来执行垃圾回收，以尽可能减少GC的暂停时间。
并发（Concurrency）在JVM中
并发在JVM中通常指的是垃圾回收器在执行清理工作时，允许应用程序的线程继续运行。即垃圾回收线程和应用程序线程同时运行，不需要等待彼此完成。并发执行能够减少GC引起的停顿时间，对于用户交互或实时性要求较高的应用程序非常重要。
并发垃圾回收器示例：
- Concurrent Mark Sweep (CMS) GC：目标是尽量减少应用程序停顿时间。它主要在老年代进行工作，通过并发标记和并发清除阶段来实现，减少了应用线程的等待时间。
- Garbage-First (G1) GC：设计用于大堆内存环境，通过将堆划分为多个区域并在背景中并发地进行垃圾回收来管理整个堆，同时试图平衡吞吐量和停顿时间。
线程并行与并发
除了垃圾回收之外，JVM还支持应用级别的并行和并发处理：
- 并行处理：在Java中，可以通过创建多个线程（例如，使用
Thread类或执行者服务Executors）来并行处理任务。如果运行在多核处理器上，这些线程可以实际同时运行，从而提高程序的执行效率和吞吐量。 - 并发处理：Java中的并发通常涉及到同步机制，如
synchronized关键字、ReentrantLock、Atomic类等，这些都是为了在多个线程访问共享资源时保证数据的一致性和线程的安全。
垃圾回收器
Java虚拟机（JVM）提供了多种垃圾回收器（GC），每种都有其特定的使用场景和优化目标。以下是一些常见的JVM垃圾回收器：
1. Serial GC
- 工作方式：单线程进行垃圾回收，即在垃圾回收时会暂停所有应用线程（Stop-The-World）。
- 适用场景：小型应用，单核处理器环境。
- 启动参数：
-XX:+UseSerialGC
2. Parallel GC（也称为Throughput Collector）
- 工作方式：多线程并行执行垃圾回收，追求高吞吐量。
- 适用场景：多核处理器，关注吞吐量的应用。
- 启动参数：
-XX:+UseParallelGC
3. Concurrent Mark-Sweep (CMS) GC
- 工作方式：并发执行大部分垃圾回收工作，减少停顿时间。
- 适用场景：需要低延迟的应用，如Web应用、交互式应用。
- 启动参数：
-XX:+UseConcMarkSweepGC
4. Garbage-First (G1) GC
- 工作方式：将堆内存划分为多个区域，并根据垃圾回收的优先级来选择区域进行回收，平衡吞吐量和停顿时间。
- 适用场景：适用于各种类型的应用，特别是大堆内存环境。
- 启动参数：
-XX:+UseG1GC
5. Z Garbage Collector (ZGC)
- 工作方式：一种可伸缩的低延迟垃圾回收器，设计用于处理非常大的堆内存。
- 适用场景：需要处理大堆内存且对延迟有严格要求的应用。
- 启动参数：
-XX:+UseZGC
6. Shenandoah GC
- 工作方式：与ZGC类似，也是一种低延迟、可伸缩的垃圾回收器。
- 适用场景：大堆内存环境，对延迟敏感的应用。
- 启动参数：
-XX:+UseShenandoahGC
选择垃圾回收器的考虑因素
- 应用类型：交互式应用可能需要低延迟的GC，而批处理应用可能更关注吞吐量。
- 堆内存大小：大堆内存可能需要更高级的GC，如G1、ZGC或Shenandoah。
- 硬件资源：多核处理器可以利用并行或并发GC来提高效率。
- 性能要求：根据应用的性能要求选择合适的GC策略。
jvm如何监控
jconsole
jconsole 是 Java 自带的一个图形化监控和管理工具，它基于 Java 管理扩展（JMX）技术，可以用来监控本地和远程的 Java 应用程序。jconsole 提供了一个用户友好的界面，用于查看 JVM 的实时性能和资源消耗情况。（默认在jdk-bin路径下）
如何使用 jconsole
-
启动 jconsole：
- 在命令行中输入
jconsole，然后按回车键。 - 如果你的系统环境变量配置正确，
jconsole将会启动。
- 在命令行中输入
-
连接到 Java 进程：
- 启动后，
jconsole会显示一个对话框，列出所有本地运行的 Java 进程。 - 选择你想要监控的进程，然后点击“连接”。
- 启动后，
-
监控界面：
- 连接后，你会看到几个标签页，包括“概览”、“内存”、“线程”、“类”、“VM 概要”和“MBean”。
主要功能
- 概览：提供 JVM 和应用程序的整体性能概览，包括内存使用、线程数、类加载数量和 CPU 使用情况。
- 内存：显示 JVM 内存的实时使用情况，包括堆内存和非堆内存的详细信息。
- 线程：显示当前活动的线程数，并允许你查看每个线程的状态和堆栈跟踪。
- 类：显示已加载的类数量和类加载器的活动。
- VM 概要：提供 JVM 的详细信息，如版本、启动参数、系统属性等。
- MBean：允许你查看和管理通过 JMX 暴露的所有 MBean。
远程监控
jconsole 也支持远程监控 Java 应用程序。为了连接到远程 JVM，你需要在远程服务器上配置 JMX，并确保 jconsole 可以访问远程 JVM 的 JMX 端口。
-
配置远程 JMX：
- 在启动 Java 应用程序时，添加以下参数：
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=<true/false> -Dcom.sun.management.jmxremote.ssl=<true/false> -Djava.rmi.server.hostname=<hostname>
- 替换
<port>、<true/false>和<hostname>为你的配置。
- 在启动 Java 应用程序时，添加以下参数：
-
连接到远程 JVM：
- 在
jconsole的连接对话框中，选择“远程进程”，输入远程主机的 IP 地址和 JMX 端口，然后点击“连接”。
- 在
jconsole 是一个非常有用的工具，可以帮助开发者和系统管理员监控 Java 应用程序的性能和健康状况。通过实时监控，可以及时发现性能问题，并进行相应的调优。
jvisualvm
`jvisualvm` 是一个集成在 JDK 中的 Java 虚拟机监控和分析工具，它提供了一个图形界面，用于查看和分析 Java 应用程序的运行时信息。`jvisualvm` 可以监控本地和远程的 JVM，并且支持多种插件来扩展其功能。（默认在jdk-bin路径下）
如何使用
1. **启动 jvisualvm**：
- 在命令行中输入 `jvisualvm`，然后按回车键。
- 如果你的系统环境变量配置正确，`jvisualvm` 将会启动。
2. **连接到 Java 进程**：
- 启动后，`jvisualvm` 会显示一个窗口，列出所有本地运行的 Java 进程。
- 选择你想要监控的进程，然后双击它或点击工具栏上的“监视”按钮。
3. **监控界面**：
- 连接后，你会看到多个标签页，包括“概览”、“监视”、“线程”、“抽样器”、“VisualVM Dump”等。
主要功能
- **概览**：提供 JVM 和应用程序的基本信息，如启动参数、系统属性和环境变量。
- **监视**：显示 JVM 的实时性能数据，包括 CPU 使用率、堆内存和非堆内存的使用情况、类加载数量和线程数。
- **线程**：显示当前活动的线程，并允许你查看每个线程的状态和堆栈跟踪。
- **抽样器**：允许你进行 CPU 和内存的抽样分析，帮助识别性能瓶颈。
- **VisualVM Dump**：允许你生成堆转储（heap dump）和线程转储（thread dump），用于离线分析。
插件管理
`jvisualvm` 支持通过插件来扩展其功能。你可以通过以下步骤安装插件：
1. 打开 `jvisualvm`。
2. 选择“工具”菜单，然后选择“插件”。
3. 在插件管理器中，选择你想要安装的插件，然后点击“安装”。
远程监控
`jvisualvm` 也支持远程监控 Java 应用程序。为了连接到远程 JVM，你需要在远程服务器上配置 JMX，并确保 `jvisualvm` 可以访问远程 JVM 的 JMX 端口。
1. **配置远程 JMX**：
- 在启动 Java 应用程序时，添加以下参数：
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<port>
-Dcom.sun.management.jmxremote.authenticate=<true/false>
-Dcom.sun.management.jmxremote.ssl=<true/false>
-Djava.rmi.server.hostname=<hostname>
- 替换 `<port>`、`<true/false>` 和 `<hostname>` 为你的配置。
2. **连接到远程 JVM**：
- 在 `jvisualvm` 的主界面中，选择“远程”节点，然后右键点击“添加远程主机”。
- 输入远程主机的 IP 地址，然后右键点击该主机，选择“添加 JMX 连接”，输入 JMX 端口。
`jvisualvm` 是一个功能强大的工具，可以帮助开发者和系统管理员监控和分析 Java 应用程序的性能。通过实时监控和分析，可以及时发现和解决性能问题。
jstat
`jstat` 是 Java 虚拟机（JVM）自带的一个监控工具，用于查看 JVM 的统计信息。它可以帮助开发者和系统管理员监控和分析 JVM 的性能，包括垃圾收集（GC）活动、类加载情况、编译器统计等。`jstat` 是一个命令行工具，可以在不停止应用程序的情况下实时监控 JVM。（默认在jdk-bin路径下）
如何使用 jstat
`jstat` 的基本语法如下：
jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]- **`-option`**：指定要显示的统计信息类型。
- **`-t`**：在输出中添加时间戳列，显示自 JVM 启动以来的时间（以秒为单位）。
- **`-h<lines>`**：在输出中每 `lines` 行显示一次头部信息，这在长周期监控时很有用。
- **`vmid`**：虚拟机标识符，通常是进程 ID（PID）。
- **`interval`**：刷新统计信息的间隔时间（以秒或毫秒为单位）。
- **`count`**：刷新统计信息的次数。
常用选项
- `-class`：显示类加载器的行为统计。
- `-gc`：显示垃圾收集的行为统计。
- `-gccapacity`：显示各个代的容量及其对应空间的统计。
- `-gcutil`：显示垃圾收集的利用率统计。
- `-compiler`：显示即时编译器的行为统计。
- `-printcompilation`：显示即时编译的细节。
示例
1. **查看垃圾收集统计**：
jstat -gc 12345
这将显示 PID 为 12345 的 JVM 的垃圾收集统计信息。
2. **每秒刷新一次垃圾收集统计，共刷新 10 次**：
jstat -gc 12345 1000 10
这里 `1000` 是间隔时间（毫秒），`10` 是刷新次数。
3. **显示垃圾收集利用率，并添加时间戳**：
jstat -gcutil -t 12345
这将显示垃圾收集的利用率，并在每行输出前添加时间戳。
### 输出解释
`jstat` 的输出通常包含多个列，具体列名取决于你选择的选项。例如，使用 `-gcutil` 选项时，输出可能包含以下列：
- **S0**、**S1**、**E**、**O**、**M**、**YGC**、**YGCT**、**FGC**、**FGCT**、**GCT**：
- **S0**、**S1**：Survivor 空间的利用率。
- **E**：Eden 空间的利用率。
- **O**：老年代的利用率。
- **M**：元空间的利用率。
- **YGC**：年轻代垃圾收集的次数。
- **YGCT**：年轻代垃圾收集的时间。
- **FGC**：Full GC 的次数。
- **FGCT**：Full GC 的时间。
- **GCT**：总的垃圾收集时间。
`jstat` 是一个非常实用的工具，尤其适合在生产环境中监控 JVM 的性能。通过分析 `jstat` 的输出，可以了解 JVM 的运行状况，并据此进行性能调优。
jmap
`jmap` 是 Java 虚拟机（JVM）的一个命令行工具，用于生成堆内存映射和获取运行中的 Java 应用程序的内存相关信息。`jmap` 可以帮助开发者和系统管理员诊断内存泄漏问题，分析对象的分布情况，以及生成堆转储（heap dump）文件，用于离线分析。
如何使用 jmap
`jmap` 的基本语法如下：
jmap [option] <pid>- **`option`**：指定要执行的操作。
- **`pid`**：Java 进程的 ID。
常用选项
- `-dump`：生成堆转储文件。
- `-heap`：显示 Java 堆的详细信息，包括使用的垃圾收集器、内存配置和使用情况。
- `-histo`：显示堆中对象的直方图（按类分组的对象实例数和内存占用）。
- `-clstats`：显示类加载器的统计信息。
示例
1. **生成堆转储文件**：
jmap -dump:format=b,file=heapdump.hprof 12345这将生成一个名为 `heapdump.hprof` 的堆转储文件，用于后续的内存分析。
2. **显示堆的详细信息**：
jmap -heap 12345这将显示 PID 为 12345 的 JVM 的堆配置和使用情况。
3. **显示堆中对象的直方图**：
jmap -histo 12345这将显示堆中对象的直方图，包括每个类的实例数和内存占用。
4. **显示类加载器的统计信息**：
jmap -clstats 12345这将显示类加载器的统计信息，包括每个类加载器加载的类数量和内存占用。
注意事项
- 使用 `jmap` 时，特别是在生成堆转储文件时，可能会对正在运行的 Java 应用程序产生性能影响，因为它需要暂停应用程序的执行来获取内存状态。
- 在生产环境中使用 `jmap` 时，应谨慎操作，以避免对应用程序的性能产生不利影响。
- 生成的堆转储文件可以使用工具如 `jhat`、`VisualVM`、`Eclipse Memory Analyzer` 等进行分析。
`jmap` 是一个强大的工具，用于诊断和分析 Java 应用程序的内存问题。通过使用 `jmap`，可以有效地识别内存泄漏和优化内存使用。
jvm性能分析与诊断
如何读懂gc日志
jstack
读懂垃圾收集（GC）日志是理解和优化Java应用程序性能的关键技能。GC日志提供了关于内存使用、垃圾收集活动和性能瓶颈的详细信息。以下是一些基本的步骤和指南，帮助你理解和分析GC日志：
1. 理解GC日志的基本格式
GC日志的格式通常由JVM的启动参数控制，例如：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log- `-XX:+PrintGCDetails`：打印详细的GC信息。
- `-XX:+PrintGCTimeStamps`：打印每次GC的时间戳。
- `-Xloggc:gc.log`：指定GC日志文件的位置。
2. 识别GC事件
GC日志通常包含以下类型的GC事件：
- **Minor GC**：年轻代的垃圾收集。
- **Major GC**：老年代的垃圾收集。
- **Full GC**：整个堆（包括年轻代和老年代）的垃圾收集。
3. 分析GC日志条目
一个典型的GC日志条目可能如下所示：
2.167: [GC (Allocation Failure) 2.167: [ParNew: 138240K->12799K(138240K), 0.0036134 secs] 138240K->12800K(497792K), 0.0036387 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]- **时间戳**（2.167）：自JVM启动以来的时间（秒）。
- **GC原因**（Allocation Failure）：触发GC的原因。
- **ParNew**：使用的年轻代垃圾收集器。
- **年轻代回收前后的内存使用**（138240K->12799K(138240K)）：回收前后的年轻代大小和总大小。
- **整个堆回收前后的内存使用**（138240K->12800K(497792K)）：回收前后的总堆大小。
- **GC持续时间**（0.0036134 secs）：年轻代GC的持续时间。
- **总GC持续时间**（0.0036387 secs）：整个GC事件的持续时间。
- **GC时间统计**（Times: user=0.01 sys=0.00, real=0.00 secs）：GC在用户模式、系统模式和实际时间上的时间消耗。
4. 关键指标
- **GC频率**：GC发生的频率，频繁的GC可能表明内存分配过快或内存配置不当。
- **GC持续时间**：每次GC的持续时间，长时间的GC可能导致应用程序暂停。
- **内存使用**：堆内存的使用情况，包括年轻代和老年代的使用率。
- **吞吐量**：应用程序运行时间与总时间的比例，较低的吞吐量可能表明GC影响了应用程序的性能。
5. 使用工具
- **GC日志分析工具**：如GCeasy、HP JMeter's GC log analyzer等，可以帮助你更直观地分析GC日志。
- **性能分析工具**：如VisualVM、JVisualVM、YourKit等，可以提供实时的性能监控和分析。
### 6. 优化建议
- **调整堆大小**：根据应用程序的需求和GC日志的分析结果，调整年轻代和老年代的大小。
- **选择合适的垃圾收集器**：根据应用程序的特点选择合适的垃圾收集器，如G1、CMS等。
- **优化对象生命周期**：减少大对象的创建，优化对象的生命周期，减少GC的压力。
通过以上步骤，你可以开始理解和分析GC日志，从而优化Java应用程序的性能。记住，GC日志分析是一个迭代过程，需要根据应用程序的实际运行情况不断调整和优化。
jvm调优技巧
如何减少gc
----------------------待续--------------------------------
另类的java内存泄露
这里的另类的java内存泄露指的是JNI调用时发生的内存泄露一般有以下几个特点：
1、通过监控jvm内存使用发现内存正常使用，没有明显泄露
2、通过jmap生成heap dumo文件，用 MAT工具分析时发现内初使用并不多，无法判断内存泄露
3、分析gc日志时，发现gc垃圾回收正常，甚至很少发生Full GC
4、监控JVM进程时，发现该进程使用物理内存一直宅缓慢增加，等到操作系统的物理内存不够用时，会发现操作系统的虚拟内存使用也开始一直缓慢增加，此时会发现应用程序的响应时间越来越长。
5、如果一直运行下去，最终会发现jvm进程会自动被操作系统杀死。当发现JVM进程自动消失时，可以通过linux操作系统dmesg命令。查看原因发现是操作系统进程耗光了物理内存而自动将进程杀死
6、JVM进程的实际物理内存消耗已经远远大于JVM启动参数中指定的大小
mysql数据库的性能分析
mysql数据库性能监控
如何查看mysql数据库的连接数
在MySQL数据库性能监控中，查看数据库的连接数是一个基本的操作，可以通过多种方式实现。以下是一些常用的方法：
1. 使用MySQL命令行工具
你可以直接在MySQL的命令行界面中使用以下命令来查看当前的连接数：
SHOW STATUS LIKE 'Threads_connected';这个命令会返回一个名为 `Threads_connected` 的变量值，它表示当前打开的连接数。
2. 使用MySQL Workbench
如果你使用MySQL Workbench，可以通过以下步骤查看连接数：
1. 打开MySQL Workbench并连接到你的数据库。
2. 在导航面板中选择 `Server Status`。
3. 在右侧的 `Server Status` 面板中，你可以看到各种服务器状态信息，包括当前的连接数。
3. 使用SQL语句
你也可以编写一个简单的SQL脚本来查询连接数：
SELECT COUNT(*) FROM information_schema.processlist WHERE USER != 'system user';这个查询会返回除系统用户之外的所有用户连接数。
4. 使用性能监控工具
有许多第三方工具可以帮助你监控MySQL的性能，包括连接数。例如：
- **Percona Monitoring and Management (PMM)**：这是一个开源的监控和管理工具，可以提供详细的MySQL性能指标，包括连接数。
- **MySQL Enterprise Monitor**：这是MySQL官方提供的一个监控工具，可以监控和管理MySQL服务器。
5. 使用系统状态变量
在MySQL中，还有一些系统状态变量可以提供连接数的信息：
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Max_used_connections';第一个命令显示MySQL服务器允许的最大连接数，第二个命令显示自服务器启动以来同时使用的最大连接数。
6. 使用命令行工具
如果你更喜欢使用命令行，可以使用 `mysqladmin` 工具来获取连接数：
mysqladmin -u root -p status输入密码后，你会看到包括连接数在内的服务器状态信息。
通过上述任何一种方法，你都可以轻松地监控和查看MySQL数据库的连接数。这对于确保数据库的稳定性和性能至关重要。
如何查看mysql数据库当前运行的事务与锁
在MySQL数据库中，监控当前运行的事务及相关的锁十分重要，可以帮助你理解性能瓶颈和潜在的锁争用问题。以下是一些常用的方法来查看MySQL中当前的事务和锁信息：
查看当前运行的事务
SELECT * FROM information_schema.innodb_trx;上述查询会在`information_schema`的`innodb_trx`表中返回当前正在进行的InnoDB事务的列表。这些信息包括事务ID、开始时间、是否锁等待以及相关的SQL语句等。
查看锁定情况
SELECT * FROM information_schema.innodb_locks;如果存在锁争用，`information_schema`的`innodb_locks`表将显示当前等待和持有锁的事务信息。这是InnoDB存储引擎特有的表，它提供了锁的类型、模式、所在的表以及锁定的具体行等信息。
查看锁等待情况
SELECT * FROM information_schema.innodb_lock_waits;`innodb_lock_waits`表显示了锁等待的关系，哪些事务正在等待其他事务释放锁。这个表将帮助你理解事务之间的阻塞关系。
综合查询锁争用情况
对于更综合的锁争用分析，可以使用以下查询：
SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM
information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON
b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON
r.trx_id = w.requesting_trx_id;这个查询结合了锁等待和事务信息，展示了等待锁的事务和持有锁的事务之间的详细信息，包括它们的ID、线程ID和查询。
查看表锁情况
不只是InnoDB引擎，如果你需要查看表级锁争用，可以使用以下查询：
SHOW OPEN TABLES WHERE In_use > 0;这会显示所有当前被锁定的表。
使用性能模式
MySQL的性能模式（Performance Schema）提供了一系列的表，可以用于监控数据库的性能指标，包括锁：
SELECT * FROM performance_schema.events_waits_current WHERE waiting_thread_id IS NOT NULL;这个查询提供了当前等待事件的信息，包括锁等待事件。
使用`SHOW ENGINE INNODB STATUS`命令
此外，还可以使用`SHOW ENGINE INNODB STATUS`命令来获取一个包括锁信息的InnoDB引擎状态报告：
SHOW ENGINE INNODB STATUS;在输出的结果中，`LATEST DETECTED DEADLOCK`部分会显示最近检测到的死锁信息，而`TRANSACTIONS`部分会显示当前的事务信息，包括存在的锁。
通过以上这些方法，你可以有效地监控和诊断MySQL数据库中的当前事务和锁的状况，这对于数据库调优和性能分析非常关键。
mysql中数据库表的监控
查看数据中当前打开了哪些表
检查当前打开了哪些表 SHOW OPEN TABLES
SHOW OPEN TABLES
您可以使用`SHOW OPEN TABLES`命令来查看当前打开的表。这个命令将列出数据库中所有打开的表，以及它们是否被锁定。
SHOW OPEN TABLES;如果您只对特定数据库或表感兴趣，可以加上`FROM`或`LIKE`子句：
SHOW OPEN TABLES FROM your_database_name;
SHOW OPEN TABLES LIKE 'your_table_name';查看数据库表的状态 SHOW STATUS LIKE '%table%';
SHOW STATUS LIKE '%table%';
这个命令将返回一系列的变量及其当前值，其中一些关键的变量包括：
- Table_locks_immediate: 表示能够立即获得表级锁的次数。
- Table_locks_waited: 表示需要等待的表级锁的次数。如果这个值很高，可能表明存在锁竞争问题。
- Open_tables: 表示当前打开的表的数量。
- Opened_tables: 表示自服务器启动以来打开过的表的数量。如果这个值增长很快，可能意味着表缓存（table cache）太小。
- Handler_read_first: 表示全索引扫描的次数。如果这个值很高，可能表明查询没有使用索引。
- Handler_read_key: 表示根据索引读取一行的请求数。这个值越高，表明索引使用得越好。
- Handler_read_next: 表示按照索引顺序读取下一行的请求数。通常在范围查询或使用索引进行排序时增加。
- Handler_read_rnd: 表示在固定位置读取行的请求数。如果这个值很高，可能表明查询没有使用索引，或者表有大量随机I/O。
- Handler_read_rnd_next: 表示在数据文件中读取下一行的请求数。如果这个值很高，可能表明正在进行大量的全表扫描。
这些变量可以帮助你了解MySQL服务器在处理表操作时的性能和效率。例如，如果Table_locks_waited的值很高，可能需要考虑优化查询或调整事务隔离级别。如果Opened_tables的值增长很快，可能需要增加table_open_cache的值。
查看数据中锁的信息 SHOW STATUS LIKE '%lock%';
SHOW STATUS LIKE '%lock%';
这个查询返回所有与锁定机制相关的状态信息，可能包括但不限于：
- Table_locks_immediate: 表示能够立即获得的表锁的次数。
- Table_locks_waited: 表示必须等待的表锁的数量。如果这个数值很高，说明有很多锁争用发生。
- Innodb_row_lock_current_waits: 表示当前在InnoDB行锁上等待的数量。
- Innodb_row_lock_time: 表示行锁定所花费的总时间（以毫秒为单位）。
- Innodb_row_lock_time_avg: 表示等待行锁平均所需的时间（以毫秒为单位）。
- Innodb_row_lock_time_max: 表示等待行锁的最长时间（以毫秒为单位）。
- Innodb_row_lock_waits: 表示InnoDB行锁定的等待次数。较高的值可能指示频繁的锁竞争。
- Innodb_deadlocks: 表示由于死锁而必须回滚的事务数量。
- Innodb_os_log_pending_fsyncs: 表示正在等待文件同步操作的挂起日志写入数量。
检查这些变量可以帮助你了解数据库中的锁定活动和潜在的性能瓶颈。例如，高的 Innodb_row_lock_waits 或 Table_locks_waited 值可能表明频繁的锁竞争，这会影响查询性能。在这种情况下，你可能需要优化查询逻辑，调整事务大小，或者考虑使用不同的隔离级别来减少锁争用。
查看数据库被扫描的情况SHOW Global status LIKE 'handler_read%'
SHOW GLOBAL STATUS LIKE 'handler_read%';
这个命令将返回一系列的变量及其当前值，其中一些关键的变量包括：
- Handler_read_first: 表示全索引扫描的次数。如果这个值很高，可能表明查询没有使用索引。
- Handler_read_key: 表示根据索引读取一行的请求数。这个值越高，表明索引使用得越好。
- Handler_read_next: 表示按照索引顺序读取下一行的请求数。通常在范围查询或使用索引进行排序时增加。
- Handler_read_rnd: 表示在固定位置读取行的请求数。如果这个值很高，可能表明查询没有使用索引，或者表有大量随机I/O。
- Handler_read_rnd_next: 表示在数据文件中读取下一行的请求数。如果这个值很高，可能表明正在进行大量的全表扫描。
这些变量可以帮助你了解MySQL服务器在处理查询时的性能和效率。例如，如果 Handler_read_rnd_next 的值很高，可能意味着查询正在执行大量的全表扫描，这通常是性能瓶颈的标志。优化这些查询可能包括添加适当的索引，重写查询以减少扫描的数据量，或者调整表结构。
性能测试时mysql数据中的其他常用监控
查看每秒事务的提交数
SHOW GLOBAL STATUS LIKE 'Com_commit';
查看每秒事务的回滚数
SHOW GLOBAL STATUS LIKE 'Com_rollback';查看线程的运行情况
SHOW GLOBAL STATUS LIKE 'threads_%';
这个命令通常会返回以下状态变量的值：
Threads_cached：缓存中的线程数，这些线程用于处理新的连接。线程缓存可以避免创建新线程的开销。Threads_connected：当前打开的连接数，即当前有多少客户端正连接到服务器。Threads_created：自服务器启动以来创建的线程数。如果这个数字很大，可能需要增加线程缓存的大小。Threads_running：活动线程数，即当前正在执行查询的线程数。
这些状态变量提供了服务器当前状态的快照。通过监控这些值，您可以对服务器的性能和行为有一个大致的了解，例如，了解是否需要调整线程缓存的大小等。如果Threads_created值在增长并且Threads_cached值较低，可能意味着您需要增加thread_cache_size配置以改善性能。
查看数据库建立过的连接总数
SHOW GLOBAL STATUS LIKE 'Connections';这个命令会返回一个结果，其中包含一个名为Connections的状态变量，以及一个数字值，表示自MySQL服务器启动以来所有的连接尝试次数。这个计数包括成功的连接和因为任何原因（如认证失败）而未能成功的连接尝试。
请注意，这个命令返回的是一个累积的总数，不区分当前的连接状态或者是否这些连接已经关闭。如果你想得到当前打开的连接数，应使用Threads_connected状态变量。
查看innodb引擎缓存命中情况
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
在MySQL中，可以通过查看InnoDB缓冲池的相关状态变量来了解InnoDB存储引擎的缓存命中情况。InnoDB缓冲池是一个存储缓存页（如数据和索引）的内存区域，旨在减少磁盘I/O并提高性能。
查看join操作时全表扫描的次数
SHOW GLOBAL STATUS LIKE 'select_full_join';
在MySQL中，select_full_join是一个全局状态变量，用于记录自服务器启动以来执行的没有使用索引的JOIN操作的次数。这种类型的JOIN通常会导致全表扫描，可能会影响查询性能。
查看sql中排序使用的情况
SHOW GLOBAL STATUS LIKE 'Sort%';在MySQL中，您可以通过查看相关的状态变量来监控排序操作的性能和效率。主要有两个状态变量与排序操作相关：
-
Sort_scan：这个状态变量显示了MySQL服务器进行排序时扫描表的次数，这种情况通常发生在无法使用索引进行排序时。 -
Sort_range：当排序操作涉及一个范围的时候，MySQL会记录在Sort_range状态变量中。这种情况通常发生在使用索引进行排序的查询中。 -
Sort_merge_passes：这个变量显示了算法已经执行的合并排序的次数。如果这个数字过高，表明排序操作可能需要大量的内存和磁盘I/O。 -
Sort_rows：表示已经排序的行的数量。
请注意，SHOW GLOBAL STATUS命令返回的是自MySQL服务器启动以来的累计值。如果您想要获取特定查询或在某个时间段内排序操作的数据，您需要在运行您的查询前后捕获状态变量的值，并计算差值。
如果排序操作的性能是一个问题（例如，Sort_merge_passes的值很高），您可能需要考虑优化您的查询或者增加sort_buffer_size的值以给排序操作提供更多的内存。然而，增加sort_buffer_size可能会影响服务器上的所有线程，因为每个线程都可以分配到这么多内存进行排序。因此，在调整这个值之前，您应该仔细考虑并测试更改的影响。
查看sql查询缓存的命中情况
在较新的MySQL版本中（如MySQL 8.0及以上），查询缓存功能已被完全移除，因此不再有原生的查询缓存命中率的监控和优化。查询缓存在以前的版本（如MySQL 5.7及以下）中是一项功能，用于缓存SELECT查询的结果，以便相同的查询可以迅速返回已缓存的结果。
SHOW STATUS LIKE 'Qcache%';
这将显示与查询缓存有关的多个状态变量，其中包括：
Qcache_hits：显示查询缓存命中的次数。Qcache_inserts：显示添加到查询缓存的查询数。Qcache_lowmem_prunes：显示因为内存不足而从缓存中清除的查询数。Qcache_not_cached：显示不可缓存的查询数，或者因为查询缓存功能被禁用而未尝试缓存的查询数。Qcache_queries_in_cache：显示当前在缓存中的查询数。Qcache_total_blocks：查询缓存中的总块数。
如果是在MySQL 8.0或更高版本上工作，由于没有查询缓存，您需要依赖其他性能优化技术来提高查询效率，例如：
- 优化索引：确保对查询中使用的字段进行适当索引。
- 优化查询：改写复杂的SQL查询，减少不必要的JOIN操作，使用适当的WHERE子句条件等。
- 使用缓存层：在应用层使用如Redis、Memcached等外部缓存系统来缓存查询结果。
- 配置和优化InnoDB缓冲池：适当配置InnoDB缓冲池大小，使其可以缓存更多的数据页和索引页。
这些技术可以帮助减少数据库的负载，提高查询处理的速度。
查看数据库查询缓存的设置
在MySQL 8.0版本及以上，查询缓存(query cache)功能已经被移除，因为它在高并发场景下通常会导致性能问题，而且难以管理。因此，在这些版本中并不存在查询缓存的配置。
对于MySQL 5.7及以下版本，查询缓存是存在的，并且可以通过以下参数进行配置：
query_cache_type：这个选项决定是否启用查询缓存以及何时启用。它的值可以是OFF、ON或者DEMAND。query_cache_size：这个选项设置查询缓存的总大小。设置为0可以禁用查询缓存。query_cache_limit：这个选项设置能够缓存的单个查询结果的最大大小。
要查看当前的查询缓存设置，可以使用以下命令：
SHOW VARIABLES LIKE 'query_cache_%';
这将返回与查询缓存相关的所有设置的当前值，包括上述参数以及其他一些与查询缓存细节相关的参数。
请记住，即使在支持查询缓存的较旧版本的MySQL中，也通常建议将query_cache_type设置为DEMAND或完全关闭它。因为查询缓存会在表更新时被清空，对于更新频繁的数据库，查询缓存会频繁失效，导致性能下降。在这些情况下，通过优化查询和索引以及可能的情况下使用外部缓存解决方案，通常会得到更好的性能提升。
查询数据库更多的状态信息
在MySQL中，您可以使用`SHOW STATUS`命令来获取数据库的各种状态信息。这些信息包括系统变量、性能统计、连接信息等。以下是一些常用的命令和方法来获取更多的状态信息：
1. 全局状态变量：
SHOW GLOBAL STATUS;这个命令会列出所有全局状态变量及其当前值。这些变量提供了关于服务器操作的详细统计信息，如连接数、查询执行次数、缓存命中情况等。
2. 会话状态变量：
SHOW STATUS;这个命令会列出当前会话的状态变量。这些变量通常与全局状态变量相同，但只反映当前会话的活动。
3. 特定状态变量：
如果您只对特定类型的状态变量感兴趣，可以使用`LIKE`子句来过滤结果。例如，查看与InnoDB存储引擎相关的所有状态变量：
SHOW STATUS LIKE 'Innodb%';4. 性能模式：
在MySQL 5.6及以上版本中，您可以启用性能模式来获取更详细的性能统计信息：
SET GLOBAL performance_schema = ON;然后，您可以使用性能模式中的表来查询详细的性能数据，例如：
SELECT * FROM performance_schema.table_io_waits_summary_by_table;5. 慢查询日志：
如果您想了解执行时间较长的查询，可以启用慢查询日志：
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 设置慢查询的时间阈值，单位为秒慢查询日志将记录执行时间超过指定阈值的查询。
6. 错误日志：
错误日志包含了MySQL服务器的启动和关闭信息，以及运行时错误和警告信息。您可以通过查看错误日志文件来获取这些信息。
通过这些命令和方法，您可以获取MySQL服务器的详细状态信息，帮助您监控和优化数据库性能。请注意，某些操作可能需要适当的权限，并且启用某些功能（如慢查询日志和性能模式）可能会对服务器性能产生影响。
mysql数据库的性能定位
慢sql
-
启用慢查询日志： 首先，确保慢查询日志功能已经开启。在MySQL中，您可以通过设置
slow_query_log变量为ON来启用慢查询日志：SET GLOBAL slow_query_log = ON; -
设置慢查询时间阈值： 接下来，您需要设置一个合适的慢查询时间阈值，即
long_query_time。这个阈值定义了MySQL认为一个查询是“慢”的时间长度。例如，设置阈值为1秒：SET GLOBAL long_query_time = 2; -
执行程序： 在启用慢查询日志并设置好时间阈值后，您可以执行您的应用程序或脚本，让数据库处理查询。
-
查看慢查询日志： 执行完程序后，您可以查看慢查询日志来找出执行时间超过您设置的阈值的SQL查询。慢查询日志通常位于
slow_query_log_file变量指定的文件中。您可以直接查看这个文件，或者使用工具如mysqldumpslow或pt-query-digest来分析日志。 -
分析和优化： 通过分析慢查询日志中的查询，您可以识别出哪些查询是性能瓶颈，并采取相应的优化措施，如重写查询、添加索引、优化表结构等。
执行计划 EXPLAIN
EXPLAIN SELECT * FROM users WHERE id = 5;
`EXPLAIN`是一个在MySQL中使用的命令，用于显示MySQL如何执行一个特定的SQL查询。通过使用`EXPLAIN`，您可以获取关于查询执行计划的详细信息，这有助于理解MySQL是如何处理查询的，以及为什么某些查询可能执行得慢。
当您在SQL查询前加上`EXPLAIN`关键字时，MySQL会返回一个结果集，其中包含以下信息：
1. **id**：查询中每个SELECT语句的唯一标识符。
2. **select_type**：SELECT语句的类型，例如SIMPLE（简单查询，不包含子查询或UNION）、PRIMARY（最外层查询）、SUBQUERY（子查询中的第一个SELECT）等。
3. **table**：查询涉及的表。
4. **type**：表的访问类型，表示MySQL如何查找表中的行。这是非常重要的字段，因为它反映了查询的效率。常见的访问类型包括ALL（全表扫描）、index（索引全扫描）、range（索引范围扫描）、ref（非唯一索引扫描）、eq_ref（唯一索引或主键扫描）、const（通过主键或唯一索引一次找到）等。
5. **possible_keys**：MySQL认为可能用到的索引。
6. **key**：MySQL实际选择的索引。
7. **key_len**：所选索引的长度。
8. **ref**：显示索引的哪一列被使用了，如果可能的话，是一个常数。
9. **rows**：MySQL认为必须检查的用来返回请求数据的行数。
10. **filtered**：表示返回结果的行数占需读取行数的百分比。
11. **Extra**：包含MySQL解决查询的额外信息，如Using index（使用索引覆盖）、Using temporary（使用临时表）、Using filesort（使用文件排序）等。
通过分析`EXPLAIN`的结果，您可以了解查询的性能瓶颈，并据此进行优化。例如，如果发现查询使用了全表扫描（type为ALL），您可能需要考虑添加索引来提高查询效率。如果`Extra`列中出现了`Using filesort`或`Using temporary`，这通常意味着查询需要优化，因为这些操作通常很耗资源。
使用`EXPLAIN`是数据库性能调优的一个重要工具，它可以帮助您识别和解决查询性能问题。
394
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
