View a markdown version of this page

Pemantauan dan Pengoptimalan Konfigurasi untuk Timestream untuk InfluxDB 2 - Amazon Timestream
IkhtisarCloudWatch Referensi MetrikUkuran Instans dan Pedoman KinerjaOptimasi Konfigurasi menurut MetrikMemantau Praktik TerbaikPanduan Pemecahan Masalah

Untuk kemampuan serupa dengan Amazon Timestream LiveAnalytics, pertimbangkan Amazon Timestream untuk InfluxDB. Ini menawarkan konsumsi data yang disederhanakan dan waktu respons kueri milidetik satu digit untuk analitik waktu nyata. Pelajari lebih lanjut di sini.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemantauan dan Pengoptimalan Konfigurasi untuk Timestream untuk InfluxDB 2

Ikhtisar

Pemantauan dan pengoptimalan konfigurasi yang efektif sangat penting untuk menjaga kinerja, keandalan, dan efisiensi biaya yang optimal dalam Timestream Anda untuk penyebaran InfluxDB. Panduan ini memberikan panduan komprehensif tentang CloudWatch metrik, ambang kinerja, dan strategi penyetelan konfigurasi untuk membantu Anda mengelola instans InfluxDB secara proaktif.

CloudWatch Referensi Metrik

Amazon CloudWatch menyediakan metrik terperinci untuk memantau Timestream Anda untuk instans InfluxDB. Memahami metrik ini dan ambang batasnya sangat penting untuk menjaga kesehatan dan kinerja sistem.

Metrik Pemanfaatan Sumber Daya

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
CPUUtilization DbInstanceName Persentase CPU yang digunakan Persen

  • Pengembangan/Tumbuh: < 70%

  • Produksi: < 80%

  • Peringatan Kritis: > 90% selama 5+ menit
MemoryUtilization DbInstanceName Persentase memori yang digunakan Persen

  • Pengembangan/Tumbuh: < 70%

  • Produksi: < 80%

  • Peringatan Kritis: > 90%
HeapMemoryUsage DbInstanceName Jumlah memori heap yang digunakan Byte

  • Pantau pertumbuhan atau lonjakan yang stabil

  • Peringatan: Mendekati ukuran tumpukan maks
ActiveMemoryAllocation DbInstanceName Alokasi memori aktif saat ini Byte

  • Pantau lonjakan tak terduga

  • Bandingkan dengan total memori yang tersedia
DiskUtilization DbInstanceName Persentase ruang disk yang digunakan Persen

  • Pengembangan/Tumbuh: < 70%

  • Produksi: < 75%

  • Peringatan Kritis: > 85%

Metrik Operasi I/O

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
ReadOpsPerSec DbInstanceName Jumlah operasi baca per detik Hitungan/Detik

Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakan

Contoh: 12K IOPS → pertahankan < 8,400 IOPS total
WriteOpsPerSec DbInstanceName Jumlah operasi tulis per detik Hitungan/Detik

Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakan

Contoh: 12K IOPS → pertahankan < 8,400 IOPS total
Jumlah IOps PerSec DbInstanceName Total I/O operasi per detik (baca+tulis) Hitungan/Detik

Pertahankan ≥ 30% ruang kepala di bawah IOPS yang disediakan

Memantau terhadap kemampuan kelas instance

Metrik Throughput

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
ReadThroughput DbInstanceName Data membaca throughput Byte/Detik Pantau terhadap batas throughput penyimpanan
WriteThroughput DbInstanceName Throughput penulisan data Byte/Detik Pantau terhadap batas throughput penyimpanan

Metrik Kinerja API

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
APIRequestTarif DbInstanceName, Titik Akhir, Status Nilai permintaan API ke titik akhir tertentu dengan kode status (2xx, 4xx, 5xx) Hitungan/Detik

Tingkat kesalahan:

  • Kesalahan 4xx: < 1% dari permintaan

  • Kesalahan 5xx: < 0,1% dari permintaan

  • Peringatan: Lonjakan mendadak dalam tingkat kesalahan
QueryResponseVolume DbInstanceName, Titik Akhir, Status Volume tanggapan kueri berdasarkan titik akhir dan kode status Byte

  • Pantau respons yang luar biasa besar

  • Peringatan: Tanggapan > 10MB secara konsisten

Metrik Eksekusi Kueri

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
QueryRequestsTotal DbInstanceName, Hasil Jumlah total permintaan kueri berdasarkan jenis hasil (sukses, runtime_error, compile_error, queue_error) Hitungan

Tingkat keberhasilan: > 99%

Tingkat kesalahan:

  • runtime_error: < 0,5%

  • compile_error: < 0,1%

  • queue_error: < 0,1%

Metrik Organisasi Data

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang Kritis
SeriesCardinality DbInstanceName, Ember Jumlah deret waktu unik dalam ember Hitungan

  • <100K: Performa luar biasa

  • <1M: Performa bagus

  • 1M - 5M: Dampak sedang, membutuhkan penyetelan

  • 5M - 10M: Dampak signifikan, diperlukan pengoptimalan yang cermat

  • > 10M: KRITIS - Pertimbangkan InfluxDB 3.0
TotalBuckets DbInstanceName Jumlah total ember dalam instance Hitungan

  • Pantau pertumbuhan dari waktu ke waktu

  • Pertimbangkan konsolidasi jika > 100 ember

Metrik Sistem Kesehatan

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
EngineUptime DbInstanceName Waktu mesin InfluxDB telah berjalan Detik

Pantau untuk restart yang tidak terduga

Peringatan: Uptime disetel ulang secara tak terduga
WriteTimeouts DbInstanceName Jumlah operasi tulis yang habis waktunya Hitungan

Peringatan: > 0,1% dari operasi tulis

Kritis: Meningkatnya tren

Metrik Manajemen Tugas

CloudWatch Nama Metrik Dimensi Deskripsi Unit Ambang yang Direkomendasikan
ActiveTaskWorkers DbInstanceName Jumlah pekerja tugas aktif Hitungan

Pantau terhadap batas pekerja tugas yang dikonfigurasi

Peringatan: Secara konsisten maksimal
TaskExecutionFailures DbInstanceName Jumlah eksekusi tugas yang gagal Hitungan

Peringatan: > 1% dari eksekusi tugas

Kritis: Meningkatkan tingkat kegagalan

Memahami Hubungan Metrik Kunci

IOPS dan Hubungan Throughput

Aturan Headroom 30%: Selalu pertahankan setidaknya 30% ruang kepala antara operasi berkelanjutan Anda per detik dan IOPS yang Anda berikan. Ini menyediakan buffer untuk:

  • Operasi pemadatan (dapat melonjak IOPS secara signifikan)

  • Setiap database restart untuk berjalan dengan lancar

  • Kueri meledak selama penggunaan puncak

  • Tulis lonjakan dari konsumsi batch

  • Operasi pemeliharaan indeks

Contoh Perhitungan:

  • IOPS yang disediakan: 12.000

  • Target IOPS Berkelanjutan Maksimum (Total IOpsPerSec): 8.400 (pemanfaatan 70%)

  • Ruang Kepala Cadangan: 3.600 IOPS (30%)

Jika Total IOps PerSec secara konsisten melebihi 8.400: → Tingkatkan tingkat penyimpanan atau optimalkan beban kerja

Formula Pemantauan:

