案例：troubleshooting Connection is Slow using SCAN LISTENER

本案例来自西区某客户，数据库版本12.2。客户故障现象为连接local vip正常，但是连接scan vip就异常缓慢甚至超时。严重影响到了业务的连接。

话不多说，遇到这种问题不管三七二十一先strace跟踪一把

可以看到此次连接运气很差，达到了sqlnet.inbound_connect_timeout默认的60s，都无法获取到socket，所以连接超时。

再试一次，这次运气比较好，能连接上，但是获取socket仍然花了近15s。

分析网络相关问题，还是老办法先看看网卡的TX errors 、dropped 、overruns，发现无明显异常后，通过watch结合netstat分析故障时刻的各项统计指标增长。

可以发现times the listen queue of a socket overflowed一直在增长，说明存在全连接队列溢出。

通过ss命令查看scanip(xxx.xxx.xxx.47)对应的RECV-Q溢出了，在LISTEN状态下RECV-Q就代表全队列，可以看到此时全队列最大长度为128。当前长度为129，说明大量连接已经完成了TCP三次握手正在等待服务端accept() ，但由于连接风暴监听过于繁忙或者系统负载过高来不及处理。

此时看看监听日志是否存在连接风暴，发现几个小时的监听日志，连接并不多，并且tail发现当前的监听日志也并没有大量的连接进来，这就有点奇怪了。

莫非有一些非数据库连接在一直连接scanip吗?比如频繁的telnet scanip。

尝试调整一些TCP参数包括增加全队列长度，仍然没有效果，发现全队列长度仍然为128，后续通过查看资料才发现全队列长度并不止取决于net.core.somaxconn，而是取决于 somaxconn 和 backlog 之间的最小值，也就是 min(somaxconn, backlog)，backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小。

回顾监听的工作原理，也有可能是大量的连接全在全队列上直到被丢弃都无法通过等待到服务器accept()，这种情况的连接风暴监听日志是分析不出来的。

监听工作原理大致如下：

1) 首先客户端向监听进程发起数据库连接请求。这个过程又分为两个步骤：
a) 通过三次握手机制建立 TCP 连接。这一步一般来说比较快，只是在客户端操作系统与监听所在操作系统内核之间的交互过程，不涉及到监听进程。
b) 监听进程接受客户端的连接。在客户端发起数据库连接请求这一过程中，如果监听进程太忙，则在建立 TCP 连接之后，需要等待一段时间，监听进程才能真正地接受连接请求，监听进程接受连接将使用操作系统调用 accept。
2) 监听进程 fork 一个子进程，这里我们称为“监听子进程 1”，然后等待子进程退出。在这一步中，如果子进程退出之前所耗的时间越长，那么监听等待的时间也越长，在这个等待过程 中监听不能做任何其他动作。如果子进程异常，不能退出，监听进程将 Hang 住。在一个连接频繁的系统上，我们使用 ps –ef | grep tnslsnr 命令看到的父进程不为 1 的 tnslsnr 进程， 就是这样的子进程。
3) 监听子进程 1 fork 一个子进程，这里我们称为“子进程 2”。
4) 监听子进程 1 完成工作，立即结束。监听进程然后又会一直等待，这里是等待 Oracle Server Process 发送数据过来。
5) 子进程 2 执行系统调用 exec，调用的是 oracle 这个可执行文件，这样这个子进程 2 就变更 为 Oracle Server Process。也就是说，Server Process 与“子进程 2”具有相同的进程号。 Server Process 进行一些初始化操作。
6) Server Process 向监听进程传递一些特定的数据，包括进程号等，典型的数据是“N T P 0 1 9 1 9 0”，这里 19190 为进程号，每个字符用空格分开。
7) 监听进程向 Server Process 发送客户端的连接串数据，这个数据用于 Server Process 验证客户端。然后监听进程向 listener.log 写入日志。这个时候，监听进程的工作就完成了，继续处理下一个连接请求。监听进程能工作到这一步，表明监听并没有被挂起。
8) Server Process 向客户端发送数据，对客户端的连接进行响应。
9) 客户端与 Server Process 之间进行交互，完成连接过程，然后再提交SQL执行真正的工作等等。

直到第7步才会写入监听日志，此时很可能大量的进程都在TCP三次握手成功后，在全队列队列上或者由于全连接队列已满被废弃(由tcp_abort_on_overflow)控制。

通过netstat可以看到scanip上存在大量ESTABLISHED的连接，说明都已经完成了TCP三次握手在等待accept()，并且1s时间内增长了400多个,ip都为10.196.184.83

询问客户和业务厂商，没有人知道这个IP的出处，由于紧急需要恢复所以并没有通过tcpdump去继续深入分析，使用sqlnet黑名单禁用该ip的连接之后，业务连接恢复正常。