SQL Server üzerinde yük oluşturarak kaynak kullanımlarını ve sql server’ın bu yük ile başa çıkma durumu incelenmek için zaman zaman bazı testler yapılır. Yük oluştururken Microsoft tool’u ile bunu yapmak isterseniz daha önce kaleme aldığımız MSSQL Load (Stress) Test adlı makalemize bakabilirsiniz.
Bu testleri yapmak için birçok tool vardır. Bunlardan biri de Adam Mechanic’in yapmış olduğu SqlQuerryStress Tool’u dur. Bu tool ile istediğiniz sorguyu istediğiniz thread’de ve istediğiniz sayıda göndererek sistem üzerinde yük oluşturabilirsiniz.
Bu başlık altında SqlQueryStress tool’un kullanım durumuna ve kullanım sonrasında Sql Server üzerindeki yükleri inceleyeceğiz.
Öncelikle bu tool’u aşağıdaki linkten indirebilirsiniz. İndirdikten sonra exe’yi yönetici olarak çalıştırmanız tool’un başlatılması için yeterli olacaktır. Bu tool’u birden fazla kez açıp farklı sorgularda gönderebilirsiniz.
https://github.com/ErikEJ/SqlQueryStress/releases
Görsel-1
Görsel – 2
Görsel – 3
Exe’yi başlattığımızda yukarıdaki görsel bizi ilk olarak karşılayacaktır. Burada başlatmadan önce Database button’u ile yükü hangi server ve database üzerinde, hangi kullanıcı ile yapacağımız bilgisini girmemiz gerekmektedir.
Eğer sql server Authentication ile yapacaksak kullanıcı ismi ve şifresini girmemiz gerekmektedir.
Ayrıca Always encrypt ve Readonly routing gibi özellikleri aktif olarak kullanmak istiyorsak bu seçenekleri seçerek ilerleyebiliriz. Bizim amacımız sadece yük oluşturmak olduğu için şimdilik bu kısımları boş bırakarak devam edeceğiz.
Görsel – 4
Yukarıdaki bizi ilgilendiren alanları doldurduktan sonra tekrar ana pencereye geliyoruz. Yük testini başlatmadan önce “Clean Buffers” ve “Free Cache” seçeneğini seçmelimiyiz yoksa seçmemelimiyiz.
Eğer bu işlemleri test ortamında yapacaksak öncesinde seçmek yük oluşturma anlamında daha verimli olacaktır. Prod ortamda tüm cache ve buffer’ı boşaltacağı için danışmanınızdan bu konuda yardım almanızı tavsiye ederim.
Number of Iterations: Yazmış olduğumuz select count(*) person.person sorgusunun kaç kez execute edileceği ilgili bilgiyi belirtir.
Number Of threads: Yazmış olduğumuz sorgunun kaç tane eşzamanlı olarak thread açacağını belirtir.
Siyah olarak görünen alanlarda ise istediğimiz sorguyu istediğimiz thread ve sayıyı belirledikten sonra go diyerek çalıştırdıktan sonra ne kadar sürede bittiği ve toplamda ne kadar iteration tamamladığı bilgisini gösterecektir. Ayrıca sistem üzerindeki Avg. Logical Read değerini okuyacağız ve CPU’da geçirdiği süreyi göreceğiz.
Görsel – 5
Görsel – 6
SELECT dmes.session_id AS SPID, dmer.start_time, UPPER (DB_NAME(dmer.database_id)) DBName, dmes.host_name AS HostName, UPPER(dmes.login_name) AS LoginName, UPPER(dmer.status) AS SPIDState, dmer.command as RequestCommand, dmer.total_elapsed_time AS ElapsedTime, dmer.cpu_time AS CPUTime, dmer.reads AS RequestRead, dmer.writes AS RequestWrites, dmer.logical_reads AS RequestLogicalRead, SUBSTRING (dmest.text, (dmer.statement_start_offset/2) + 1, ((CASE WHEN dmer.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), dmest.text)) * 2 ELSE dmer.statement_end_offset END - dmer.statement_start_offset)/2) + 1) AS SubQuery, UPPER(REPLACE(LTRIM(LTRIM(CONVERT(varchar(2000),REPLACE(REPLACE(REPLACE(dmest.text,'-',''),'=',''),'*','')))),CHAR(9),'')) AS ParentQuery, dmeqp.query_plan AS QueryPlan, dmer.wait_type AS Current_WaitType, dmer.wait_time AS Current_WaitTime, dmer.last_wait_type AS Last_WaitType, dmer.wait_resource AS RequestWaitResource, dmer.blocking_session_id AS RequestBlockingSPID, dmer.lock_timeout AS RequestTimeout, dmer.open_transaction_count OpenTransactionCount, dmer.row_count RowsCount, dmer.percent_complete TaskCompletedPercent, (dmes.memory_usage*8) AS Memory_UsagesInKB, GETDATE() FROM sys.dm_exec_sessions dmes INNER JOIN sys.dm_exec_requests dmer ON dmer.session_id = dmes.session_id CROSS APPLY sys.dm_exec_sql_text(dmer.sql_handle) dmest CROSS APPLY sys.dm_exec_query_plan(dmer.plan_handle) dmeqp LEFT JOIN sys.dm_exec_cached_plans dmecp ON dmecp.plan_handle = dmer.plan_handle LEFT JOIN sys.dm_db_task_space_usage dmtsu ON dmtsu.session_id = dmer.session_id and dmtsu.request_id = dmer.request_id LEFT JOIN sys.dm_db_session_space_usage dmssu ON dmssu.session_id = dmes.session_id WHERE dmes.session_id <> @@SPID ORDER BY 11 DESC
Test öncesi ve sonrası sistem CPU kullanımı ve Activity Monitor batch request durumuna kısa göz gezdirelim.
Test öncesi;
Görsel – 7
Görsel – 8
Test sonrası;
Görsel – 9
Görsel – 10
Parametrik değerler ile random sorgular göndermek istersek eğer;
Görsel – 11
Görsel – 12
Sorgu ile kontrol etmek isterseniz eğer;
—-Arka planda çalışan sorguların kontrolü için
sp_WhoIsActive
—Procedure’in kaç kez çalıştığını görmek için
SELECT DB_NAME(st.dbid) DBNamee ,OBJECT_SCHEMA_NAME(st.objectid,dbid) SchemaName ,OBJECT_NAME(st.objectid,dbid) StoredProcedure ,MAX(cp.usecounts) Execution_count FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st WHERE DB_NAME(st.dbid) IS NOT NULL AND cp.objtype = 'proc' AND OBJECT_NAME(st.objectid, dbid) LIKE 'uspGetEmployeeManagers' GROUP BY cp.plan_handle, DB_NAME(st.dbid), OBJECT_SCHEMA_NAME(objectid,st.dbid), OBJECT_NAME(objectid,st.dbid) ORDER BY MAX(cp.usecounts) DESC GO
Random değerler ile göndermesini istersek eğer aşağıdaki konfigürasyonlar ile kontrol edebiliriz;
Görsel – 13
Görsel – 14
Görsel – 15
Ayrıca Profiler açarak çok kısa süre içerisinde farklı BusinessEntityID’ler ile 8000’in üzerinde sorgu çalıştırdığı tespit ettik.
Görsel – 16
0 Yorum