Pemanfaatan IOPS% = (ReadOpsPerSec + WriteOpsPerSec)/IOPS yang Disediakan × 100

  • Target: Jaga Pemanfaatan IOPS < 70%

  • Peringatan: Pemanfaatan IOPS > 70%

  • Kritis: Pemanfaatan IOPS> 90%

Memahami Dampak Kinerja Kardinalitas Seri

Kardinalitas seri memiliki efek perkalian pada sumber daya sistem:

Hitungan Seri Dampak Memori Dampak Kinerja Kueri Dampak Ukuran Indeks Rekomendasi
< 100K Minimal Dapat diabaikan Kecil Konfigurasi standar
100K - 1M Sedang 10-20% lebih lambat Sedang Setel pengaturan cache
1M - 5M Signifikan 30-50% lebih lambat Besar Diperlukan optimasi agresif
5M - 10M Tinggi 50-70% lebih lambat Sangat Besar Penyetelan maksimum, pertimbangkan desain ulang
> 10M Parah 70% + lebih lambat Berlebihan Migrasi ke InfluxDB 3.0

Mengapa 10M adalah Ambang Kritis:

  • Arsitektur InfluxDB 2.x menggunakan pengindeksan dalam memori

  • Di luar seri 10M, operasi indeks menjadi sangat mahal

  • Kebutuhan memori tumbuh secara non-linier

  • Overhead perencanaan kueri meningkat secara dramatis

  • InfluxDB 3.0 menggunakan mesin penyimpanan kolumnar yang dirancang untuk kardinalitas tinggi

Ukuran Instans dan Pedoman Kinerja

Tabel berikut memberikan panduan tentang ukuran instans yang sesuai berdasarkan kardinalitas seri dan karakteristik beban kerja Anda:

Jumlah Seri Maks Menulis (baris/detik) Membaca (pertanyaan/detik) Instance yang Direkomendasikan Jenis Penyimpanan Kasus Penggunaan
< 100K ~ 50.000 < 10 db.influx.large Influx IO Termasuk 3K Penerapan kecil, pengembangan, pengujian
< 1M ~ 150.000 < 25 db.influx.2xlarge Influx IO Termasuk 3K Beban kerja produksi kecil hingga menengah
~ 1M ~ 200.000 ~ 25 db.influx.4xlarge Influx IO Termasuk 3K Beban kerja produksi sedang
< 5M ~ 250.000 ~35 db.influx.4xlarge Influx IO Termasuk 12K Beban kerja produksi besar
<10M ~ 500.000 ~50 db.influx.8xlarge Influx IO Termasuk 12K Beban kerja produksi yang sangat besar
~ 10M < 750.000 < 100 db.influx.12xlarge Influx IO Termasuk 12K Kapasitas maksimum InfluxDB 2.x
> 10M N/A N/A Migrasi ke InfluxDB 3.0 N/A Di luar jangkauan optimal InfluxDB 2.x

Optimasi Konfigurasi menurut Metrik

Pemanfaatan CPU Tinggi (CPUUtilization > 70%)

Gejala:

  • CPUUtilization> 70% berkelanjutan

  • QueryRequestsTotal(volume tinggi atau kueri lambat)

  • ActiveTaskWorkers(beban tugas tinggi)

Penyesuaian Konfigurasi:

Prioritas 1: Kontrol Konkurensi Kueri

  • query-concurrency: Setel ke 50-75% dari jumlah vCPU

  • Contoh: 8 vCPU instance → query-concurrency = 4-6

Prioritas 2: Batasi Kompleksitas Kueri

  • influxql-max-select-series: 10000 (mencegah kueri tak terbatas)

  • influxql-max-select-point: 100000000

  • query-queue-size: 2048 (mencegah penumpukan antrian)

Prioritas 3: Aktifkan Analisis Kueri

  • flux-log-enabled: TRUE (sementara untuk debugging)

  • log-level: info (atau debug untuk analisis terperinci)

Pertimbangan Penting:

Mengurangi query-concurrency akan membatasi jumlah kueri yang dapat dijalankan secara bersamaan, yang dapat meningkatkan kueri antrian dan menyebabkan latensi kueri yang lebih tinggi selama periode puncak. Pengguna mungkin mengalami pemuatan dasbor yang lebih lambat atau melaporkan batas waktu jika permintaan kueri melebihi batas konkurensi yang dikurangi.

Menyetel batas perlindungan (influxql-max-select-series,influxql-max-select-point) akan menyebabkan kueri yang melebihi ambang batas ini gagal dengan compile_error atau runtime_error di. QueryRequestsTotal Meskipun ini melindungi sistem dari kehabisan sumber daya, ini dapat merusak kueri yang ada yang sebelumnya berfungsi.

Praktik Terbaik: Sebelum menerapkan perubahan ini, analisis pola kueri Anda menggunakan QueryResponseVolumedan QueryRequestsTotalmetrik. Identifikasi dan optimalkan kueri yang paling mahal terlebih dahulu - cari kueri tanpa filter rentang waktu, kueri yang mencakup seri kardinalitas tinggi, atau kueri yang meminta titik data yang berlebihan. Mengoptimalkan kueri di tingkat aplikasi selalu lebih baik daripada memaksakan batas keras yang dapat merusak fungsionalitas.

Tindakan Perangkat Keras:

  • Skala ke kelas instance berikutnya dengan lebih banyak v CPUs

  • Tinjau pola kueri untuk peluang pengoptimalan

Pemanfaatan Memori Tinggi (MemoryUtilization > 70%)

Gejala:

  • MemoryUtilization> 70% berkelanjutan

  • HeapMemoryUsagetren ke atas

  • ActiveMemoryAllocationmenunjukkan paku

  • SeriesCardinality(kardinalitas tinggi meningkatkan penggunaan memori)

Penyesuaian Konfigurasi:

Prioritas 1: Kurangi Memori Cache

  • storage-cache-max-memory-ukuran: Setel ke 10-15% dari total RAM

  • Contoh: 32GB RAM → 3.355.443.200 hingga 5.033.164.800 byte

  • storage-cache-snapshot-memory-ukuran: 26.214,400 (25MB)

Prioritas 2: Batasi Memori Kueri

  • query-memory-bytes: Setel ke 60-70% dari total RAM

  • query-max-memory-bytes: Sama seperti query-memory-bytes

  • query-initial-memory-bytes: 10% dari query-memory-bytes

Prioritas 3: Optimalkan Cache Seri

  • storage-series-id-set-ukuran cache: Kurangi jika kardinalitas tinggi

  • Memori tinggi: 100-200

  • Normal: 500-1000

Pertimbangan Penting:

Sementara perubahan ini akan mengurangi tekanan memori, mereka akan memiliki dampak negatif langsung pada kinerja aplikasi. Mengurangi storage-cache-max-memory-size berarti lebih sedikit data yang di-cache dalam memori, memaksa lebih banyak pembacaan disk dan meningkatkan latensi kueri - Anda mungkin akan melihat ReadOpsPerSecpeningkatan dan waktu QueryResponseVolumerespons menurun.

Pembatasan query-memory-bytes akan menyebabkan kueri intensif memori gagal dengan runtime_error di QueryRequestsTotal, terutama kueri yang menggabungkan kumpulan data besar atau mengembalikan set hasil yang substansif. Pengguna mungkin mengalami kesalahan “kehabisan memori” untuk kueri yang sebelumnya berhasil.

