关于 Dead Connection Detection, Resource Limits, V$SESSION, V$PROCESS and OS processes ( 601605.1)

本文探讨了Oracle数据库中Dead Connection Detection (DCD) 的作用及其与用户配置文件中的资源限制相结合的效果。DCD用于清理异常终止的连接,而资源限制则针对超出设定阈值的会话进行管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Applies to:

Oracle Database - Enterprise Edition - Version 8.0.3.0 and later
Oracle Net Services - Version 9.2.0.1 and later
Information in this document applies to any platform.

Goal

Discuss what can be expected when implementing Dead Connection Detection (DCD) along with Database Resource Limits with user Profiles, inactive sessions and the effects on V$SESSION, V$PROCESS and OS processes

Solution

Dead Connection Detection (DCD)

These are previously valid connections with the database but the connection between the client and server processes has terminated abnormally.
Examples of a dead connection:
- A user reboots/turns-off their machine without logging off or disconnecting from the database.
- A network problem prevents communication between the client and the server.

In these cases, the shadow process running on the server and the session in the database may not terminate.

Implemented by
      * adding SQLNET.EXPIRE_TIME = <MINUTES> to the sqlnet.ora file

With DCD is enabled, the Server-side process sends a small 10-byte packet to the client process after the duration of the time interval specified in minutes by the SQLNET.EXPIRE_TIME parameter.

If the client side connection is still connected and responsive, the client sends a response packet back to the database server, resetting the timer..and another packet will be sent when next interval expires (assuming no other activity on the connection).

If the client fails to respond to the DCD probe packet
     * the Server side process is marked as a dead connection and
     * PMON performs the clean up of the database processes / resources
     * The client OS processes are terminated

NOTE: SQLNET.RECV_TIMEOUT can be set on the SERVER side sqlnet.ora file. This will set a timeout for the server process
                 to wait for data from the client process.

Inactive Sessions:

These are sessions that remain connected to the database with a status in v$session of INACTIVE.
Example of an INACTIVE session:
- A user starts a program/session, then leaves it running and idle for an extended period of time.


Database Resource Limits (using user profiles)

Implemented by
     * Setting RESOURCE_LIMIT = TRUE in the database startup parameter file (spfile or pfile)
     * Creating or modifying existing user profiles (DBA_PROFILES) to have one or more resource limit
     * Assigning a profile to a user whose resources are wished to be limited

It could happen that if the idle_time has been set on the DEFAULT profile, this can lead to an MTS dispatchers being set to 'sniped' and then getting 'cleaned up' via the shell script. The removal of the dispatcher will result in other sessions 'dying' .In that case, If you are to implement resource limits, may be advisable to create new profiles
that be assigned to users and not to change the characteristics of DEFAULT.
Alternatively, if you do change DEFAULT, ensure that all the properties that you
have affected have been fully tested in a development environment.

When a resource limit is exceeded (for example IDLE_TIME) ... PMON does the following
     * Mark the V$SESSION as SNIPED
     * Clean up the database resources for the session
     * Remove the V$SESSION entry

It is strongly recommended that both DCD and Resource Limits with Profiles be implemented in order to clean up resources at both the database and OS level

This combination will not clean up IDLE / ABANDONED / INACTIVE connections (OS processes) as these sessions still have active clients

For this case we will see that :
     * PMON has cleaned up the V$SESSION entries .. but both the OS processes and the V$PROCESS entries will still exist
     * SQLNET will continue to be able to send the 10 byte packet successfully until the session is logged off

This condition can be a major problem as
     * The database exhausts PROCESSES and gives ORA-20 maximum number of processes <num> exceeded
     * The OS can become exhausted due to the unneeded resources consumed by the abandoned processes

The SYMPTOMS of this condition are
     * The database view V$PROCESS will have no corresponding V$SESSION entry
     * An OS process / thread still exists for the SNIPED session

The solutions to this scenario can are to cleanup the OS processes ... after which the $PROCESS entries should be removed automatically

Methods to cleanup OS processes:

     * UNIX : kill -x ... the OS process at the OS level (typically kill -9)
     * UNIX:  if using a dedicated server, use the following shell script to kill the shadow process (script has been tested on Solaris, AIX, Tru64 and  HPUX):
#!/bin/sh
tmpfile=/tmp/tmp.$$
sqlplus system/manager <<EOF
spool $tmpfile
select p.spid from v\$process p,v\$session s
where s.paddr=p.addr
and s.status='SNIPED';
spool off
EOF
for x in `cat $tmpfile | grep "^[0123456789]"`
do
kill -9 $x
done
rm $tmpfile

NOTE: If you are running in a shared server environment, you need to be careful not to accidentally kill your dispatchers and/or shared servers. In Oracle 10.2 (or higher) a dedicated connections V$SESSION + V$PROCESS + OS Process can be cleaned up with
ALTER SYSTEM DISCONNECT SESSION '<SID>,<SERIAL>' IMMEDIATE
At this point in versions prior to 10.2 and for shared server connections the only solution is to kill the session at the OS level (see Kill and ORAKILL above)
     * Windows : use the orakill command .... orakill <ORACLE SID> <Thread ID> (see Note 69882.1 for details)

On occasions we see conditions where a database session has a V$SESSION.STATUS = SNIPED ... and the entry never goes away . This condition can be achieved by implementing Database Resource Limits + Profiles without DCD and allow the database session to exceed the limit in the profile


Summary of what was discussed here:

