Mengidentifikasi tempat terjadinya latensi

Halaman ini menjelaskan cara memecahkan masalah komponen Spanner untuk menemukan sumber latensi. Untuk mempelajari lebih lanjut tentang kemungkinan titik latensi dalam permintaan Spanner, lihat Titik latensi dalam permintaan Spanner.

  1. Di aplikasi klien yang memengaruhi layanan Anda, pastikan ada peningkatan latensi dari latensi dua-arah klien. Periksa dimensi berikut dari metrik sisi klien Anda.

    • Nama Aplikasi Klien
    • Lokalitas klien (misalnya, zona VM Compute Engine) dan Host (yaitu, nama VM)
    • Metode Spanner API
    • Status Spanner API

    Kelompokkan menurut dimensi-dimensi tersebut untuk melihat apakah masalahnya terbatas pada klien, status, atau metode tertentu. Untuk workload dual-region atau multi-region, lihat apakah masalahnya terbatas pada klien atau region Spanner tertentu.

  2. Periksa kondisi aplikasi klien Anda, terutama infrastruktur komputasi di sisi klien (misalnya, pemanfaatan VM, CPU, atau memori, koneksi, deskriptor file, dan sebagainya).

  3. Periksa latensi di komponen Spanner:

    a. Periksa latensi dua-arah klien dengan OpenTelemetry atau dengan OpenCensus.

    b. Periksa latensi Google Front End (GFE) dengan OpenTelemetry atau dengan OpenCensus.

    c. Periksa latensi permintaan Spanner API dengan OpenTelemetry atau dengan OpenCensus.

    Jika Anda memiliki latensi dua-arah klien yang tinggi, tetapi latensi GFE rendah, dan latensi permintaan Spanner API yang rendah, kode aplikasi mungkin mengalami masalah. Hal ini juga dapat menunjukkan masalah jaringan antara klien dan GFE regional. Jika aplikasi Anda memiliki masalah performa yang menyebabkan beberapa jalur kode menjadi lambat, latensi dua-arah klien untuk setiap permintaan API mungkin meningkat. Mungkin juga ada masalah pada infrastruktur komputasi klien yang tidak terdeteksi pada langkah sebelumnya.

  4. Periksa dimensi berikut untuk metrik Spanner:

    • Nama Database Spanner
    • Metode Spanner API
    • Status Spanner API

    Kelompokkan menurut dimensi-dimensi tersebut untuk melihat apakah masalahnya terbatas pada database, status, atau metode tertentu. Untuk workload dual-region atau multi-region, periksa apakah masalahnya terbatas pada region tertentu.

    Jika Anda mengalami latensi GFE yang tinggi, tetapi latensi permintaan Spanner API yang rendah, hal ini mungkin disebabkan oleh salah satu penyebab berikut:

    • Mengakses database dari region lain. Tindakan ini dapat menyebabkan latensi GFE yang tinggi dan latensi permintaan Spanner API yang rendah. Misalnya, traffic dari klien di region us-east1 yang memiliki instance di region us-central1 mungkin memiliki latensi GFE yang tinggi, tetapi latensi permintaan Spanner API yang lebih rendah.

    • Ada masalah di lapisan GFE. Periksa Google Cloud Dasbor Status untuk melihat apakah ada masalah jaringan yang sedang terjadi di region Anda. Jika tidak ada masalah, buka kasus dukungan dan sertakan informasi ini agar engineer dukungan dapat membantu memecahkan masalah GFE.

  5. Periksa pemakaian CPU instance. Jika pemakaian CPU instance berada di atas tingkat yang direkomendasikan, Anda harus menambahkan lebih banyak node secara manual, atau menyiapkan penskalaan otomatis. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penskalaan otomatis.

  6. Amati dan pecahkan masalah hotspot atau pola akses tidak seimbang yang berpotensi terjadi menggunakan Key Visualizer, lalu coba kembalikan perubahan kode aplikasi yang sangat berkorelasi dengan jangka waktu masalah.

  7. Periksa perubahan pola traffic.

  8. Periksa Insight kueri dan Insight transaksi untuk melihat apakah ada hambatan performa transaksi atau kueri.

  9. Gunakan prosedur di Kueri aktif terlama untuk melihat kueri biaya yang dapat menyebabkan hambatan performa dan batalkan kueri tersebut sesuai kebutuhan.

  10. Gunakan prosedur di bagian pemecahan masalah dalam topik berikut untuk memecahkan masalah lebih lanjut menggunakan alat introspeksi Spanner:

Langkah berikutnya