Mengurangi storage-series-id-set-cache-size menurunkan kinerja untuk kueri terhadap data kardinalitas tinggi, karena sistem harus menghitung ulang hasil seri lebih sering daripada mengambilnya dari cache. Ini terutama memengaruhi dasbor yang berulang kali menanyakan kombinasi seri yang sama.

Praktik Terbaik: Sebelum menerapkan perubahan restriktif ini, analisis pola kueri Anda dan optimalkan terlebih dahulu:

  • Tinjau QueryResponseVolumeuntuk mengidentifikasi kueri yang mengembalikan data yang berlebihan

  • Gunakan QueryRequestsTotaluntuk menemukan kueri yang sering dijalankan yang dapat mengambil manfaat dari pengoptimalan

  • Tambahkan filter rentang waktu untuk mengurangi pemindaian data ke apa yang diperlukan untuk beban kerja Anda

  • Menerapkan caching hasil kueri di tingkat aplikasi

  • Pertimbangkan pra-agregasi data menggunakan tugas downsampling

  • Tinjau SeriesCardinalitydan optimalkan model data Anda untuk mengurangi tag yang tidak perlu

Pengoptimalan kueri harus selalu menjadi pendekatan pertama Anda - pembatasan konfigurasi harus menjadi pilihan terakhir ketika pengoptimalan tidak cukup.

Tindakan Perangkat Keras:

  • Tingkatkan ukuran instans untuk lebih banyak RAM

Pemanfaatan Penyimpanan Tinggi (DiskUtilization > 70%)

CloudWatch Metrik untuk Memantau:

  • DiskUtilization> 70%

  • WriteThroughputpola

  • TotalBuckets(banyak ember bertambah overhead)

Penyesuaian Konfigurasi:

Prioritas 1: Periksa Konfigurasi Logging

  • log-level: Pastikan disetel ke “info” (bukan “debug”)

  • flux-log-enabled: Setel ke FALSE kecuali secara aktif men-debug

Prioritas 2: Retensi Agresif

  • storage-retention-check-interval: 15m0s (pembersihan lebih sering)

Prioritas 3: Optimalkan Pemadatan

  • storage-compact-full-write-durasi-dingin: 2h0m0s (lebih sering)

  • storage-cache-snapshot-write-durasi-dingin: 5m0s

Prioritas 4: Kurangi Ukuran Indeks

  • storage-max-index-log-file-size: 524.288 (512KB untuk pemadatan lebih cepat)

Pertimbangan Penting:

Langkah Pertama Kritis - Periksa Konfigurasi Logging Anda: Sebelum membuat perubahan lain, verifikasi pengaturan logging Anda. Pencatatan debug dan log kueri Flux dapat menghabiskan ruang disk sebanyak atau lebih banyak daripada data deret waktu Anda yang sebenarnya, dan ini adalah salah satu penyebab paling umum dari kelelahan penyimpanan yang tidak terduga.

Dampak Penebangan:

  • log-level: debugmenghasilkan log yang sangat bertele-tele, berpotensi ratusan MB per jam

  • flux-log-enabled: TRUEmencatat setiap eksekusi kueri Flux dengan detail lengkap, membuat file log besar

  • Log ini terakumulasi dengan cepat dan sering diabaikan selama perencanaan kapasitas

  • File log dapat mengisi ruang disk lebih cepat daripada konsumsi data, terutama pada instance yang lebih kecil

  • Tidak seperti data deret waktu, log disimpan dalam penyimpanan lokal selama 24 jam sebelum penghapusan

Tindakan Segera jika Log Besar:

  1. Set log-level: info (dari debug)

  2. Set flux-log-enabled: FALSE

  3. Pantau DiskUtilizationuntuk perbaikan segera

Trade-off Konfigurasi Pemadatan:

Perubahan konfigurasi ini dirancang khusus untuk beban kerja dengan throughput konsumsi tinggi dan jendela retensi pendek di mana penggunaan disk berfluktuasi secara substansif. Mereka memaksa mesin pemadatan untuk bekerja lebih agresif, yang hanya bermanfaat dalam skenario tertentu.

Trade-off Kritis: Meningkatkan frekuensi pemadatan akan secara signifikan meningkatkan konsumsi sumber daya:

  • CPUUtilizationakan meningkat karena operasi pemadatan mengkonsumsi siklus CPU

  • MemoryUtilizationakan meningkat selama pemadatan karena data dimuat dan diproses

  • WriteOpsPerSecdan WriteThroughputakan melonjak selama jendela pemadatan, berpotensi melebihi ruang kepala IOPS 30% Anda

  • WriteTimeoutsdapat meningkat jika pemadatan I/O bersaing dengan penulisan aplikasi

Perubahan ini dapat menciptakan masalah kinerja cascading di mana pemadatan agresif mengkonsumsi sumber daya yang diperlukan untuk operasi kueri dan penulisan, menurunkan kinerja sistem secara keseluruhan bahkan sambil mengurangi penggunaan disk.

Praktik Terbaik: Sebelum menyesuaikan pengaturan pemadatan, fokuslah pada data dan manajemen logging:

  1. Periksa Logging Pertama (Masalah Paling Umum): Verifikasi log-level adalah “info” dan flux-log-enabled FALSE

  2. Tinjau Model Data Anda: Apakah Anda menulis data yang sebenarnya tidak Anda butuhkan? Bisakah Anda mengurangi pengukuran atau granularitas bidang?

  3. Optimalkan Kebijakan Retensi: Periksa TotalBucketsdan tinjau setelan retensi untuk setiap bucket

  4. Memantau Dampak Pemadatan: Garis dasar Anda CPUUtilization, MemoryUtilization, dan sebelum perubahan WriteOpsPerSec

Pendekatan Alternatif:

  • Meningkatkan kapasitas penyimpanan (seringkali lebih sederhana dan lebih hemat biaya)

  • Menerapkan strategi downsampling atau agregasi data

  • Konsolidasikan ember (kurangi TotalBuckets) untuk mengurangi overhead

  • Meninjau dan menegakkan kebijakan retensi secara lebih ketat

Hanya terapkan pengaturan pemadatan agresif jika Anda telah mengoptimalkan manajemen data dan mengonfirmasi instans Anda memiliki CPU, memori, dan ruang kepala IOPS yang cukup untuk menangani peningkatan beban.

Tindakan Perangkat Keras:

  • Meningkatkan kapasitas penyimpanan

Pemanfaatan IOPS Tinggi (ReadIOPS/WriteIOPS/TotalOperationsPerSecond> 70% dari yang disediakan)

CloudWatch Metrik untuk Memantau:

  • ReadOpsPerSec+ WriteOpsPerSec= Jumlah IOps PerSec

  • ReadThroughput dan WriteThroughput

  • Bandingkan dengan IOPS yang disediakan (3K, 12K, atau 16K)

Penyesuaian Konfigurasi:

Prioritas 1: Kontrol Pemadatan I/O

  • storage-max-concurrent-compactions: 2-3 (batasi pemadatan bersamaan)

  • storage-compact-throughput-burst: Sesuaikan berdasarkan kemampuan disk

  • 3K IOPS: 25.165.824 (24MB/s)

  • 12K IOPS: 50.331.648 (48MB/s)

Prioritas 2: Optimalkan Operasi Tulis

  • storage-wal-max-concurrent-menulis: 8-12

  • storage-wal-max-write-keterlambatan: 5m0s

