Azure SQL Connection Timeout və sorğu performansı problemlərinin aradan qaldırılması

Azure SQL Database ilə əlaqəli tətbiq performansı problemləri üzə çıxır. Simptomlar: – Connection Timeout: Veb tətbiqi və ya API Azure SQL-ə bağlanmağa çalışdıqda bəzən “Connection timeout” xətası alır. Yəni, müştəri 15-30 saniyə gözlədikdən sonra verilənlər bazasına qoşulma qurula bilmir. – Yavaş sorğular: Əvvəl tez işləyən SQL sorğuları (Stored Procedure-lər və ya ORMovel query-lər) indi çox ləng icra olunur. Məsələn, normalda 200 ms olan bir sorğu indi 5-10 saniyə vaxt alır. Bu isə tətbiqdə gecikmələr yaradır. – Deadlock və ya CPU tavan problemləri: Bəzən App təbəqədə xətalar görünə bilər (SqlException-lar) – “deadlock victim” mesajları, yaxud query time-out (default 30s aşaraq). Azure Portalda Azure SQL üçün CPU və DTU usage qrafiklərinin 100%-ə dirəndiyi görülə bilər. – Gecə saatlarında normal, pik saatlarda problemlər: Yük artdıqca problem kəskinləşir. Az sayda istifadəçi ilə hər şey normaldır, lakin pik trafficdə həm sorğular yavaşıyır, həm də bəzən Connection Drop-lar yaşanır (məsələn, connection pool içində atılmış bağlantılar).

Mümkün kök səbəblər:

• İstifadə edilən servisin ölçüsünün (sku) yetersizliyi: Azure SQL Database’in seçilmiş ölçüsü (DTU planı və ya vCore) mövcud yüklə baş edə bilmir. Məsələn, bir S0 tier database-də bir anda 100-lərlə sorğu çalışdırılmağa başlayıbsa, onun DTU-ları çatmayacaq, nəticədə CPU 100%-ə vurub sorğular gecikəcək. DTU-lar dolanda database sorğuları gözləməyə (queue) salır və ya throttle edir. Bu həm sorğu ləngimələrinə, həm də connection time-out-lara səbəb ola bilər. Qeyd: Connection timeout birbaşa DB tərəfdən deyil, adətən client tərəfdən baş verir (30s limitinə çatır), lakin kökü DB-nin cavab verməməsidir.
• Tədbiq edilməmiş indekslər və sorğu optimizasiyası: Verilənlər cədvəllərində lazımi indekslər yoxdursa, müəyyən sorğular tam skan aparır və böyük cədvəllərdə bu çox vaxt apara bilər. Bu, tək bir sorğunu yavaşıdır, eyni zamanda resurs tükətdiyi üçün başqalarını da yavaşıdar. Misal: 10 milyon sətrlik cədvəldə tez-tez id=… şərtli sorğu atılır, lakin id sütunu indekslənməyib – hər dəfə tam masa scan edir, 100% CPU tükəndirir və sorğu 15 saniyə çəkir.
• Parametr sniffing / plan regressing: Bəzən SQL sorğuları üçün öncədən tərtib edilmiş planlar spesifik parametrlərə optimallaşır. Nadir hallarda, bir param ilə gələn sorğu pis plan seçir (məsələn, parametriyə görə yanlış index usage). Bu “parametr sniffing” problemləri performansı qeyri-sabit edə bilər – bəzi dəyərlərlə sorğu sürətli, bəziləri ilə çox yavaşdır.
• Connection String konfiqurasiyası: Məs., Connection Timeout parametri default 15 saniyədir – şəbəkədə bir az əlavə gecikmə olsa belə, tez time-out ola bilər. Yaxud, bəlkə application yanlış server adına qoşulmağa çalışır (yanlış FQDN). Ümumiyyətlə, connection time-out-lar çox vaxt şəbəkə/konfiqurasiya məsələsidir: firewall icazəsi, DNS resolution problemi (Application bəlkə köhnə server adına gedir?), yaxud virtual şəbəkə ilə inteqrasiya olunubsa NSG-UDR blokları. Məsələn, Azure SQL üçün firewall-da müvafiq client IP icazəsi verilməyibsə, bağlantı qulağa kimi gedib orada drop ola bilər və client time-out əldə edər.
• Yüksək lakentli şəbəkə / geolokasiya: Tətbiq və Azure SQL fərqli regionlardadırsa (və ya client on-prem-lə Azure arasında), şəbəkə gecikməsi connection qurulmasına əlavə 100+ ms qata bilər. Bu, adətən tək başına time-out yaratmaz, amma həddi-hüdudunda olan hallarda töhfə verə bilər.
• Connection pooling düzgün işləməməsi: Əgər tətbiq hər sorğu üçün yeni bağlantı açır və pooling istifadə etmirsə, connection open overhead-ləri görülə bilər. Bu, sanki connection time-out kimi də görünə bilər əgər qısa müddətdə çox sayda connect cəhdi varsa. Və ya pool config çox kiçikdir (max 10 connection, ancaq 50 thread eyni anda DB çağırır), qalanlar növbədə gözləyib time-out ola bilər.
• Blockings, Deadlocks: Application sorğuları bir-birini bloklayırsa (məsələn, Transaction A bir cədvələ X lock qoyub, eyni vaxtda Transaction B həmin resursa girmək istəyir – B blokda gözləyir), bu da performans probleminə yol açar. Uza müddətli locks nəticədə “deadlock” halına gəlib SQL-in birini qurban seçib abort etməsi ilə nəticələnir. Deadlock qurbanı olan transaction-lar kənara atılar (application-larda exception olar). Bu hal tez-tez son istifadəçilər üçün kəsilmələr yaradar.

