halo semua, seperti biasa, nulis untuk kebutuhan catatan saja bagi saya. atau bisa juga sebagai Portofolio, kali aja artikel saya ini di lirik sama seseorang yang sedang membutuhan jasa saya. hehehe wkwkwk. judulnya itu analisa sistem dan infrastruktur untuk pemecahan masalah.

oiya, artikel ini khusus pemula, untuk yang sudah Pro = Profesional, jangan dibaca. karena saya bisa diketawain. wkwkwkwkw begitu. karena ini analisa abal-abal alias sembarangan. saya sendiri baru pertama kali melakukan analisa se kompleks ini. permasalah ini sudah beberapa bulan terjadi, dan saya baru sempat nulisnya sekarang.

berawal dari laporan client, bahwa aplikasinya lambat di akses. errornya itu lo yang bikin menarik. :

dari error diatas, rata-rata mahluk hidup di muka bumi ini pasti menduga ada masalah dengan jaringan, lalu mereka akan berasumsi bahwa bandwith di servernya bermasalah. karena mereka buka yutub aman kok, dan web-web lain aman. bandwith servernya nih pasti. gitchu~~~

btw, wait… eh, itu di akses jam 11 malam loh, (lihat pojok kiri atas). harusnya, jam segitu bandwith server gak tinggi. oke deh, untuk memanstikan, saya terpaksa hubungi pihak provider, apakah benar, pada jam segitu bandwith mentok. dan jawabannya, tidak. mentoknya kalo siang wkwkwkw.

oke, kita bahas yang benerannya, error tersebut terjadi karena ada lost koneksi dari client (HP) ke server aplikasi. penyebabnya ? bisa jaringan di client, jaringan di server, query, bandwith, daaaaaaaann server yang terlalu sibuk, gak tau deh ngapain dan lain-lain, banyak deh. oke, kita eliminasi masalah, ini yang penting, bisa eliminasi. seperti indonesian idol aja ya. wkwkkw

A. eliminasi permasalahan

1. internet client bermasalah? tidak mungkin. karena doi bisa buka yutub dan web web lain
2. trafik network server bermasalah, ? tidak mungkin juga. karena itu diakses jam 11 malam, yang begitu di konfirmasi ke pihak provider juga aman.
3. logic dari aplikasi, ? bisa jadi. mari kita cek untuk memastikan.
4. utilitas server bermasalah ? bisa jadi, mari kita cek untuk memastikan.

B. cek utilisasi server

kemudian, saya akses server. hal pertama yang dilakukan adalah ketik htop . wkwkw, ini perintah paling lazim dilakukan untuk liat kondisi server.

dan ternyata, benar… resourcenya CPU nya tinggi banget. nah, ada apa ini ? wah wah.. kok bisa. ini yang bikin error disisi usernya

wealah, kok bisa ya CPU 16 core mentok. ini server ngapain ya ? seperti sedang dipakai mining Bitcoin ajah, wkwkkw. sek. kok ya jadi kepikiran ya mining Bitcoin pake server, lumayan juga buat nambah asupan gizi dimasa pandemi gini, wkwkwkw. wes wes sadar.

agak aneh bagi saya, dan bagi teman-teman yang saya tanyai. apalagi setelah melihat dari fungsi aplikasi, kegunaan, jumlah user akses, dan logicnya. 16 core VCPU harusnya udah lebih dari cukup.

nah, bagi orang yang panikan, biasanya langsung buru-buru untuk menjustifikasi masalah pada cpu yang penuh, dan harus di tambah, tidak main-main, 4 kali lipat sekaligus. wew, emangnya mau bikin Data Center Bos pakai 64 core ??? 😀 lagian, belum tentu kan masalahnya teratasi ????. tenang, mari kita cari tau masalahnya lebih dalam.

C. cek aplikasi yang memakan resource

ada dua aplikasi yang tertinggi memakan resource dari server tersebut, yang pertama database, yang kedua web server. saya melakukan penangkapan slow query log pada kedua aplikasi tersebut. yang pertama backend web server hasilnya :

