求助：关于消息队列堵塞的问题

zhongzhe27

我们的一个系统出现了一次消息队列堵塞问题，具体情况如下：我们有两个进程，一个是TCP接入进程，一个是业务处理进程，两个进程通过消息队列传输数据，处理进程收到信息后，立刻fork出子进程进行处理，然后父进程继续接收消息队列数据。子进程的处理中有关于操作数据库的部分。前两天客户反映我们的系统已经半天没有交易处理了，他们重启了系统，但没有奏效。在重启INFORMIX之后，再重启系统，系统恢复了正常，据客户反映，数据库是正常的，online.log里也没有异常情况。我们查找日志发现是接入进程写消息队列失败，看日志是因为消息队列堵住了，但处理进程的日志里却没有这段时间的任何记录，说明处理进程没收到数据，或是在此时阻塞了。当时并没有保存下来当时消息队列的状态和系统状态，请各位高手分析一下是什么原因造成的这次消息队列堵塞呢，为什么重启了INFORMIX，处理进程就能正常工作了呢，处理主进程是跟数据库无关的啊？有哪些可能的原因，或是SCO在哪里记录下了有关消息队列异常、服务器异常之类的日志？
多谢！

CNL

如果并发业务多，用fork子进程做数据库操作的办法是不当的办法，比如同时上来上百个请求，如果你fork成百个进程，别说你消息队列会堵塞，内存也可能被用光，你的系统自然会陷于停滞状态
通用的做法是做一个数据库业务进程池，池内进程个数多少根据你业务并发程度而定，通讯程序只是把数据通过消息队列或共享内存发给业务池，这种机制与B/S架构下的web服务类似，只是你还需要自己设计有关应答同步和进程池调度机制。

sunlan

堵塞是使用消息队列最常见的问题。把消息队列开大点能在一定程度上减少堵塞的发生，但不能完全解决这一问题

zhongzhe27

的确如此，如果程序问题不解决，消息队列不管有多大都会堵住。关于CNL所说的架构问题，实际上我们新的系统就跟你说的类似。感谢二位。

经过确认，已经排除了跟数据库的关系，也就是说单纯与进程与系统环境有关。我们这个老系统在客户自98年到现在差不多兢兢业业给客户干了7年多了，早该退役，不过运行还是蛮稳定的，这是第一次碰到这样的问题，当时的系统状态没有留下来，不太好查这是个啥子原因导致的。不知道系统里哪里有记录有关这样的系统IPC异常的日志，有知道的兄弟提供一下，万分感谢。