VPS Saya Tetap Online. Lalu Linux Mulai Menunggu 18 Detik untuk Membaca Disk

Sebelum masuk ke proses debugging, saya ingin memperjelas satu hal: kesan saya terhadap FDCServers secara keseluruhan tidak negatif. Ini bukan ulasan yang menyuruh orang menghindari mereka dan bukan upaya menilai seluruh kualitas infrastrukturnya. Saya memiliki satu VPS, pada satu periode tertentu, dengan satu masalah yang tidak biasa dan sulit.

Untuk waktu yang cukup lama, VPS itu bekerja normal dan menangani traffic production nyata. Lalu sesuatu berubah. Request biasa mulai membutuhkan waktu yang tidak masuk akal. Halaman terbuka lambat, lalu kadang tidak terbuka sama sekali. Di waktu lain, mesin kembali terlihat normal sebelum saya sempat memeriksa kegagalan dengan baik.

Pada kondisi terburuk saya merekam:

CPU iowait:       97–100%
I/O PSI full:     ~95–98%
read latency:     up to 18.7 seconds
flush latency:    up to 53.6 seconds
I/O queue depth:  128+

Nginx tetap berjalan. Backend tetap berjalan. VM tetap online. Namun hampir tidak ada pekerjaan berguna yang selesai.

Kegagalan production tentu membuat frustrasi, tetapi proses debugging-nya justru benar-benar menarik. Inilah salah satu hal yang saya sukai dari Linux: mesin bisa terlihat hidup dari luar, sementara beberapa antarmuka kernel yang independen menunjukkan di mana progress yang berguna sebenarnya berhenti. Artikel ini tentang mengikuti petunjuk tersebut, bukan menentukan apakah FDCServers penyedia yang baik atau buruk.

active (running) ternyata hampir tidak berarti apa-apa

Saya mulai dari pemeriksaan yang jelas:

top
free -h
df -h
systemctl status nginx

Saat sehat, kondisinya kira-kira:

D-state processes: 0
CPU iowait:        ~0%
disk latency:      ~2–4 ms
I/O PSI some:      0.04
I/O PSI full:      0.04

Jika saya hanya login pada saat seperti itu, saya mudah menyimpulkan VPS sehat. Setelah traffic normal kembali, kondisinya bisa berubah total. Snapshot sehat dari sistem yang mengalami masalah intermittent hampir tidak mengatakan apa pun tentang kondisi saat gagal. Saya perlu mengumpulkan bukti ketika kegagalan benar-benar sedang terjadi.

Sampel iostat yang mengubah investigasi

r_await = 18744 ms
f_await = 53561 ms
aqu-sz  = 128.54
util    ≈ 100%
read    = 88 KB/s

Read yang selesai membutuhkan sekitar 18,7 detik. Operasi flush membutuhkan sekitar 53,6 detik. Rata-rata antrean berada di atas 128, sementara throughput read yang berguna hanya 88 KB/s.

Ini tidak terlihat seperti storage yang sekadar sibuk karena melayani workload berat secara efisien. Jalur block virtual praktis jenuh sementara hanya menyelesaikan sedikit pekerjaan. Utilization tinggi saja bukan kegagalan, tetapi utilization tinggi yang disertai latency sangat besar, antrean panjang, task yang stalled, throughput kecil, dan request gagal memberikan sinyal yang sama sekali berbeda.

Saya berhenti menganggap iowait sebagai diagnosis

blocked processes: 4–9
CPU iowait:        97–100%
CPU idle:          0%

Mudah untuk menyederhanakannya menjadi CPU menghabiskan 100% waktunya menunggu disk. Intuisi itu berguna, tetapi accounting Linux lebih kompleks dan iowait bukan pengukuran langsung terhadap disk. Jadi saya memperlakukannya sebagai satu gejala dan mencari bukti independen.

PSI menunjukkan bahwa I/O menghentikan pekerjaan berguna

