说明：这是几年前，大约2014年吧，项目上的一次事故的回顾。
刚整理之前的工作笔记，翻出来了，现在读起来依然有点心惊胆战，惊心动魄的感觉，因为系统是一个收费系统，对系统的稳定性，实时性要求比较高。
现摘录在此。
-------------------------------------------------------
今天系统的事故回顾。
今天出大事了！一大早一卡通收费大厅反映不能收费，现象是一个表的空间不能扩展，导致不能收费。
很明显，是数据库表空间满了，并且达到了空间自动扩展上限。这个表是一个日志表，用来记录一个数据同步的调试信息，数据库一查，这个表的数据已经非常非常大（估计上千万了），表空间还只有区区20M的空间，由于这个表的数据不重要，就赶紧吧这个表truncate了，一下子空出来7G的空间，注意你没看错，确实是7个G。
本以为问题解决了，但是！用户仍然反映系统非常慢，甚至都不能登录系统。继续排查原因。由于有用户反映说收费的时候，提示 批扣用户正在批扣xx用户的费用，不能窗口收费。想起来今天是5号，费用自动批扣程序自动运行，凌晨系统自动批扣用户费用。是不是昨晚上数据库就慢了导致i批扣失败，这个程序还在运行？？一检查果然还在运行，想当然认为是这个程序占用了大量的数据库资源，吧系统堵死了。赶紧把他停掉。把批扣生成的操作锁删除掉，松了口气。
但是，噩耗还没有结束，用户依然大喊系统慢，排队的人非常之多。甚至和用户吵起来了，有些收费员已经不冷静了，项目组压力非常之大。
问题到底出在哪里，登录数据库，查表，很快，没问题。
项目组所有人都在尝试系统，发现一个现象，访问登录网页，都非常之慢，甚至好几分钟才能出来登录界面，登录进入，主页上的一个图标数据展示也是，根本就不能用，别提收费了，群里依然有收费员在喊。
登录页面不能？这时候还没有访问数据库啊，把数据库的原因排除掉，以为内刚才看数据库也很快嘛、
难道是应用服务器的问题，日志慢了，把硬盘空间堵死了？没时间看空间了，先把3个domain下的server.log文件删掉再说。还是不行！！
重启domain，快一会，但是没多久，还是慢！！
难道是负载均很的问题？？绕过如在均衡直接访问每个domain，仍然是很慢。 果断吧负载均衡重启，还是不行！！！
查看服务器资源占用，硬盘没问题，cpu空闲，就是内存有点大，16G的内存，使用了12G。
看看JVM状况，一时忘了监控端口，找戴看，也看不出问题，拿出必杀技吧，重启操作系统吧，厚着脸通知客户，重启服务器5分钟。
5分钟机器是起来了，但是登陆页面直接打不开了，底下的domain也不能，domain没起来？负载没起来？问戴，都起来了吗。奇怪？
5分钟终于搞明白，把domain搞错了，目录上有两个目录，glassfish3 和 glassfish312，错误地启动了前者下的 几个domain。
终于起来了，但愿能解决问题，当然，一切还没解决。依然是慢！！！！！！！！！！！！！！
疯了。
OS没问题，网络没问题，应用服务器没问题，负载没问题，但是登陆还是有问题，缴费还是有问题。最后只有数据库了，不是谁说了句，不会有死锁吧！！！
进入数据库，查询锁，没有执行权限，我#，信息中心给的权限太小。好在有个项目的用户的权限比较大，能查看锁，一查，好壮观，一堆锁在里边啊（目测100多个）！！！！估计死锁无数！！！！
就是这个原因了，先杀一些再说，找几个看着长的比较丑的杀掉，一查，所得数量猛降！再杀，估计有收费的被牺牲了，顾不上了，终于，真个世界清静了，锁越来越少了，系统马慢慢恢复了正常。
前面都是故事，还原一下整个过程：
昨晚上批扣程序自动启动，刚开始干的挺欢，一切太平，估计不知道什么时候，假设凌晨5点吧，夜黑风高，数据库满了！批扣失败，但是这个程序没有检查是否失败，依然继续运行，在数据库中留下了无数个锁，还有死锁，暂用了大量的数据库资源，数据库惹恼了，导致系统性能急剧下降，尤其是在大并发的情况下。
总结下经验教训
1，有点慌，没能准确定位错误。出现数据库空间满，导致批扣这个大事务程序异常，最应该想到的就应该是数据库层面的问题。但是由于经验不足，对数据库了解不深，没有第一时间考虑数据库的原因。当然登录页面慢也扰乱的视线（为何登录页面慢，很奇怪，明明那时候没有访问数据库，这个需要讨论）
错误定位路径： 数据库满（删除表，腾出空间）-->大事务程序暂用系统资源（停掉程序）-->应用服务器空间满（删除日志文件，清空空间）-->domain 的jvm性能下降（重启domain）-->负载均衡服务器的问题（重启）-->OS的问题（重启OS）-->数据库锁的问题（删除死锁）-->问题解决！
在这个路径中，只有第一步和最后一步是有效的。
2，没有趁手的监控诊断工具，不了解常用的命令。无论是分析数据库问题，还是网络，应用服务器等等，我们都没有现成的诊断工具，配置信息也维护的不好，jvm的监控端口都忘了，centos的监控指令不不熟悉。重启负载均衡都没有成功，不知道命令。
esp本身没有提供有效的监控手段和问题排查机制，处理简单的server log。
3，服务器安装配置没有及时更新。
重启服务器后，重启domain的时候，竟然起错了，原因是，曾经升级过glassfish到glassfish312，因此服务器上有两个目录，glassfish 和 glassfish312，应该重启后者下的domain。glassfish目录没有删除（！！删除掉他！！）。
没有记录帆软报表的domain信息！！。
重启domain的批处理有问题，没有自动起来（这个待查！！）
4，批扣程序不完善，没有在检查到错误的时候，停止执行，造成了大量的日志，导致数据库空间满，甚至大量的死锁。这是罪魁祸首。应该是连续出错多少次后，应该停止执行。我相信很多人写程序都没有注意到这一点。
5，日志管理不善。没有日志清除程序，没有日志级别定义，可以来关闭日志记录。本来那个大表的日志是debug时的日志信息，后来保留下来了，造成大量的日志积压。简介原因
6，系统中依然后大量的临时表尸体。
6，后台自动程序，没有管理界面。也就是系统的可管理性不好。要停止程序执行，还要到数据库中修改配置表的配置项，而且还不止一个。
7，运维管理方面
没有有效的系统监控手段和制度。三个没有：没有指定制度，没有有效的手段，没有指定责任人。