Diaqnostika üsulları:

1. Azure SQL-in daxili monitorinqini yoxlayın: Azure Portalda database səhifəsində Monitoring bölməsində SQL Insights (Intelligent Insights) və Query Performance Insight istifadə edin. Intelligent Insights tez-tez avtomatik anomaliyalar aşkar edir – məsələn, “High CPU detected due to missing index on table X” kimi xəbərdarlıqlar yarada bilər. Query Performance Insight isə ən çox qaynaq istifadə edən sorğuları göstərir: CPU, duration, execution count kimi məlumatlarla. Orada top 5 yavaş query siyahısına baxın. Bir sorğunun average duration-u kəskin artıbsa, bu, problemli sorğudur (Application Insights Profiler izləmələrində göstərildiyi kimi).
2. SQL Server DMVs istifadə: Azure SQL-in Query Store funksionallığını aktiv edin (əgər onsuz da aktiv deyilsə, yeni DB-lərdə default aktivdir). Query Store-dan Regressed Queries siyahısına baxın – planı dəyişib yavaşıyan sorğuları göstərir. Həmçinin sys.dm_exec_requests DMV-sinə real vaxtda baxaraq, hal-hazırda çalışan sorğuları, onların gözləmə səbəblərini (wait type) görə bilərsiniz. Məsələn, bir çox session WAIT_TIMEOUT ya da NETWORK_IO gözləməsindədirsə, connection-lar bir şeyə görə asılı qalıb.
3. Sürətli troubleshoot üçün Application Insights (əgər varsa): Tətbiq App Insights ilə instrumentedirsə, Dependency telemetriyasında Azure SQL çağırışlarının müddətlərinə və uğur/hata statuslarına baxın. Application Insights application map-də SQL DB-ni node kimi göstərib gecikməni vurğulaya bilər. Həmçinin, yavaş query-lər App Insights-un Performance bölməsində “SQL database on X” adıyla dependency olaraq görsənə bilər. Oradan ən yavaş query-nin tam textini də bəzən çıxarmaq olur. Bu, sizə hansının optimize tələb etdiyini göstərə bilər.
4. Konnektivlik testləri: Connection time-out şikayətləri varsa, səbəb network ola bilər. Tətbiq serverindən SQL serverin FQDN-nə telnet/test-connection edin. Məs: tcping <sqlservername>.database.windows.net 1433. Alınmırsa, demək, firewall məsələsi var. Azure SQL firewall-u altındakı qaydaları (“Allow Azure Services” açıqdırmı?), tətbiqin şəbəkə mühitindən (VNet) çıxış icazəsi varmı – bunları yoxlayın. Bəzi hallarda, Azure SQL Connection Policy “Default” vs “Proxy” olması performance fərqi yarada bilər: recommended “Default” (Redirect) modunda müştəri birbaşa regiondakı qapılara bağlanır, proxy modunda bütün trafik bir gateway üzərindən gedir – bu da gecikmə qata bilər. Proxy modunda olub olmamasını connection string parametrləri ilə anlaya bilərsiz (tcp: server adına vs udp). Query SELECT connectionproperty(‘client_tcp_port’) in DB: 11000+ portlar redirect modunu göstərir, 1433 isə proxy.
5. Sistem məhdudiyyətlərinin monitorinqi: Azure SQL metriçlərinə baxın: CPU, Data IO, Log IO, DTU Usage, Active Sessions vs. CPU davamlı 90-100%dirsə, aydın resurs tükənməsidir. DTU varsa (köhnə planlarda), eyni cür. Avg. wait time per connection metriyi də var, yüksəkdirsə concurrency issues deməkdir. Ayrıca, Workers count-u (thread count) limitə çatırsa, server yeni sorğuları gözləməyə qoyur.
6. Deadlock diagnostikası: Azure SQL avtomatik deadlock qurbanı log-u tutmalıdır (System Health Extended Event-lər). Query Store-da da deadlock məlumatları ola bilər. Azure portalda Alerts varsa, “deadlock graph” event-lərini göndərmək mümkün. Yoxdursa, sys.event_log DMV-də Deadlock anları qeydə alınıb. Deadlock-lar varsa, onların səbəbini (hansı prosedurlar) Query Store’un Blocked Queries və ya Extended Events ilə aşkar etmək lazımdır.