Prioritas 3: Sesuaikan Waktu Snapshot

  • storage-cache-snapshot-write-durasi dingin: 15m0s (lebih jarang)

  • storage-compact-full-write-durasi dingin: 6h0m0s (lebih jarang)

Pertimbangan Penting:

Perubahan ini menciptakan trade-off yang signifikan antara I/O pemanfaatan dan kinerja sistem:

Membatasi Pemadatan I/O:

  • Mengurangi storage-max-concurrent-compactions akan memperlambat operasi pemadatan, menyebabkan file TSM menumpuk dan meningkat DiskUtilizationlebih cepat

  • Lebih rendah storage-compact-throughput-burst memperpanjang durasi pemadatan, menjaga pemadat tetap aktif lebih lama dan berpotensi memblokir operasi lain

  • Pemadatan yang lebih lambat berarti kinerja kueri menurun seiring waktu karena mesin penyimpanan harus membaca dari lebih banyak file TSM yang lebih kecil daripada yang terkonsolidasi

  • Anda mungkin melihat tingkat QueryRequestsTotalruntime_error meningkat karena batas waktu kueri sambil menunggu I/O

Mengurangi Frekuensi Snapshot:

  • Meningkat storage-cache-snapshot-write-cold-duration dan storage-compact-full-write-cold-duration berarti data tetap berada di log write-ahead (WAL) lebih lama

  • Ini meningkat MemoryUtilizationkarena lebih banyak data disimpan dalam cache sebelum dibuang ke disk

  • Risiko kehilangan data sedikit meningkat jika instance crash sebelum data cache dipertahankan

  • Waktu pemulihan setelah restart meningkat karena lebih banyak data WAL harus diputar ulang

Tulis Operasi Tuning:

  • Mengurangi storage-wal-max-concurrent-writes akan membuat serialisasi operasi penulisan lebih banyak, berpotensi meningkat WriteTimeoutsselama periode throughput tinggi

  • Meningkatnya storage-wal-max-write-delay berarti menulis mungkin menunggu lebih lama sebelum ditolak, yang dapat menutupi masalah kapasitas tetapi membuat pengguna frustrasi dengan respons yang lambat

Praktik Terbaik: Pemanfaatan IOPS yang tinggi biasanya menunjukkan bahwa Anda telah melampaui tingkat penyimpanan Anda daripada masalah konfigurasi. Sebelum membatasi I/O, analyze I/O pola dan mengoptimalkan sebelum membatasi.

Tindakan Perangkat Keras:

  • Tingkatkan ke tingkat penyimpanan IOPS yang lebih tinggi (3K → 12K)

  • Pastikan 30% headroom IOPS dipertahankan

Kardinalitas Seri Tinggi (SeriesCardinality > 1M)

CloudWatch Metrik untuk Memantau:

  • SeriesCardinalityper ember dan total

  • MemoryUtilization(meningkat dengan kardinalitas)

  • CPUUtilization(overhead perencanaan kueri)

  • QueryRequestsTotal(tingkat runtime_error dapat meningkat)

Penyesuaian Konfigurasi:

Prioritas 1: Optimalkan Penanganan Seri

  • storage-series-id-set-ukuran cache: 1000-2000 (meningkatkan cache)

  • storage-series-file-max-concurrent-snapshot-compactions: 4-8

Prioritas 2: Tetapkan Batas Perlindungan

  • influxql-max-select-series: 10000 (mencegah kueri pelarian)

  • influxql-max-select-buckets: 1000

Prioritas 3: Optimalkan Operasi Indeks

  • storage-max-index-log-ukuran file: 2.097.152 (2MB)

Pertimbangan Penting:

Kardinalitas seri tinggi pada dasarnya adalah masalah pemodelan data, bukan masalah konfigurasi. Perubahan konfigurasi hanya dapat mengurangi gejala - mereka tidak dapat menyelesaikan masalah yang mendasarinya.

Konfigurasi Trade-off:

Peningkatan storage-series-id-set-cache-size akan meningkatkan kinerja kueri dengan caching seri pencarian, tetapi dengan biaya peningkatan. MemoryUtilization Setiap entri cache menghabiskan memori, dan dengan jutaan seri, ini bisa sangat besar. Pantau HeapMemoryUsagedan ActiveMemoryAllocationsetelah melakukan perubahan ini.

Menyetel batas perlindungan (influxql-max-select-series,influxql-max-select-buckets) akan menyebabkan kueri yang sah gagal dengan compile_error QueryRequestsTotaljika melebihi ambang batas ini. Dasbor yang sebelumnya berfungsi dapat rusak, dan pengguna perlu memodifikasi kueri mereka. Ini sangat bermasalah untuk:

  • Memantau dasbor yang terkumpul di banyak host/layanan

  • Kueri analitik yang perlu membandingkan beberapa entitas

  • Peringatan kueri yang mengevaluasi kondisi di seluruh armada

Menyesuaikan storage-max-index-log-file-size dengan nilai yang lebih kecil meningkatkan frekuensi pemadatan indeks, yang meningkat CPUUtilizationdan WriteOpsPerSecsaat sistem melakukan pemeliharaan indeks yang lebih sering.

Pemahaman Kritis:

Ketika SeriesCardinalitymelebihi 5M, Anda mendekati batas arsitektur InfluxDB 2.x. Pada seri 10M+, kinerja menurun secara eksponensial terlepas dari konfigurasi:

  • Perencanaan kueri menjadi sangat mahal (tinggi) CPUUtilization

  • Kebutuhan memori tumbuh secara non-linier (tinggi) MemoryUtilization

  • Operasi indeks mendominasi I/O (ReadOpsPerSec, WriteOpsPerSec)

  • QueryRequestsTotaltingkat runtime_error meningkat karena batas waktu kueri atau memori knalpot

Praktik Terbaik: Perubahan konfigurasi adalah alat bantu pita sementara. Anda harus mengatasi akar penyebabnya:

  1. Analisis Model Data Anda:

    • Tinjau SeriesCardinalityper ember untuk mengidentifikasi area masalah

    • Identifikasi tag mana yang memiliki jumlah nilai unik yang tinggi

    • Cari nilai tag tak terbatas (UUIDs, stempel waktu, pengguna, sesi) IDs IDs

    • Temukan tag yang seharusnya berupa bidang

Tindakan Model Data:

  • Tinjau desain tag untuk mengurangi kardinalitas yang tidak perlu

  • Pertimbangkan untuk mengkonsolidasikan seri serupa

  • Jika > seri 10M: Rencanakan migrasi ke InfluxDB 3.0

Masalah Kinerja Kueri

CloudWatch Metrik untuk Memantau:

  • QueryRequestsTotalberdasarkan jenis hasil (sukses, runtime_error, compile_error, queue_error)

  • APIRequestNilai dengan Status = 500 atau Status = 499

  • QueryResponseVolume(tanggapan besar menunjukkan pertanyaan mahal)

Penyesuaian Konfigurasi:

Prioritas 1: Meningkatkan Sumber Daya Kueri

  • query-concurrency: Meningkat menjadi 75% dari v CPUs

  • query-memory-bytes: Alokasikan 70% dari total RAM

  • query-queue-size: 4096

Prioritas 2: Optimalkan Eksekusi Kueri

  • storage-series-id-set-ukuran cache: 1000 (meningkat untuk caching yang lebih baik)

  • http-read-timeout: 60-an (mencegah batas waktu prematur)