cat /proc/pressure/io

Pada salah satu periode parah:

some avg10=99.14
full avg10=95.55

Pada reproduksi berikutnya, full mendekati 98%. Untuk tekanan I/O, some mewakili waktu ketika setidaknya sebagian pekerjaan non-idle stalled karena I/O, sedangkan full mewakili waktu ketika semua task non-idle secara bersamaan stalled karena I/O. Nilai mendekati 100% berarti jauh lebih dari sekadar disk sibuk: workload hampir tidak mendapatkan kesempatan untuk maju.

D-state membuat saya berhenti menyalahkan satu proses

ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'

Satu proses yang sebentar masuk D-state tidak membuktikan masalah storage. Yang penting adalah proses mana yang terblokir bersama-sama. Saya melihat komponen yang tidak berhubungan seperti jbd2, systemd-journald, worker Nginx, proses cache Nginx, dan aktivitas filesystem lainnya.

Jika hanya backend yang macet, saya memeriksa backend. Jika hanya Nginx yang macet, saya memeriksa Nginx. Namun jika Nginx, system journal, dan thread journal EXT4 berhenti maju bersamaan, dependency yang mereka bagi menjadi jauh lebih menarik. Dalam kasus ini dependency tersebut adalah filesystem dan storage path di bawahnya.

Kernel stack menunjukkan layer berikutnya

Thread journal EXT4 muncul pada path seperti:

wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transaction

Worker Nginx muncul pada path baca filesystem biasa:

folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64

Pada satu titik kernel melaporkan:

INFO: task nginx blocked for more than 122 seconds.

systemctl status nginx masih bisa menampilkan active (running). Keduanya benar: prosesnya ada, tetapi sebuah task Nginx telah lebih dari dua menit tidak mampu menyelesaikan pekerjaan berguna. Proses yang berjalan tidak sama dengan layanan yang sehat.

Eksperimen paling bersih hanya membutuhkan sekitar tiga milidetik

Request melalui Nginx gagal:

HTTP=000
SSL connection timeout

Lalu saya melewati Nginx dan menghubungi backend lokal langsung:

connect = 0.000423 s
TTFB    = 0.003063 s
total   = 0.003139 s

Sekitar 3 ms. Status HTTP persisnya tidak penting untuk pengujian ini. Backend menerima koneksi, menjalankan request, dan mengembalikan respons hampir seketika. Pada waktu yang hampir sama, worker Nginx terlihat berada di dalam path baca EXT4.

application execution       → progressing normally
filesystem-backed web path  → not progressing normally

Semakin dalam saya memeriksa, semakin tidak masuk akal penjelasan di level aplikasi.

VPS yang sama bisa kolaps dalam sekitar 30 detik

Sebelum salah satu reproduksi:

HTTP:          200
D-state:       0
CPU iowait:    3%
r_await:       ~1.18 ms
I/O PSI full:  ~2.95%

Sekitar setengah menit kemudian:

D-state:       4
CPU iowait:    91%
CPU idle:      0%
I/O PSI some:  86.11%
I/O PSI full:  78.02%
r_await:       236.50 ms
HTTP:          000

Kemudian memburuk lagi:

CPU iowait:    96–100%
I/O PSI full:  ~98%
HTTPS queue:   512
HTTP:          000

Saat workload saya hilangkan, transisi sebaliknya bisa terjadi dengan cepat:

D-state:      0
CPU iowait:   6%
r_await:      ~0.98 ms
queue depth:  ~0.07
HTTP:         200

Inilah sebabnya kegagalan infrastruktur intermittent sangat sulit. Seseorang bisa memeriksa VM yang sama sepuluh menit kemudian dan dengan jujur melaporkan latency di bawah satu milidetik. Ia belum tentu salah; ia hanya melihat state yang berbeda.

Latency nol ternyata bisa sangat tidak membantu