Sınaqdan keçmiş həll yolları:

• Database-in ölçüsünü artırmaq (Scale-up): Ən birbaşa həll, əgər resurs çatışmazlığı varsa, Azure SQL-in tierini yüksəltməkdir. Məsələn, S2-dən S4-ə keçmək (DTU ikiqat artır), yaxud Gen5 2 vCore-dan 4 vCore-a keçmək. Bu, həm CPU, həm də I/O qabiliyyətini yüksəldəcək, sorğuların daha tez işləməsinə imkan verəcək. Microsoft tövsiyə edir ki, CPU daim 70%-i keçirsə və optimizasiya ilə düzəlmirsə, servis planını böyüdün. Scale-up nəticəsində connection time-out problemləri də çözülsə, demək, kök səbəb sadəcə resurs yetməməsi idi.
• Alternativ (xüsusən Business Critical tier-lərdə) Scale-out read replicas: Əgər problem ancaq oxu sorğularıdır və onlar primary-də yüklənmə yaradırsa, Readonly Replica-lardan istifadə edib oxu işini oraya yönləndirmək olar (Connection stringdə ApplicationIntent=ReadOnly istifadə etməklə). Bu, primary üzərində yükü azaldar.
• Sorğu optimizasiyası və indeksləmə: Diaqnostika əsasında müəyyən etdisinizsə ki, filan sorğu yavaşdır:
• Yaxşı bir Query Tuning qaydası: Execution plan’a baxın. Azure Portalda Query Performance Insight-dan bir sorğunu seçib “View Plan” eləyə bilərsiniz (ya da SSMS/Azure Data Studio ilə qoşulub EXPLAIN plan). Orada Table Scan görsənirsə, həmin sütunlara indeks əlavə etməyi düşünün. Missing Index tövsiyələrini Query Store verir – əl ilə də yoxlayın: sys.dm_db_missing_index* DMV-lər.
• Parametr sniffing hallarında: ya Stored Procedure-lərdə OPTION (RECOMPILE) kimi hint-lər müvəqqəti kömək edə bilər (hər çağırış plan qurur, sniffing effektini azaldır, amma CPU daha çox sərf edir). Və ya OPTIMIZE FOR UNKNOWN hintindən istifadə. Uzunmüddətli həll sorğunu refactor etmək və ya statistikaları yeniləmək ola bilər. Bəzən sadə UPDATE STATISTICS plan seçimlərini düzəldir, plan yenidən tərtib olunaraq normal hala gəlir.
• Index maintenance: Yüksək fragmentasiya varsa, yenidən təşkil/tikmə (REBUILD/REORGANIZE) performansı artıra bilər. Azure SQL Manage tibində Automatic Index Tuning açıqdırsa, onsuz da bunu qismən edəcək. “High CPU due to missing index” kimi Intelligent Insights tövsiyəsi çıxıbsa, həmin indeksi yaratmaq adətən dərhal fayda verir.
• Query redesign: Məsələn, N+1 query problemləri varsa (ORM-lər eyni şeyi 100 dəfə soruşur), onu tək sorğuya birləşdirin. Və ya çox böyük dataset-ləri SELECT * ilə çəkməkdənsə, lazımi sütunları seçin, lazımsız trafiki azaldın.
• Connection Timeout-ların şəbəkə yönlü həlli:
• Azure SQL server firewall – lazım olan bütün IP-lərə icazə verin (məsələn, App Service istifadə edirsinizsə, dənəvər çıxış IP-lərini əlavə edin və ya “Allow Azure Services”=On, amma bu hamıya icazə verir).
• VNet Service Endpoint və ya Private Link istifadə edin: App-lə eyni VNet-də Service Endpoint açıb Azure SQL-ə bağlansanız, şəbəkə laqı daha sabit və sürətli olur (internet şəbəkəsini dolanmaz, ancaq Azure backbone). Private Endpoint isə tamamilə özəl IP-dən qoşulma verir. Bu, gecikməni bir qədər azaldar və kəsilmə riskini azaldar.
• Connection retry siyasəti: Application səviyyəsində, connection open üçün bir retry mexanizmi qura bilərsiniz (məsələn, .NET-də SqlConnection avtomatik yok, ancaq Transient Fault Handling kitabxanası ilə). Bəzən ilk cəhd time-out olsa belə, ikinci cəhd uğurlu ola bilər (məsələn, qısa anlıq şəbəkə hıçqırığı idi deyə).
• Connection Timeout parametri: Default 15 saniyədir (.NET). Bunu bir qədər (30 saniyə) artırmaq müvəqqəti band-aid ola bilər, amma əslində problem davam edirsə sadəcə gözləmə uzanar. Yenə də, əgər bağlanmanı normalda 16-17 saniyədə alırdısa, default 15s-ə görə kəsilirdi – 30s etmək həll edər. Amma idealda, bağlanmanın bu qədər zaman almamasını təmin etmək lazımdır.
• Connection pooling istifadə: Tətbiqinizi yoxlayın ki, connection-ları yenidən istifadə etsin (Most frameworks do by default). Məsələn, .NET-də Max Pool Size default 100-dür; əgər eyni anda 200 thread DB-yə vurursa, bəziləri gözləyəcək. Pool size-ni artırmaq çözüm ola bilər, amma daha da yaxşısı, tətbiq boyu o qədər paralel DB çağırışı etməməyi təmin etmək. Bəzən dev-lər pool size-ni çox aşağıya salır yanlışlıqla – buna diqqət edin.
• Deadlock həlləri: Deadlock-u yaradan prosedurları analiz edib kilidləmə cərgəsini azaltmaq lazımdır. Məsələn, iki transaction eyni vaxtda bir-birinin lazım olduğu cədvəlin fərqli hissələrini kilidləyirsə, design’i dəyişmək lazım gəlir (resursların kilidlənmə sırasını eyniləşdirmək ya da transaction-u kiçik scope-lu eləmək). SQL Profiler Extended Events-lə deadlock graph-larını çıxarıb, oradakı obyektləri və query-ləri müəyyənləşdirib kodu modifikasiya etmək lazımdır. Kodu dəyişmək çətindirsə, oxu sorğuları üçün READ_COMMITTED_SNAPSHOT isolation-u aktiv edərək versioning istifadə etmək olar – bu, oxu əməliyyatlarının yazma əməliyyatlarını bloklamamasını təmin edir (Azure SQL-də default ON-dur yeni DB-lərdə).