Prioritas 3: Tetapkan Batas yang Wajar

  • influxql-max-select-point: 100000000

  • influxql-max-select-series: 10000

  • influxql-max-select-buckets: 1000

Pertimbangan Penting:

Meningkatkan sumber daya kueri menciptakan persaingan sumber daya dan potensi ketidakstabilan sistem:

Pertukaran Alokasi Sumber Daya:

Peningkatan query-concurrency memungkinkan lebih banyak kueri untuk berjalan secara bersamaan, tetapi setiap kueri bersaing untuk CPU dan memori:

  • CPUUtilizationakan meningkat, berpotensi mencapai saturasi selama periode kueri puncak

  • MemoryUtilizationakan meningkat karena lebih banyak kueri mengalokasikan memori secara bersamaan

  • Jika Anda meningkatkan konkurensi tanpa sumber daya yang memadai, semua kueri melambat, bukan hanya beberapa antrian

  • Risiko kegagalan cascading jika kueri bersamaan menghabiskan sumber daya yang tersedia

Mengalokasikan lebih banyak query-memory-bytes berarti lebih sedikit memori yang tersedia untuk caching dan operasi lainnya:

  • HeapMemoryUsageakan meningkat

  • storage-cache-max-memory-sizemungkin perlu dikurangi untuk mengkompensasi

  • Lebih sedikit klik cache berarti kinerja kueri yang lebih tinggi ReadOpsPerSecdan lebih lambat

  • Sistem menjadi lebih rentan terhadap kelelahan memori jika kueri menggunakan alokasi penuh mereka

Peningkatan query-queue-size hanya menunda masalah - itu tidak menyelesaikan masalah kapasitas:

  • Kueri menunggu lebih lama dalam antrian, meningkatkan latensi end-to-end

  • Pengguna menganggap sistem lebih lambat meskipun throughput mungkin tidak berubah

  • Antrian besar dapat menutupi masalah kapasitas yang mendasarinya

  • QueryRequestsTotaltingkat queue_error menurun, tetapi pengalaman pengguna mungkin tidak membaik

Peningkatan http-read-timeout mencegah pembatalan kueri prematur, tetapi:

  • Kueri yang berjalan lama menghabiskan sumber daya lebih lama, mengurangi kapasitas untuk kueri lain

  • Pengguna menunggu lebih lama sebelum menerima kesalahan batas waktu

  • Dapat menyembunyikan kueri yang tidak efisien yang harus dioptimalkan

  • Dapat menyebabkan kehabisan sumber daya jika banyak kueri lambat menumpuk

Praktik Terbaik: Masalah kinerja kueri biasanya disebabkan oleh kueri yang tidak efisien, bukan sumber daya yang tidak mencukupi. Sebelum meningkatkan alokasi sumber daya:

  1. Menganalisis Pola Kueri:

    • Tinjau QueryResponseVolumeuntuk mengidentifikasi kueri yang mengembalikan data berlebihan (> 1MB)

    • Periksa pola QueryRequestsTotalruntime_error - apa yang menyebabkan kegagalan?

    • Cari APIRequestRate with Status=499 (batas waktu klien) - kueri terlalu lambat

    • Identifikasi kueri mahal yang sering dieksekusi

  2. Optimalkan Kueri Pertama:

    Kueri Umum Anti-pola:

    • Filter rentang waktu yang hilang → Tambahkan batas waktu eksplisit

    • Menanyakan semua seri → Tambahkan filter tag tertentu

    • Jendela agregasi berlebihan → Gunakan interval yang sesuai

    • Bidang yang tidak perlu di SELECT → Minta hanya data yang diperlukan

    • Tidak ada klausul LIMIT → Tambahkan batas yang wajar

  3. Solusi Tingkat Aplikasi:

    • Menerapkan caching hasil kueri (Redis, Memcached)

    • Gunakan tugas untuk pra-agregat pola umum

    • Tambahkan pagination untuk set hasil besar

    • Menerapkan pembatasan tingkat kueri per pengguna/dasbor

    • Gunakan data downsampled untuk kueri historis

  4. Verifikasi Ketersediaan Sumber Daya:

    • Periksa CPUUtilization- jika sudah > 70%, meningkatkan konkurensi akan memperburuk keadaan

    • Periksa MemoryUtilization- jika sudah > 70%, mengalokasikan lebih banyak memori kueri akan menyebabkan OOM

    • Verifikasi Total IOps PerSec memiliki 30% headroom sebelum meningkatkan beban kueri

Pendekatan yang Direkomendasikan:

  1. Mulailah dengan mengoptimalkan 10 kueri termahal teratas (oleh) QueryResponseVolume

  2. Menerapkan caching hasil kueri di tingkat aplikasi

  3. Hanya tingkatkan alokasi sumber daya jika kueri dioptimalkan dan metrik menampilkan headroom

  4. Skala ke kelas instance yang lebih besar jika beban kerja melebihi kapasitas saat ini

Tindakan Perangkat Keras:

  • Skala kapasitas komputasi Anda, kueri mendapat manfaat dari daya pemrosesan ekstra (v) CPUs

RegEx Perangkap Kinerja dalam Kueri Flux

Saat memfilter data di Flux, hindari menggunakan ekspresi reguler untuk kecocokan persis atau pencocokan pola sederhana, karena ini akan menimbulkan penalti kinerja yang signifikan. RegEx operasi di Flux berulir tunggal dan melewati indeks TSM yang mendasarinya sepenuhnya. Alih-alih memanfaatkan indeks tag InfluxDB yang dioptimalkan untuk pencarian cepat, RegEx filter memaksa mesin kueri untuk mengambil semua seri yang cocok dari penyimpanan dan melakukan perbandingan teks secara berurutan terhadap setiap nilai. Ini menjadi sangat bermasalah ketika:

  • Memfilter pada nilai tag yang tepat - Gunakan operator kesetaraan (==) atau contains() fungsi alih-alih RegEx pola seperti /^exact_value$/

  • Mencocokkan beberapa nilai tertentu - Gunakan in operator dengan larik nilai daripada pola pergantian seperti /(value1|value2|value3)/

  • Awalan sederhana atau pencocokan akhiran - Pertimbangkan untuk menggunakan strings.hasPrefix() atau strings.hasSuffix() fungsi, yang lebih efisien daripada jangkar RegEx

Untuk skenario yang membutuhkan beberapa kecocokan pola, restrukturisasi kueri Anda untuk menggunakan beberapa predikat filter yang dikombinasikan dengan operator logis, atau pra-filter menggunakan kesetaraan tag sebelum menerapkan operasi string yang lebih kompleks. Cadangan RegEx khusus untuk kasus yang membutuhkan pencocokan pola sebenarnya yang tidak dapat diekspresikan melalui operator perbandingan yang lebih sederhana.

Tulis Masalah Kinerja

CloudWatch Metrik untuk Memantau:

  • WriteTimeouts(peningkatan jumlah)

  • WriteOpsPerSec dan WriteThroughput

  • APIRequestNilai dengan Status = 500 untuk menulis titik akhir

  • QueryRequestsTotaldengan result=runtime_error selama penulisan

Penyesuaian Konfigurasi:

Prioritas 1: Optimalkan WAL Menulis

  • storage-wal-max-concurrent-menulis: 12-16

  • storage-wal-max-write-keterlambatan: 10m0s

  • http-write-timeout: 60-an

