Mengapa database Azure SQL (SQL Server) saya kelebihan beban dengan data IO selama beberapa waktu? [Tutup]


9

Saya menjalankan database Azure SQL di bawah edisi S2 (50 DTU). Penggunaan normal server biasanya hang sekitar 10% DTU. Namun, server ini secara teratur masuk ke dalam kondisi di mana ia akan mengirim penggunaan database DTU ke 85-90% selama berjam-jam. Kemudian tiba-tiba kembali ke penggunaan normal 10%.

masukkan deskripsi gambar di sini

Permintaan terhadap server dari aplikasi sepertinya masih beroperasi dengan cepat selama keadaan kelebihan ini.

Saya dapat mengatur skala server dari S2 => apa saja (S3 misalnya) => S2 dan tampaknya menghapus status apa pun yang digunakan. Tetapi kemudian beberapa jam kemudian ia akan mengulangi siklus keadaan kelebihan beban yang sama. Hal aneh lain yang saya perhatikan adalah bahwa jika saya menjalankan server ini pada paket S3 (100 DTU) 24/7 saya belum mengamati perilaku ini. Tampaknya hanya terjadi ketika saya downscaled database ke paket S2 (50 DTU). Pada paket S3 saya selalu duduk di 5-10% penggunaan DTU. Jelas kurang dimanfaatkan.

Saya sudah memeriksa laporan kueri Azure SQL mencari kueri nakal, tapi saya tidak benar-benar melihat sesuatu yang tidak biasa dan itu menunjukkan kueri saya menggunakan sumber daya seperti yang saya harapkan.

masukkan deskripsi gambar di sini

Seperti yang bisa kita lihat di sini, penggunaannya semua berasal dari Data IO. Jika saya mengubah laporan kinerja di sini untuk menampilkan kueri IO Data atas dengan MAX, kami melihat ini:

masukkan deskripsi gambar di sini

Melihat quires yang berjalan lama ini sepertinya menunjuk ke pembaruan statistik. Tidak benar-benar sesuatu berjalan dari aplikasi saya. Misalnya, kueri 16302 di sana menunjukkan:

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

Tetapi sekali lagi, laporan itu juga menunjukkan bahwa kueri ini hanya menggunakan sebagian kecil dari penggunaan Data IO di server (<4%). Saya juga menjalankan pembaruan statistik (dan indeks pembangunan kembali) di seluruh database setiap minggu sebagai bagian dari pemeliharaan rutinnya.

Berikut ini adalah laporan lain yang menunjukkan MAX IO data data untuk rentang waktu yang mencakup beberapa jam hanya selama insiden penggunaan sumber daya tinggi.

masukkan deskripsi gambar di sini

Seperti yang bisa kita lihat, sebenarnya tidak ada pertanyaan yang melaporkan penggunaan IO data yang signifikan.

Saya juga berlari sp_who2dan sp_whoisacivepada database dan tidak benar-benar melihat sesuatu melompat ke arah saya (meskipun saya akui saya bukan ahli dengan alat ini).

Bagaimana cara mengetahui apa yang terjadi di sini? Saya tidak berpikir salah satu permintaan aplikasi saya yang harus disalahkan untuk penggunaan sumber daya ini dan saya merasa bahwa ada beberapa proses internal yang berjalan di latar belakang pada server yang membunuhnya.


Jadi Anda melihat ada pembaruan statistik yang berjalan, yang secara alami akan memiliki beberapa biaya I / O yang layak terkait, kan? Jika kueri itu 4% dari total IO selama lebih dari 24 jam, apakah menurut Anda itu masih bisa menjadi kontributor lonjakan yang Anda lihat dalam grafik? Saya akan ragu untuk menggunakan kata "kelebihan beban" ketika Anda tidak memaksimalkan DTU Anda dan kinerja permintaan Anda juga masih dapat diterima. Mengapa masalah bahwa server menggunakan sumber dayanya berbeda dari waktu ke waktu?
LowlyDBA

