Masalah koneksi persisten - Amazon ElastiCache
Grup keamananJaringan ACLsTabel ruteDNSresolusiMengidentifikasi masalah dengan diagnostik sisi serverValidasi konektivitas jaringanBatas terkait jaringanCPUPemakaianKoneksi yang dihentikan dari sisi serverPemecahan masalah sisi klien untuk instans Amazon EC2Membedah waktu yang dibutuhkan untuk menyelesaikan satu permintaan tunggal

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

Masalah koneksi persisten

Item berikut harus diverifikasi saat memecahkan masalah konektivitas persisten dengan: ElastiCache

Grup keamanan

Grup Keamanan adalah firewall virtual yang melindungi ElastiCache klien Anda (EC2misalnya, AWS Lambda fungsi, ECS wadah Amazon, dll.) dan ElastiCache cache. Grup keamanan bersifat stateful, artinya bahwa setelah lalu lintas masuk atau keluar diizinkan, maka tanggapan untuk lalu lintas itu akan secara otomatis mendapatkan otorisasi dalam konteks grup keamanan tertentu itu.

Fitur stateful mensyaratkan grup keamanan melacak semua koneksi yang diberikan otorisasi, dan terdapat batasan untuk koneksi dilacak. Jika batas itu tercapai, maka koneksi baru akan gagal. Silakan merujuk ke bagian pemecahan masalah untuk bantuan tentang cara mengidentifikasi apakah batas telah tercapai pada klien atau ElastiCache sisi.

Anda dapat memiliki satu grup keamanan yang ditetapkan secara bersamaan ke klien dan ElastiCache klaster, atau grup keamanan individual untuk masing-masing grup.

Untuk kedua kasus, Anda perlu mengizinkan lalu lintas TCP keluar di ElastiCache port dari sumber dan lalu lintas masuk pada port yang sama ke. ElastiCache Port default adalah 11211 untuk Memcached, dan 6379 untuk Valkey atau Redis. OSS Secara default, grup keamanan mengizinkan semua lalu lintas ke luar. Dalam kasus ini, hanya aturan masuk di target grup keamanan yang diperlukan.

Untuk informasi selengkapnya, lihat Pola akses untuk mengakses ElastiCache klaster di Amazon VPC.

Jaringan ACLs

Network Access Control Lists (ACLs) adalah aturan stateless. Lalu lintas harus diizinkan di kedua arah (masuk dan keluar) agar koneksi berhasil. Jaringan ACLs ditugaskan ke subnet, bukan sumber daya khusus. Dimungkinkan untuk memiliki yang sama ACL ditugaskan ke ElastiCache dan sumber daya klien, terutama jika mereka berada di subnet yang sama.

Secara default, jaringan ACLs memungkinkan semua lintasan. Namun, dimungkinkan untuk menyesuaikan ACL agar menolak atau mengizinkan lalu lintas. Selain itu, evaluasi ACL aturan bersifat berurutan, yang berarti bahwa aturan dengan angka terendah yang cocok dengan lalu lintas akan memungkinkan atau menolaknya. Konfigurasi minimum untuk memungkinkan OSS lalu lintas Valkey atau Redis adalah:

Jaringan sisi klienACL:

  • Aturan Masuk:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: TCP Aturan Kustom;

  • Protokol: TCP

  • Rentang Port: 1024-65535

  • Sumber: 0.0.0.0/0 (atau buat aturan individual untuk subnet cluster) ElastiCache

  • Izinkan/Tolak: Izinkan

  • Aturan keluar:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: TCP Aturan Kustom;

  • Protokol: TCP

  • Rentang Port: 6379

  • Sumber: 0.0.0.0/0 (atau subnet cluster. ElastiCache Ingatlah bahwa menggunakan spesifik IPs dapat menimbulkan masalah jika terjadi failover atau penskalaan cluster)

  • Izinkan/Tolak: Izinkan

ElastiCache JaringanACL:

  • Aturan Masuk:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: TCP Aturan Kustom;

  • Protokol: TCP

  • Rentang Port: 6379

  • Sumber: 0.0.0.0/0 (atau buat aturan individual untuk subnet cluster) ElastiCache

  • Izinkan/Tolak: Izinkan

  • Aturan keluar:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: TCP Aturan Kustom;

  • Protokol: TCP

  • Rentang Port: 1024-65535

  • Sumber: 0.0.0.0/0 (atau subnet cluster. ElastiCache Ingatlah bahwa menggunakan spesifik IPs dapat menimbulkan masalah jika terjadi failover atau penskalaan cluster)

  • Izinkan/Tolak: Izinkan

Untuk informasi selengkapnya, lihat Jaringan ACLs.

Tabel rute

Sama halnya dengan NetworkACLs, setiap subnet dapat memiliki tabel rute yang berbeda. Jika klien dan ElastiCache cluster berada dalam subnet yang berbeda, pastikan bahwa tabel rute mereka memungkinkan mereka untuk mencapai satu sama lain.

Lingkungan yang lebih kompleks, yang melibatkan beberapaVPCs, perutean dinamis, atau firewall jaringan, mungkin menjadi sulit untuk dipecahkan. Lihat Validasi konektivitas jaringan untuk mengonfirmasi bahwa pengaturan jaringan Anda sesuai.

DNSresolusi

