在组里，我负责一个推送通知系统，这个系统主要的功能就是提醒客户端是否该拉去最新的数据，3周前，上线了新的功能，经过staging环境的详细测试通过，全部部署上线后，每天会受到snmp.udp.inError报警，这是每台服务器内置监控的报警，表示udp包没有及时处理，我们系统内部都是udp通信的。通过监控界面查看，不是特别频繁，丢包率不到1%，而且我们udp网络库应用层做了重传，不影响业务层逻辑。查看历史记录，之前很少，没这么频繁，这个监控理论上应该为0，从改动上来看，功能上没啥太大变化，不应该出现这个问题。
首先影响服务器的性能因素：
cpu：体现为多线程，多进程充分利用多核，提高并发性能
内存：现在内存的访问速度很快，速度不是问题，内存不足时，系统会内存置换，比较影响性能
网卡：网络流量打满了网卡，多余的请求就没法被处理。
锁：锁本身并不会影响性能问题，锁的等待比较影响。
-
同步阻塞IO：如果某一个同步操作很费事，所有的后续操作被阻塞到这个地方，所以现在针对IO密集型服务，异步才是最高效的方式。
该系统是一个io密集型的，基于有限状态机的异步框架，同步的操作只有访问mysql，redis这些都是异步访问的，最终需要执行mysql的操作很少，而且mysql操作改成异步比较麻烦。所以排除锁，先从cpu，内存等着手处理。
查看系统资源监控，cpu的idle长期处于70%，看来cpu的利用率不足，系统本身是多线程的，线程数可配置的，上调1.5倍的线程数，重启观察1天，发现没有什么明显的改善，还是有报警，cpu问题排除。
服务部署了2个机房，我比较了下两个机房的配置，A机房的内存64G，cpu也好，B机房32G，cpu差点，A的流量比B的少很多，首先直接系统是无状态的，修改下游的路由策略，改为不限定IDC，权重一致，使流量均匀，(我们内部有一套软件，通过分布式路由控制可以做到),上线后A机房的报警明显减少了，B机房由于流量增大，之前没有的现在有了部分报警。问题看上去得到缓解。
后续上线了新的功能，这次会增加和下游服务多了一次udp通信，这次上线后，报警就多了，error数有时候到了100多，这下问题就需要继续排查了。丢包，是因为接受的udp没有及时处理。调低单个实例的权重，选一台机器在上面部署两个实例，上线观察，恢复回去，问题又重新出现，通过比较发现，问题的确是系统处理速度太慢。看看内存占用，不到20多G，还很宽松，不是内存引起的， 网卡流量也还不到一般，网卡排除。
系统没什么大的变化，难道是代码新功能有耗时的地方，回滚了几台机器，观察回滚了也没啥效果。我也是没啥头绪，思考再三，先放着，暂时不影响业务。放置了几天。晚上下班，想起来，同步操作除了mysql访问，还有日志，我接手这个系统时，的确是逐渐加了一些日志。线上日志的level时INFO，再调高到WARN试下，上线后观察，error不出现了。看来的确是log输出影响了性能。问题目前来看得到了彻底的解决。但日志太少的问题，后续我们会有新的工具来实现分布式追踪。
后续我又想了下，这个问题一开始我的思路也是错了，这个系统本来规模就挺大，我自己首先就排除了业务增长导致的性能压力，我接手了半年，半年里我司也是卖出了好几千玩太手机，额每个手机都要连入我的服务，所以业务应该是的确增长一些，导致的性能压力。很多时候，问题最后没法解决，可能是自己把正确的解决方案先排除了。
由于半路转的java后端，在这些问题排查方面经验不足，特记录一下，也算是一次经验吧。