Prioritas 2: Optimalkan Snapshot Cache

  • storage-cache-snapshot-memory-ukuran: 52.428.800 (50MB)

  • storage-cache-snapshot-write-durasi-dingin: 10m0s

Prioritas 3: Validasi Bidang Kontrol

  • storage-no-validate-field-size: TRUE (jika sumber data dipercaya)

Pertimbangan Penting:

Penyetelan kinerja tulis melibatkan pertukaran yang cermat antara throughput, keandalan, dan konsumsi sumber daya:

Trade-off Konfigurasi WAL:

Peningkatan storage-wal-max-concurrent-writes memungkinkan lebih banyak operasi penulisan paralel, tetapi:

  • CPUUtilizationmeningkat karena lebih banyak utas tulis bersaing untuk CPU

  • MemoryUtilizationmeningkat karena lebih banyak data disangga dalam memori sebelum WAL flush

  • WriteOpsPerSecakan melonjak, berpotensi melebihi ruang kepala IOPS 30% Anda

  • Peningkatan pertengkaran untuk disk sebenarnya I/O dapat memperlambat penulisan individu

  • Jika Anda melebihi I/O kapasitas disk, WriteTimeoutsdapat meningkat daripada menurun

Meningkat storage-wal-max-write-delay berarti menulis menunggu lebih lama sebelum waktu habis:

  • Masker masalah kapasitas dengan membuat penulisan menunggu alih-alih gagal dengan cepat

  • Pengguna mengalami waktu respons tulis yang lebih lambat bahkan ketika penulisan akhirnya berhasil

  • Dapat menyebabkan penumpukan antrian tulis dan tekanan memori

  • Tidak benar-benar meningkatkan kapasitas - hanya menunda batas waktu

Meningkatkan kesalahan batas waktu penundaan yang http-write-timeout serupa:

  • Memungkinkan penulisan batch yang lebih besar untuk diselesaikan

  • Tetapi juga memungkinkan penulisan lambat untuk mengkonsumsi sumber daya lebih lama

  • Dapat menyembunyikan masalah kinerja yang mendasarinya

  • Dapat menyebabkan kelelahan sumber daya jika banyak penulisan lambat menumpuk

Trade-off Cache Snapshot:

Meningkat storage-cache-snapshot-memory-size berarti lebih banyak data terakumulasi dalam memori sebelum pembilasan:

  • MemoryUtilizationmeningkat secara signifikan

  • Risiko kehilangan data meningkat jika instance crash sebelum snapshot

  • Snapshot yang lebih besar membutuhkan waktu lebih lama untuk ditulis, menciptakan lonjakan yang lebih besar WriteOpsPerSec

  • Dapat meningkatkan throughput tulis dengan mengumpulkan lebih banyak data, tetapi dengan mengorbankan memori dan keandalan

Meningkatkan jepretan storage-cache-snapshot-write-cold-duration penundaan:

  • Lebih lanjut meningkat MemoryUtilizationkarena data tetap dalam cache lebih lama

  • Meningkatkan jendela risiko kehilangan data

  • Mengurangi WriteOpsPerSecfrekuensi tetapi menciptakan lonjakan yang lebih besar saat snapshot terjadi

  • Waktu pemulihan setelah restart meningkat karena lebih banyak WAL harus diputar ulang

Trade-off Validasi Bidang:

Pengaturan storage-no-validate-field-size: TRUE menonaktifkan validasi ukuran bidang:

  • Meningkatkan throughput penulisan dengan melewatkan pemeriksaan validasi

  • Risiko Kritis: Memungkinkan data yang salah bentuk atau berbahaya ditulis

  • Dapat menyebabkan kerusakan data jika penulisan berisi ukuran bidang yang tidak valid

  • Membuat masalah data debugging jauh lebih sulit

  • Gunakan hanya jika Anda memiliki kontrol penuh dan kepercayaan atas sumber data Anda

Praktik Terbaik: Masalah kinerja tulis biasanya menunjukkan batas kapasitas atau pola penulisan yang tidak efisien. Sebelum menyetel konfigurasi:

  1. Analisis Pola Tulis:

    • Ulasan WriteThroughputdan WriteOpsPerSectren

    • Periksa WriteTimeoutskorelasi dengan beban tulis

    • APIRequestTingkat Monitor untuk menulis titik akhir berdasarkan kode status

    • Identifikasi ukuran dan frekuensi batch tulis

  2. Optimalkan Operasi Tulis Pertama:

    Tulis Umum Anti-pola:

    • Menulis poin individu → Batch menulis (5.000-10.000 poin)

    • Terlalu sering menulis → Buffer dan batch

    • Penulisan sinkron → Terapkan antrian tulis async

    • Semburan tulis tanpa batas → Menerapkan pembatasan laju

    • Menulis presisi yang tidak perlu → Stempel waktu bundar dengan tepat

  3. Verifikasi I/O Kapasitas:

    • Periksa Total IOps PerSec - jika sudah > 70%, meningkatkan konkurensi WAL akan memperburuk keadaan

    • Tinjau WriteOpsPerSecselama periode puncak

    • Pastikan ruang kepala IOPS 30% ada sebelum menyetel pengaturan tulis

    • Pertimbangkan apakah 3K IOPS cukup atau jika tingkat 12K IOPS diperlukan

  4. Perbaikan Tingkat Aplikasi:

    • Terapkan buffering tulis dengan ukuran batch yang dapat dikonfigurasi

    • Tambahkan logika coba lagi tulis dengan backoff eksponensial

    • Gunakan operasi tulis asinkron

    • Menerapkan pembatasan laju tulis selama periode puncak

    • Pantau kedalaman antrian tulis dan terapkan tekanan balik

Pendekatan yang Direkomendasikan:

  1. Mulailah dengan mengoptimalkan ukuran batch tulis di tingkat aplikasi (bertujuan untuk 5.000-10.000 poin per batch)

  2. Menerapkan operasi buffering tulis dan async

  3. Verifikasi Total IOps PerSec memiliki ruang kepala yang memadai

  4. Tingkatkan ke tingkat penyimpanan berikutnya (3K IOPS → 12K IOPS → 16K IOPS) jika secara konsisten di atas 70% pemanfaatan

  5. Hanya atur pengaturan WAL jika penulisan dioptimalkan dan I/O kapasitasnya memadai

  6. Jangan pernah menonaktifkan validasi bidang kecuali Anda memiliki kontrol penuh atas sumber data

Tindakan Perangkat Keras:

  • Tingkatkan ke penyimpanan IOPS yang lebih tinggi (3K → 12K → 16K)

  • Pastikan I/O headroom memadai

  • Skala ke kelas instance yang lebih besar jika CPU atau memori dibatasi

Memantau Praktik Terbaik

CloudWatch Konfigurasi Alarm

Alarm Kritis (Diperlukan Tindakan Segera):

CPUUtilization:

  • Ambang batas: > 90% selama 5 menit

  • Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Penskalaan Komputasi

MemoryUtilization:

  • Ambang batas: > 90% selama 5 menit

  • Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Penskalaan Komputasi

DiskUtilization:

  • Ambang batas: > 85%

  • Tindakan: Cobalah untuk mengosongkan ruang dengan menghapus bucket lama, memperbarui konfigurasi retensi atau Storage Scaling

