BEA-000449


-Dweblogic.client.socket.ConnectTimeout=500



The message is a warning and typically has no user impact, thus no action needs to be taken.

Note that there is an option to filter out the 'Closing socket' messages, as described below. But we advise against doing this since there is a small chance that the messages could be indicative of some sort of issue in your environment, therefore it is good to be aware of whether these messages are logged and the frequency at which they are logged. However, if still choose to filter out the messages, you can do so as follows:

Log into WebLogic Admin console
Click the 'Lock & Edit' button on left menu

First, add the log filter:

a. Click on your PeopleSoft Domain Name (on left menu in the 'Domain Structure' section)

b. Go to 'Configuration' tab and 'Log Filters' subtab

c. Click 'New' button to create a new filter

d. Give any name to your new log file (eg "LogFilter-ClosingSocket'

e. Click 'OK'

f. Now click on the hyperlink for the newly created filter and in the 'Current Log Filter Expressions', click edit button to add the following: NOT(MESSAGE LIKE 'Closing socket as no data read from it%')

g. Save the change h. Click 'Activate Changes' button on left menu


4. Now assign the filter to the server

a. On left menu, choose Environment->Servers
b. On right menu, click the hyperlink for server you wish to update (eg 'PIA')
c. Choose 'Logging' tab and 'General' subtab
d. Go to bottom of page and click 'Advanced' hyperlink
e. Click 'Lock & Edit button
f. In the 'Logging' section, add the new filter that you created (in step 3 above)

g. Also add the filter to the 'Standard out' section (so that message is not logged to PIA_weblogic.log nor the stdout/ntservice log)

h. Save the change

i. Click 'Activate Changes' button on left menu
### WebLogic Server 中 `java.lang.OutOfMemoryError: GC overhead limit exceeded` 的解决方案 在运行 WebLogic Server 时,如果遇到 `java.lang.OutOfMemoryError: GC overhead limit exceeded` 错误,这表明 JVM 在尝试回收内存时花费了过多时间,但释放的内存却非常有限。该错误通常出现在堆内存不足、对象分配过快或存在内存泄漏的情况下。 #### 常见原因分析 - **堆内存配置不足**:JVM 分配的初始堆(`-Xms`)和最大堆(`-Xmx`)设置过小,无法满足应用程序的需求。 - **频繁 Full GC**:大量不可达对象导致频繁 Full GC,而回收后仍不足以容纳新对象。 - **内存泄漏**:程序中存在未被释放的对象引用,导致堆内存持续增长。 - **大对象分配**:一次性创建非常大的对象,GC 回收后的空闲内存不足以容纳该对象[^5]。 #### 解决方案 ##### 1. 调整 JVM 内存参数 确保 `-Xms` 和 `-Xmx` 设置合理,并保持一致以避免动态调整带来的性能开销: ```bash JAVA_OPTIONS="-Xms4g -Xmx4g -XX:MaxPermSize=512m" ``` 此外,可以适当增加老年代空间,防止频繁触发 Full GC: ```bash JAVA_OPTIONS="$JAVA_OPTIONS -XX:NewRatio=3" ``` ##### 2. 更换垃圾回收器 默认使用 Parallel Scavenge 收集器可能会加剧 GC Overhead Limit Exceeded 异常。建议切换为 CMS 或 G1 收集器以优化低延迟场景下的表现: 使用 CMS(Concurrent Mark Sweep)收集器: ```bash JAVA_OPTIONS="$JAVA_OPTIONS -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled" ``` 使用 G1(Garbage First)收集器(适用于 Java 7 及以上): ```bash JAVA_OPTIONS="$JAVA_OPTIONS -XX:+UseG1GC -XX:MaxGCPauseMillis=200" ``` ##### 3. 禁用 GC Overhead Limit 检查(不推荐) 虽然可以通过添加以下 JVM 参数来禁用该限制检查,但这只是掩盖问题而非根本解决: ```bash JAVA_OPTIONS="$JAVA_OPTIONS -XX:-UseGCOverheadLimit" ``` 应优先排查内存泄漏或优化代码逻辑,而不是简单地跳过异常[^4]。 ##### 4. 使用内存分析工具进行诊断 利用工具如 **VisualVM**、**MAT (Memory Analyzer Tool)** 或 **JProfiler** 对堆内存进行快照分析,识别占用内存最多的对象及其引用链,从而发现潜在的内存泄漏点。 ##### 5. 优化代码逻辑 - 避免一次性加载大量数据到内存,改用分页读取或流式处理。 - 减少不必要的对象创建,复用已有对象。 - 清理不再使用的缓存和集合类,及时将其置为 `null`。 - 检查是否有静态集合类长期持有对象引用。 ##### 6. 监控与日志分析 通过 APM 工具(如 New Relic、AppDynamics)监控 WebLogic Server 的 JVM 内存使用情况及 GC 行为。结合 GC 日志分析工具(如 GCViewer、GCEasy)进一步定位瓶颈所在。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值