Saya tidak menulis ini sebagai ulasan negatif tentang FDCServers. Saya juga tidak mencoba mengatakan apakah orang lain sebaiknya membeli VPS dari mereka atau tidak. Saya punya satu server, satu workload, dan satu rangkaian masalah. Itu tidak cukup untuk menilai seluruh perusahaan hosting.
Ini hanyalah salah satu cerita dari keseharian saya sebagai developer. VPS tersebut sudah berjalan normal selama beberapa waktu dan telah mentransfer lebih dari 3 TB trafik. Kemudian workload biasa mulai menimbulkan delay yang sangat besar. Halaman bisa membutuhkan waktu sangat lama untuk merespons atau timeout sepenuhnya. Awalnya saya mencurigai hal-hal yang biasa: aplikasi, Nginx, memory, network, batas koneksi, atau load terlalu tinggi. Metrics Linux menunjuk ke arah lain.
VPS tidak lambat sejak awal
Di antara insiden, mesin bisa terlihat sepenuhnya sehat. Pada satu periode normal, tidak ada process dalam D-state, CPU iowait sekitar 0%, latensi disk sekitar 2–4 ms, dan I/O PSI hampir nol:
D-state processes: 0
CPU iowait: ~0%
disk latency: ~2–4 ms
I/O PSI some: 0.04
I/O PSI full: 0.04Kalau saya hanya login pada saat itu dan memeriksa top, free -h, df -h, serta systemctl status nginx, saya mungkin akan menyimpulkan VPS baik-baik saja. Lalu workload normal kembali dan keadaan mesin berubah drastis.
Pembacaan 18,7 detik mengubah arah investigasi
Salah satu sample iostat paling kuat terlihat seperti ini:
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util = 100.10%
read = 88 KB/sAngka-angka ini perlu dibaca bersama. Read yang selesai rata-rata membutuhkan sekitar 18,7 detik. Latensi flush sekitar 53,6 detik. Rata-rata queue I/O di atas 128, sementara throughput baca yang berguna hanya 88 KB/s. Ini bukan sekadar disk sibuk yang memindahkan banyak data. Storage path menghabiskan waktu sangat besar menunggu operasi selesai.
iowait dan PSI menunjukkan tekanan I/O di seluruh sistem
Pada periode terburuk, vmstat menunjukkan 4–9 process blocked, CPU iowait sekitar 97–100%, dan CPU idle 0%. iowait bukan berarti aplikasi memakai seluruh CPU. Artinya pekerjaan yang berguna menunggu I/O yang masih outstanding.
Linux Pressure Stall Information membuat gambarnya lebih jelas:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55Pada reproduksi selanjutnya, full mendekati 98%. Disk utilization mengatakan perangkat sedang sibuk; PSI menunjukkan seberapa parah workload tertahan oleh resource itu. Tekanan I/O berkelanjutan sekitar 95–98% bukan penurunan performa kecil.
D-state dan kernel stack menunjuk ke bawah lapisan aplikasi
Saya lalu melihat process mana yang blocked. Pada saat bersamaan saya melihat jbd2, systemd-journald, Nginx worker, process cache Nginx, dan aktivitas filesystem lain dalam D-state. Kalau hanya aplikasi saya yang macet, saya akan menyelidiki aplikasinya. Ketika Nginx, system journal, dan EXT4 journal semuanya blocked sekaligus, storage menjadi dependency bersama yang paling jelas.
Path journaling EXT4 mencakup:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx worker menunggu pada pembacaan file biasa:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64Pada satu titik kernel melaporkan task Nginx telah blocked selama lebih dari 122 detik. Nginx masih bisa ditampilkan sebagai active, tetapi itu tidak berarti worker-nya mampu menyelesaikan pekerjaan berguna. running dan sehat adalah dua keadaan berbeda.
Respons backend 3 ms memisahkan aplikasi dari path filesystem
Perbandingan paling bersih adalah Nginx melawan backend aplikasi lokal. Request melalui Nginx menghasilkan HTTP=000 karena connection atau TLS timeout. Request langsung ke backend selesai sekitar 3 ms:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sStatus HTTP tepatnya tidak penting dalam test ini. Backend menerima connection, memproses request, dan menghasilkan response hampir seketika. Pada saat yang sama, Nginx worker terlihat menunggu read EXT4. Ini memisahkan eksekusi aplikasi normal dari path di depannya yang bergantung pada filesystem.
Masalah bisa direproduksi dan bisa hilang lagi
Sebelum satu reproduksi, mesin terlihat normal:
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: 000Kemudian CPU iowait mencapai 96–100%, I/O PSI full mendekati 98%, queue HTTPS mencapai 512, dan pemeriksaan HTTP masih gagal. Ini jauh lebih berguna sebagai evidence daripada sekadar mengatakan VPS terasa lambat.
Saat workload dipindahkan, transisi sebaliknya bisa terjadi cepat:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200Itulah sebabnya masalah storage yang intermittent sulit diperiksa setelah kejadian. Provider dapat melihat server setelah pulih dan benar-benar menemukan latensi normal. Itu tetap tidak menjelaskan apa yang terjadi sepuluh menit sebelumnya. Timestamp UTC yang tepat menjadi sangat penting.
Dua metric yang bisa menyesatkan: await=0 dan ruang disk kosong
Pada beberapa interval buruk saya melihat r_await = 0 sementara iowait tinggi, process berada dalam D-state, request masih in-flight, dan hampir tidak ada read yang selesai. Statistik latency didasarkan pada I/O yang selesai. Jika sebuah operasi tetap macet dan tidak selesai selama interval sampling, operasi itu tidak bisa masuk ke average latency operasi yang selesai. Jadi angka nol tidak selalu berarti disk seketika.
Saya juga mempertimbangkan disk fullness. Belakangan filesystem menjadi lebih penuh daripada yang biasanya saya izinkan, tetapi jenis failure yang sama sudah muncul ketika root filesystem baru terpakai sekitar 24%. Saat itu sekitar 1,2 GiB RAM tersedia, penggunaan inode sekitar 5%, dan interface network tidak menunjukkan error atau dropped packet. Disk fullness tidak bisa menjelaskan seluruh insiden.
Apa yang bisa saya buktikan dan yang tidak
Dari dalam VPS saya bisa melihat aplikasi, Linux VFS, EXT4, dan virtual block device. Setelah itu ada infrastructure provider: virtualization, distributed storage, storage network, perangkat fisik, scheduling, serta lapisan lain yang tidak dapat saya inspect dari guest.
Karena itu saya tidak bisa dengan jujur mengklaim bahwa SSD fisik tertentu rusak, atau menunjuk storage node, network path, atau komponen virtualization tertentu sebagai root cause.
Yang bisa saya katakan lebih sempit tetapi didukung kuat: virtual storage path yang diberikan ke Linux guest saya berulang kali masuk ke keadaan ketika I/O filesystem biasa membutuhkan beberapa detik atau gagal selesai dalam waktu yang wajar. Evidence berasal dari iostat, PSI, D-state, kernel wait stack, wait EXT4/jbd2, wait filesystem Nginx, queue depth, dan request timing. Itu cukup untuk diagnosis engineering yang saya perlukan, tetapi tidak cukup untuk menentukan root cause fisik.
Mengapa lebih dari 3 TB trafik sebelumnya tidak bertentangan dengan stall berikutnya
Awalnya ini membuat saya bingung. Kalau storage bermasalah, bagaimana VPS sebelumnya bisa mentransfer beberapa terabyte dengan sukses?
Karena network traffic tidak sama dengan physical disk I/O. Sebuah file bisa dibaca sekali dari backing storage, tetap berada di Linux page cache, lalu disajikan berkali-kali dari memory. Jadi tiga terabyte yang dikirim lewat network tidak berarti tiga terabyte unique physical disk reads.
Kondisi infrastructure juga berubah: cache state, storage load, queueing, host placement, dan workload lain dapat berubah seiring waktu. VPS yang berjalan normal kemarin tidak menjamin perilaku storage identik hari ini.
Akhirnya saya berhenti menunggu root cause yang lebih dalam
Saya mengumpulkan timestamp yang tepat, vmstat, iostat, PSI, snapshot process blocked, kernel stack, wait filesystem, queue depth, dan HTTP timing. Saya mengirim diagnostics ke FDCServers dan menunggu penjelasan yang lebih dalam di tingkat infrastructure.
Saya menunggu cukup lama. Pada akhirnya saya berhenti menunggu. Dari sisi saya, informasi sudah cukup untuk mengambil keputusan operasional: masalahnya reproducible, parah, terlihat di bawah application layer, dan penyebab fisiknya berada di luar visibility VPS saya.
Saya meminta refund dan FDCServers mengembalikan uangnya
Saya mengirim ringkasan masalah dan diagnostics yang sudah saya kumpulkan kepada FDCServers, meminta service dibatalkan, lalu meminta refund. Mereka mengembalikan uang saya.
Jadi cerita ini tidak berakhir dengan pertengkaran panjang soal uang. Saya menunggu penjelasan teknis definitif, memutuskan berhenti menunggu, mengirim evidence yang saya miliki, dan meminta uang saya kembali. FDCServers mengembalikannya.
Apa yang saya ubah setelah itu
Hasil yang berguna bukanlah menentukan apakah satu perusahaan hosting baik atau buruk. Pengalaman ini mengubah cara saya debug server Linux yang lambat.
Saya masih memakai top, free -h, dan df -h, tetapi sekarang jauh lebih cepat beralih ke:
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-pagerSaya juga menguji request path secara terpisah bila memungkinkan: public request, Nginx lokal, backend langsung, filesystem, dan block-device metrics. Pertanyaannya tidak lagi sekadar mengapa server lambat. Pertanyaannya adalah: di lapisan mana pekerjaan yang berguna berhenti selesai?
Jika memungkinkan, saya menangkap evidence sebelum reboot. Reboot bisa memulihkan service, tetapi juga bisa menghapus D-state, PSI, queue, dan latency yang justru membuat insiden intermittent bisa didiagnosis.
Penutup
Saya tidak membeli VPS FDCServers karena ingin mendapatkan bahan artikel hosting. Saya membutuhkan server dengan bandwidth besar. Selama beberapa waktu, itulah yang saya dapatkan: server menangani workload nyata dan mentransfer lebih dari tiga terabyte.
Kemudian workload normal mulai secara reproducible menghasilkan iowait hingga 100%, I/O PSI hampir 100%, read hingga 18,7 detik, flush latency lebih dari 53 detik, queue besar, Nginx blocked pada filesystem read, dan EXT4/jbd2 menunggu I/O.
Saya tidak pernah mengetahui komponen fisik atau host-side mana yang menyebabkannya, dan saya tidak perlu berpura-pura mengetahuinya. Saya menemukan layer tempat failure muncul, mengumpulkan evidence yang cukup untuk membedakannya dari masalah aplikasi, berhenti menunggu penjelasan root cause yang lebih dalam, dan meminta uang saya kembali. FDCServers mengembalikannya.
Ini bukan verdict untuk setiap VPS FDCServers. Ini hanya pengingat yang terdokumentasi dengan baik bahwa sebuah service bisa terlihat active, sebuah process bisa terlihat running, sementara mesin menghabiskan hampir seluruh waktu produktifnya menunggu storage.