ElastiCache menyediakan titik akhir layanan berdasarkan DNS nama. Titik akhir yang tersedia adalah Configuration, Primary, Reader, dan titik akhir Node. Untuk informasi selengkapnya, lihat Menemukan Titik Akhir Koneksi.

Dalam hal failover atau perubahan klaster, alamat yang terkait dengan nama titik akhir mungkin berubah dan akan diperbarui secara otomatis.

DNSPengaturan khusus (yaitu, tidak menggunakan VPC DNS layanan) mungkin tidak mengetahui DNS nama ElastiCache yang disediakan. Pastikan sistem Anda berhasil menyelesaikan ElastiCache titik akhir menggunakan alat sistem seperti dig (seperti yang ditunjukkan berikut) ataunslookup.

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

Anda juga dapat memaksakan resolusi nama melalui VPC DNS layanan:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Mengidentifikasi masalah dengan diagnostik sisi server

CloudWatch metrik dan informasi run-time dari ElastiCache mesin adalah sumber umum atau informasi untuk mengidentifikasi potensi sumber masalah koneksi. Analisis yang baik biasanya dimulai dengan item berikut:

  • CPUpenggunaan: Valkey dan Redis OSS adalah aplikasi multi-threaded. Namun, pelaksanaan dari setiap perintah terjadi dalam satu thread tunggal (utama). Untuk alasan ini, ElastiCache berikan metrik CPUUtilization danEngineCPUUtilization. EngineCPUUtilizationmenyediakan CPU pemanfaatan yang didedikasikan untuk OSS proses Valkey atau Redis, dan penggunaan CPUUtilization di semua. vCPUs Node dengan lebih dari satu v CPU biasanya memiliki nilai yang berbeda untuk CPUUtilization danEngineCPUUtilization, yang kedua biasanya lebih tinggi. Tinggi EngineCPUUtilization dapat disebabkan oleh peningkatan jumlah permintaan atau operasi kompleks yang membutuhkan banyak CPU waktu untuk menyelesaikannya. Anda dapat mengidentifikasi keduanya dengan berikut ini:

    • Peningkatan jumlah permintaan: Periksa peningkatan pada metrik lain yang cocok dengan pola EngineCPUUtilization. Metrik yang berguna adalah:

      • CacheHits dan CacheMisses: jumlah permintaan berhasil atau permintaan yang tidak menemukan item yang valid dalam cache. Jika rasio dari yang meleset lebih tinggi dibandingkan yang berhasil, maka aplikasi memboroskan waktu dan sumber daya dengan permintaan yang tidak membuahkan hasil.

      • SetTypeCmds dan GetTypeCmds: Kedua metrik ini yang berhubungan dengan EngineCPUUtilization dapat membantu untuk memahami jika beban secara signifikan lebih tinggi untuk permintaan tulis, diukur oleh SetTypeCmds, atau lebih tinggi untuk permintaan baca, diukur oleh GetTypeCmds. Jika yang lebih banyak adalah beban baca, maka menggunakan beberapa replika baca dapat menyeimbangkan permintaan di beberapa simpul sehingga simpul primer dapat melayani permintaan tulis saja. Dalam cluster yang dinonaktifkan mode cluster, penggunaan replika baca dapat dilakukan dengan membuat konfigurasi koneksi tambahan dalam aplikasi menggunakan endpoint pembaca. ElastiCache Untuk informasi selengkapnya, lihat Menemukan Titik Akhir Koneksi. Operasi baca harus dikirimkan ke koneksi tambahan ini. Operasi tulis akan dilakukan melalui titik akhir primer biasa. Pada mode klaster diaktifkan, sebaiknya menggunakan pustaka yang mendukung replika baca secara native. Dengan flag yang tepat, perpustakaan akan dapat secara otomatis menemukan topologi cluster, node replika, mengaktifkan operasi baca melalui OSS perintah READONLYValkey atau Redis, dan mengirimkan permintaan baca ke replika.

    • Jumlah koneksi yang meningkat:

      • CurrConnections dan NewConnections: CurrConnection adalah jumlah koneksi yang dibuat pada saat pengumpulan titik data, sementara NewConnections menunjukkan jumlah koneksi yang dibuat pada periode itu.

        Membuat dan menangani koneksi menyiratkan CPU overhead yang signifikan. Selain itu, jabat tangan TCP tiga arah yang diperlukan untuk membuat koneksi baru akan berdampak negatif pada waktu respons keseluruhan.

        Sebuah ElastiCache node dengan ribuan NewConnections per menit menunjukkan bahwa koneksi dibuat dan digunakan hanya dengan beberapa perintah, yang tidak optimal. Menjaga koneksi selalu tersedia dan menggunakan kembali koneksi itu untuk operasi baru adalah praktik terbaik. Hal ini dimungkinkan jika aplikasi klien mendukung dan menerapkan dengan baik pooling koneksi atau koneksi yang persisten. Dengan pooling koneksi, angka currConnections tidak akan memiliki variasi besar, dan NewConnections seharusnya menjadi serendah mungkin. Valkey dan Redis OSS memberikan kinerja optimal dengan jumlah kecil. currConnections Menjaga currConnection urutan puluhan atau ratusan meminimalkan penggunaan sumber daya untuk mendukung koneksi individu seperti buffer klien dan CPU siklus untuk melayani koneksi.

    • Throughput jaringan:

      • Tentukan bandwidth: ElastiCache node memiliki bandwidth jaringan yang sebanding dengan ukuran node. Karena aplikasi memiliki karakteristik yang berbeda, hasilnya dapat bervariasi sesuai dengan beban kerja. Sebagai contoh, aplikasi dengan tingkat permintaan kecil yang tinggi cenderung mempengaruhi lebih banyak CPU penggunaan daripada throughput jaringan sementara kunci yang lebih besar akan menyebabkan pemanfaatan jaringan yang lebih tinggi. Untuk alasan itu, sebaiknya menguji simpul dengan beban kerja yang sebenarnya untuk pemahaman yang lebih baik tentang batasan.

        Mensimulasi beban dari aplikasi akan memberikan hasil yang lebih akurat. Namun, alat tolok ukur dapat memberikan gambaran yang baik tentang batasan.

      • Untuk kasus di mana permintaan didominasi oleh operasi baca, menggunakan replika untuk operasi baca akan mengurangi beban pada simpul primer. Jika kasus penggunaan didominasi operasi tulis, digunakannya banyak replika akan memperkuat penggunaan jaringan. Untuk setiap byte yang ditulis ke simpul primer, N byte akan dikirim ke replika, di mana N adalah jumlah replika. Praktik terbaik untuk menulis beban kerja intensif adalah menggunakan ElastiCache (RedisOSS) dengan mode cluster yang diaktifkan sehingga penulisan dapat diseimbangkan di beberapa pecahan, atau ditingkatkan ke tipe node dengan lebih banyak kemampuan jaringan.

      • CloudWatchmetrics NetworkBytesInDan NetworkBytesOut memberikan jumlah data yang masuk atau keluar dari node, masing-masing. ReplicationBytesadalah lalu lintas yang didedikasikan untuk replikasi data.

      Untuk informasi selengkapnya, lihat Batas terkait jaringan.

    • Perintah kompleks: OSS Perintah Redis disajikan pada satu utas, yang berarti bahwa permintaan disajikan secara berurutan. Perintah tunggal yang lambat dapat memengaruhi permintaan lain dan koneksi, yang berpuncak pada terjadinya waktu habis. Penggunaan perintah yang bertindak pada beberapa nilai, kunci, atau jenis data harus dilakukan dengan hati-hati. Koneksi dapat diblokir atau dihentikan tergantung pada jumlah parameter, atau ukuran nilai input atau output-nya.

      Contoh yang terkenal buruk adalah perintah KEYS. Perintah ini menyapu seluruh ruang kunci untuk mencari pola tertentu dan memblokir pelaksanaan dari perintah lain selama pelaksanaannya. Redis OSS menggunakan notasi “Big O” untuk menggambarkan kompleksitas perintahnya.

      Perintah keys memiliki O(N) kali kompleksitas, N menjadi jumlah kunci dalam basis data. Oleh karena itu, semakin besar jumlah kunci, semakin lambat perintahnya. KEYS dapat menyebabkan masalah dengan cara yang berbeda: Jika tidak menggunakan pola pencarian, perintah ini akan menghasilkan semua nama kunci yang tersedia. Dalam basis data dengan ribuan atau jutaan item, output yang besar akan tercipta dan membanjiri buffer jaringan.

      Jika pola pencarian digunakan, hanya kunci yang cocok dengan pola yang akan dikembalikan ke klien. Namun, mesin masih akan menyapu ke seluruh ruang kunci untuk mencarinya, dan waktu untuk menyelesaikan perintah akan sama.

      Alternatif untuk KEYS adalah perintah SCAN. Perintah ini melakukan iterasi atas ruang kunci dan membatasi iterasi dalam jumlah tertentu dari item, menghindari pemblokiran yang berkepanjangan pada mesin.

      Scan memiliki parameter COUNT, digunakan untuk mengatur ukuran dari blok iterasi. Nilai default-nya adalah 10 (10 item per iterasi).

      Tergantung pada jumlah item dalam basis data, blok dengan nilai COUNT yang kecil akan membutuhkan lebih banyak iterasi untuk menyelesaikan perintah scan penuh, dan nilai yang lebih besar ini akan membuat mesin sibuk lebih lama di setiap iterasi. Sementara nilai count yang kecil akan membuat SCAN lebih lambat pada basis data yang besar, nilai yang lebih besar dapat menyebabkan masalah yang sama seperti disebutkan untuk KEYS.

      Sebagai contoh, menjalankan perintah SCAN dengan nilai count sebesar 10 akan membutuhkan 100.000 pengulangan pada basis data dengan 1 juta kunci. Jika waktu pulang pergi jaringan rata-rata adalah 0,5 milidetik, sekitar 50.000 milidetik (50 detik) akan dihabiskan untuk mengirimkan permintaan ini.

      Di sisi lain, jika nilai count adalah 100,0000, iterasi tunggal akan diperlukan dan hanya 0,5 milidetik yang akan dihabiskan untuk mengirimnya. Namun, mesin akan sepenuhnya terblokir untuk operasi lain sampai perintah itu selesai menyapu semua ruang kunci.

      Selain KEYS, beberapa perintah lain berpotensi membahayakan jika tidak digunakan dengan benar. Untuk melihat daftar semua perintah dan kompleksitas waktu masing-masing, buka perintah Valkey dan Redis OSS.

      Contoh potensi masalah:

      • Skrip Lua: Valkey dan Redis OSS menyediakan penerjemah Lua tertanam, memungkinkan eksekusi skrip di sisi server. Skrip Lua pada Valkey dan Redis OSS dieksekusi pada tingkat mesin dan bersifat atomik menurut definisi, yang berarti bahwa tidak ada perintah atau skrip lain yang diizinkan untuk dijalankan saat skrip sedang dieksekusi. Skrip Lua memberikan kemungkinan menjalankan beberapa perintah, algoritme pengambilan keputusan, penguraian data, dan lainnya langsung di mesin. Meskipun sifat atom dari skrip dan kemungkinan melepaskan aplikasi cukup menarik, skrip harus digunakan dengan hati-hati dan untuk operasi yang kecil. ElastiCacheAktif, waktu eksekusi skrip Lua dibatasi hingga 5 detik. Skrip yang belum ditulis ke ruang kunci akan secara otomatis dihentikan setelah periode 5 detik. Untuk menghindari kerusakan dan inkonsistensi data, simpul akan melakukan failover jika pelaksanaan skrip belum selesai dalam 5 detik dan tetap menjalankan operasi tulis apa pun selama pelaksanaan skrip. Transaksi adalah alternatif untuk menjamin konsistensi beberapa modifikasi kunci terkait di RedisOSS. Perintah transaction memungkinkan eksekusi dari suatu blok perintah, memperhatikan perubahan pada kunci yang sudah ada. Jika salah satu kunci yang diperhatikan berubah sebelum selesainya transaksi, maka semua perubahan akan dibuang.

      • Penghapusan item secara massal: perintah DEL menerima beberapa parameter, yang merupakan nama kunci yang akan dihapus. Operasi penghapusan sinkron dan akan memakan CPU waktu yang signifikan jika daftar parameter besar, atau berisi daftar besar, set, set diurutkan, atau hash (struktur data yang menyimpan beberapa sub-item). Dengan kata lain, bahkan penghapusan satu kunci pun dapat memakan waktu lama jika kunci itu memiliki banyak elemen. Alternatifnya DEL adalahUNLINK, yang merupakan perintah asinkron yang tersedia sejak Redis 4. OSS UNLINKharus lebih disukai daripada DEL bila memungkinkan. Mulai ElastiCache (RedisOSS) 6x, lazyfree-lazy-user-del parameter membuat DEL perintah berperilaku seperti UNLINK saat diaktifkan. Untuk informasi selengkapnya, lihat Redis OSS 6.0 Perubahan Parameter.

      • Perintah yang bekerja pada beberapa kunci: DEL disebutkan sebelumnya sebagai perintah yang menerima beberapa argumen dan waktu pelaksanaannya akan berbanding lurus dengan itu. Namun, Redis OSS menyediakan lebih banyak perintah yang bekerja sama. Sebagai contoh, MSET dan MGET memungkinkan penyisipan atau pengambilan beberapa kunci String sekaligus. Penggunaannya mungkin bermanfaat untuk mengurangi latensi jaringan yang terjadi pada beberapa perintah tersendiri SET atau GET. Namun, daftar parameter yang luas akan memengaruhi CPU penggunaan.

        Meskipun CPU pemanfaatan saja bukanlah penyebab masalah konektivitas, menghabiskan terlalu banyak waktu untuk memproses satu atau beberapa perintah melalui beberapa kunci dapat menyebabkan kegagalan permintaan lain dan meningkatkan CPU pemanfaatan secara keseluruhan.

        Jumlah kunci dan ukurannya akan memengaruhi kompleksitas perintah dan karena itu berpengaruh pada waktu penyelesaian.

        Contoh lain dari perintah yang dapat bertindak atas beberapa kunci: HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER atau ZINTERSTORE.

      • Perintah yang bekerja pada beberapa tipe data: Redis OSS juga menyediakan perintah yang bertindak atas satu atau beberapa kunci, terlepas dari tipe datanya. ElastiCache (RedisOSS) menyediakan metrik KeyBasedCmds untuk memantau perintah tersebut. Metrik ini menjumlahkan eksekusi dari perintah berikut pada periode yang dipilih:

        • Kompleksitas O(N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N) untuk mengeklaim kembali memori. Namun tugas mengeklaim kembali memori itu terjadi di thread yang terpisah dan tidak memblokir mesin

        • Waktu kompleksitas yang berbeda akan tergantung pada jenis data:

          • DEL

          • DUMP

          • RENAME dianggap perintah dengan kompleksitas O(1), tetapi menjalankan DEL secara internal. Waktu pelaksanaan akan bervariasi tergantung pada ukuran kunci yang diganti namanya.

          • RENAMENX

          • RESTORE

          • SORT

        • Hash besar: Hash adalah jenis data yang memungkinkan satu kunci dengan beberapa sub-item nilai kunci. Setiap hash dapat menyimpan 4.294.967.295 item dan operasi pada hash yang besar dapat menghabiskan banyak daya komputasi. Sama dengan KEYS, hash mempunyai perintah HKEYS dengan kompleksitas waktu O(N), N adalah jumlah item dalam hash. HSCAN seharusnya lebih dipilih dibandingkan HKEYS untuk menghindari perintah yang berjalan lama. HDEL, HGETALL, HMGET, HMSET dan HVALS adalah perintah yang harus digunakan dengan hati-hati pada hash besar.

      • Struktur data besar lainnya: Selain hash, struktur data lainnya bisa intensif. CPU Set, List, Sorted Set, dan Hyperloglog juga dapat memakan waktu yang lama untuk dimanipulasi tergantung pada ukuran dan perintah yang digunakan. Untuk informasi lebih lanjut tentang perintah tersebut, lihat perintah Valkey dan Redis OSS.

