우리는 다음 서버 사양으로 SQL Server 2019 (Linux) CU4를 실행하고 있습니다.
- 운영 체제: Centos 8
- 메모리: 32GB
- 하드 드라이브: 1TB 솔리드 스테이트 드라이브
- CPU: 8코어 I-7
- SQL: Linux(CentOS Linux 8(코어))의 Microsoft SQL Server 2019(RTM-CU4)(KB4548597) - 15.0.4033.1(X64) Standard Edition(64비트)
과부하 후 SQL 서버가 응답하지 않는 것처럼 보였으며 충돌 후 SQLDump 파일에 다음 내용이 포함되었습니다.
2020-04-09 02:38:11.48 spid12s AppDomain 3 (mssqlsystemresource.dbo[runtime].2) is marked for unload due to memory pressure.
2020-04-09 02:38:11.48 spid12s AppDomain 3 (mssqlsystemresource.dbo[runtime].2) unloaded.
2020-04-09 10:09:43.60 spid31s AppDomain 2 (master.sys[runtime].1) is marked for unload due to memory pressure.
2020-04-09 10:09:43.61 spid31s AppDomain 2 (master.sys[runtime].1) unloaded.
2020-04-10 11:52:15.26 Backup Database backed up. Database: readyalert, creation date(time): 2020/02/11(08:19:22), pages dumped: 190987, first LSN: 67110:336:1, last LSN: 67110:360:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'/var/opt/mssql/backup/readyalert_prod.BAK'}). This is an informational message only. No user action is required.
2020-04-10 11:52:15.28 Backup BACKUP DATABASE successfully processed 190746 pages in 4.842 seconds (307.765 MB/sec).
2020-04-12 00:00:02.54 spid59 [8]. Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-04-12 00:00:12.34 spid59 DBCC CHECKDB (readyalert) executed by NT AUTHORITY\NETWORK SERVICE found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 9 seconds. Internal database snapshot has split point LSN = 00010627:00010e78:0001 and first LSN = 00010627:00010e68:0001.
2020-04-15 11:12:58.53 spid59 AppDomain 4 (mssqlsystemresource.dbo[runtime].3) created.
2020-04-15 11:16:28.21 spid88 AppDomain 5 (master.sys[runtime].4) created.
2020-04-15 14:39:02.71 Server Using 'dbghelp.dll' version '4.0.5'
2020-04-15 14:39:02.76 Server ***Unable to get thread context for spid 0
2020-04-15 14:39:02.76 Server * *******************************************************************************
2020-04-15 14:39:02.76 Server *
2020-04-15 14:39:02.76 Server * BEGIN STACK DUMP:
2020-04-15 14:39:02.76 Server * 04/15/20 14:39:02 spid 384
2020-04-15 14:39:02.76 Server *
2020-04-15 14:39:02.76 Server * Non-yielding Scheduler
2020-04-15 14:39:02.76 Server *
2020-04-15 14:39:02.76 Server * *******************************************************************************
2020-04-15 14:39:02.77 Server Stack Signature for the dump is 0x0000000000000338
최신 CU4로 업데이트하려고 하는데 문제가 계속 발생하므로 도움을 주시면 감사하겠습니다.
답변1
우리의 해결책은 노드 간 데이터베이스 동기화를 비활성화하는 것이었습니다. Microsoft는 별도의 스레드에서 실행될 수 있으므로 트랜잭션을 사용하여 데이터를 동기화하고 트랜잭션을 주 서버와 잠글 수 있습니다. 따라서 경주 조건과 궁극적으로 양보하지 않음
최신 15.0.4043.16-4
2020-07-06 13:04:01.87 Server Using 'dbghelp.dll' version '4.0.5'
2020-07-06 13:04:01.96 Server ***Unable to get thread context for spid 0
2020-07-06 13:04:01.96 Server * *******************************************************************************
2020-07-06 13:04:01.96 Server *
2020-07-06 13:04:01.96 Server * BEGIN STACK DUMP:
2020-07-06 13:04:01.97 Server * 07/06/20 13:04:01 spid 400
2020-07-06 13:04:01.97 Server *
2020-07-06 13:04:01.97 Server * Non-yielding Scheduler
2020-07-06 13:04:01.97 Server *
2020-07-06 13:04:01.97 Server * *******************************************************************************
2020-07-06 13:04:01.98 Server Stack Signature for the dump is 0x0000000000000246
2020-07-06 13:04:55.94 Server DumpCallbackHk::CreateCabFile: at 2206 g_CabDdfFile file is null, normally because no collectors added any files, exiting
2020-07-06 13:04:55.94 Server DumpCallbackHk::CollectFiles: at 594 failed at CreateCabFile with error: 0x80004005
2020-07-06 13:04:57.21 Server External dump process return code 0x20000001.
External dump process returned no errors.
2020-07-06 13:04:57.21 Server Process 0:0:0 (0x4298) Worker 0x0000001D4CE46160 appears to be non-yielding on Scheduler 0. Thread creation time: 13238513480709. Approx Thread CPU Used: kernel 130 ms, user 7180 ms. Process Utilization 16%. System Idle 0%. Interval: 70006 ms.
...