[wolf💀wulaoer.org 🔥🔥🔥🔥 ~ ]$ pidstat -d 1 平均时间: UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 平均时间: 0 574 0.00 6.39 0.00 0 jbd2/dm-0-8 平均时间: 0 1449 0.00 6.39 0.00 0 wsssr_defence_d 平均时间: 0 6911 0.00 236.56 0.00 1 jbd2/dm-3-8 平均时间: 1007 149974 0.00 1700.70 1035.76 0 java 平均时间: 0 247056 0.00 0.00 0.00 0 kworker/u256:2-events_unbound 平均时间: 1008 1013333 0.00 57.54 0.00 0 java [wolf💀wulaoer.org 🔥🔥🔥🔥 ~ ]$ ps -ef | grep 149974 elastic 149974 149647 11 11:15 ? 00:34:16 /ELK/server/elasticsearch/jdk/bin/java -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -Djava.security.manager=allow -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j2.formatMsgNoLookups=true -Djava.locale.providers=SPI,COMPAT --add-opens=java.base/java.io=ALL-UNNAMED -Xms4g -Xmx4g -Djava.class.path=/ELK/service/elasticsearch/ -XX:+UseG1GC -Djava.io.tmpdir=/tmp/elasticsearch-3210332282851559590 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=logs/hs_err_pid%p.log -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m -XX:MaxDirectMemorySize=2147483648 -XX:G1HeapRegionSize=4m -XX:InitiatingHeapOccupancyPercent=30 -XX:G1ReservePercent=15 -Des.distribution.type=tar --module-path /ELK/server/elasticsearch/lib --add-modules=jdk.net -m org.elasticsearch.server/org.elasticsearch.bootstrap.Elasticsearch elastic 150031 149974 0 11:15 ? 00:00:00 /ELK/server/elasticsearch/modules/x-pack-ml/platform/linux-aarch64/bin/controller root 330012 328297 0 16:02 pts/1 00:00:00 grep 149974
通过pidstat -d
会显示每个进程的磁盘I/O活动,每个读取和写入的字节数,刷新间隔是每秒钟一次。我这里是已经处理完了,在排查的时候忘记保留信息了。
[wolf💀wulaoer.org 🔥🔥🔥🔥 ~ ]$ iostat -x 1 Linux 4.19.90-52.22.v2207.ky10.aarch64 (CARGO-ELK01) 2024年11月19日 _aarch64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.36 0.00 0.65 3.08 0.00 94.91 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz aqu-sz %util dm-0 0.85 49.19 0.00 0.00 1.84 57.99 5.17 52.34 0.00 0.00 1.59 10.13 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.89 dm-1 0.06 3.74 0.00 0.00 1.84 64.01 0.09 5.85 0.00 0.00 11.74 64.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.03 dm-2 0.00 2.12 0.00 0.00 8.50 521.38 0.00 0.01 0.00 0.00 12.50 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-3 0.42 36.27 0.00 0.00 1.57 86.85 493.44 1693.59 0.00 0.00 0.87 3.43 0.00 127.67 0.00 0.00 4.60 1048555.52 0.43 21.29 vda 0.59 55.17 0.33 35.72 1.80 93.94 2.95 57.47 2.31 43.90 1.51 19.47 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.91 vdb 0.38 39.18 0.06 13.31 1.84 103.74 359.79 1515.77 133.66 27.09 0.78 4.21 0.00 127.67 0.00 0.00 4.73 1048555.52 0.00 21.29 vdc 0.00 0.00 0.00 0.00 0.78 90.99 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 0.00
常见字段说明:
Device: 磁盘设备名称,例如 sda
、sdb
、vda
等。
r/s: 每秒读取请求数(Read requests per second),表示磁盘每秒读取的请求数量。
rkB/s: 每秒读取的数据量(Read kilobytes per second),表示磁盘每秒读取的字节数(KB)。
rrqm/s: 每秒合并的读取请求数(Read requests merged per second),表示在 I/O 操作中合并的读取请求数。
%rrqm: 读取请求合并的百分比(Percentage of read requests merged),显示读取请求合并的比率。
r_await: 读取请求的平均等待时间(Read await),即完成一个读取操作所需的平均时间(以毫秒为单位)。
w_await: 写入请求的平均等待时间(Write await),即完成一个写入操作所需的平均时间(以毫秒为单位)。
svctm: 平均服务时间(Service time),即每个 I/O 请求的平均处理时间(以毫秒为单位)。
%util: 磁盘的利用率(Disk utilization),表示磁盘总的 I/O 请求处理时间的百分比。如果这个值接近 100%,表示磁盘几乎满负荷运行。
我当时%util
就是接近一百,找到是哪个服务了,那就是针对这个服务做优化看看,我一直以为是因为我的es集群做的分片原因,查看了一下三个节点设置的副本不对导致yellow
,不过这个不是导致I/O高的原因,在网上搜索了一下可以调整es的参数减少每次操作的写入延迟
index.translog.durability: async index.translog.sync_interval: 30s
在es集群中执行时失败了,原因是因为8.*版本不支持,这个没有具体查看原因,不过可以通过ES直接设置
PUT /my_index { "settings": { "index": { "refresh_interval": "30s" } } }
虽然我在查询日志时,确实有延迟,但是我的磁盘I/O确实下降了很多。有原来的百分之80-100降到现在的20-40之间,我原来以为是因为我设置的内存原因,结果还是不理想,先记录一下后期有时间好好整理一下。
您可以选择一种方式赞助本站
支付宝扫一扫赞助
微信钱包扫描赞助
赏