Validasi konektivitas jaringan

Setelah meninjau konfigurasi jaringan yang terkait dengan DNS resolusi, grup keamanan, jaringan, dan tabel ruteACLs, konektivitas dapat divalidasi dengan Reachability VPC Analyzer dan alat sistem.

Reachability Analyzer akan menguji konektivitas jaringan dan mengonfirmasi jika semua persyaratan dan izin terpenuhi. Untuk tes di bawah ini Anda akan memerlukan ENI ID (Elastic Network Interface Identification) dari salah satu ElastiCache node yang tersedia di AndaVPC. Anda dapat menemukannya dengan melakukan hal berikut:

  1. Pergi ke https://console.aws.amazon.com/ec2/v2/home? #NIC:

  2. Filter daftar antarmuka dengan nama ElastiCache cluster Anda atau alamat IP yang didapat dari DNS validasi sebelumnya.

  3. Tuliskan atau simpan ENI ID. Jika beberapa antarmuka ditampilkan, tinjau deskripsi untuk mengonfirmasi bahwa mereka termasuk dalam ElastiCache cluster yang tepat dan pilih salah satunya.

  4. Lanjutkan ke langkah berikutnya.

  5. Buat jalur analisis di https://console.aws.amazon.com/vpc/rumah? # ReachabilityAnalyzer dan pilih opsi berikut:

    • Jenis Sumber: Pilih instance jika ElastiCache klien Anda berjalan pada EC2 instans Amazon atau Antarmuka Jaringan jika menggunakan layanan lain, seperti AWS Fargate Amazon ECS dengan jaringan awsvpc, dll) AWS Lambda, dan ID sumber daya masing-masing (EC2instance atau ENI ID);

    • Jenis Tujuan: Pilih Network Interface dan pilih Elasticache ENI dari daftar.

    • Port tujuan: tentukan 6379 untuk ElastiCache (RedisOSS) atau 11211 untuk (Memcached). ElastiCache Itu adalah port yang ditetapkan dengan konfigurasi default dan contoh ini mengasumsikan bahwa port tersebut tidak berubah.

    • Protokol: TCP

