Sistem yang sibuk di jaringan yang digunakan oleh beberapa pengguna lokal (atau ribuan pengguna web) mengalami masalah kinerja selama siklus hidupnya. Hanya sistem yang tidak sibuk yang kebal terhadap masalah kinerja yang mengganggu kita semua. Artikel ini mengeksplorasi tersangka yang biasa ditemukan dan memperbaiki masalah kinerja.
Berikut ini adalah panduan umum, ringkasan dasar "tempat untuk memulai". Setiap masalah berbeda, tetapi saat Anda mendapatkan lebih banyak pengalaman, Anda akan memiliki gagasan yang lebih baik tentang di mana dan bagaimana mulai mencari masalah tertentu. Saya percaya bahwa Anda dapat diajari dasar-dasar pemecahan masalah tetapi Anda tidak dapat diajarkan pengalaman atau intuisi. Mereka berdua datang dengan waktu. Juga, perhatikan bahwa beberapa masalah memanifestasikan dirinya sedemikian rupa sehingga Anda memulai satu jalan dan sering mengarah ke yang lain. Faktor ini membuat frustrasi tetapi normal. Misalnya, masalah disk tertentu dapat menyebabkan penggunaan CPU melonjak, dan masalah memori dapat menutupi dirinya sebagai masalah performa disk. Mulailah dengan hal-hal yang mudah terlebih dahulu dan kemudian lanjutkan ke hal yang lebih kompleks. Jangan mempersulit hidup Anda lebih dari yang diperlukan. Terkadang Anda hanya perlu mengganti kabel jaringan atau mem-boot ulang sistem. Sederhana, tapi efektif.
Membalikkan perubahan terbaru
Membuat perubahan dalam lingkungan produksi diperlukan. Mendokumentasikan perubahan tersebut adalah wajib. Anda akan senang melakukannya saat terjadi kesalahan, dan itu akan terjadi. Hal yang aneh tentang membuat perubahan di Linux (atau sistem lainnya) adalah bahwa perubahan itu sendiri mungkin bekerja dengan sempurna saat Anda membuatnya, tetapi dalam satu atau dua hari, kinerja sistem Anda menurun. Sebelum Anda melakukan hal lain, periksa dokumentasi perubahan Anda untuk melihat apakah ada perubahan terbaru yang dilakukan pada sistem. Perubahan mencakup patch perangkat lunak, pembaruan dalam bentuk apa pun, penggantian atau peningkatan perangkat keras, pembaruan driver, pembaruan firmware, kode push, pemasangan perangkat lunak baru, dan perubahan konfigurasi.
Saat Anda memeriksa dokumentasi perubahan Anda, bandingkan perubahan terbaru dengan masalah yang Anda alami. Setelah melakukan pemeriksaan sistem yang biasa, Anda harus membalikkan perubahan Anda satu per satu untuk melihat mana yang dapat ditelusuri ke akar penyebab kinerja Anda. Terkadang, Anda akan menemukan bahwa "cluster" pembaruan tertentu tidak kompatibel, atau harus diinstal atau diterapkan dalam urutan tertentu. Selalu periksa dokumentasi vendor Anda untuk melihat apakah ini masalahnya.
Perbarui, perbarui, perbarui
Anda dapat menghindari masalah kinerja yang terkait dengan bug perangkat lunak dan perangkat keras dengan terus memperbarui semuanya, terutama jika menyangkut perangkat lunak sisi server (bukan sisi klien, seperti browser web). Sisi klien juga harus diperbarui, tentu saja, tetapi itu diskusi yang berbeda.
Ya, ini adalah pekerjaan penuh waktu untuk memperbarui semua sistem Anda. Selalu ada sesuatu yang perlu diperbarui pada suatu sistem:BIOS, firmware, driver, sistem operasi, aplikasi, agen, perangkat lunak keamanan, basis data, perangkat lunak cadangan, dan sebagainya. Tugas ini tidak pernah berakhir. Putuskan seberapa sering Anda perlu memperbarui, atau mematuhi kebijakan tambalan organisasi Anda untuk merencanakan, menjadwalkan, dan menerapkan pembaruan tersebut. Di salah satu pekerjaan saya, kami melakukan patch seminggu sekali. Melakukan hal itu menyakitkan. Itu mengharuskan kami untuk begadang seminggu sekali, yang menjadi cepat tua. Namun, tidak ada cara untuk menghindari melakukannya secara teratur. Anda harus mengupdate untuk memastikan bahwa sistem Anda aman dan memiliki patch stabilitas terbaru.
Jika sistem Anda mutakhir dan tidak ada pembaruan baru yang tersedia, Anda biasanya dapat mengesampingkan pembaruan dan patch sebagai akar penyebab masalah kinerja.
Keterbatasan dan kegagalan perangkat keras
Dalam pengalaman saya, semua orang (programmer, administrator jaringan, manajemen, dan vendor) ingin menyalahkan infrastruktur untuk semua masalah kinerja. Mereka semua secara kolektif percaya bahwa infrastruktur adalah mata rantai terlemah dan di situlah kemungkinan besar kerusakan terjadi, jadi Anda harus membuktikan bahwa bukan perangkat keras Anda yang menyebabkan masalah sebelum ada yang mengambil tindakan. Saya setuju dengan satu hal, tetapi agak mengganggu ketika itu asumsi pertama, daripada yang diselidiki secara bersamaan dengan penyebab potensial lainnya.
Biasanya ada empat komponen perangkat keras yang dapat gagal atau mencapai batasan yang dapat menyebabkan masalah:CPU, jaringan, memori, dan disk. Ada komponen lain yang juga dapat gagal, seperti catu daya, tetapi "empat besar" ini adalah penyebab paling umum dan tempat pertama yang harus Anda perhatikan saat mengalami masalah.
CPU
Saat ini sebagian besar sistem server memiliki bank CPU multi-inti dan multi-prosesor. Jika Anda memiliki masalah CPU, itu mungkin disebabkan oleh cacat pada CPU itu sendiri. Menemukan CPU tertentu yang memberi Anda masalah berada di luar cakupan artikel ini. Jika Anda mencurigai kegagalan atau anomali CPU yang sebenarnya, hubungi vendor sistem Anda untuk meminta saran. Kemungkinan mereka memiliki rutinitas diagnostik yang dapat Anda jalankan yang akan mengidentifikasi masalah CPU. Di luar itu, mereka akan mengirim teknisi untuk mengganti satu CPU atau semuanya.
Jadi, selain kegagalan CPU yang datar, apa yang Anda cari ketika Anda mencurigai adanya masalah CPU? Centang top untuk melihat apakah ada proses yang membebani CPU Anda. Untuk mengurutkan top untuk CPU, jalankan top lalu ketik P (Shift+P). Lihat proses yang menghabiskan siklus CPU Anda. Apakah yang di bagian atas daftar berkaitan dengan sistem atau aplikasi? Jika itu adalah proses sistem, periksa waktu aktif Anda. Uptime tidak boleh terlalu tinggi karena reboot secara teratur.
Jika Anda menemukan aplikasi tertentu menggunakan jumlah siklus CPU yang tidak normal, mulai ulang aplikasi untuk melihat apakah masalah tetap ada. Jika prosesnya terkait dengan sistem, coba mulai ulang proses jika memungkinkan. Jika tidak, reboot sistem. Ya, reboot sistem.
Bonus pemecahan masalah (boot ulang)
Ya, Anda perlu me-reboot setidaknya sebulan sekali. Saya tahu ada banyak argumen tentang praktik ini, tetapi untuk mengesampingkan banyak masalah, reboot yang baik akan menyelesaikan banyak masalah dan membantu Anda mendiagnosis masalah perangkat keras dengan sedikit usaha. Mematikan sistem sesekali juga merupakan praktik yang baik, karena menghidupkan sistem dari boot dingin dapat mengidentifikasi banyak masalah perangkat keras yang mungkin tersembunyi pada sistem yang sedang berjalan. Anda juga dapat mempersempit masalah jika masalah kinerja tetap ada setelah reboot.
Memori
Tempat paling jelas berikutnya untuk dilihat ketika kinerja pemecahan masalah adalah penggunaan memori. Masalah memori dapat memanifestasikan dirinya dengan cara yang berbeda yang mengaburkan fakta bahwa memori memang masalahnya. Jika Anda mendapati bahwa selama satu hari memori sistem Anda terkuras, hal pertama yang harus diperiksa adalah logging Anda. Saya tahu kedengarannya gila, tetapi menangkap kayu hampir menghabiskan jutaan dolar untuk perusahaan tempat saya bekerja. Saya perhatikan dalam laporan kinerja bahwa memori sistem cluster kami sedang terkuras di siang hari. Ada banyak gigabyte memori yang tersedia, jadi masalah ini seharusnya tidak terjadi. Selain itu, kinerja semakin buruk seiring berjalannya waktu. Setiap malam di tengah malam, semuanya akan kembali. Apa yang terjadi di tengah malam, Anda bertanya? Rotasi log. Rupanya, seseorang telah mengaktifkan debugging untuk log, yang berarti bahwa puluhan gigabyte per hari dikumpulkan, dicadangkan, dan disimpan secara tidak perlu. Dan, itu menguras ingatan kita. Setelah ditemukan dan diperbaiki, kinerjanya kembali dengan kekuatan penuh dan mengurangi kebutuhan untuk menghabiskan jutaan dolar untuk sistem tambahan untuk cluster besar ini.
Anda juga harus melihat ruang swap jika Anda mencurigai adanya masalah memori. Pada output ini, sistem saya dalam keadaan idle sehingga hasilnya tidak dramatis. Gunakan free -m perintah untuk memeriksa penggunaan memori fisik dan virtual (swap):
$ free -m
total used free shared buff/cache available
Mem: 821 200 288 10 333 484
Swap: 0 0 0
Jika Anda menggunakan banyak swap, sistem Anda mungkin melakukan apa yang *nix administrator sebut "thrashing." Memukul, bertentangan dengan apa yang dilakukan pemain skateboard, adalah hal yang buruk bagi kami. Anda tidak ingin sistem Anda rusak. Thrashing juga dapat muncul sebagai masalah disk jika cukup parah. Jika sistem Anda sangat sibuk untuk masuk dan keluar sehingga mempengaruhi kinerja disk, Anda harus segera bertindak dengan memulai ulang proses yang mengganggu. Sekarang, jangan salah paham. Swap diatur dan dikonfigurasi untuk mem-page sesuatu ke disk, tetapi jika hal itu menyebabkan masalah kinerja, masalah ini perlu diperbaiki.
Banyak sistem modern memiliki begitu banyak memori sehingga swap berbasis disk tidak digunakan sama sekali. Beberapa administrator merasa itu membuang-buang ruang disk. Bagi saya, apakah saya mengonfigurasi swap bergantung pada tujuan sistem dan jumlah RAM yang dimilikinya. Pertimbangan swap benar-benar untuk artikel lain, tetapi saya akan mengatakan bahwa cara Anda menangani swap terserah Anda. Saya tidak berpikir aturan lama 1,5x RAM adalah formula yang baik lagi. Pikirkan tentang itu. Jika sistem Anda memiliki RAM 128GB, itu berarti Anda mengonfigurasi RAM 192GB untuk ruang swap. Konyol. Saya mungkin menyiapkan 16GB paling banyak untuk sistem itu jika saya mengonfigurasi swap sama sekali.
Dalam kasus yang jarang terjadi, RAM Anda bisa buruk, atau rusak. Saya pernah mengalaminya. Anda juga harus berhati-hati dengan jenis RAM yang Anda beli untuk suatu sistem jika Anda meningkatkan. Cocokkan apa yang Anda miliki atau ganti semuanya jika Anda tidak dapat mencocokkannya. Jangan mencampur kecepatan, cache, atau merek. Juga, gunakan jenis RAM yang disarankan untuk sistem Anda. Menggunakan di luar merek atau RAM yang tidak cocok adalah bencana yang menunggu untuk terjadi.
Akhirnya, program yang salah dapat menyebabkan masalah memori. Program berbasis Java secara historis paling menyedihkan bagi saya. Beberapa pemrogram Java tidak memprogram dengan benar untuk pembersihan sampah atau pelepasan memori, dan masalah muncul saat beban tinggi atau saat panggilan tertentu dilakukan. Saya selalu memulai dengan memulai kembali proses. Opsi saya selanjutnya adalah mencentang top untuk jumlah memori yang dikonsumsi oleh program. Jika semua pemeriksaan dan proses restart saya tidak berhasil, saya reboot sistem. Jika masalah mulai lagi, saya akan pergi ke programmer dan mengeluh dan memberikan laporan saya.
Disk
Disk gagal. Itu adalah pernyataan yang kuat tapi benar. Bahkan SSD gagal di beberapa titik, jadi bersiaplah untuk kegagalan disk. Ingatlah bahwa RAID tidak sama dengan cadangan, dan bahwa disk dan partisi terisi, yang membuatnya berperilaku dengan kinerja yang kurang optimal. Jika Anda mencurigai sebuah disk adalah pembunuh performa Anda, hal pertama yang harus dilihat adalah ruang yang tersedia dengan df cepat perintah:
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 397M 0 397M 0% /dev
tmpfs 411M 0 411M 0% /dev/shm
tmpfs 411M 11M 400M 3% /run
tmpfs 411M 0 411M 0% /sys/fs/cgroup
/dev/sda2 16G 1.8G 14G 12% /
/dev/sda1 495M 152M 344M 31% /boot
tmpfs 83M 0 83M 0% /run/user/1000 Anda dapat melihat di atas bahwa tidak ada sistem file penuh atau hampir penuh di server saya.
Item berikutnya yang harus diperiksa adalah apakah sistem file Anda penuh atau hampir penuh. Jika tidak ada, maka Anda memiliki disk yang gagal. Saya tidak dapat mensimulasikan kegagalan disk, tetapi beberapa sistem server memberi tahu Anda ketika mereka memiliki disk yang gagal. Misalnya, beberapa server lama saya menunjukkan lampu kuning dan bukan lampu hijau saat terjadi kesalahan. Perhatikan indikator perangkat keras Anda. Saya juga memiliki server yang memiliki layar LCD kecil yang memberi tahu saya tentang kegagalan dan kesalahan. Alat ini sangat membantu ketika sistem operasi tidak memberi tahu saya bahwa ada masalah.
Disk yang gagal memengaruhi kinerja, apa pun konfigurasinya. Konfigurasi RAID tidak menjamin kinerja jika disk anggota gagal. Sebaliknya, mereka menjamin keamanan karena redundansi. Dengan kata lain, data Anda utuh, tetapi pengguna dan pelanggan Anda tidak akan senang karena kinerja yang lamban. Harapkan masalah kinerja saat disk anggota gagal.
Jika Anda memiliki sistem yang lamban, periksa server fisik dan semua komponen, peringatan, dan pesannya. Langkah ini untuk mereka yang memiliki akses ke server fisik. Begitu banyak administrator sistem harus berurusan dengan sistem remote atau host dan karena itu tidak memiliki akses semacam ini.
Jaringan
Masalah jaringan karena perangkat keras agak jarang terjadi, tetapi memang terjadi. NIC yang mengoceh, kabel yang buruk, atau sakelar atau port sakelar yang gagal dapat menjadi sumber frustrasi bagi administrator sistem. Dan, jika Anda menambahkan port switch atau kesalahan konfigurasi jaringan pada host itu sendiri, Anda sekarang memiliki resep untuk banyak hal yang menarik. Terkadang sulit untuk menemukan sumber masalah jaringan karena masalahnya bisa lokal, di sakelar, atau di suatu tempat di luar sakelar. Anda harus melihat setiap level secara terpisah untuk menemukan masalahnya.
Periksa host Anda yang lain untuk perbandingan. Apakah masalah terlokalisasi ke satu host, apakah terbatas pada satu grup, atau seluruh sistem? Pemeriksaan ini akan membantu Anda mengidentifikasi apakah masalahnya bersifat lokal, apakah terbatas pada satu sakelar, jika memengaruhi seluruh rak atau baris, atau jika masalah lebih meluas.
Periksa konfigurasi jaringan lokal Anda. Periksa changelogs untuk melihat apakah ada sesuatu yang baru saja berubah. Selanjutnya, lakukan pemeriksaan fisik pada NIC Anda. Apakah lampu terlihat benar bagi Anda? Apakah kabelnya terlihat bagus dan apakah stekernya tampak tidak rusak? Apakah konfigurasi kabel terlihat benar? Periksa seluruh panjang kabel dari kerusakan fisik, jika memungkinkan. Periksa sakelar fisik dan terminator kabel di sakelar apakah ada cacat fisik.
Periksa sendiri konfigurasi sakelar atau minta admin jaringan untuk melakukannya. Periksa secara fisik lokasi sakelar atau lihat dokumentasi Anda untuk menemukan port yang benar untuk dilaporkan ke admin jaringan. Jika konfigurasi terlihat bagus, minta admin jaringan melakukan reset cepat pada port. Juga, tanyakan kepada admin tentang pembaruan sakelar terakhir dan tanggal reboot terakhir.
Bergantung pada pekerjaan Anda dan tempat Anda bekerja, Anda mungkin tidak memiliki kendali atau visibilitas di luar sakelar Anda. Bekerja dengan admin jaringan, ISP, atau penyedia hosting untuk menemukan masalah kinerja jaringan lebih lanjut. Pengalaman pribadi memberi tahu saya bahwa kecuali masalah jaringan meluas, admin jaringan menginginkan bukti dari apa yang telah Anda periksa yang membuat Anda menyalahkan jaringan. Karena alasan ini, saya menempatkan pemecahan masalah jaringan di urutan terakhir dalam daftar. Saya tidak dapat menghitung berapa kali saya mendengar kata-kata yang membuat frustrasi itu: "Ini bukan jaringan, kawan. Ini pasti infrastruktur." Dan kemudian nada panggil.
Menutup
Tidak ada jalan pintas untuk mendapatkan pengetahuan pemecahan masalah. Anda dapat belajar dan bersiap, tetapi sayangnya, pengalaman adalah guru terbaik karena Anda harus mengalami kegagalan sebelum merasakan pemecahan masalah yang sesungguhnya. Bahkan kegagalan yang disimulasikan tidak memberi Anda pengalaman yang sama dengan kegagalan nyata, dengan pengguna sebenarnya bertanya kapan semuanya akan diperbaiki, dan manajer nyata melihat Anda seperti kesalahan Anda bahwa perusahaan kehilangan uang, dan kesal karena keyboard Anda tidak berfungsi. t membuat kebisingan.
Memecahkan masalah bukanlah bagian yang menyenangkan dari menjadi sysadmin, tetapi ini adalah bagian yang diperlukan. Sebenarnya, saya tidak yakin apakah ada bagian yang menyenangkan, dan itu semua diperlukan. Menjadi sysadmin membuat stres, dan pemecahan masalah adalah bagian besar dari stres itu. Saya telah memberi Anda petunjuk dalam upaya untuk menurunkan stres itu, tetapi Anda tetap bergantung pada Anda untuk mendapatkan pengalaman dan kepercayaan diri dalam menerapkannya.