2017-04-24 12 views
0

응용 프로그램의 알 수없는 부분에서 상당히 이상한 동작이 발생합니다.Django가 FreeTDS를 사용하여 SQL Server에서 서비스 거부가 발생했습니다.

내 설정 :

  • 장고
  • FreeTDS를
  • 인 unixODBC
  • 장고 - pyodbc - 푸른
  • MS SQL

응용 프로그램은 겉으로는 임의 시간 동안 작동합니다 시간 (일반적으로 2-3 분)이 지나면 응답을 멈추고 SQL Server가 될 것입니다. 다른 계정을 가진 다른 응용 프로그램도 데이터베이스에 대한 요청을 수행 할 수 없습니다.

내 측면의 명시 적 요청 수는 ditaly 응용 프로그램의 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와 응용 프로그램과 데이터베이스간에 미친 양의 패킷이 이동하는 것을 볼 수 있습니다 (간단한 SELECT는 +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] 

나는 그것을 종료하는 즉시 모든 사람을위한 DB에 대한 액세스를 복원하기 때문에 응용 프로그램이 서비스 거부의 원인 알고있다.

SELECT DB_NAME(dbid) AS DBName, 
COUNT(dbid) AS NumberOfConnections, loginame 
FROM sys.sysprocesses 
GROUP BY dbid, loginame 
ORDER BY DB_NAME(dbid) 

하나의 연결 만이 나열됩니다

사용하여 활성 연결을 나열합니다.

쉽게 설명 할 수있는 루프가 없습니다.

+0

몇 가지 아이디어 : SSMS에서 SQL Server Activity Monitor를 가져 와서 응용 프로그램을 가져 와서 실제로 수행중인 내용을 확인하면서 실시간으로 쿼리를 보았습니까? 블로킹 프로세스가 있는지보기 위해 SQL Server에서'sp_who2'를 사용해 보셨습니까? 이것은 문제를 삼각형 화하는 것을 도울 것입니다. 또한, dev 인스턴스의 Django Debug Toolbar는 페이지 당 생성되는 쿼리를 표시 할 수 있습니다. – FlipperPA

답변

1

우리는 함수 내에서 db 연결을 사용했는지 여부에 관계없이 풀을 사용할 때 문제가 발생한다는 것을 발견했습니다. 처리 된 여러 자식 만들기가 문제의 원인이었습니다. 이를 해결하기 위해서는 프로세스를 포크하기 전에 간단히 connection.close()을 사용하십시오.