Buat jalur analisis dan tunggu beberapa saat untuk hasilnya. Jika status tidak terjangkau, buka detail analisis dan tinjau Penjelajah analisis untuk detail di mana permintaan diblokir.

Jika tes penjangkauan sudah lulus, lanjutkan ke verifikasi di tingkat OS.

Untuk memvalidasi TCP konektivitas pada port ElastiCache layanan: Di Amazon Linux, Nping tersedia dalam paket nmap dan dapat menguji TCP konektivitas pada ElastiCache port, serta menyediakan waktu pulang-pergi jaringan untuk membuat koneksi. Gunakan ini untuk memvalidasi konektivitas jaringan dan latensi saat ini ke ElastiCache cluster, seperti yang ditunjukkan berikut: 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

Secara default, nping mengirimkan 5 paket penyelidikan dengan waktu tunda 1 detik di antara paket itu. Anda dapat menggunakan opsi "-c" untuk menambah jumlah paket penyelidikan dan "--delay " untuk mengubah waktu untuk mengirim pengujian baru.

Jika pengujian nping gagal dan pengujian VPCReachability Analyzer lulus, minta administrator sistem Anda untuk meninjau kemungkinan aturan firewall berbasis Host, aturan perutean asimetris, atau pembatasan lain yang mungkin terjadi pada tingkat sistem operasi.

