Mengidentifikasi tempat terjadinya latensi

Halaman 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 Anda, pastikan ada 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 masalahnya terbatas pada klien, status, atau metode tertentu. Untuk workload multi-region atau region ganda, lihat apakah masalahnya terbatas pada klien atau region Spanner tertentu.

  2. Periksa kesehatan aplikasi klien Anda, terutama infrastruktur komputasi di sisi klien (misalnya, penggunaan VM, CPU, atau memori, koneksi, deskripsi 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 bolak-balik klien yang tinggi, tetapi latensi GFE rendah, dan latensi permintaan Spanner API rendah, kode aplikasi mungkin memiliki 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 bolak-balik klien untuk setiap permintaan API mungkin akan meningkat. Mungkin juga ada masalah dalam 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 masalahnya terbatas pada database, status, atau metode tertentu. Untuk workload multi-region atau region ganda, periksa untuk melihat apakah masalahnya terbatas pada region tertentu.

    Jika Anda memiliki latensi GFE yang tinggi, tetapi latensi permintaan Spanner API rendah, hal ini mungkin disebabkan oleh salah satu hal 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 penggunaan 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 informasi selengkapnya, lihat Ringkasan penskalaan otomatis.

  6. Amati dan pecahkan masalah potensi hotspot atau pola akses yang tidak seimbang menggunakan Key Visualizer dan 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 mungkin ada bottleneck performa kueri atau transaksi.

  9. Gunakan prosedur di Kueri aktif terlama untuk melihat kueri pengeluaran yang mungkin menyebabkan bottleneck performa dan membatalkan kueri sesuai kebutuhan.

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

Langkah selanjutnya