1、点击运营管理平台页面，直接提示504
2、对应机器应用数据层CPU暴涨

排查方案：
1、top 命令查看，cpu暴涨，某个java 的cpu暴涨 到200以上
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               
22562 root      20   0 5226852   1.6g（堆栈1g+堆外0.6g）  14648 S 319.9 10.7 133:11.65 java                                                                                                 
 2444 root      20   0 5065660 662684  14336 S   1.3  4.1 156:19.17 java                                                                                            
18040 root      20   0 5061352 640448  14368 S   1.3  4.0 146:15.72 java                                                                                       
  626 root      10 -10  144368  15756  10224 S   1.0  0.1  68:34.90 AliYunDunMonito                                                                                    
   
2、jstat -gcmetacapacity -h5 PID 1000 20  发现JVM  GC 频繁
   MCMN       MCMX        MC       CCSMN      CCSMX       CCSC     YGC   FGC    FGCT     GCT   
       0.0  1251328.0   227328.0        0.0  1048576.0    24832.0   181     5    0.779    3.226
       0.0  1251328.0   227328.0        0.0  1048576.0    24832.0   181     6    0.779    3.226
       0.0  1251328.0   227328.0        0.0  1048576.0    24832.0   181     7    0.779    3.226
       0.0  1251328.0   227328.0        0.0  1048576.0    24832.0   181     8    0.779    3.226
       0.0  1251328.0   227328.0        0.0  1048576.0    24832.0   181     9    0.779    3.226
3、jstack -F PID  查看当前进程堆栈信息 ，发现大量零售业务查询线程阻塞

解决方案:
1、调整java  JVM内存，由-Xms512m -Xmx1G  调整为 -Xms2G -Xmx2G （本来想调整成4G，但是运维反馈机器内存不够）
2、调整业务代码，修改零售业务接口中的大List逻辑，并且优化Elasticsearch 性能，接口性能

扩展（推论）：
1、零售业务查询ES时，可能响应速度太慢，当用户数操作过于频繁时，则导致了堆栈内存不够用，出现频繁FGC，和STW （只是推论，因为没有做调用链和性能监控）


观察中。。。。。