Di ElastiCache konsol, periksa apakah Enkripsi dalam transit diaktifkan di detail ElastiCache klaster Anda. Jika enkripsi in-transit diaktifkan, konfirmasikan apakah TLS sesi dapat dibuat dengan perintah berikut:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Output ekstensif diharapkan jika koneksi dan TLS negosiasi berhasil. Periksa kode yang dihasilkan yang terdapat di baris terakhir, nilainya harus 0 (ok). Jika openssl mengembalikan sesuatu yang berbeda, periksa alasan kesalahan di https://www.openssl.org/docs/man1.0.2/man1/verify.html #. DIAGNOSTICS

Jika semua pengujian infrastruktur dan sistem operasi lulus tetapi aplikasi Anda masih tidak dapat terhubung ElastiCache, periksa apakah konfigurasi aplikasi sesuai dengan pengaturan. ElastiCache Kesalahan yang umum adalah:

  • Aplikasi Anda tidak mendukung mode ElastiCache cluster, dan ElastiCache mengaktifkan mode cluster;

  • Aplikasi Anda tidak mendukungTLS/SSL, dan ElastiCache telah mengaktifkan enkripsi dalam perjalanan;

  • Aplikasi mendukungTLS/SSLtetapi tidak memiliki bendera konfigurasi yang tepat atau otoritas sertifikasi tepercaya;