Saya juga melihat interval iostat dengan r_await = 0 saat sistem jelas tidak sehat: iowait tinggi, proses D-state, I/O outstanding, hampir tidak ada read yang selesai, dan hampir tidak ada throughput.

Rata-rata yang bergantung pada operasi selesai menjadi kurang informatif ketika hampir tidak ada operasi yang selesai selama interval sampling. Nilai nol tidak membuktikan bahwa read selesai seketika; mungkin hanya ada terlalu sedikit completion yang berguna untuk menggambarkan operasi yang masih macet.

Sejak kejadian ini saya melihat latency, IOPS, throughput, queue depth, in-flight I/O, D-state, PSI, dan completion request aktual secara bersamaan.

Satu incident berubah menjadi investigasi support yang jauh lebih panjang

Insiden parah pertama bertepatan dengan scheduled backup pada infrastruktur awal dan FDCServers mengonfirmasi backup tersebut sedang berjalan. Itu merupakan kandidat penjelasan yang masuk akal. Namun kemudian saya mereproduksi jenis storage stall yang sama setelah backup selesai dan di luar window backup awal.

Masalah kembali muncul pada beberapa hari. Dalam salah satu insiden, VPS kemudian tidak tersedia selama 4 jam, 41 menit, dan 15 detik menurut service log saya. Saya tidak dapat membuktikan bahwa storage stall itu sendiri menyebabkan VM memasuki state tersebut; pembuktian itu membutuhkan informasi sisi host yang tidak saya miliki.

application
    ↓
Linux VFS
    ↓
EXT4
    ↓
virtual block device
    ↓
?

Di balik tanda tanya itu bisa terdapat virtualization, host queue, storage networking, distributed storage, media fisik, scheduler, dan sistem lain yang tidak terlihat dari guest. Saya bisa melihat di mana kegagalan muncul, tetapi tidak bisa melihat physical root cause.

FDCServers mengeskalasi masalah secara internal dan akhirnya memigrasikan VPS ke node lain. Setelah migrasi saya kembali merekam storage stall berat dari sisi guest. Ini tidak membuktikan bahwa semua node FDCServers memiliki masalah storage. Ini hanya membuktikan bahwa, dari sudut pandang saya, masalah pada VPS saya belum tereliminasi.

Mengapa saya tetap tidak menganggap ini cerita negatif tentang FDCServers

Insiden infrastruktur mudah diubah menjadi vonis terhadap seluruh provider. Saya tidak ingin melakukan itu.

Saya membedakan layanan yang model operasional normalnya memang tidak cocok dengan workload saya dari masalah infrastruktur intermittent yang sulit direproduksi dan membutuhkan waktu lama untuk diisolasi. Pengalaman saya dengan FDCServers terasa seperti kasus kedua.

Sebelum incident, VPS bekerja normal dan menangani traffic production nyata. Support melakukan investigasi dan mencoba menyelesaikan masalah. Pada akhirnya saya memiliki cukup evidence untuk memutuskan bahwa saya tidak ingin production tetap bergantung pada VPS tersebut.

Saya meminta pembatalan layanan dan refund. FDCServers mengembalikan uang saya. Itu penting dalam kesan keseluruhan saya.

Saya belum menguji ulang infrastruktur mereka saat ini, jadi saya tidak bisa mengatakan bagaimana VPS FDCServers bekerja sekarang. Saya juga tidak memiliki bukti bahwa apa yang terjadi pada instance saya mewakili seluruh fleet mereka. Infrastruktur terus berubah. Saya tidak akan mengubah satu incident sulit pada satu VPS menjadi penilaian permanen terhadap seluruh provider. Saya juga tidak sedang merekomendasikan FDCServers; saya hanya menceritakan apa yang terjadi pada saya.

Bagian yang paling saya nikmati justru Linux sendiri

Downtime memang membuat frustrasi, tetapi investigasinya menyenangkan. Saya benar-benar menikmati menemukan batas masalahnya.

