这是来自应用程序未知部分的一种相当奇怪的行为
我的设置:
应用程序将工作一段看似随机的时间(通常为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
SQLServerTracer将记录一些请求,但没有异常(相当多的BatchStarted/BatchFinished)
Wireshark可以看到大量的数据包在应用程序和数据库之间移动(简单的选择是+250)。这里我举了一个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的原因,因为关闭它会立即恢复每个人对DB的访问
列出活动连接时使用:
SELECT DB_NAME(dbid) AS DBName,
COUNT(dbid) AS NumberOfConnections, loginame
FROM sys.sysprocesses
GROUP BY dbid, loginame
ORDER BY DB_NAME(dbid)
只列出一个连接
没有任何类型的循环可以对此提供简单的解释
我们发现问题发生在使用池时,不管我们是否在函数中使用db连接,创建多个子进程都是导致问题的原因。要解决这个问题,只需在分叉进程之前
connection.close()
相关问题 更多 >
编程相关推荐