Batas terkait jaringan

  • Jumlah maksimum koneksi: Ada batas keras untuk koneksi secara serentak. Setiap ElastiCache node memungkinkan hingga 65.000 koneksi simultan di semua klien. Batas ini dapat dipantau melalui CurrConnections metrik pada. CloudWatch Namun, klien juga memiliki batas untuk koneksi keluar. Pada Linux, periksa rentang port ephemeral yang diizinkan dengan perintah:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    Pada contoh sebelumnya, 28231 koneksi akan diizinkan dari sumber yang sama, ke IP tujuan (ElastiCache node) dan port yang sama. Perintah berikut menunjukkan berapa banyak koneksi yang ada untuk ElastiCache node tertentu (IP 1.2.3.4):

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Jika jumlahnya terlalu tinggi, sistem Anda mungkin menjadi kelebihan beban mencoba memproses permintaan koneksi. Sebaiknya mempertimbangkan menerapkan teknik seperti pooling koneksi atau koneksi persisten untuk menangani koneksi itu dengan lebih baik. Jika memungkinkan, lakukan konfigurasi pool koneksi untuk membatasi jumlah maksimum koneksi hanya beberapa ratus. Selain itu, logika back-off untuk menangani masalah waktu habis atau pengecualian koneksi lain juga dianjurkan untuk menghindari masalah koneksi churn.

  • Batas lalu lintas jaringan: Periksa CloudWatch metrik berikut untuk Redis OSS untuk mengidentifikasi kemungkinan batas jaringan yang terkena pada ElastiCache node:

    • NetworkBandwidthInAllowanceExceeded / NetworkBandwidthOutAllowanceExceeded: Paket jaringan yang ditunda karena throughput melebihi batas agregasi bandwidth.

      Penting untuk dicatat bahwa setiap byte yang ditulis ke simpul primer akan direplikasi ke N replika, di mana N adalah jumlah replika. Klaster dengan jenis simpul kecil, beberapa replika, dan permintaan sarat operasi tulis mungkin tidak mampu mengatasi backlog replikasi. Untuk kasus seperti itu, praktik terbaiknya adalah menaikkan skala (mengubah jenis simpul), menskalakan ke luar (menambahkan serpihan dalam klaster dengan mode klaster diaktifkan), mengurangi jumlah replika, atau meminimalkan jumlah operasi tulis.

    • NetworkConntrackAllowanceExceeded: Paket yang ditunda karena telah terlampauinya jumlah maksimum koneksi yang dilacak di seluruh grup keamanan yang ditetapkan ke simpul. Koneksi baru kemungkinan akan gagal selama periode ini.

    • NetworkPackets PerSecondAllowanceExceeded: Jumlah maksimum paket per detik terlampaui. Beban kerja berdasarkan laju yang tinggi dari permintaan yang sangat kecil dapat mencapai batas ini sebelum bandwidth mencapai maksimum.

    Metrik di atas adalah cara ideal untuk mengonfirmasi simpul yang mencapai batas jaringannya. Namun, batas juga dapat diidentifikasi dengan bentuk plato pada metrik jaringan.

    Jika dataran tinggi diamati untuk waktu yang lama, kemungkinan akan diikuti oleh kelambatan replikasi, peningkatan byte Digunakan untuk cache, drop pada memori yang dapat dibebaskan, swap tinggi dan penggunaan. CPU EC2Instans Amazon juga memiliki batas jaringan yang dapat dilacak melalui metrik ENAdriver. Instans Linux dengan dukungan jaringan yang ditingkatkan dan ENA driver 2.2.10 atau yang lebih baru dapat meninjau penghitung batas dengan perintah:

    # ethtool -S eth0 | grep "allowance_exceeded"

CPUPemakaian

