]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds
. Stack trace:
Thread-3847 "[STUCK] ExecuteThread: '92' for queue: 'weblogic.kernel.Default (se
lf-tuning)'" <alive, suspended, priority=1, DAEMON> {。。。。。}





,"weblogic.kernel.Default"是从客户端提交请求后产生的线程所在的队列名。这个队列的线程数默认是15个。如果超过15个线程堵塞，则部署的应用将不能访问。同时后台报：
<2008-2-27 下午09时37分48秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy for "1,720" seconds working on the request "Http Request: /myapp/test/index.jsp", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.> 
2，线程数(Tread Count)：指派到weblogic.kernel.Default队列的线程数。如果你不需要使用超过15个线程（默认），就不必更改这个属性值。


    如果发送该请求较多，很有可能会导致weblogic的线程阻塞，严重会引起weblogic挂起现象。
可以通过以下几种方法解决： 
1）修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。
2）增大线程数，防止线程阻塞问题。
3）优化程序，减少处理时间。



1） 如何修改StuckThreadMaxTime参数值：http://lujinan858.iteye.com/blog/986237

启动weblogic服务，进入控制台：

your_domain->Environment->Servers->your_server->Configuration->Tuning->Stuck Thread Max Time

如下图：


2）怎样增大线程数



window环境下修改【bea】\user_projects\domains\my_domain\bin\setDomainEnv.cmd文件，查询最下面set JAVA_OPTIONS=%JAVA_OPTIONS%

改为：

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MinPoolSize=50
set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MaxPoolSize=300



同时发现了一篇好文章：weblogic10.3优化设置  http://wenku.baidu.com/view/c42e7a5bbe23482fb4da4cf2.html

使用Weblogic版本：Weblogic 11g(10.3.6)

设置Weblogic的线程数有两种方法，

第一种，通过启动参数设置：

-Dweblogic.threadpool.MinPoolSize=1000 -Dweblogic.threadpool.MaxPoolSize=1000

 

可以加在setDomainEnv.sh文件JAVA_OPTIONS下面；

第二种，通过config.xml配置文件：

<server>
    <name>AdminServer</name>
    <self-tuning-thread-pool-size-min>1000</self-tuning-thread-pool-size-min>
    <self-tuning-thread-pool-size-max>1000</self-tuning-thread-pool-size-max>
</server>

 

 

Window环境下设置完应该直接重新启动就可以生效，Linux下，有可能会出现以下错误：


Attempting to allocate 4G bytes

There is insufficient native memory for the Java
Runtime Environment to continue.

Possible reasons:
  The system is out of physical RAM or swap space
  In 32 bit mode, the process size limit was hit

Possible solutions:
  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Disable compressed references (-XXcompressedRefs=false)

java.lang.OutOfMemoryError: Resource temporarily unavailable in tsStartJavaThread (lifecycle.c:1097).

Attempting to allocate 4G bytes

There is insufficient native memory for the Java
Runtime Environment to continue.

Possible reasons:
  The system is out of physical RAM or swap space
  In 32 bit mode, the process size limit was hit

Possible solutions:
  Reduce memory load on the system
  Increase physical memory or swap space
  Check if swap backing store is full
  Use 64 bit Java on a 64 bit OS
  Decrease Java heap size (-Xmx/-Xms)
  Decrease number of Java threads
  Decrease Java thread stack sizes (-Xss)
  Disable compressed references (-XXcompressedRefs=false)

 

出现这个原因的问题可能是因为Linux下系统对用户的默认线程数做了限制，可以通过：

ulimit -a

 

命令进行查看：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 515223
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

 

其中

max user processes              (-u) 1024

 

表示当前系统允许的最大线程数，可以把此参数设大一些。

ulimit -u 5000

 

设置当前系统用户最大允许的线程数，只对本次会话有效，如果想要永久生效，可以通过修改：

$ cat /etc/security/limits.d/90-nproc.conf 
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.

*          soft    nproc    1024

 

只需要将1024改成你需要的值即可，设置完需要重启系统已生效。

 

最后欢迎大家访问我的个人网站：1024s