@ LowlyDBA Saya tidak yakin bagaimana saya bisa memvalidasi bahwa permintaan adalah apa yang menyebabkan ini. Ketika itu hanya menunjukkan penggunaan 4% saya tidak akan berpikir bahwa akan menyebabkan hampir 100% penggunaan ambang DTU keseluruhan. Ada banyak penggunaan yang tidak terhitung di sini. Pada dasarnya saya mencoba mencari tahu mengapa ini terjadi. Paku berjam-jam terus-menerus menempatkan server sangat dekat 100%, dan seperti yang disebutkan ini tampaknya tidak terjadi sama sekali ketika saya menggandakan sumber daya DTU tersedia (rencana S3).
kspearrin

Ingat DTU bukan hanya I / O, itu juga CPU dan memori . Jadi membandingkan keduanya mungkin bukan metrik yang membantu. Apa yang diberikan alat wawasan kinerja kueri untuk perincian visual sumber daya di jendela yang lebih kecil (hanya berjam-jam Anda melihat lonjakan)?
LowlyDBA

@LowlyDBA Screenshot laporan yang saya posting di atas tampaknya dengan jelas menunjukkan sumber daya semuanya berasal dari Data IO. CPU dan Log IO tidak terlalu menjadi faktor. Sebagai contoh, melihat pertanyaan oleh Max CPU% hanya menunjuk ke pelaku terbesar menggunakan hanya 2% selama beberapa jam saat masalah terjadi. Tangkapan layar: imgur.com/rxyMLc9
kspearrin

1
@DirkBoer Dalam kasus kami, ini tampaknya terkait dengan permintaan agregat statistik yang berjalan di server. Kami mematikan statistik otomatis pada tabel tertentu untuk membantu menyelesaikan masalah.
kspearrin

Jawaban:


1

Mengingat bahwa selama spike (s) aktivitas log Anda minimal, kami dapat menganggap tidak ada (atau banyak) DUI yang terjadi.

Anda menyebutkan pada satu titik bahwa lonjakan tidak mempengaruhi kinerja, dan di titik lain itu tidak. Yang mana itu?

Anda juga menyebutkan bahwa ini hilang setelah operasi skala. Ini masuk akal karena analog dengan restart di tempat yang secara efektif akan membunuh semua proses dll.

Apakah saya berasumsi benar dalam menebak bahwa database ini sedang diakses dari tingkat aplikasi? Jika demikian, saya menduga koneksi Anda tidak ditutup dengan benar . Pengumpul sampah seharusnya mengurus ini pada akhirnya (yang seharusnya tidak diandalkan), tetapi saya telah melihat situasi yang tepat ini terjadi karena koneksi tidak tertutup dari app-tier. Dalam kasus kami, aplikasi sangat sibuk sehingga kami akhirnya menerima kesalahan koneksi bersamaan yang menyebabkan kami mengalami masalah.

Coba kueri berikut selama spike:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

Jika saya benar, Anda akan menemukan sejumlah besar catatan yang dikembalikan dengan status Sleeping, atau lebih buruk Running. Jika itu masalahnya Anda memiliki masalah yang lebih besar di app-tier.

Kami dapat lebih lanjut men-debug ini dengan menyalin basis data, menggunakan kueri berikut (menggunakan tingkat dasar untuk menghindari biaya berlebihan), dan memantau perilaku ini.

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );

1
Ya, basis data diakses dari tingkat aplikasi, tetapi sejauh yang saya tahu semua koneksi terbungkus dalam usingpernyataan. Info yang saya posting di pertanyaan awal tampaknya menunjukkan bahwa data IO bertanggung jawab atas lonjakan.
kspearrin

1
@pimbrouwers: Bisakah Anda menjelaskan secara spesifik mengapa koneksi dalam kondisi tidur / berlari buruk? Pemahaman saya tentang pooling koneksi adalah bahwa koneksi bisa dalam keadaan seperti itu sebagai bagian dari operasi normal.
obaylis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.