sending data

Status thread sending data menunjukkan bahwa thread membaca dan memfilter baris untuk kueri guna menentukan set hasil yang benar. Namanya agak membingungkan karena menyiratkan status mentransfer data, bukan mengumpulkan dan menyiapkan data untuk dikirim nanti.

Versi mesin yang didukung

Informasi status thread ini didukung untuk versi berikut:

• Aurora MySQL versi 2 hingga 2.09.2

Konteks

Banyak status thread tidak bertahan lama. Operasi yang terjadi selama sending data cenderung melakukan pembacaan disk atau cache dalam jumlah besar. Oleh karena itu, sending data sering kali merupakan status yang paling lama berjalan selama masa kueri tertentu. Status ini muncul saat Aurora MySQL melakukan hal berikut:

• Membaca dan memproses baris untuk pernyataan SELECT

• Menjalankan pembacaan dalam jumlah besar baik dari disk atau memori

• Menyelesaikan pembacaan lengkap semua data dari kueri tertentu

• Membaca data dari tabel, indeks, atau pekerjaan prosedur yang disimpan

• Menyortir, mengelompokkan, atau menyusun data

Setelah status sending data selesai menyiapkan data, status thread writing to net akan menunjukkan pengembalian data ke klien. Biasanya, writing to net diambil hanya ketika set hasil sangat besar atau latensi jaringan yang parah memperlambat transfer.

Kemungkinan penyebab peningkatan peristiwa tunggu

Kemunculan sending data tidak dengan sendirinya menunjukkan adanya suatu masalah. Jika performa buruk, dan Anda sering melihat instans sending data, berikut adalah penyebab yang paling memungkinkan.

Topik

• Kueri yang tidak efisien
• Konfigurasi server suboptimal

Kueri yang tidak efisien

Dalam sebagian besar kasus, status ini terutama disebabkan oleh kueri yang tidak menggunakan indeks yang sesuai untuk menemukan set hasil kueri tertentu. Sebagai contoh, pertimbangkan kueri yang membaca tabel berisi 10 juta data untuk semua pesanan yang ditempatkan di California, dengan kolom status tidak diindeks atau diindeks dengan buruk. Pada contoh terakhir, indeks mungkin ada, tetapi pengoptimal mengabaikannya karena kardinalitas rendah.

Konfigurasi server suboptimal

Jika beberapa kueri muncul dalam status sending data, server basis data mungkin dikonfigurasi dengan buruk. Secara khusus, server mungkin memiliki masalah berikut:

• Server basis data tidak memiliki kapasitas komputasi yang cukup: I/O disk, jenis dan kecepatan disk, CPU, atau jumlah CPU.

• Server kekurangan sumber daya yang dialokasikan, seperti pool buffer InnoDB untuk tabel InnoDB atau buffer kunci untuk tabel MyISAM.

• Pengaturan memori per-thread seperti sort_buffer, read_buffer, dan join_buffer menghabiskan lebih banyak RAM dari yang dibutuhkan, sehingga membuat server fisik kekurangan sumber daya memori.

Tindakan

Pedoman umumnya adalah menemukan kueri yang mengembalikan baris dalam jumlah besar dengan memeriksa Skema Performa. Jika pencatatan kueri yang tidak menggunakan indeks diaktifkan, Anda juga dapat memeriksa hasil dari log lambat.

Topik

• Mengaktifkan Skema Performa jika tidak aktif
• Memeriksa pengaturan memori
• Memeriksa "jelaskan rencana" untuk penggunaan indeks
• Memeriksa volume data yang dikembalikan
• Memeriksa masalah konkurensi
• Memeriksa struktur kueri

Mengaktifkan Skema Performa jika tidak aktif

Wawasan Performa akan melaporkan status thread hanya jika instrumen Skema Performa tidak aktif. Bila instrumen Skema Performa diaktifkan, Wawasan Performa akan melaporkan peristiwa tunggu. Instrumen Skema Performa memberikan wawasan tambahan dan alat yang lebih baik untuk menyelidiki potensi masalah performa. Oleh karena itu, sebaiknya Anda mengaktifkan Skema Performa. Untuk informasi selengkapnya, lihat Mengaktifkan Skema Performa untuk Wawasan Performa di Aurora MySQL.