weblogic最大线程

 定义或什么是缠线？ 
 
 如果线程 在设定 的时间 内连续工作（非空闲），则WebLogic Server会将其诊断为阻塞 。 

 您可以通过更改在诊断出线程被阻塞之前的时间长度（ Stuck Thread Max Time ），以及通过更改服务器检查线程是否被阻塞的频率，来调整服务器的线程检测行为。 在此处查看如何更改“粘线最大时间”。 
 问题还是为什么“粘线”是邪恶的？ 
 
 WebLogic Server自动检测执行队列中的线程何时变为“阻塞”状态。 由于卡住的线程无法完成其当前工作或接受新工作，因此服务器每次诊断出卡住的线程时都会记录一条消息。 如果执行队列中的所有线程都卡住，服务器将根据执行队列将其运行状况更改为“警告”或“严重”： 

 如果默认队列中的所有线程都卡住，则服务器会将其运行状况更改为“ 严重” 。 （您可以将Node Manager应用程序设置为在严重运行状态下自动关闭和重新启动服务器。有关更多信息，请参阅“配置和管理WebLogic Server”中的“ Node Manager功能 ”。） 
 如果weblogic.admin.HTTP，weblogic.admin.RMI或用户定义的执行队列中的所有线程都卡住了，则服务器会将其运行状况更改为“ 警告” 。 

 因此，实际上，几个“阻塞线程”可能不会使服务器崩溃，从而阻止服务器处理请求，但这是一个不好的信号。 通常，卡住的线程数将增加，并且服务器最终将崩溃。 
 为避免应用程序完全失败该怎么办？ 
 
 WebLogic Server会定期检查卡住的线程（这是“ 卡住线程计时器间隔” ，您可以在此处进行调整）。 如果所有应用程序线程都卡住，则服务器实例将自身标记为失败，如果配置为失败，则退出。 您可以配置节点管理器或第三方高可用性解决方案以重新启动服务器实例以进行自动故障恢复。您可以将以下操作配置为在并非所有线程都卡住但卡住的线程数超过配置的阈值时发生：如果工作管理器卡住了线程，请关闭它。 关闭的工作管理器将通过发送拒绝消息来拒绝新工作并拒绝队列中的现有工作。 在群集中，群集客户端将故障转移到另一个群集成员。 

 如果应用程序中存在线程阻塞，请关闭应用程序。 通过使其进入管理模式来关闭该应用程序。 属于该应用程序的所有工作管理器都将关闭，并按上述方式运行。 
 将服务器实例标记为失败，如果服务器中存在线程阻塞，则将其关闭。 在群集中，已连接或尝试连接的群集客户端将故障转移到另一个群集成员。 

 如何识别问题？ 
 
 推荐的方法是检查线程转储。 选中“ 发送电子邮件警报以查找有关带有线程转储的线程卡住的中间件魔术文章” ，使线程转储在发生时自动发送给您。 
 帮助您分析线程转储的工具有： 

 TDA –线程转储分析器 
 武士 

 如何解决该问题？ 
 
 确定导致卡住线程的代码（即执行所花费的时间超过堆栈线程的最大时间）后，可以使用工作管理器执行代码。 工作管理器具有“忽略卡住线程”选项，该选项使您能够执行长时间运行的作业。 见下文： 
  
 以下是有关如何创建工作管理器的一些帖子 

 https://blogs.oracle.com/jamesbayer/entry/work_manager_leash_for_slow_js 
 http://jdeveloperfaq.blogspot.com/2011/05/faq-34-using-weblogic-work-managers-to.html 

 测试：如何创建卡死线程？ 
 
 如何创建“卡住线程”以测试您的weblogic设置？ 将断点放在请求所调用的支持bean或模型方法中。 如果您在断点处等待“最大线程停留时间”，则会注意到服务器日志中将显示“线程滞留”跟踪： 
<16 =?? 2011 12:28:22 ?? EET><Error><WebLogicServer><BEA-000337><[STUCK] ExecuteThread: '2' for queue: 
'weblogic.kernel.Default (self-tuning)' has been busy for "134" seconds working on the 
request "weblogic.servlet.internal.ServletRequestImpl@6e6f4718[
GET /---/---/----/---/days.xhtml HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.120 Safari/535.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=DYG5TDTZSnKLTFw5CMMdLCD9sPsZS4Jqlmxj9wdGNyt1BnPcfNrR!-1520792836




]", which is more than the configured time (StuckThreadMaxTime) of "60" seconds. Stack trace:
       --------------------------------------------(--------------------.java:83)
       javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:823)
       com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:285)
       com.sun.faces.renderkit.html_basic.GridRenderer.renderRow(GridRenderer.java:185)
       com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:129)
       javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:848)
       org.primefaces.renderkit.CoreRenderer.renderChild(CoreRenderer.java:55)
       org.primefaces.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:43)
       org.primefaces.component.fieldset.FieldsetRenderer.encodeContent(FieldsetRenderer.java:95)
       org.primefaces.component.fieldset.FieldsetRenderer.encodeMarkup(FieldsetRenderer.java:76)
       org.primefaces.component.fieldset.FieldsetRenderer.encodeEnd(FieldsetRenderer.java:53)
       javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:878)
       javax.faces.component.UIComponent.encodeAll(UIComponent.java:1620)
       javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
       javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:848)
       org.primefaces.renderkit.CoreRenderer.renderChild(CoreRenderer.java:55)
       org.primefaces.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:43)
       org.primefaces.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:229)
       org.primefaces.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:152)
 更多挖掘： 

 弗兰克·芒茨（Frank Munz）的精彩文章： WebLogic卡住了线程：创建，理解和处理它们 。 已针对Weblogic 12c更新。 还包括用于创建“粘滞线程”的示例应用程序。 
 http://stackoverflow.com/questions/2709410/weblogic-stuck-thread-protection 

 src： 

 Maxence Button的精彩文章： http : //m-button.blogspot.com/2008/07/using-wlst-to-perform-regular.html 
 http://download.oracle.com/docs/cd/E13222_01/wls/docs81/perfor/WLSTuning.html#1125714 
 http://download.oracle.com/docs/cd/E21764_01/web.1111/e13701/overload.htm 
 http://java.sys-con.com/node/358060?page=0,0 

 参考：在ADF和Weblogic How To博客上， 与我们的JCG合作伙伴 Spyros Doulgeridis 处理Weblogic的粘滞线程 。 


