这是一个相当奇怪的行为来自应用程序的未知部分。
我的设置:
应用程序将在看似随机的时间(通常为2-3分钟)内工作,然后将停止响应,SQL Server也将如此。其他应用程序甚至与其他帐户无法对数据库进行任何请求。
我在django应用程序的 ready()中的显式请求数为1,以获取一些初始数据。
def ready(self):
from django.conf import settings
from app.models import SomeModel
try:
settings.SomeModel_ID = SomeModel.objects.filter(identifier=settings.SomeIdentifier)[0].pk
except:
settings.SomeModel_ID = SomeModel.objects.create(identifier=settings.SomeIdentifier).pk
SQL Server Tracer会记录一些请求,但没有什么异常(很多BatchStarted / BatchFinished)。
Wireshark看到在应用程序和数据库之间移动的疯狂数据包(我们正在谈论+250用于简单的SELECT)。这里我举了一些TCP的例子但是+ 95%的数据包是TDS。
5422 36.248815392 10.10.10.66 -> 10.10.10.103 TDS 183 TLS exchange
5423 36.249013989 10.10.10.103 -> 10.10.10.66 TDS 135 TLS exchange
5424 36.249427950 10.10.10.66 -> 10.10.10.103 TDS 135 TLS exchange
5425 36.250678349 10.10.10.103 -> 10.10.10.66 TCP 1514 [TCP segment of a reassembled PDU]
5426 36.250703683 10.10.10.103 -> 10.10.10.66 TDS 607 TLS exchange
5427 36.250856893 10.10.10.66 -> 10.10.10.103 TCP 66 1433 → 39348 [ACK]
Seq=2816 Ack=5937 Win=131584 Len=0 TSval=148074754 TSecr=605610420
5428 36.253444263 10.10.10.66 -> 10.10.10.103 TDS 4215 TLS exchange
5429 36.253462203 10.10.10.103 -> 10.10.10.66 TCP 66 39348 → 1433 [ACK]
Seq=5937 Ack=6965 Win=45440 Len=0 TSval=605610421 TSecr=148074754
5430 36.255551301 10.10.10.66 -> 10.10.10.103 TDS 4215 TLS exchange
5431 36.255572551 10.10.10.103 -> 10.10.10.66 TCP 66 39348 → 1433 [ACK]
我知道应用程序是DoS的原因,因为关闭它会立即恢复对每个人的访问权限。
使用以下方式列出活动连接时
SELECT DB_NAME(dbid) AS DBName,
COUNT(dbid) AS NumberOfConnections, loginame
FROM sys.sysprocesses
GROUP BY dbid, loginame
ORDER BY DB_NAME(dbid)
仅列出一个连接。
没有任何类型的循环可以为此提供简单的解释。
答案 0 :(得分:1)
我们发现使用Pool时出现问题,无论我们是否在函数内部使用数据库连接,创建多个子处理都会导致问题。为了解决这个问题,在分配过程之前只需connection.close()
。