shuxiaohua的博客

本系统借助公司平台，持续对慢接口进行监控，当慢接口的比例超过一定阈值时就会告警。某日隔壁组收到慢接口告警，找我帮忙定位。定位前，我已先让运维临时扩容快速解决问题。

在SIT环境打开debug日志后，复现问题，并在日志中找到了问题点。从日志来看，是tomcat解析HTTPHeader时超长了。通过tomcat源码，并追溯该长度的配置，最终定位到在spring中，该值由server.max-http-header-size决定，不配置的话，默认为8192.该问题为啥dev没有，sit和生产才有？对比环境配置后，发现dev有配置该值server.max-http-header-size=1048576，其他环境没有配置使用的默认长度。

线程池的几个参数意义我这里就不详细介绍了，网上一大堆。将请求第三方的逻辑，放到异步线程里面处理，还是比较常见的做法，比如某个接口要调用好几个第三方，而且各自没有依赖，会使用异步线程，同时提交对第三方系统的请求，以减小本接口的响应时间。请求第三方属于IO密集型，本身并不会怎么消耗CPU，因此线程池的线程数可以设置大一点（比如200）。

618大促前，运维对系统做巡检时发现redis cpu利用率白天基本保持在72%左右，夜里也在60%以上。担心618流量比平时大，导致redis超负荷，因此找开发进行优化，降低redis的负载。

tcpss -ltLISTEN 状态– Recv-Q 表示当前 listen backlog 队列中的连接数目（等待用户调用 accept() 获取的、已完成 3 次握手的 socket 连接数量）– Send-Q 表示了 listen socket 最大能容纳的 backlog ，即 min(backlog, somaxconn) 值。非 LISTEN 状态– Recv-Q 表示了 receive queue 中存在的字节数目– Send-Q 表示 send queue 中存在的字节数；

问题描述spring boot开发的应用部署到环境上后，没有任何业务访问，CPU利用率长期100%。定位思路初步判断大量异步任务导致CPU占用率搞排查排查代码中使用ExcutorService的地方，及异步任务（spring的@Scheduled）。发现有使用@Scheduled,根据配置和实际的业务处理、异步任务打印的日志，理论上不会出现cpu100%，故排除掉。深入定位找到CPU占用率高的线程找到java进程，16找到cpu占用率高的线程，top -H -p 16找到线程的

系统基本介绍本系统为客服系统，“页面”为访客端；“后端”为访客端的后台；“第三方系统”为坐席（客服）端的后台。"后端"主要提供消息发送和查询、回调（“”第三方系统“”将坐席回的信息推给“后端”），3个接口占了99%的QPS。坐席端具有排队功能，所以会话具有状态，“已接入”，“待接入”。不管是待接入状态，还是已接入状态，页面每3秒轮训一次后端，调用的是消息查询接口。已接入状态坐席回的消息会通过“后端”的回调接口将消息推送给“后端”，并写入MongoDB。所以已接入状态查询消息时，只是从Mong

背景系统原来是使用(HAProxy+Sentinel+redis)做的高可用方案，该方案HAProxy无法感知到主从切换，导致写操作失败。具体可参考之前的文章。为了解决这个问题，拿掉了HAProxy，然后使用Jedis的Sentinel模式。# 代码有删减RedisSentinelConfiguration redisSentinelConfiguration = new RedisSentinelConfiguration(sentinel.getMaster(), sentinelHostAnd

sun.nio.ch.IOUtil#read(java.io.FileDescriptor, java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher)读try {return n;} }IOUtil取文件内容时，会分配DirectByteBuffer作为字节容器，并且分配的DirectByteBuffer会被缓存下来，因此要避免传入的ByteBuffer过大。IOUtil引用的地方如下，使用这些类或方法时，要特别注意。

运维接到用户反馈无法登录，拉我上线一起定位。首先我们先拉上用户进行复现，发现登录接口超时导致登录失败。遂让运维先查查有无错误日志，我这边通过啄木鸟(调用链查询系统)确认是哪一段耗时。还未等我打开啄木鸟，运维就发现有大量数据库连接报错。虽然该报错并不是登录服务(下图服务C的)的，但我知道登录接口肯定受这个报错影响了，因此就不再查看啄木鸟直接定位该报错了。且该接口QPS有点高。