目前在 CAS Node 项目中,基本上都是用的这个 ORM 来和 MSSQL 进行交互访问,如果没有高并发访问冲击的情况下,一般使用这个 ORM 第三库不会出现什么性能问题。但是遇到需要频繁操作 DB ,就可能会做成生产环境上面 DB DTU HIGH 的行为。
100% DTU Usage
架构图一览
目前 CAS 处理 ATP DP Policy Detection Mail 架构图如下所示:
##
问题定位
我们目前使用的是 Azure MSSQL DB,生产环境中从它自带的监控后台我们可以查看到每个语句的查看次数以及那些语句导致了 High DTU 的问题。
初定位
根据 OP 同学的给出的反馈,我们发现到线上有一个查询语句时间过长,在此时间点 DB 的 DTU 也非常高,这时候我们怀疑是这条语句导致的。
1
(@1 varchar(8000))SELECT [NTF_ADMIN_SUBJECT],[NTF_TO_ACCOUNT],[NTF_ADMIN_MESSAGE],[NTF_ADMIN_NOTIFY_SETTING_TYPE],[NTF_ADMIN_INTERVAL_TYPE],[NTF_ADMIN_INTERVAL_NUM],[NTF_ADMIN_OCCURENCE_NUM],[NTF_EVENTS_OCCURENCE_NUM] FROM [tm_atp_dp_notification] WHERE [cfg_index]=@1
平均耗 CPU 最多的前个 SQL (SQL SERVER 2005或以上版本) USE [tmcas-dev] GO
SELECT TOP 5 total_worker_time / execution_count AS [Avg CPU Time], SUBSTRING(st.text, (qs.statement_start_offset/2)+1, ((CASE qs.statement_end_offset WHEN-1THENDATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) AS statement_text FROM sys.dm_exec_query_stats AS qs CROSSAPPLY sys.dm_exec_sql_text(qs.sql_handle) AS st ORDERBY total_worker_time/execution_count DESC
/* Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT Licence. This sample demonstrates how the send() function can be used to send messages to Service Bus Queue/Topic. See https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions to learn about Queues, Topics and Subscriptions. */
// If sending to a Topic, use `createTopicClient` instead of `createQueueClient` const queueClient = sbClient.createQueueClient("cas-notification-queue"); const sender = queueClient.createSender();
try { for (let index = 0; index < 1000; index++) { const scientist = listOfScientists[0]; const message = { body: scientist, };