Memeriksa pengaturan memori

Periksa pengaturan memori untuk pool buffer utama. Pastikan pool ini memiliki ukuran yang sesuai untuk beban kerja. Jika basis data Anda menggunakan beberapa instans pool buffer, pastikan instans tersebut tidak dibagi menjadi banyak pool buffer kecil. Thread hanya dapat menggunakan satu pool buffer pada satu waktu.

Pastikan pengaturan memori berikut yang digunakan untuk setiap thread memiliki ukuran yang benar:

• read_buffer

• read_rnd_buffer

• sort_buffer

• join_buffer

• binlog_cache

Gunakan nilai default, kecuali jika Anda memiliki alasan khusus untuk mengubah pengaturan.

Memeriksa "jelaskan rencana" untuk penggunaan indeks

Untuk kueri dalam status thread sending data, periksa rencana untuk mengetahui apakah indeks yang sesuai telah digunakan. Jika kueri tidak menggunakan indeks yang berguna, coba tambahkan petunjuk seperti USE INDEX atau FORCE INDEX. Petunjuk dapat menambah atau mengurangi banyak waktu yang diperlukan untuk menjalankan kueri, jadi berhati-hatilah sebelum menambahkannya.

Memeriksa volume data yang dikembalikan

Periksa tabel yang ditanyakan dan jumlah data yang ada di dalamnya. Apakah data ini dapat diarsipkan? Dalam banyak kasus, penyebab waktu eksekusi kueri yang buruk bukanlah hasil dari rencana kueri, tetapi volume data yang akan diproses. Banyak developer sangat efisien dalam menambahkan data ke basis data, tetapi jarang mempertimbangkan siklus proses set data dalam fase desain dan pengembangan.

Cari kueri yang berperforma baik dalam basis data volume rendah, tetapi berperforma buruk di sistem Anda saat ini. Terkadang, developer yang mendesain kueri tertentu mungkin tidak menyadari bahwa kueri tersebut mengembalikan 350.000 baris. Developer mungkin telah mengembangkan kueri di lingkungan volume yang lebih rendah, dengan set data lebih kecil dari yang dimiliki lingkungan produksi.

Memeriksa masalah konkurensi

Periksa apakah beberapa kueri dari jenis yang sama berjalan pada waktu yang sama. Format kueri tertentu berjalan secara efisien bila dijalankan sendiri. Namun, jika format kueri serupa berjalan bersama, atau dalam volume tinggi, hal tersebut dapat menimbulkan masalah konkurensi. Masalah ini sering kali muncul bila basis data menggunakan tabel sementara untuk merender hasil. Tingkat isolasi transaksi yang ketat juga dapat menyebabkan masalah konkurensi.

Jika tabel dibaca dan ditulis secara bersamaan, basis data mungkin menggunakan kunci. Untuk membantu mengidentifikasi periode performa yang buruk, periksa penggunaan basis data melalui proses batch skala besar. Untuk melihat kunci dan rollback terbaru, periksa output dari perintah SHOW ENGINE INNODB STATUS.

Memeriksa struktur kueri

Periksa apakah kueri yang diambil dari status ini menggunakan subkueri. Jenis kueri ini sering kali menimbulkan performa yang buruk karena basis data mengompilasi hasil secara internal, lalu menggantinya kembali ke kueri untuk merender data. Proses ini merupakan langkah ekstra untuk basis data. Dalam banyak kasus, langkah ini dapat menimbulkan performa yang buruk pada kondisi pemuatan yang sangat bersamaan.

Periksa juga apakah kueri Anda menggunakan klausa ORDER BY dan GROUP BY dalam jumlah besar. Dalam operasi semacam ini, sering kali basis data harus terlebih dahulu membentuk set data secara keseluruhan dalam memori. Selanjutnya, basis data harus menyusun atau mengelompokkannya secara khusus sebelum mengembalikannya ke klien.