WCM的发布队列中，挤压了不少待发布任务；
编辑执行的发布，都进入了待发队列中。
出现发布堵塞的原因很有多种，以下几种情况比较常见：
站点分发不顺畅，如：ftp分发超时不成功等等
发布写文件失败，如：安装了杀毒软件，杀毒软件禁止频繁向系统些文件；
数据量比较大，导致数据库性能比较低下，由于执行了一些低效SQL，导致数据库连接比占用，其他SQL查询较慢；
3.1查看后台日志
出现异常情况，一般都需要看一下后台日志，看是否有一些异常堆栈信息，ftp分发或写文件出了问题，一般都会在日志中显示出来；
3.2获取java堆栈
如果日志里面也没有比较明显的日志信息，但现象是发布队列里面有很多待发任务，所以有必要了解一下当前Java进程正在执行什么事情，则需要获取一下Java堆栈
获取办法：
Linux操作系统
获取到Java的进程号
ps -ef | grep java
或者java的堆栈，其中<pid>需要缓存上一步中获取的编号
kill -3 <pid>
Windows操作系统：
进入jdk的bin目录，执行jstack <pid>
可以在获取的java core文件中搜索com.trs相关的关键词，看看WCM相关的类正在执行什么动作
3.3设置BaseObjs的调试开关为DEBUG级别
如果是数据库查询比较慢，则我们一般需要知道是WCM执行哪些SQL比较慢；我们可以从数据库获取TopSQL，也可以将WCM的BaseObjs的调试开关打开，因为一般数据库查询都会通过BaseObjs的进行查询。
设置BaseObjs为DEBUG的办法：
可以使用wcm/wcm_use/下的log4j级别动态修改功能，具体设置可参考：如何动态调整WCM某些类的log4j级别
则查询超过700ms的SQL都将在日志里面显示出来，在日志中查询关键词：]ms
根据获取到的低效SQL，利用Oracle SQL Developer工具分析低效的原因，如：是否走索引等等，这个可以介质工具查看SQL的解析计划。
3.4数据库连接池层面的SQL跟踪
1、设定阀值
管理员身份访问wcm/wcm_use/dbcp.tracer.setthreshold.jsp?thresh=n
其中参数thresh=n是指定秒数。
如果没有这个JSP，直接下载：
2、打开调试开关
使用wcm/wcm_use/log4j.jsp动态设置com.trs.util.dbcp.impl.ConnectionWrapper类的logger级别为Debug
dbcp.tracer.setthreshold.zip