benar, aplikasi tersebut menggunakan engine php untuk menjalankannya. perlu diingat, php itu bukan akronim dari Pemberi Harapan Palsu , ya.

dari error php tersebut mengarah ke database.

benar, satu query di eksekusi sampai dengan 15 -20 detik, panteslah error disisi clientnya TCP error.karena server gagal melayani permintaan dari client.

sampai disini, sysadmin harus berkomunikasi dengan Programmer dan Database Engineer. harus ada hubungan yang harmonis antara ketiga elemen tersebut.

hubungan ini tidak akan terjadi jika sebuah project hanya di handle oleh satu orang saja. biasa di sebut Full Stack Developer. dia programmernya, dia database enginernya, dia juga sysadminnya. bisa mabok darat doi. wkwkwkw

sysadmin menanyakan kepada Database engineer, apakah query pada aplikasi sudah di sederhanakan secara maksimal. jika jawabannya sudah, namun masih terdapat error slow query log. maka harus mencari penyebab lainnya.

D. pengecekan di sisi perangkat.

pengecekan dilanjutkan disisi perangkat. yang berhubungan dengan itu adalah perangkat Input Output. ada dua, NIC dan Disk. saya cek NIC terlebih dahulu. setelah di cek, NIC dalam kondisi baik. NIC dengan 10 Gbps dapat dilewati dengan mulus oleh data-data yang di transfer.

kemudian say cek Disk. untuk cek disk, bisa menggunakan hdparm, fdisk, dll, banyak toolsnya, disini saya menggunakan fio. yaitu aplikasi untuk mengecek Read & Write pada Disk. dan, setelah di cek ini hasilnya :

FYI, server ini masih menggunakan HDD , IOPS segitu untuk digunakan aplikasi yang trafik dan Read Write datanya tinggi, sangat jelek, bahkan bisa dikatakan jeblok. lihat saja Readnya, hanya 38.

beberapa orang yang pasrah dengan keadaan, maksudnya ya hanya punya server itu dan gak mungkin upgrade, maka akan mengakali dengan memecahnya menjadi banyak bagian aplikasi pada server.

untuk aplikasi, bisa menggunakan teknologi kekinian yang biasa di kenal Microservices. bisa di baca disini : https://medium.com/codelabs-unikom/microservices-apaan-tuh-b9f5d56e8848

untuk database, bisa upgrade ke yang lebih mumpuni untuk pengolahan data besar, Postgresql, atau Monggo DB lebih sangat bagus. setelah itu di cluster. Read dan Write database di pisah, menggunakan Proxy. pasti akan jadi pekerjaan berat nan keren. ya gimana lagi, adanya server itu. wkwkwkw

solusi yang kedua, upgrade SSD, maka masalah IOPS beres. begini penampakan IOPS yang menggunakan SSD

jauh banget kan ya ? hehehe

oke. lanjut.

pada kasus ini, server sudah upgrade menggunakan SSD, dan ternyata, aplikasi sudah beres, aman dan kenceng.

coba deh di lihat CPU nya, pasti tidak load mentok lagi. karena query yang di Read dan Write di Dsik tidak antri, tidak lama lagi waktunya, otomatis, CPU juga tidak bekerja keras lagi. dan loadnya menurun.

sampai disini saya tidak cek server lagi dari sisi sistem Operasi, karena sudah di handle oleh sysadminnya. saya hanya menyediakan SSD.

jadi, tidak perlu upgrade CPU kan ? bayangkan saja jika harus upgrade CPU, larang regone Rekkkkkk. dan kerjaannya ribet Rekkkk. kudu backup data, matiin server, bongkar, halah, mumet. semetara aplikasi diburu kudu running dan yang lebih kacau, bisa jadi setelah upgrade CPU masalah tidak teratasi.

Mal Praktek Rekkkk jenenge neng dunia kedokteran. 😀

yoweslah, sekian aja, yang penting client udah tersenyum lebar karena aplikasinya udah aman. disitu saya merasa dipuasin oleh client . walaupun clientnya LANANGAN.