症状
一到半夜，流量少的时候，此时请求接口非常卡，观察资源监视器，Java占用的内存就只剩两三百M，这本来不会引起太大重视，但是，频繁出现502的现象，便引入了ELK分析日志，才发现原来系统这么不稳定，性能如此差，经常504，502，甚至会怀疑是不是服务器不够用了。本来是追踪不同的错误现象，最后都汇聚到了同一个病因，才发现原来是任务计划的锅，改动一下，灰常好用。
查找问题
在探寻502的原因的过程中，发现Nginx错误日志为no live upstreams while connecting to upstream，表示无上游可用。
无上游可用的直接原因是——间接实现健康检查模块阈值太低，相对可以容忍的504也被判定为fail，多次fail，导致一台台上游被判定为down，最终导致无上游可用，全部返回502。
便引入了阿里的健康检查模块nginx_upstream_check_module
引入参考Windows版Nginx配置实现不停服更新Tomcat
心跳普通接口判断生命，再调大参数。虽有好转，但仍然有零星的502，504出现，心跳请求也常有慢请求，这说明没有根本性地解决问题。
Nginx关闭上游只是502的直接原因，504的原因也不是针对具体业务的，而是整个tomcat，根本原因还是tomcat处理请求不稳定。
追踪502，504，nio改为apr，ng分流走http1.1，tomcat、ng调优，没有肉眼可见的好转，只能调优到这个程度，告一段落。。。。
服务器是采用Jenkins自动化部署，为了解决Jenkins会杀死子进程问题，又采用了Jenkins调用任务计划来间接启动tomcat，从而一步一步的入坑。
这一年来系统改动较大，而流量也上涨了不少，系统明显变卡了，导致不清楚是哪个环节出了问题。流量上涨了，服务器内存不够用了？cpu吃不消了？带宽不够了？数据库存储过大，所以慢了？Nginx性能开始下滑了？
无凭无据的假设难以解决问题，偶然的机会，我引入了ELK分析Nginx日志，这才发现问题的严重性，既然手动的操作都能肉眼可见的卡顿，更何况大比例的数据上报，那些不可见调用的失败。
搭建起ELK后，明显可以看到伪qps的抖动(以nginx写入日志统计，即统计返回数据的那个时间点，不是请求的那一刻的时间点，所以不能说是正规的QPS，不过参考性还是有的)。——这个抖动说明请求在单位时间内卡住了，又在很快的时间内都处理完毕，所以这个伪QPS堆积在某些点上。
平均响应时间和最大响应时间数值都偏大，而且骤升骤降，起伏不定——说明服务效率低并且不稳定。
解决方法
■ 发现
偶尔也有手动启动过tomcat，性能不错，心里已经埋下了对自动化部署的怀疑，好像系统平稳的的时候常和手动重启的时间线重合。
怀疑的心态，略微的敏感触发了机缘巧合。深夜，我尝试在一台服务器上同时手动和自动开启一台tomcat，手动开启的tomcat内存平稳占据1g出头，而通过任务计划开启的tomcat隔了一两分钟没什么流量，内存就会慢慢的降下来，越降越低，突然的请求会造成大量的硬错误(硬错误指的是从磁盘加载到内存)，所以非常卡顿。
很自然的查看任务管理器的Java进程，优先级竟然是低于标准，豁然开朗，低于标准还能有什么好性能。
■ 解决
① 导出
② 修改
Priority默认值为7，修改为0-3。
③ 导入
保存，再导入即可。
■ 解析
任务计划的默认优先级是7——低于标准，所以得修改任务计划的优先级。
下图为我做的文档翻译和实际显示值。
按道理4就是相当于我们手动启动的级别，但仍会降内存，我便设为0，后面发现这个超高的优先级导致，java物理内存会约占越大，直到占满虚拟内存(申请内存)，不过性能是真的好，也不差那点内存。
■ 打个比方
高优先级就是好空调，低优先级就是烂空调。虽然都可以制冷到20度，但好空调只需要10分钟，烂空调却要2个小时。当你还想再冰，要17度，好空调10分钟搞定，烂空调外机都冒烟了还没搞定。
如果你是个年轻人连续好几天只要20度，好空调坏空调都能维持住20度，只是初始制冷有差距。但是你是个老人家，一会儿怕冷一会儿怕热，温度调来调去，好空调可以随你心意很快适应你，而坏空调忙坏了，就感觉很难制冷。
ELK图表前后对比图
可以明显感受到前后的变化。由不稳定变为了较为平和，稳定。
最后
如果你采用winserver任务计划启动tomcat，一定要配上较高的优先级，否则白瞎了服务器的资源。