Meningkatkan Performa Indeks Full-Text
Berlaku untuk:
SQL ServerAzure SQL Database
Topik ini menjelaskan beberapa penyebab umum performa buruk untuk indeks dan kueri teks lengkap. Ini juga memberikan beberapa saran untuk mengurangi masalah ini dan meningkatkan performa.
Penyebab umum masalah performa
Masalah sumber daya perangkat keras
Performa pengindeksan teks lengkap dan kueri teks lengkap dipengaruhi oleh sumber daya perangkat keras, seperti memori, kecepatan disk, kecepatan CPU, dan arsitektur mesin.
Penyebab utama berkurangnya performa pengindeksan teks lengkap adalah batas sumber daya perangkat keras.
CPU. Jika penggunaan CPU oleh proses host daemon filter (fdhost.exe) atau proses SQL Server (sqlservr.exe) mendekati 100 persen, CPU adalah hambatan.
Memori. Jika ada kekurangan memori fisik, memori mungkin menjadi hambatan.
Disk. Jika panjang antrean menunggu disk rata-rata lebih dari dua kali jumlah kepala disk, ada hambatan pada disk. Solusi utamanya adalah membuat katalog teks lengkap yang terpisah dari file dan log database SQL Server. Letakkan log, file database, dan katalog teks lengkap pada disk terpisah. Menginstal disk yang lebih cepat dan menggunakan RAID juga dapat membantu meningkatkan performa pengindeksan.
Catatan
Dimulai di SQL Server 2008 (10.0.x), Mesin Teks-Penuh dapat menggunakan memori AWE karena Mesin Teks-Penuh adalah bagian dari proses sqlservr.exe. Untuk informasi selengkapnya, lihat Arsitektur Pencarian Teks Lengkap.
Masalah batching teks lengkap
Jika sistem tidak memiliki hambatan perangkat keras, performa pengindeksan pencarian teks lengkap sebagian besar tergantung pada hal berikut:
Berapa lama waktu yang dibutuhkan SQL Server untuk membuat batch teks lengkap.
Seberapa cepat daemon filter dapat mengonsumsi batch tersebut.
Masalah populasi indeks teks lengkap
Jenis populasi. Tidak seperti populasi penuh, populasi pelacakan perubahan bertahap, manual, dan otomatis tidak dirancang untuk memaksimalkan sumber daya perangkat keras untuk mencapai kecepatan yang lebih cepat. Oleh karena itu, saran penyetelan dalam topik ini mungkin tidak meningkatkan performa untuk pengindeksan teks lengkap saat menggunakan populasi pelacakan perubahan bertahap, manual, atau otomatis.
Penggabungan master. Ketika populasi telah selesai, proses penggabungan akhir dipicu yang menggabungkan fragmen indeks bersama-sama menjadi satu indeks teks lengkap master. Ini menghasilkan peningkatan performa kueri karena hanya indeks master yang perlu dikueri daripada sejumlah fragmen indeks, dan statistik penilaian yang lebih baik dapat digunakan untuk peringkat relevansi. Namun penggabungan master bisa intensif I/O, karena sejumlah besar data harus ditulis dan dibaca ketika fragmen indeks digabungkan, meskipun tidak memblokir kueri masuk.
Master menggabungkan sejumlah besar data dapat membuat transaksi yang berjalan lama, menunda pemotongan log transaksi selama titik pemeriksaan. Dalam hal ini, di bawah model pemulihan penuh, log transaksi mungkin tumbuh secara signifikan. Sebagai praktik terbaik, sebelum mengatur ulang indeks teks lengkap besar dalam database yang menggunakan model pemulihan penuh, pastikan bahwa log transaksi Anda berisi ruang yang cukup untuk transaksi yang berjalan lama. Untuk informasi selengkapnya, lihat Mengelola Ukuran File Log Transaksi.
Menyetel performa indeks teks lengkap
Untuk memaksimalkan performa indeks teks lengkap Anda, terapkan praktik terbaik berikut:
Untuk menggunakan semua prosesor atau inti CPU ke maksimum, atur sp_configure 'rentang perayapan teks lengkap maks' ke jumlah CPU pada sistem. Untuk informasi tentang opsi konfigurasi ini, lihat Opsi Konfigurasi Server rentang perayapan teks lengkap maks.
Pastikan bahwa tabel dasar memiliki indeks berkluster. Gunakan jenis data bilangan bulat untuk kolom pertama indeks berkluster. Hindari menggunakan GUID di kolom pertama indeks berkluster. Populasi multi-rentang pada indeks berkluster dapat menghasilkan kecepatan populasi tertinggi. Kami menyarankan agar kolom yang berfungsi sebagai kunci teks lengkap adalah jenis data bilangan bulat.
Perbarui statistik tabel dasar dengan menggunakan pernyataan UPDATE STATISTICS . Yang lebih penting, perbarui statistik pada indeks berkluster atau kunci teks lengkap untuk populasi penuh. Ini membantu populasi multi-rentang untuk menghasilkan partisi yang baik pada tabel.
Sebelum Anda melakukan populasi penuh pada komputer multi-CPU besar, kami sarankan Anda membatasi ukuran kumpulan buffer untuk sementara dengan mengatur nilai memori server maks untuk meninggalkan cukup memori untuk proses fdhost.exe dan penggunaan sistem operasi. Untuk informasi selengkapnya, lihat Memperkirakan Persyaratan Memori Proses Host Daemon Filter (fdhost.exe), nanti dalam topik ini.
Jika Anda menggunakan populasi inkremental berdasarkan kolom tanda waktu, buat indeks sekunder pada kolom tanda waktu untuk meningkatkan performa populasi bertambah bertahas.
Memecahkan masalah performa populasi penuh
Meninjau log perayapan teks lengkap
Untuk membantu mendiagnosis masalah performa, lihat log perayapan teks lengkap.
Ketika kesalahan terjadi selama perayapan, fasilitas pengelogan perayapan Pencarian Teks Lengkap membuat dan memelihara log perayapan, yang merupakan file teks biasa. Setiap log perayapan sesuai dengan katalog teks lengkap tertentu. Secara default, log perayapan untuk instans tertentu (dalam contoh ini, instans default) terletak di %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG folder.
File log rayapan mengikuti skema penamaan berikut:
SQLFT<DatabaseID\><FullTextCatalogID\>.LOG[<n\>]
Bagian variabel dari nama file log perayapan adalah sebagai berikut.
- <DatabaseID> - ID database. <dbid> adalah angka lima digit dengan nol di depannya.
- <FullTextCatalogID> - ID katalog teks lengkap. <catid> adalah angka lima digit dengan nol di depannya.
- <n> - Adalah bilangan bulat yang menunjukkan satu atau beberapa log perayapan dari katalog teks lengkap yang sama ada.
Misalnya, SQLFT0000500008.2 adalah file log perayapan untuk database dengan ID database = 5, dan ID katalog teks lengkap = 8. 2 di akhir nama file menunjukkan bahwa ada dua file log perayapan untuk pasangan database/katalog ini.
Periksa penggunaan memori fisik
Selama populasi teks lengkap, dimungkinkan untuk fdhost.exe atau sqlservr.exe kehabisan memori atau kehabisan memori.
- Jika log perayapan teks lengkap menunjukkan bahwa
fdhost.exesering dimulai ulang atau kode kesalahan 8007008 dikembalikan, itu berarti salah satu proses ini kehabisan memori. - Jika
fdhost.exememproduksi cadangan, terutama pada komputer multi-CPU besar, mungkin kehabisan memori. - Untuk mendapatkan informasi tentang buffer memori yang digunakan oleh perayapan teks lengkap, lihat sys.dm_fts_memory_buffers (Transact-SQL).
Kemungkinan penyebab memori rendah atau masalah kehabisan memori adalah sebagai berikut:
Memori tidak cukup. Jika jumlah memori fisik yang tersedia selama populasi penuh adalah nol, kumpulan buffer SQL Server mungkin mengonsumsi sebagian besar memori fisik pada sistem.
Proses ini
sqlservr.exemencoba mengambil semua memori yang tersedia untuk kumpulan buffer, hingga memori server maksimum yang dikonfigurasi. Jika alokasi memori server maksimum terlalu besar, kondisi di luar memori dan kegagalan untuk mengalokasikan memori bersama dapat terjadi untuk proses fdhost.exe.Anda dapat mengatasi masalah ini dengan mengatur nilai memori server maks dari kumpulan buffer SQL Server dengan tepat. Untuk informasi selengkapnya, lihat Memperkirakan Persyaratan Memori Proses Host Daemon Filter (fdhost.exe), nanti dalam topik ini. Mengurangi ukuran batch yang digunakan untuk pengindeksan teks lengkap juga dapat membantu.
Ketidakcocokan memori. Selama populasi teks lengkap pada komputer multi-CPU, ketidakcocokan untuk memori kumpulan buffer dapat terjadi antara fdhost.exe atau sqlservr.exe. Kurangnya memori bersama yang dihasilkan menyebabkan percobaan ulang batch, pembatasan memori, dan pembuangan oleh proses fdhost.exe.
Masalah halaman. Ukuran file halaman yang tidak memadai, seperti pada sistem yang memiliki file halaman kecil dengan pertumbuhan terbatas, juga dapat menyebabkan fdhost.exe atau sqlservr.exe kehabisan memori. Jika log perayapan tidak menunjukkan kegagalan terkait memori, kemungkinan performanya lambat karena penomoran yang berlebihan.
Memperkirakan persyaratan memori proses Filter Daemon Host (fdhost.exe)
Jumlah memori yang diperlukan oleh proses fdhost.exe untuk populasi terutama tergantung pada jumlah rentang perayapan teks lengkap yang digunakannya, ukuran memori bersama masuk (ISM), dan jumlah maksimum instans ISM.
Jumlah memori (dalam byte) yang dikonsumsi oleh host daemon filter dapat diperkirakan kira-kira dengan menggunakan rumus berikut:
number_of_crawl_ranges * ism_size * max_outstanding_isms * 2
Nilai default variabel dalam rumus sebelumnya adalah sebagai berikut:
| Variabel | Nilai default |
|---|---|
| number_of_crawl_ranges | Jumlah CPU |
| ism_size | 1 MB untuk komputer x86 4 MB, 8 MB, atau 16MB untuk komputer x64, tergantung pada total memori fisik |
| max_outstanding_isms | 25 untuk komputer x86 5 untuk komputer x64 |
Tabel berikut menyajikan panduan tentang cara memperkirakan persyaratan memori fdhost.exe. Rumus dalam tabel ini menggunakan nilai berikut:
F, yang merupakan perkiraan memori yang diperlukan oleh fdhost.exe (dalam MB).
T, yang merupakan total memori fisik yang tersedia pada sistem (dalam MB).
M, yang merupakan pengaturan memori server maks optimal.
Untuk informasi penting tentang rumus berikut ini, lihat catatan yang mengikuti tabel.
| Platform | Memperkirakan persyaratan memori fdhost.exe dalam MB-F^1 | Rumus untuk menghitung memori server maks-M^2 |
|---|---|---|
| x86 | F = Jumlah rentang rayapan * 50 | M =minimum(T, 2000) - F - 500 |
| x64 | F = Jumlah rentang rayapan * 10 * 8 | M = T - F - 500 |
Catatan tentang rumus
- Jika beberapa populasi penuh sedang berlangsung, hitung persyaratan memori fdhost.exe masing-masing secara terpisah, sebagai F1, F2, dan sebagainya. Kemudian hitung M sebagai T- sigma**(_F_i)**.
- 500 MB adalah perkiraan memori yang diperlukan oleh proses lain dalam sistem. Jika sistem melakukan pekerjaan tambahan, tingkatkan nilai ini.
- . ism_size diasumsikan 8 MB untuk platform x64.
Contoh: Memperkirakan persyaratan memori fdhost.exe
Contoh ini adalah untuk komputer 64-bit yang memiliki RAM 8GB dan prosesor inti ganda 4. Perkiraan perhitungan pertama memori yang diperlukan oleh fdhost.exe -F. Jumlah rentang rayapan adalah 8.
F = 8*10*8 = 640
Perhitungan berikutnya mendapatkan nilai optimal untuk memori -server maks M. Total memori fisik yang tersedia pada sistem ini dalam MB-T-adalah8192 .
M = 8192-640-500 = 7052
Contoh: Mengatur memori server maks
Contoh ini menggunakan pernyataan sp_configure dan RECONFIGURE Transact-SQL untuk mengatur memori server maks ke nilai yang dihitung untuk M dalam contoh sebelumnya, 7052:
USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO
Untuk informasi selengkapnya tentang opsi memori server, lihat Opsi Konfigurasi Server Server Memory.
Periksa penggunaan CPU
Performa populasi penuh tidak optimal ketika konsumsi CPU rata-rata lebih rendah dari sekitar 30 persen. Berikut adalah beberapa faktor yang memengaruhi konsumsi CPU.
Waktu tunggu tinggi untuk halaman
Untuk mengetahui apakah waktu tunggu halaman tinggi, jalankan pernyataan Transact-SQL berikut:
SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;Tabel berikut ini menjelaskan jenis tunggu yang menarik di sini.
Jenis tunggu Deskripsi Kemungkinan resolusi PAGEIO_LATCH_SH (_EX atau _UP) Ini dapat menunjukkan penyempitan IO, dalam hal ini Anda biasanya juga akan melihat panjang antrean disk rata-rata tinggi. Memindahkan indeks teks lengkap ke grup file yang berbeda pada disk yang berbeda dapat membantu mengurangi hambatan IO. PAGELATCH_EX (atau _UP) Ini dapat menunjukkan banyak ketidakcocokan di antara utas yang mencoba menulis ke file database yang sama. Menambahkan file ke grup file tempat indeks teks lengkap berada dapat membantu meringankan pertikaian tersebut. Untuk informasi selengkapnya, lihat sys.dm_os_wait_stats (Transact-SQL).
Inefisiensi dalam memindai tabel dasar
Populasi penuh memindai tabel dasar untuk menghasilkan batch. Pemindaian tabel ini bisa tidak efisien dalam skenario berikut:
Jika tabel dasar memiliki persentase tinggi kolom di luar baris yang sedang diindeks teks lengkap, memindai tabel dasar untuk menghasilkan batch mungkin menjadi hambatan. Dalam hal ini, memindahkan data dalam baris yang lebih kecil menggunakan varchar(max) atau nvarchar(max) mungkin membantu.
Jika tabel dasar sangat terfragmentasi, pemindaian mungkin tidak efisien. Untuk informasi tentang komputasi data di luar baris dan fragmentasi indeks, lihat sys.dm_db_partition_stats (Transact-SQL) dan sys.dm_db_index_physical_stats (Transact-SQL).
Untuk mengurangi fragmentasi, Anda dapat mengatur ulang atau membangun kembali indeks berkluster. Untuk informasi selengkapnya, lihat Mengatur ulang dan Membangun Ulang Indeks.
Memecahkan masalah pengindeksan dokumen yang lambat
Catatan
Bagian ini menjelaskan masalah yang hanya memengaruhi pelanggan yang mengindeks dokumen (seperti dokumen Microsoft Word) di mana tipe dokumen lain disematkan.
Mesin Teks Lengkap menggunakan dua jenis filter saat mengisi indeks teks lengkap: filter multitulis dan filter utas tunggal.
- Beberapa dokumen, seperti dokumen Microsoft Word, difilter menggunakan filter multithreaded.
- Dokumen lain, seperti dokumen Adobe Acrobat Portable Document Format (PDF), difilter menggunakan filter utas tunggal.
Untuk alasan keamanan, filter dimuat oleh proses host daemon filter. Instans server menggunakan proses multithreaded untuk semua filter multi-utas dan proses utas tunggal untuk semua filter utas tunggal. Saat dokumen yang menggunakan filter multithreaded berisi dokumen yang disematkan yang menggunakan filter utas tunggal, Mesin Teks-Penuh meluncurkan proses utas tunggal untuk dokumen yang disematkan. Misalnya, pada menemukan dokumen Word yang berisi dokumen PDF, Mesin Teks-Penuh menggunakan proses multithreaded untuk konten Word dan meluncurkan proses utas tunggal untuk konten PDF. Filter utas tunggal mungkin tidak berfungsi dengan baik di lingkungan ini, namun, dan dapat menstabilkan proses pemfilteran. Dalam keadaan tertentu di mana penyematan seperti itu umum, destabilisasi dapat menyebabkan crash proses. Ketika ini terjadi, Mesin Teks-Penuh merutekan ulang dokumen yang gagal - misalnya, dokumen Word yang berisi konten PDF yang disematkan - ke proses pemfilteran satu utas. Jika perutean ulang sering terjadi, hal ini menghasilkan penurunan performa proses pengindeksan teks lengkap.
Untuk mengatasi masalah ini, tandai filter untuk dokumen kontainer (dokumen Word, dalam contoh ini) sebagai filter utas tunggal. Untuk menandai filter sebagai filter berulir tunggal, atur nilai registri ThreadingModel untuk filter ke Utas Apartemen. Untuk informasi tentang apartemen berulir tunggal, lihat laporan resmi Memahami dan Menggunakan Model Utas COM.
Lihat Juga
Opsi Konfigurasi Server Memori Server
Opsi Konfigurasi Server rentang perayapan teks lengkap maks
Mengisi Indeks Teks Lengkap
Membuat dan Mengelola Indeks Teks Lengkap
sys.dm_fts_memory_buffers (T-SQL)
sys.dm_fts_memory_pools (T-SQL)
Memecahkan Masalah Pengindeksan Teks Lengkap
Arsitektur Pencarian Teks Lengkap
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk