Mengidentifikasi tempat terjadinya latensi

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

  1. Di aplikasi klien yang memengaruhi layanan, pastikan terdapat peningkatan latensi dari latensi bolak-balik 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 ini untuk melihat apakah masalah tersebut terbatas pada klien, status, atau metode tertentu. Untuk workload multi-regional, lihat apakah masalahnya terbatas pada klien atau region Spanner tertentu.

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

  3. Periksa latensi di komponen Spanner:

    a. Periksa latensi bolak-balik 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 bolak-balik klien yang tinggi, tetapi latensi GFEnya rendah dan latensi permintaan Spanner API yang rendah, kode aplikasi mungkin akan mengalami masalah. Hal ini juga bisa 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 dapat meningkat. Mungkin juga ada masalah di infrastruktur komputasi klien yang tidak terdeteksi di langkah sebelumnya.

  4. Periksa dimensi berikut untuk metrik Spanner:

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

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

    Jika Anda memiliki latensi GFE yang tinggi, tetapi latensi permintaan Spanner API-nya rendah, hal tersebut 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 Dasbor Status Google Cloud untuk melihat apakah ada masalah jaringan yang sedang berlangsung 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 penggunaan 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 potensi hotspot atau pola akses yang tidak seimbang menggunakan Key Visualizer dan coba roll back perubahan kode aplikasi yang sangat berkorelasi dengan jangka waktu masalah.

  7. Periksa apakah ada perubahan pola traffic.

  8. Periksa Analisis kueri dan Insight transaksi untuk melihat apakah mungkin ada bottleneck performa kueri atau transaksi. Pada sebagian besar kasus, Anda harus mengikuti praktik terbaik Spanner untuk mengoptimalkan kueri atau transaksi.

  9. Gunakan prosedur dalam Kueri aktif terlama untuk mengetahui kueri biaya yang mungkin menyebabkan bottleneck performa dan membatalkan kueri sesuai kebutuhan.

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

Langkah selanjutnya