Metrik CPU penggunaan adalah titik awal penyelidikan, dan item berikut dapat membantu mempersempit kemungkinan masalah di ElastiCache samping:

  • Redis OSS SlowLogs: Konfigurasi ElastiCache default mempertahankan 128 perintah terakhir yang membutuhkan waktu lebih dari 10 milidetik untuk diselesaikan. Riwayat perintah lambat disimpan selama runtime mesin dan akan hilang jika terjadi kegagalan atau mulai ulang. Jika daftar mencapai 128 entri, maka peristiwa lama akan dihapus untuk memberikan tempat untuk peristiwa baru. Ukuran dari daftar peristiwa lambat dan waktu pelaksanaan yang dianggap lambat dapat diubah melalui parameter slowlog-max-len dan slowlog-log-slower-than dalam grup parameter kustom. Daftar slowlogs dapat diambil dengan menjalankan SLOWLOG GET 128 pada mesin, 128 adalah 128 perintah lambat terakhir yang dilaporkan. Setiap entri memiliki bidang berikut:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    Peristiwa di atas terjadi pada 26 Desember, pukul 19:26:07UTC, membutuhkan waktu 4,8 detik (4,823ms) untuk diselesaikan dan disebabkan oleh KEYS perintah yang diminta dari klien 1.2.3.4.

    Di Linux, stempel waktu dapat dikonversi dengan perintah tanggal:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Pada Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    Atau di Windows dengan PowerShell:

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Banyak perintah lambat dalam waktu singkat (menit yang sama atau kurang) menjadi hal yang dikhawatirkan. Tinjau sifat dari perintah dan bagaimana perintah itu dapat dioptimalkan (lihat contoh sebelumnya). Jika perintah dengan kompleksitas waktu O (1) sering dilaporkan, periksa faktor-faktor lain untuk CPU penggunaan tinggi yang disebutkan sebelumnya.

  • Metrik latensi: ElastiCache (RedisOSS) menyediakan CloudWatch metrik untuk memantau latensi rata-rata untuk berbagai kelas perintah. Titik data dihitung dengan membagi jumlah pelaksanaan perintah dalam kategori dengan total waktu pelaksanaan pada periode tersebut. Penting untuk dipahami bahwa hasil metrik latensi merupakan kumpulan dari beberapa perintah. Satu perintah dapat menyebabkan hasil tidak terduga, seperti waktu habis, tanpa dampak signifikan pada metrik. Untuk kasus seperti ini, peristiwa slowlog akan menjadi sumber informasi yang lebih akurat. Daftar berikut berisi metrik latensi yang tersedia dan perintah terkait yang memengaruhinya.

    • EvalBasedCmdsLatency: terkait dengan perintah Lua Script,eval,evalsha;

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: Baca perintah, terlepas dari tipe data;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: Perintah yang dapat bertindak atas tipe data yang berbeda: dump existskeys,object,pttl,,randomkey,ttl,type,del,expire,expireat,move,persist,pexpire,pexpireat,rename,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;

    • PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: Menulis perintah, terlepas dari tipe data;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Perintah OSS runtime Redis:

    • info commandstats: Menyediakan daftar perintah yang dijalankan sejak OSS mesin Redis dimulai, jumlah eksekusi kumulatifnya, total waktu eksekusi, dan waktu eksekusi rata-rata per perintah;

    • client list: Menyediakan daftar klien yang saat ini terhubung dan informasi yang relevan seperti penggunaan buffer, perintah yang dilaksanakan terakhir, dll;

  • Backup dan replikasi: ElastiCache (RedisOSS) versi lebih awal dari 2.8.22 menggunakan proses bercabang untuk membuat cadangan dan memproses sinkronisasi penuh dengan replika. Metode ini mungkin menyebabkan overhead memori yang besar untuk kasus penggunaan sarat operasi tulis.

    Dimulai dengan ElastiCache Redis OSS 2.8.22, AWS memperkenalkan metode pencadangan dan replikasi tanpa garpu. Metode yang baru dapat menunda operasi tulis untuk mencegah kegagalan. Kedua metode dapat menyebabkan periode CPU pemanfaatan yang lebih tinggi, menyebabkan waktu respons yang lebih tinggi dan akibatnya menyebabkan batas waktu klien selama eksekusi mereka. Selalu periksa apakah kegagalan klien terjadi selama periode pencadangan atau metrik SaveInProgress bernilai 1 pada periode tersebut. Sebaiknya menjadwalkan periode pencadangan untuk periode pemanfaatan yang rendah untuk meminimalkan kemungkinan masalah dengan klien atau kegagalan proses pencadangan.

Koneksi yang dihentikan dari sisi server

Konfigurasi default ElastiCache (RedisOSS) membuat koneksi klien dibuat tanpa batas waktu. Namun, dalam beberapa kasus penghentian koneksi mungkin diinginkan. Misalnya:

  • Bug dalam aplikasi klien dapat menyebabkan koneksi dilupakan dan tetap terhubung dengan keadaan idle. Ini disebut “kebocoran koneksi “ dan konsekuensinya adalah peningkatan yang tetap pada jumlah koneksi terhubung yang diamati pada metrik CurrConnections. Perilaku ini dapat mengakibatkan kejenuhan pada klien atau ElastiCache sisi. Ketika perbaikan langsung tidak dimungkinkan dari sisi klien, beberapa administrator menetapkan nilai” batas waktu “dalam grup ElastiCache parameter mereka. Waktu habis adalah waktu dalam detik yang diizinkan bagi koneksi idle untuk bertahan. Jika klien tidak mengirimkan permintaan apa pun dalam periode tersebut, OSS mesin Redis akan menghentikan koneksi segera setelah koneksi mencapai nilai batas waktu. Nilai waktu habis yang kecil dapat mengakibatkan pemutusan koneksi yang tidak perlu dan klien akan perlu menangani ini dengan tepat dan menghubungkan kembali, yang menyebabkan penundaan.

  • Memori yang digunakan untuk menyimpan kunci dibagikan dengan buffer klien. Klien lambat dengan permintaan atau tanggapan besar mungkin menuntut sejumlah besar memori untuk menangani buffer. Konfigurasi default ElastiCache (RedisOSS) tidak membatasi ukuran buffer keluaran klien biasa. Jika batas maxmemory tercapai, mesin akan mencoba mengosongkan item untuk memenuhi penggunaan buffer. Dalam kondisi memori yang sangat rendah, ElastiCache (RedisOSS) mungkin memilih untuk memutuskan klien yang mengkonsumsi buffer keluaran klien besar untuk membebaskan memori dan mempertahankan kesehatan cluster.

    Dimungkinkan untuk membatasi ukuran buffer klien dengan konfigurasi kustom dan klien yang mencapai batas ini akan terputus. Namun, klien harus dapat menangani pemutusan yang tidak terduga. Parameter untuk menangani ukuran buffer untuk klien biasa adalah sebagai berikut:

    • client-query-buffer-limit: Ukuran maksimum permintaan input tunggal;

    • client-output-buffer-limit-normal-soft-limit: Batas lunak untuk koneksi klien. Koneksi akan dihentikan jika tetap di atas batas lunak selama lebih dari waktu dalam detik yang ditentukan pada client-output-buffer-limit - normal-soft-seconds atau jika mencapai batas keras;

    • client-output-buffer-limit-normal-soft-seconds: Waktu yang diizinkan untuk koneksi melebihi client-output-buffer-limit -normal-soft-limit;

    • client-output-buffer-limit-normal-hard-limit: Koneksi yang mencapai batas ini akan segera dihentikan.

    Selain buffer klien biasa, pilihan berikut mengontrol buffer untuk simpul replika dan klien Pub/Sub (Publikasi/Berlangganan):

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Pemecahan masalah sisi klien untuk instans Amazon EC2