翻译自: https://www.javacodegeeks.com/2012/05/dealing-with-weblogic-stuck-threads.html
weblogic最大线程

    

一、背景 
最近负责做一个平台的poc测试，性
能测试要求测试1000并发下平台的表现，web服务器采用的是weblogic，版本是11g，10.3.6，所有操作都是基于这个版本（因为以前修改
线程数的操作有些基于这个版本不能生效）。在LoadRunner压1000并发下，发现应用表现并不好，响应时间明显增加。
二、分析   
监
控服务器资源，发现集群平台服务器负载并不高，而web应用服务器负载同样也不高，服务器性能并没达到瓶颈。进入weblogic控制台，查看线程池，发
现在压1000并发的时候，请求积压队列明显较多，而线程数只有50左右。说明一下，weblogic产品模式下，默认初始线程数为25，开发模式下好像
是15，weblogic11g采用的是自调整线程池，看名字就可以猜出，他会根据应用情况自动增加减少线程数，而实际情况下，在压力增大的情况
下，weblogic也确实增加了线程数，但是增加的线程数不足以应付该需求，于是自然而然地想到了增加线程数。
三、解决   
weblogic11g已经不支持在控制台修改线程数，只能通过配置文件，网上有朋友说可以通过增加weblogic启动参数来配置线程数:    
-Dweblogic.threadpool.MinPoolSize=100    
-Dweblogic.threadpool.MaxPoolSize=500    
该方法经试验，并不能生效，还好还一种方法，修改域下面conf里面的config.xml文件：    
<server>    
<name>AdminServer</name>    
<self-tuning-thread-pool-size-min>400</self-tuning-thread-pool-size-min>    
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max>    
<listen-address/>    
</server>    
在
这里把线程数最大值最小值都设成了400，400这个数值不是乱设的，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就
越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。一般来说一个CPU最好小于50个线程数（注：笔者刚才
发现之前我把CPU数当成了核心数，笔者用的服务器是24核，所以当时理所当然认为设置1000个线程数也是ok的）。最开始使用1000线程数做测试，
因为最大并发数是1000，笔者想象来一个请求就给一个线程处理，没有请求排队，实际上确实如此，但是把线程数调低后，发现即使有排队情况出现，但响应时
间却比之前1000线程要快，为什么会出现这种情况呢？原来还有一点我们忘记了，数据库连接池。数据库连接池也是影响性能的指标之一，想想应用1000个
请求过来，但是数据库连接数不够，在数据库这边排队，还是会影响整体性能表现，所以如何配置weblogic线程数以及数据库连接线程数使整体性能达到最
优，这需要再仔细测试，如果数据库连接数也能设置到1000，我想应该这是一个比较理想的设置，但很多情况下根据平台不同，不可能这么简单，过高的连接数
总会占用过多系统资源，引发GC等一系列问题。笔者的应用根据多次测试，把数据库连接跟线程数设置成了一样的，都是400，这肯定不是最优的，但应该算是
性能表现比较满意的一组值。
四、总结   
1、出现性能瓶颈时，先找出现瓶颈的地方，是应用服务器还是数据库服务器    
2、判断是否需要修改weblogic线程数以及数据库连接池的值    
3、多次测试，得出一组合适的weblogic线程数的值以及数据库连接数的值



转载于:https://www.cnblogs.com/atwanli/articles/4906776.html