Saya tidak punya visibility yang cukup untuk mengidentifikasi physical root cause. Jawaban yang saya cari lebih sederhana: di layer mana pekerjaan berguna berhenti selesai?

Backend merespons sekitar tiga milidetik. Nginx mengatakan dirinya aktif, sementara kernel stack menunjukkan Nginx menunggu di dalam read EXT4. vmstat menunjukkan proses terblokir dan I/O wait ekstrem. PSI menunjukkan I/O stall memakan hampir seluruh workload. iostat menunjukkan latency dan queueing sangat besar. D-state menunjukkan proses yang tidak berhubungan menunggu bersama. Kernel bahkan melaporkan task Nginx terblokir lebih dari 122 detik.

Tidak ada satu metric yang menyelesaikan insiden ini. Kesepakatan di antara semuanya yang melakukannya. Itulah salah satu alasan saya menyukai Linux: Anda bisa mulai dari keluhan samar seperti “website saya kadang tidak terbuka” lalu perlahan mengubahnya menjadi pernyataan presisi tentang layer tempat useful work berhenti maju.

Workflow debugging yang saya gunakan sekarang

top
free -h
df -h

date -u
uptime
cat /proc/pressure/io
cat /proc/pressure/memory
cat /proc/pressure/cpu
vmstat 1 10
iostat -x 1 10
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'
ss -lntp
journalctl -k --since "30 min ago" --no-pager

Bila memungkinkan, saya juga menguji setiap bagian request path secara terpisah:

public request
      ↓
reverse proxy
      ↓
direct backend
      ↓
filesystem
      ↓
block device

Saya tidak lagi hanya bertanya mengapa server lambat. Saya bertanya: di layer mana pekerjaan berguna berhenti selesai? Pertanyaan itu menghasilkan eksperimen yang jauh lebih baik.

Satu aturan terakhir: kumpulkan bukti sebelum reboot

Reboot mungkin persis yang dibutuhkan production, tetapi reboot juga bisa menghapus state diagnostik paling berharga yang pernah Anda lihat.

Before reboot:
D-state:     high
I/O PSI:     ~97%
iowait:      ~100%
queues:      large
requests:    failing

After reboot:
D-state:     0
latency:     milliseconds
requests:    healthy

Jika availability dan dampak bisnis memungkinkan, saya lebih dulu merekam UTC timestamp, PSI, vmstat, iostat, D-state, wchan, pesan kernel, socket queue, dan request timing. Setelah itu baru saya memulihkan mesin.

Server berjalan. Workload tidak.

Saya tidak pernah mengetahui komponen host-side mana yang pada akhirnya menyebabkan insiden. Saya tidak dapat mengatakan SSD tertentu rusak, menunjuk storage node tertentu, atau membuktikan apa yang terjadi di balik virtual block device.

Apa yang dapat saya buktikan dari dalam Linux sudah cukup:

read latency:       up to 18.7 s
flush latency:      up to 53.6 s
I/O PSI full:       almost 100%
iowait:             almost 100%
I/O queue:          128+
Nginx:              blocked in filesystem reads
EXT4/jbd2:          blocked waiting for I/O
direct backend:     ~3 ms
HTTP through Nginx: timing out

Itu cukup untuk memisahkan aplikasi saya dari layer yang gagal dan cukup untuk membuat keputusan operasional. FDCServers mengembalikan biaya VPS, saya pindah, dan saya tidak menjadikan satu incident infrastruktur yang sulit sebagai vonis terhadap provider.

Hal yang tetap saya ingat justru lebih berguna: proses bisa running, service bisa active, VM bisa online, ping bisa bekerja, dan mesin tetap hampir tidak menyelesaikan pekerjaan berguna.

Linux memberikan cukup evidence untuk membedakan keduanya. Anda hanya perlu mengajukan pertanyaan yang tepat saat kegagalannya masih ada.