1) DCD initiates clean up of OS and database processes  that have disconnected / terminated abnormally
2) DCD will not initiate clean up sessions that are still connected ... but are idle / abandoned / inactive
3) Database Resource Limits + user Profiles clean up database resources for user sessions that exceed resource limits
4) Database Resource Limits + user Profiles will not clean up OS processes
5) If DCD and Database Resource Limits + user Profiles are used in combination .. Dead Connections OS and Database Resources will be cleaned up
6) IDLE / ABANDONED / INACTIVE sessions OS processes will not be cleaned up even if DCD and Database Resource Limits + user Profiles are used in combination ... these must be cleaned up manually

<think>好的,我现在需要解决用户在Mininet中设置资源限制时出现的错误。用户提到参考了三个引用,但看起来这些引用可能和MySQL、防火墙设置、数据库实例升级有关,可能与Mininet的问题关联不大。不过,我需要先理解Mininet的资源限制错误通常是什么原因导致的。 首先,Mininet在启动时可能会设置一些系统资源限制,比如最大进程数、文件描述符数量等。如果这些限制设置失败,可能导致错误。常见的错误信息可能包括“RTNETLINK answers: Operation not permitted”或者与ulimit相关的错误。用户可能尝试通过修改系统配置文件来调整这些限制,但方法不正确导致问题。 接下来,我应该考虑可能的解决方案。比如检查用户是否有足够的权限,可能需要使用sudo运行Mininet。然后,检查系统的资源限制配置文件,如/etc/security/limits.conf,确保相关限制设置正确。另外,Mininet本身可能有一些参数可以调整资源限制,比如在启动拓扑时使用--ulimit参数。 还需要考虑系统的其他限制,比如cgroups或者systemd的配置是否影响了资源限制的设置。用户可能在虚拟化环境中运行Mininet,比如在虚拟机或容器中,这时宿主机的限制也需要调整。此外,SELinux或AppArmor等安全模块可能阻止资源限制的修改,需要检查日志确认是否有相关拒绝信息。 然后,根据用户提供的引用内容,引用[1]提到在limits.conf中设置用户的限制,这可能适用于Mininet的情况,因为可能需要调整open files或nproc的值。引用[2]提到的防火墙设置可能不相关,但如果有连接超时问题,可能需要检查网络配置。引用[3]关于数据库实例的升级设置可能不适用,但可以忽略。 总结可能的解决步骤:1. 使用sudo权限运行Mininet;2. 修改/etc/security/limits.conf文件,增加用户限制;3. 调整系统级的sysctl参数;4. 检查安全模块的设置;5. 使用Mininet的参数调整资源限制。同时,需要验证这些步骤是否有效,并处理可能出现的其他问题,比如重启服务或重新登录用户使配置生效。 最后,需要将这些步骤以清晰的中文回答呈现,确保用户能够逐步操作,并生成相关问题帮助用户进一步排查问题。</think>### Mininet设置资源限制错误的解决方案 当Mininet出现`error setting resource limits`错误时,通常与系统资源限制(如最大进程数、文件描述符数量等)配置不足或权限问题相关。以下是分步解决方案: --- #### **1. 检查权限并尝试以root权限运行** Mininet需要修改系统资源限制,因此需确保使用`sudo`运行: ```bash sudo mn # 以root权限启动Mininet ``` 若仍报错,可能是系统级限制未正确配置。 --- #### **2. 修改系统资源限制文件** 编辑`/etc/security/limits.conf`文件,添加以下配置以放宽限制[^1]: ```bash sudo nano /etc/security/limits.conf ``` ```conf * soft nofile 65535 # 最大文件描述符数量 * hard nofile 65535 * soft nproc 65535 # 最大进程数 * hard nproc 65535 ``` 保存后**重启系统**或**重新登录用户**使配置生效。 --- #### **3. 调整系统内核参数** 修改`/etc/sysctl.conf`以优化网络相关限制: ```bash sudo nano /etc/sysctl.conf ``` ```conf fs.file-max = 2097152 # 全局文件描述符上限 net.core.somaxconn = 65535 # TCP连接队列长度 net.ipv4.neigh.default.gc_thresh3 = 4096 ``` 执行以下命令应用修改: ```bash sudo sysctl -p ``` --- #### **4. 检查安全模块限制** - **SELinux/AppArmor**:临时禁用测试是否解决问题: ```bash sudo setenforce 0 # 临时禁用SELinux sudo systemctl stop apparmor # 停止AppArmor ``` 若问题解决,需调整安全策略或添加例外规则。 - **cgroups限制**:若使用容器或虚拟化环境,检查宿主机的cgroups配置。 --- #### **5. 使用Mininet参数调整资源** 启动Mininet时显式指定资源限制: ```bash sudo mn --ulimit -n 65535 # 设置文件描述符数量 ``` --- #### **6. 验证资源限制** 通过以下命令验证当前用户的限制是否生效: ```bash ulimit -n # 查看文件描述符限制 ulimit -u # 查看最大进程数 ``` --- ### 常见错误场景与修复 - **错误示例**:`RTNETLINK answers: Operation not permitted` **原因**:权限不足或内核参数限制。 **解决**:使用`sudo`运行,并检查`/etc/sysctl.conf`中的`net.core.somaxconn`值。 - **错误示例**:`error: [Errno 24] Too many open files` **原因**:文件描述符限制过低。 **解决**:修改`limits.conf`并重启系统。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值