Beban dan daya tanggap di sisi klien juga dapat memengaruhi permintaan. ElastiCache EC2instance dan batas sistem operasi perlu ditinjau dengan cermat saat memecahkan masalah konektivitas intermiten atau batas waktu. Beberapa poin penting untuk diamati:

  • CPU:

    • EC2CPUpenggunaan instance: Pastikan CPU belum jenuh atau mendekati 100 persen. Analisis historis dapat dilakukan melalui CloudWatch, namun perlu diingat bahwa perincian titik data adalah 1 menit (dengan pemantauan terperinci diaktifkan) atau 5 menit;

    • Jika menggunakan EC2instans burstable, pastikan saldo CPU kredit mereka belum habis. Informasi ini tersedia pada CPUCreditBalance CloudWatch metrik.

    • Periode CPU penggunaan tinggi yang singkat dapat menyebabkan batas waktu tanpa mencerminkan pemanfaatan 100 persen. CloudWatch Kasus seperti itu memerlukan pemantauan waktu nyata dengan peralatan sistem operasi seperti top, ps, dan mpstat.

  • Jaringan

    • Periksa apakah throughput Jaringan berada di bawah nilai yang dapat diterima sesuai dengan kemampuan instans. Untuk informasi selengkapnya, lihat Jenis EC2 Instans Amazon

    • Pada instans dengan ena penggerak Jaringan yang Ditingkatkan, periksa statistik ena untuk waktu habis habis atau batas yang terlampaui. Statistik berikut berguna untuk mengonfirmasi kejenuhan batas jaringan:

      • bw_in_allowance_exceeded / bw_out_allowance_exceeded: jumlah paket yang ditunda karena kelebihan throughput masuk atau keluar;

      • conntrack_allowance_exceeded: jumlah paket yang tidak diteruskan karena batas pelacakan koneksi dari grup keamanan. Koneksi baru akan gagal saat batas ini jenuh;

      • linklocal_allowance_exceeded: jumlah paket turun karena permintaan yang berlebihan untuk instance meta-data, melalui. NTP VPC DNS Batasnya adalah 1024 paket per detik untuk semua layanan;

      • pps_allowance_exceeded: jumlah paket yang tidak diteruskan karena rasio paket per detik yang berlebihan. PPSBatas dapat dicapai ketika lalu lintas jaringan terdiri dari ribuan atau jutaan permintaan yang sangat kecil per detik. ElastiCache Lalu lintas dapat dioptimalkan untuk memanfaatkan paket jaringan dengan lebih baik melalui saluran pipa atau perintah yang melakukan beberapa operasi sekaligus seperti MGET alih-alih. GET

Membedah waktu yang dibutuhkan untuk menyelesaikan satu permintaan tunggal

  • Di jaringan: Tcpdump dan Wireshark (tshark pada baris perintah) adalah alat yang berguna untuk memahami berapa banyak waktu yang dibutuhkan permintaan untuk melakukan perjalanan jaringan, menekan ElastiCache mesin dan mendapatkan pengembalian. Contoh berikut menyorot satu permintaan tunggal yang dibuat dengan perintah berikut: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    Sejajar dengan perintah di atas, tcpdump dijalankan dan menghasilkan:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    Dari output di atas kami dapat mengonfirmasi bahwa jabat tangan TCP tiga arah selesai dalam 222 mikrodetik (918091 - 917869) dan perintah ping dikirimkan dan dikembalikan dalam 173 mikrodetik (918295 - 918122).

    Dibutuhkan waktu 438 mikrodetik (918307 - 917869) mulai dari membuat permintaan hingga koneksi ditutup. Hasil tersebut akan memastikan bahwa waktu respons jaringan dan mesin adalah baik dan penyelidikan dapat berfokus pada komponen lainnya.

  • Pada sistem operasi: Strace dapat membantu mengidentifikasi kesenjangan waktu pada tingkat OS. Analisis aplikasi aktual akan jauh lebih luas dan dianjurkan menggunakan alat profil khusus untuk aplikasi atau debugger. Contoh berikut hanya menunjukkan jika komponen sistem operasi dasar berfungsi seperti yang diharapkan, jika tidak, penyelidikan lebih lanjut mungkin diperlukan. Menggunakan OSS PING perintah Redis yang sama dengan strace kita mendapatkan:

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    Pada contoh di atas, perintah ini membutuhkan waktu sekitar 54 milidetik untuk diselesaikan (752110 - 697712 = 54398 mikrodetik).

    Sejumlah besar waktu, sekitar 20ms, diambil untuk membuat instance nc dan melakukan resolusi nama (dari 697712 hingga 717890), setelah itu, 2ms diperlukan untuk membuat TCP soket (745659 hingga 747858), dan 0,4 ms (747858 hingga 748330) untuk mengirimkan dan menerima tanggapan atas permintaan tersebut.