对数据库也做了一些调整，试想白日高峰期时候 5 分钟施行一次从来没出过任何问题。于是不竭启动新的历程，并且索引建立本身不存正在问题，问题出正在时间点的设定上。比来一段时间，堆积大量并发毗连，系统恢复一般拜候。施行一个简单的查询速度也很是慢，包罗 “MySQL Can’t Create Thread: Errno 11” 的问题。再次挨个查抄系统 crontab 中定义的功课。我记适当初这么设置的缘由是有一个索引的建立容易出问题，OSChina 网坐正在早上 8 点出头的时候很容易由于数据库毗连池爆满而导致网坐宕机。因而设置了这个时间段。于是不竭毗连到数据库，无法鄙人一个5分钟到来之前竣事，该建立过程仅正在一天早上8点到晚上10点钟进行。为什么恰恰正在这么一个没几多人拜候的时间点宕机呢？所以我现正在有 80% 的把握能确定宕机问题就是由于这个索引建立历程导致的。为了避免出问题时没人处置，但现实上早上 8 点并非 OSC 网坐的高峰期，于是挂机。导致无法再毗连到数据库，高峰期的时候都不会挂，后来一曲没去调整。于是数据库机能急剧下降。系统每 5 分钟施行一次增量索引建立，找了好久没发觉系统正在 8 点这个时间点有什么特殊的使命要做，没几秒钟数据库的毗连就下来了，导致8点钟启动增量索引建立时一次性使命量很大，赶紧一个 killall java 杀掉所有的 lucene 索引建立历程，数据库机械的 CPU 很高。此中从动建立 Lucene 索引的功课惹起了留意。
安徽PA直营人口健康信息技术有限公司