Jumlah IOpsPerSec:

  • Ambang batas: > 90% dari yang disediakan selama 10 menit

  • Tindakan: Menerapkan langkah-langkah remediasi lalu lintas atau Meningkatkan IOPS

SeriesCardinality:

  • Ambang: > 10.000.000

  • Tindakan: Tinjau model Data Anda, jika tidak ada perubahan yang memungkinkan, jelajahi migrasi ke InfluxDB 3 atau pisahkan data Anda

EngineUptime:

  • Ambang batas: Reset tak terduga (< 300 detik)

  • Tindakan: Periksa apakah itu bertepatan dengan jendela pemeliharaan, jika tidak membuat tiket ke dukungan Timestream.

Alarm Peringatan (Diperlukan Investigasi):

CPUUtilization:

  • Ambang batas: > 70% selama 15 menit

  • Tindakan: meninjau perubahan beban kerja atau lalu lintas

MemoryUtilization:

  • Ambang batas: > 70% selama 15 menit

  • Tindakan: meninjau perubahan beban kerja atau lalu lintas

DiskUtilization:

  • Ambang batas: > 70%

  • Tindakan: Meninjau kebijakan retensi

Jumlah IOpsPerSec:

  • Ambang batas: > 70% dari yang disediakan selama 15 menit

  • Tindakan: meninjau perubahan beban kerja atau lalu lintas

QueryRequestsTotal (runtime_error):

  • Ambang batas: > 1% dari total kueri

  • Tindakan: meninjau perubahan beban kerja atau lalu lintas

WriteTimeouts:

  • Ambang: > 1% dari operasi tulis

  • Tindakan: meninjau perubahan beban kerja atau lalu lintas

SeriesCardinality:

  • Ambang: > 5.000.000

  • Tindakan: Tinjau optimasi model data

Daftar Periksa Pemantauan Proaktif

Setiap hari:

  • APIRequestTingkat Tinjauan untuk lonjakan kesalahan (400, 404, 499, 500)

  • Periksa tingkat QueryRequestsTotal runtime_error dan queue_error

  • Verifikasi WriteTimeouts jumlah minimal

  • Periksa alarm kritis apa pun

  • Verifikasi EngineUptime (tidak ada restart yang tidak terduga)

Mingguan:

  • Ulasan CPUUtilization, MemoryUtilization, dan DiskUtilization tren

  • Menganalisis QueryRequestsTotal pola berdasarkan jenis hasil

  • Periksa tingkat SeriesCardinality pertumbuhan per ember

  • Tinjau Tren IOps PerSec pemanfaatan total

  • Verifikasi parameter konfigurasi optimal

  • TaskExecutionFailures Pola ulasan

Bulanan:

  • Tinjauan perencanaan kapasitas (proyek 3-6 bulan ke depan)

  • Bandingkan metrik saat ini dengan tabel ukuran

  • Meninjau dan mengoptimalkan kebijakan retensi

  • Menganalisis pola kueri dari APIRequest Rate dan QueryResponseVolume

  • Tinjauan SeriesCardinality dan efisiensi model data

  • Menilai kebutuhan misalnya penskalaan atau perubahan konfigurasi

  • Tinjau TotalBuckets dan peluang konsolidasi

Panduan Pemecahan Masalah

Skenario: Degradasi Kinerja Mendadak

Langkah Investigasi:

Periksa Perubahan Terbaru:

  • Modifikasi parameter konfigurasi di Konsol AWS Manajemen

  • Perubahan penerapan aplikasi

  • Perubahan pola kueri

  • Modifikasi model data

  • Perubahan infrastruktur (tipe instance, penyimpanan)

Tinjau CloudWatch Metrik:

  • Lonjakan CPU? → Periksa CPUUtilization, QueryRequestsTotal

  • Tekanan memori? → Periksa MemoryUtilization, HeapMemoryUsage, ActiveMemoryAllocation

  • Saturasi IOPS? → Periksa Total IOpsPerSec, ReadOpsPerSec, WriteOpsPerSec

  • Seri kardinalitas melompat? → Periksa SeriesCardinality pertumbuhan

  • Tingkat kesalahan meningkat? → Periksa QueryRequestsTotal (runtime_error), APIRequest Nilai (Status = 500)

  • Restart yang tidak terduga? → Periksa EngineUptime

Aktifkan Pencatatan Terperinci:

Perubahan konfigurasi:

  • tingkat log: debug

  • flux-log-enabled: BENAR

Monitor selama 1-2 jam, lalu tinjau log

Kembali ke tingkat log: info setelah penyelidikan

Langkah Resolusi:

  • Menerapkan perubahan konfigurasi yang sesuai berdasarkan temuan

  • Skala sumber daya jika batas tercapai

  • Optimalkan kueri atau model data jika diperlukan

  • Menerapkan pembatasan laju jika beban tiba-tiba meningkat

Skenario: Kelelahan Memori

Gejala:

  • MemoryUtilization > 90%

  • HeapMemoryUsage mendekati maksimum

  • QueryRequestsTotal menampilkan runtime_error (kehabisan memori)

  • APIRequestNilai yang menunjukkan Status = 500

Langkah Resolusi:

Tindakan Segera (jika kritis):

  1. Mulai ulang instance untuk menghapus memori (jika aman untuk melakukannya)

  2. Mengurangi query-concurrency untuk sementara

  3. Hilangkan kueri yang berjalan lama jika memungkinkan

Perubahan Konfigurasi:

Prioritas 1: Kurangi Memori Cache

  • storage-cache-max-memory-ukuran: Kurangi hingga 10% dari RAM

  • Contoh: 32GB → 3.355.443.200 byte

  • storage-cache-snapshot-memory-ukuran: 26.214,400 (25MB)

Prioritas 2: Batasi Memori Kueri

  • query-memory-bytes: Setel ke 60% dari total RAM

  • query-max-memory-bytes: Pertandingan query-memory-bytes

  • query-initial-memory-bytes: 10% dari query-memory-bytes

Prioritas 3: Tetapkan Batas Perlindungan

  • influxql-max-select-series: 10000

  • influxql-max-select-point: 100000000

  • query-concurrency: Kurangi hingga 50% dari v CPUs

Solusi Jangka Panjang:

  • Optimalkan model data untuk mengurangi SeriesCardinality

  • Menerapkan batas ukuran hasil kueri di tingkat aplikasi

  • Tambahkan penegakan batas waktu kueri

  • Tinjau pertanyaan yang paling umum untuk memastikan ini mengikuti praktik terbaik yang disebutkan di bagian Masalah Kinerja Kueri

Skenario: Dampak Kardinalitas Seri Tinggi

Tinjau CloudWatch metrik:

  • SeriesCardinality> 5M

  • MemoryUtilizationtinggi

  • QueryRequestsTotalmenunjukkan peningkatan runtime_error

  • CPUUtilizationmeningkat karena overhead perencanaan kueri

Langkah Investigasi:

Menganalisis Pertumbuhan Kardinalitas:

  • SeriesCardinality tingkat pertumbuhan (harian/mingguan)

  • Proyeksi ke ambang 10M

  • Identifikasi sumber kardinalitas tinggi

  • Tinjau desain dan penggunaan tag

Menilai Dampak Kinerja:

  • Bandingkan tingkat QueryRequestsTotalkeberhasilan peningkatan before/after kardinalitas

  • MemoryUtilizationKorelasi ulasan

  • Periksa CPUUtilizationpola

  • Menganalisis QueryResponseVolumetren

