slow sshHari ini berarti sudah 12 jam lebih website GLC tidak dapat diakses baik melalui http maupun ssh. Jadi, ketika anda membuka website GLC, website tersebut tidak akan menghasilkan apa2 selain blank. Bisa diakses sih, cuman hasilnya timeout karena mungkin yang akses banyak sekali sehingga load server menjadi tinggi sekali. di media sosial beberapa rekan memberikan saran untuk troubleshooting slow ssh, dan saya sangat mengapresiasi sekali pendapat mereka.

berikut ini hal2 yang dapat kita ambil sebagai pelajaran:

  • Ketika troubleshooting, adalah wajib hukumnya untuk berpikir kritis, logis, analitis, dan sistematis.
    • kritis dalam praktis berarti tidak langsung menerima data/informasi/masukan yang ada. semua input yang masuk perlu di verifikasi dengan proses2 sesudahnya.
    • Logis artinya harus masuk akal (logika) dan mempunyai sebab akibat yang jelas. dalam kasus ini, troubleshooter harus tahu cara kerja aplikasi (ssh), tahapannya bagaimana, kemudian stuck dimana.
    • Analitis artinya mampu memahami data/informasi yang diberikan dan membuat keputusan berdasarkan data/informasi yang dimiliki. dalam analitis juga perlu dipersiapkan logika IF-THEN-ELSE yang banyak untuk mendiagnosis masalah. tentunya agar punya kemampuan analisis masalah yang baik diperlukan skill teknis yang mumpuni. Dalam kasus ini, troubleshooter wajib punya sesuatu yang bisa dipakai sebagai acuan untuk mengambil keputusan. nah salah seorang rekan, memberikan saran yang bagus sekali untuk mencoba koneksi ssh dengan opsi verbose sehingga terlihat jelas tahapan koneksinya.
    • Sistematis artinya kita perlu berpikir sistemik (bukan spesifik), maksudnya kita memandang system yang kita analisys adalah sebuah system dimana terdiri dari subsystem (misal: komponen2) merupakan bagian dari system yang lebih besar, sehingga dapat dipengaruhi/mempengaruhi system/komponen lain. konsekuensinya, dalam kasus “slow SSH”, bisa jadi karena ada sebab internal atau external. Sering terjadi, slow ssh ini hanya gejala saja, penyebabnya justru bukan dari SSH itu sendiri.
  • dari hasil verbose, tahap koneksi sudah sampai pada “entering interactive shell” yang berarti sudah dapet shell
  • ada yang berkomentar “ssh daemonnya gak jalan kali mas?”. komentar ini mentah karena ada reply dari server.
  • ada yang berkomentar “ssh_exchange_identification: Connection closed by remote host?”. komentar ini mentah karena tahap koneksi sudah sampai pada shell. umumnya symptom ini terjadi ketika koneksi kita ditolak, biasanya karena hosts.deny
  • ada yang berkomentar “mas… Install ulang saja servernya“. wuah… ini apalagi… langsung dibuang ke laut (maap yak…) hahaha… ya jelas aja kalo ini diikuti berarti menghina admin, karena adminnya ngak tau apa2 :-D. di company besar, mengusulkan ini bisa jadi mengundang surat peringatan atau ancaman dipecat… :-p
  • ada yang berkomentar “apalagi kayaknya ada yg ganti privilledge file auth_keynya… jadi accountnya jadi ga bisa baca private keynya…“. ini bisa jadi sebab terutama untuk koneksi yan udah trusted sehingga ngak perlu masukin password lagi. nah kalo key yang sudah disetup berubah, maka jadi ngak bisa login. tapi masalahnya bukan ini. slow ssh
  • ada yang berkomentar “hapus aja directory .ssh“. ehem.. sayapun balik nanya apa dasarnya & kenapa saya harus mengikuti sarannya? dan dijawab, “saya sering mengalaminya.. biasanya terjadi kalau ada pergantian server ip sama.. tetapi mesin berbeda.. dan diremote menggunakan client yang sama“. oh begitu ternyata. sayang sekali, sering mengalami bukan berarti otomatis bisa diterapkan dalam kasus ini. Jika problemnya adalah known-hosts, kenapa hasil debug sampai pada tahap ‘entering interactive shell’? Berarti masalahnya bukan ada pada known-hosts. Memberi solusi tanpa ada dasar yang kuat (mis: dari hasil debug), bisa jadi salah obat. Karena itu (mohon maaf) usulannya tidak saya laksanakan. slow ssh
  • ada yang berkomentar “saya rasa bukan known hosts. kalo itu problemnya, error output yang terjadi adalah tentang “key mismatch”. menurut saya kasus pak Achmad lebih mirip dengan problem di IP network/IP Backbone. misalnya seperti network split, ato dilewatin ke load balancer yang ga men-keep by session. Karena kalo servernya ga diutak-atik, ga mungkin kan behavior ssh servernya aneh begitu? lain cerita kalo sudah bisa masuk, tapi eksekusi command lemot. patut dicurigai adalah hardware faulty. Dan suspect pertamanya adalah hardisk ato HDD/RAID controllernya yang bermasalah. mumpung masih bisa di remote, saya usul supaya semua log system (messages, syslog, dmesg, kernel, secure) ditarik ke local. lebih fleksibel untuk mendebug problemnya.“.
    reply saya, “Betul kasusnya mirip dengan ssh yang dilewatkan di load balancer yang g aware terhadap session. tapi ini g pake load balancer. Saya rasa ini karena load di server tinggi sekali. Bisa jadi karena ada yang ngelakuin DOS. dan (berdasarkan pengalaman sbelumnya) yang bikin berat adalah php-fpmnya. Karena load tinggi, maka di sshpun susah (maklum cuman single core CPU). Kliatannya php-fpm memang belum mature enough… Dalam kasus ini saya udah pernah dapat shell kok. Cuman ya itu, responnya lama sekali. Ini kejadian udah beberapa kali. Udah dicek juga log file yang macem2 itu terutama pada baris yang dekat2 dengan waktu hang, tapi hasil nihil. Ga ada faulty hardware disana.
  • Komentar, “bottleneck IO sepertinya. Udh coba dishutdown service yg suspected kena DOS/too high? Siapa tau IO nya bisa free sendiri.“. reply saya, “ya itu dia, ngetik command untuk matikan itu service aja lama sekali. Malah sampe timeout. Jadinya ngak pernah bisa dieksekusi itu command. Hehehe alhasil masih ngehang”
  • Komentar, “pake one-liner command: ssh root@server “/etc/init.d/http restart” sapa tau bisa…:D” reply saya, “yeah.. Saya tau command itu & pengennya sih gitu. Sayangnya, saya harus melewati pertahanan sudo. Hehehe”

Summary:

  • Untuk troubleshooting slow ssh, diperlukan pemahaman terhadap cara kerja aplikasi kita.
  • Fasilitas verbose sangat beguna untuk debug (nyari error program)
  • kita juga harus terbuka terhadap kemungkinan lain, yaitu ternyata service SSH tidak bermasalah, melainkan dipengaruhi dari system lain
  • ternyata, setelah diinvetigasi lebih jauh, akar permasalahan datang dari aspek lain, yaitu high IO / high CPU usage. server ini menggunakan single core, hal ini benar2 sangat berpengaruh ke service sehingga menjadi slow ssh.
  • jadi slow ssh ini hanyalah gejala (symptoms) saja, dan sama sekali tidak bermasalah. koneksi ssh menjadi slow karena ada high IO pada system. high IO artinya sistem menunggu untuk mendapatkan IO resources (biasanya harddisk). kenapa high IO? nah ini untuk artikel  berikutnya… :-p

picture: wakyeng.com

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.