More edits per Anna review
This commit is contained in:
Родитель
f2d9edaf13
Коммит
f87aea5a8a
|
@ -87,7 +87,7 @@ In this activity, you will take a typical workload based on SQL queries and lear
|
|||
|
||||
Using the Azure SQL Database based on the AdventureWorksLT sample, you are given an example workload and need to observe its performance. You are told there appears to be a performance bottleneck. Your goal is to identify the possible bottleneck and identify solutions.
|
||||
|
||||
>**NOTE**: These scripts use the database name **AdventureWorks0406**. Anywhere this database name is used you should substitute in the name of the database you deployed in Module 2.
|
||||
>**NOTE**: Put in your exact database name where you see AdventureWorks`<ID`> in scripts. Anywhere this database name is used you should substitute in the name of the database you deployed in Module 2.
|
||||
|
||||
**Step 1: Setup to monitor Azure SQL Database**
|
||||
|
||||
|
@ -133,10 +133,10 @@ The Azure Monitor Log system requires time to setup and establish logging for a
|
|||
**Step 2: Prepare the workload script**
|
||||
|
||||
Edit the script that runs ostress **sqlworkload.cmd**:<br><br>
|
||||
Substitute your Azure Database Server created in Module 2 for the **-S parameter**<br>
|
||||
Substitute the login name created for the Azure SQL Database Server created in Module 2 for the **-U parameter**
|
||||
Substitute the database you deployed in Module 2 for the **-d parameter**<br>
|
||||
Substitute the password for the login for the Azure SQL Database Server created in Module 2 for the **-P parameter**.
|
||||
- Substitute your Azure Database Server created in Module 2 for the **-S parameter**<br>
|
||||
- Substitute the login name created for the Azure SQL Database Server created in Module 2 for the **-U parameter**<br>
|
||||
- Substitute the database you deployed in Module 2 for the **-d parameter**<br>
|
||||
- Substitute the password for the login for the Azure SQL Database Server created in Module 2 for the **-P parameter**.
|
||||
|
||||
**Step 3: Run the workload and observe performance**
|
||||
|
||||
|
@ -393,7 +393,7 @@ When you view the ALTER DATABASE documentation, notice the ability to click on y
|
|||
Using SSMS, run the script modify_service_objective.sql or T-SQL command:
|
||||
|
||||
```sql
|
||||
ALTER DATABASE AdventureWorks0406 MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
|
||||
ALTER DATABASE AdventureWorks<ID> MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
|
||||
```
|
||||
|
||||
This statement comes back immediately but the scaling of the compute resources take place in the background. A scale this small should take less than a minute and for a short period of time the database will be offline to make the change effective. You can monitor the progress of this scaling activity using the Azure Portal.<br>
|
||||
|
@ -504,7 +504,7 @@ ORDER BY waiting_tasks_count DESC;
|
|||
```sql
|
||||
SELECT io_stall_write_ms/num_of_writes as avg_tlog_io_write_ms, *
|
||||
FROM sys.dm_io_virtual_file_stats
|
||||
(db_id('AdventureWorks0406'), 2);
|
||||
(db_id('AdventureWorks<ID>'), 2);
|
||||
```
|
||||
|
||||
**Step 3 - Prepare the workload script**
|
||||
|
@ -544,7 +544,7 @@ cd c:\users\[vmusername]\sqlworkshops\AzureSQLWorkshop\azuresqlworkshop\04-Perfo
|
|||
Run the workload with the following command
|
||||
|
||||
```Powershell
|
||||
.\order_rating__insert_single.cmd
|
||||
.\order_rating_insert_single.cmd
|
||||
```
|
||||
|
||||
**Step 5 - Observe query requests and duration**
|
||||
|
@ -552,15 +552,13 @@ Run the workload with the following command
|
|||
Using the queries in Step 2 you should observe the following:
|
||||
|
||||
- Many requests constantly have a wait_type of WRITELOG with a value > 0
|
||||
- The WRITELOG wait type is the highest count
|
||||
- The WRITELOG wait type is one of the highest count for wait types.
|
||||
- The avg time to write to the transaction log is somewhere around 2ms.
|
||||
|
||||
The duration of this workload on a SQL Server 2019 instance with a SSD drive is somewhere around 15 seconds. The total duration using this on Azure SQL Database using a Gen5 v8core is around 32+ seconds.
|
||||
|
||||
WRITELOG wait types are indicative of latency flushing to the transaction log. 2ms per write doesn't seem like much but on a local SSD drive these waits may < 1ms.
|
||||
|
||||
TODO: WRITELOG waits sometimes don't show up in Query Store?
|
||||
|
||||
**Step 6 - Decide on a resolution**
|
||||
|
||||
The problem is not a high % of log write activity. The Azure Portal and **dm_db_resource_stats** don't show any numbers higher than 20-25%. The problem is not an IOPS limit as well. The issue is that application requires low latency for transaction log writes but with the General Purpose database configuration a latency. In fact, the documentation for resource limits lists latency between 5-7ms (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vcore-resource-limits-single-databases).
|
||||
|
@ -581,8 +579,6 @@ Now the workload runs in almost 5 seconds compared to even 18-19 seconds with a
|
|||
|
||||
The workload runs so fast it may be difficult to observe diagnostic data from queries used previously in this activity. It is important to note that sys.dm_os_wait_stats cannot be cleared using DBCC SQLPERF as it can be with SQL Server.
|
||||
|
||||
TODO: The first test is interesting. A GP MI with 8 vCore is MUCH SLOWER than GP v8core???? Even with "batched" INSERTs it was 10 seconds. WRITELOG waits can be very bad on MI????
|
||||
|
||||
The concept of "batching" can help most applications including Azure. Read more at https://docs.microsoft.com/en-us/azure/sql-database/sql-database-use-batching-to-improve-performance.
|
||||
|
||||
>**NOTE:** Very large transactions can be affected by resource governance on Azure and the symptoms will be LOG_RATE_GOVERNOR. In this example, the char(500) not null column pads spaces and causes large tlog records. Performance can even be more optimized by making that column a variable length column.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
SELECT<EFBFBD>database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb,<EFBFBD>primary_max_log_rate,primary_group_max_io,<EFBFBD>volume_local_iops,volume_pfs_iops
|
||||
FROM<EFBFBD>sys.dm_user_db_resource_governance;
|
||||
GO
|
||||
SELECT DATABASEPROPERTYEX('<database name>', 'ServiceObjective');
|
||||
SELECT DATABASEPROPERTYEX('AdventureWorks<ID>', 'ServiceObjective');
|
||||
GO
|
||||
|
|
|
@ -1,2 +1,2 @@
|
|||
ALTER DATABASE AdventureWorks0406 MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
|
||||
ALTER DATABASE AdventureWorks<ID> MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
|
||||
GO
|
|
@ -1,4 +1,4 @@
|
|||
SELECT io_stall_write_ms/num_of_writes as avg_tlog_io_write_ms, *
|
||||
FROM sys.dm_io_virtual_file_stats
|
||||
(db_id('AdventureWorks0406'), 2);
|
||||
SELECT io_stall_write_ms/num_of_writes as avg_tlog_io_write_ms, *
|
||||
FROM sys.dm_io_virtual_file_stats
|
||||
(db_id('Adventureworks<ID>'), 2);
|
||||
GO
|
Загрузка…
Ссылка в новой задаче