Identifikasi Sumber Kardinalitas:

Tinjau model data:

  • Ember mana yang paling tinggi? SeriesCardinality

  • Tag mana yang memiliki jumlah nilai unik yang tinggi?

  • Apakah ada tag yang tidak perlu?

  • Apakah nilai tag tidak terbatas (UUIDs, stempel waktu, dll.)?

Tinjau Konfigurasi Saat Ini:

Periksa parameter pengoptimalan:

  • storage-series-id-set-cache-size: Nilai saat ini?

  • influxql-max-select-series: Apakah itu membatasi kueri pelarian?

  • storage-max-index-log-file-size: Sesuai untuk kardinalitas?

Langkah Resolusi:

Perubahan Konfigurasi Segera:

Prioritas 1: Optimalkan Penanganan Seri

  • storage-series-id-set-ukuran cache: 1500-2000

  • storage-series-file-max-concurrent-snapshot-compactions: 6-8

  • storage-max-index-log-ukuran file: 2.097.152 (2MB)

Prioritas 2: Tetapkan Batas Perlindungan

  • influxql-max-select-series: 10000

  • influxql-max-select-buckets: 1000

  • query-concurrency: Kurangi jika memori dibatasi

Prioritas 3: Meningkatkan Sumber Daya

  • Skala ke tingkat instance berikutnya

  • Meningkatkan alokasi memori

  • Pertimbangkan tingkat penyimpanan 12K IOPS

Perencanaan Migrasi (jika > seri 10M):

  • InfluxDB 3.0 menawarkan kinerja kardinalitas tinggi yang unggul

  • Rencanakan jadwal migrasi (2-3 bulan)

  • Uji dengan subset data terlebih dahulu

  • Mempersiapkan aplikasi untuk migrasi

  • InfluxDB 3.0 menggunakan penyimpanan kolumnar yang dioptimalkan untuk miliaran seri

Skenario: Penumpukan Antrian Kueri

Tinjau CloudWatch metrik:

  • QueryRequestsTotaldengan result=queue_error meningkat (kueri ditolak)

  • APIRequestNilai dengan Status = 429 atau Status = 503 (layanan banyak permintaan) unavailable/too

  • CPUUtilizationdapat meningkat (> 70%) yang menunjukkan saturasi sumber daya

  • MemoryUtilizationmungkin tinggi (> 70%) membatasi kapasitas kueri

  • QueryResponseVolumemenunjukkan ukuran respons yang besar (kueri mengambil sumber daya yang berlebihan)

Langkah Investigasi:

Analisis Metrik Antrian dan Konkurensi:

  • Tinjau QueryRequestsTotalrincian berdasarkan jenis hasil:

    • Jumlah queue_error yang tinggi menunjukkan kueri ditolak

    • Bandingkan tingkat keberhasilan dengan baseline - apakah itu menurun?

    • Periksa peningkatan runtime_error (kueri gagal setelah memulai)

  • Pola APIRequestTingkat Monitor:

    • Cari Status = 429 (terlalu banyak permintaan) atau Status = 503 (layanan tidak tersedia)

    • Identifikasi titik akhir mana yang mengalami penolakan

    • Periksa tren tingkat permintaan dari waktu ke waktu

Tinjau Pemanfaatan Sumber Daya:

  • CPUUtilizationselama periode antrian tinggi:

    • Jika > 70%, kueri terikat CPU dan tidak dapat dijalankan lebih cepat

    • Jika < 50%, batas antrian mungkin terlalu ketat

  • MemoryUtilizationkorelasi:

    • Memori tinggi mungkin membatasi konkurensi kueri

    • Periksa HeapMemoryUsagedan ActiveMemoryAllocationuntuk tekanan memori

  • IOpsPerSecPola total:

    • Tinggi I/O mungkin memperlambat eksekusi kueri

    • Periksa apakah kueri terikat I/O

Identifikasi Pola Kueri:

  • Ulasan QueryResponseVolume:

    • Apakah kueri mengembalikan data yang berlebihan (> 1MB)?

    • Identifikasi titik akhir dengan volume respons terbesar

    • Cari pola dalam kueri mahal

  • Menganalisis QueryRequestsTotaltingkat:

    • Berapa tingkat kueri per detik?

    • Apakah ada pola burst atau beban tinggi yang berkelanjutan?

    • Bandingkan dengan kapasitas instance dari tabel ukuran

  • Periksa APIRequestTingkat berdasarkan titik akhir:

    • Titik akhir kueri mana yang memiliki lalu lintas tertinggi?

    • Apakah ada kueri duplikat atau berlebihan?

Periksa Ketersediaan Sumber Daya:

  • Bandingkan metrik saat ini dengan rekomendasi tabel ukuran:

    • SeriesCardinalityvs. kapasitas kelas instance

    • Tingkat kueri vs. kueri yang direkomendasikan per detik

    • CPUUtilizationdan ruang MemoryUtilizationkepala

  • Verifikasi kapasitas IOPS:

    • Total IOps PerSec harus memiliki 30% headroom

    • Periksa apakah kueri sedang menunggu pada disk I/O

Langkah Resolusi:

Perubahan Konfigurasi:

Prioritas 1: Meningkatkan Kapasitas Antrian

  • query-queue-size: 4096 (dari default 1024)

Prioritas 2: Meningkatkan Konkurensi (jika sumber daya memungkinkan)

  • query-concurrency: Meningkat menjadi 75% dari v CPUs

  • Contoh: 16 vCPU → query-concurrency = 12

  • Verifikasi CPUUtilization tetap < 80% setelah perubahan

  • Verifikasi MemoryUtilization tetap < 80% setelah perubahan

Prioritas 3: Optimalkan Eksekusi Kueri

  • query-memory-bytes: Pastikan alokasi yang memadai

  • storage-series-id-set-ukuran cache: 1000-1500

  • http-read-timeout: 120s (mencegah batas waktu prematur)

Prioritas 4: Tetapkan Batas Perlindungan

  • influxql-max-select-series: 10000

  • influxql-max-select-point: 100000000

Solusi Tingkat Aplikasi:

  • Menerapkan caching hasil kueri (Redis, Memcached)

    • Hasil cache untuk kueri yang sering dieksekusi

    • Tetapkan sesuai TTLs berdasarkan persyaratan kesegaran data

    • Memantau laju hit cache

  • Gunakan kueri berkelanjutan untuk melakukan pra-agregasi pola umum

    • Pra-hitung agregasi umum

    • Kueri data pra-agregat alih-alih data mentah

  • Tambahkan pagination untuk set hasil besar

    • Batasi ukuran kueri awal

    • Muat data tambahan sesuai permintaan

  • Menerapkan pembatasan tingkat kueri per pengguna/dasbor

    • Mencegah pengguna tunggal dari kewalahan sistem

    • Tetapkan kuota penggunaan wajar

  • Gunakan data downsampled untuk kueri historis

    • Kueri data resolusi rendah untuk rentang waktu yang lebih lama

    • Cadangan kueri resolusi penuh untuk data terbaru

Keputusan Penskalaan:

  • Jika CPUUtilization > 70% berkelanjutan: Skala ke instance yang lebih besar

  • Jika MemoryUtilization > 70% berkelanjutan: Skala ke instance yang dioptimalkan untuk memori

  • Jika tingkat kueri melebihi kapasitas instans: Skala ke tingkat berikutnya per tabel ukuran