Di episode 24 ini kita menyelami sisi performa tmux: mengurangi startup time, membatasi scrollback history, mematikan fitur yang mahal, dan menjaga lifecycle server yang sehat untuk mesin dengan resource terbatas.

Di episode 23 sebelumnya kita membahas troubleshooting — membaca log, mendiagnosis konfigurasi yang salah, dan menyelamatkan tmux yang tidak mau berjalan. Pada episode ini kita bergeser dari "bagaimana memperbaiki yang rusak" menuju "bagaimana mencegah yang tidak perlu". Kita akan membahas performance & resource optimization: bagaimana membuat tmux ringan, cepat dimulai, dan hemat resource — kualitas yang langsung terasa di mesin yang kekurangan memori.
Bayangkan tmux sebagai ruang kerja. Ruang kerja yang rapi, terang, dan hanya berisi barang yang benar-benar dipakai membuat kalian nyaman dan cepat bekerja; ruang kerja yang penuh dekorasi, lampu kelap-kelip, dan tumpukan dokumen lama justru memperlambat. Tmux default sebenarnya sudah cukup hemat — tetapi beberapa opsi dan kebiasaan bisa membuatnya "membengkak" tanpa disadari: scrollback yang digelembungkan, plugin yang bertumpuk, dan status bar yang terus-menerus mengeksekusi perintah shell.
Di dunia production, trade-off ini bukan teori. Di VPS dengan RAM 512 MB, server yang menjalankan banyak service, atau laptop lama yang dinyalakan semalaman — setiap megabyte dan setiap persen CPU berharga. Pada episode ini kita akan membahas tuning performa (startup time, scrollback, fitur mahal, status bar), resource management dan lifecycle server yang sehat, serta menutup dengan tabel trade-off dan best practice untuk mesin dengan resource terbatas.
Tmux versi 3.7b yang kita pakai sepanjang series ini sebenarnya sangat ringan — server tmux idle hanya memakan beberapa megabyte. Namun ada beberapa pilihan yang bisa membuat pengalaman terasa berat, baik saat startup maupun saat digunakan dalam waktu lama. Mari bedah satu per satu.
Startup time adalah waktu dari menjalankan tmux hingga prompt siap dipakai. Faktor yang paling sering memperlambatnya:
history-limit yang besar: tmux harus menyiapkan buffer scrollback untuk setiap pane baru.set -g status-left "#(git ...)" dieksekusi setiap refresh — jika perintahnya lambat, startup ikut lambat.Ukur dulu sebelum mengubah apa pun — intuisi sering menipu:
time tmux new-session -d -s benchmark
tmux kill-session -t benchmarktime mencatat durasi eksekusi. Angka real di bawah satu detik sudah bagus; jika lebih dari itu, mulai audit plugin dan perintah status bar kalian.
Tip
Aturan praktis untuk plugin: hanya pasang yang kalian pakai, bukan yang "kelihatannya keren". Setiap plugin adalah kode yang dimuat di setiap startup dan bisa berinteraksi secara tak terduga. Di episode 15 (plugin ecosystem TPM) kita membahas cara mengelola plugin; di sini ingat bahwa jumlah plugin adalah biaya yang dibayar setiap kali memulai server.
Default history-limit tmux adalah 2000 baris per pane. Banyak tutorial menyarankan menaikkannya — dan memang benar untuk beberapa kasus. Tetapi nilai ekstrem seperti 100000 punya ongkos: memori untuk menyimpan baris, waktu membangun buffer saat pane dibuat, dan scroll/search yang lebih lambat ketika buffer membesar.
set -g history-limit 5000Nilai 5000 sampai 10000 sudah lebih dari cukup untuk hampir semua pekerjaan — termasuk menelusuri log panjang atau kembali ke output sebelumnya. Kalau kalian benar-benar butuh lebih, aktifkan khusus untuk pane/window tertentu, bukan global.
Important
history-limit hanya berlaku untuk pane yang dibuat setelah pengaturan diterapkan — mengubahnya tidak memperbesar buffer pane yang sudah ada. Untuk menerapkan pada session yang berjalan, buat window/pane baru atau mulai session baru; untuk reload konfigurasi gunakan tmux source-file ~/.tmux.conf.
Ada dua opsi yang sering "hidup" padahal jarang dibutuhkan, dan keduanya memicu pekerjaan ekstra di setiap perubahan:
aggressive-resize: dengan opsi ini, setiap window di-resize ke ukuran client terkecil yang terpasang, bahkan ketika window tidak aktif. Hasilnya: layout dihitung ulang terus-menerus di banyak window sekaligus. Defaultnya off — dan itu pilihan tepat untuk kebanyakan penggunaan.monitor-activity dan monitor-bell: memantau aktivitas dan bel di setiap window. Notifikasi itu berguna, tetapi ada harganya — server terus memeriksa. Jika kalian tidak butuh peringatan aktivitas window (misalnya bekerja solo), matikan.set -g aggressive-resize off
set -g monitor-activity off
set -g monitor-bell offAnaloginya seperti mematikan sensor getar yang tidak pernah kalian butuhkan di ponsel: tidak ada yang hilang, tetapi baterai dan CPU terselamatkan.
Status bar tidak render sendiri; ia di-render ulang setiap status-interval detik. Defaultnya 15 detik. Setiap kali render, format status-left dan status-right dievaluasi — dan jika ada #() atau #{shell:...} di dalamnya, perintah itu dieksekusi setiap interval. Ini sumber utama pemborosan: perintah git yang lambat dijalankan berkali-kali per menit, sepanjang hari.
set -g status-interval 60Dengan nilai 60 (atau 120), jam di status bar tetap update, tetapi beban render dan eksekusi perintah turun drastis. Trade-off-nya: informasi yang berubah cepat menjadi sedikit "terlambat" — biasanya tidak masalah. Kalau kalian butuh refresh instan untuk sesuatu yang spesifik, jalankan perintahnya manual di pane, bukan di status bar.
Gabungkan semua tuning di atas dengan rutinitas pembersihan yang akan kita bahas berikutnya, jadi satu paket yang siap dipakai:
set -g history-limit 5000
set -g status-interval 60
set -g aggressive-resize off
set -g monitor-activity off
set -g monitor-bell offTab pertama adalah konfigurasi di ~/.tmux.conf; tab kedua adalah perintah pembersihan yang bisa dijalankan kapan saja server terasa "penuh". Mari kita bahas baris per baris pada bagian berikutnya.
Konfigurasi yang ringan hanya separuh cerita. Separuh lainnya adalah bagaimana kalian mengelola server dan session yang hidup. Server tmux bisa berjalan berhari-hari dan menumpuk session yang tidak pernah kalian sentuh lagi — masing-masing memakan memori dan membuka pane yang menjalankan proses.
tmux list-sessions (atau tmux ls) menunjukkan semua session yang hidup. Kebiasaan sehat: sebelum mengakhiri hari kerja, lihat daftar ini dan tanya, "session mana yang masih akan saya pakai besok?" Jika ragu, detach dan biarkan hidup — tmux memang dirancang untuk itu. Tetapi session yang jelas sudah tidak berguna sebaiknya diakhiri agar tidak menggerogoti memori.
tmux lsUntuk mengakhiri session tertentu gunakan tmux kill-session -t <nama>. Untuk mengakhiri semua session kecuali session yang sedang kalian gunakan:
tmux kill-session -aPerbedaan penting yang sering membingungkan pemula: kill-session mengakhiri satu session (dan seluruh window/pane di dalamnya), sedangkan kill-server mengakhiri server tmux secara keseluruhan — semua session, window, dan pane mati sekaligus, dan proses servernya berhenti.
tmux kill-serverkill-server ibarat mematikan listrik seluruh gedung: tidak ada satupun yang tersisa. Gunakan dengan sadar — periksa dulu dengan tmux ls apakah ada session lain yang penting. Di episode 12 (persistence & session restore) kita membahas plugin yang menyelamatkan session setelah kill-server; ingat itu jika kalian tergoda memakai kill-server setiap hari. Alur yang sehat adalah membunuh session yang tak terpakai, bukan membunuh semuanya lalu menata ulang dari nol.
Memahami siklus hidup server tmux membuat kalian tahu kapan resource benar-benar dibebaskan:
Implikasinya: jika kalian membuat session untuk sebuah tugas lalu melupakannya, server dan resource-nya tetap hidup berhari-hari. Ini fitur, bukan bug — persis itulah alasan session bisa dipulihkan. Tetapi sadarilah bahwa detach tidak sama dengan selesai. Detach = kerja tetap berjalan; kill = benar-benar berhenti.
Setiap session punya biaya: memori untuk buffer pane, proses yang dijalankan pane, dan konteks format di status bar. Menumpuk puluhan session "yang mungkin berguna" adalah kebiasaan yang mahal. Beberapa hal yang perlu diingat:
sleep 3600 di sebuah pane tetap memakan slot proses.Kebiasaan sehat: gunakan jumlah session yang sedikit dan terarah, manfaatkan window untuk memisahkan konteks di dalam satu session, dan tutup session yang sudah selesai tugasnya.
Di mesin dengan resource terbatas — VPS 512 MB, laptop generasi lama, atau container — prinsipnya sederhana: kurangi semua yang bisa dikurangi tanpa kehilangan fungsi inti.
history-limit antara 5000-10000, jangan lebih.status-interval ke 60 atau 120.monitor-activity dan monitor-bell jika tidak butuh.tmux kill-session -a di awal hari kerja, atau script cleanup yang berjalan saat login.exit.| Opsi | Default | Efek | Trade-off | Kapan Mengubah |
|---|---|---|---|---|
history-limit | 2000 | Jumlah baris scrollback per pane | Nilai besar = memori dan scroll lebih lambat | Naikkan ke 5000-10000 jika sering scroll jauh |
status-interval | 15 detik | Frekuensi render status bar | Nilai besar = data status sedikit "terlambat" | Naikkan ke 60+ jika status bar ringan |
aggressive-resize | off | Resize semua window ke client terkecil | Layout dihitung ulang terus-menerus | Aktifkan hanya untuk skenario shared/multi-client |
monitor-activity | variatif | Notifikasi aktivitas window lain | Pemeriksaan terus-menerus | Matikan jika bekerja solo |
monitor-bell | variatif | Notifikasi bel window | Sama seperti di atas | Matikan jika jarang butuh |
format status-left/right | default | Konten yang dirender tiap interval | Perintah shell = eksekusi tiap interval | Sederhanakan atau kurangi #() |
Baca tabel ini sebagai menu, bukan dogma: setiap opsi punya tempatnya. Kuncinya adalah mengubah dengan sadar, mengukur, dan memastikan trade-off-nya memang kalian butuhkan.
history-limit tanpa alasan. Mengatur 100000 baris agar "aman" membuat setiap pane memakan memori berkali-kali lipat dan memperlambat scroll/search. Tetapkan sesuai kebutuhan; naikkan per window hanya saat benar-benar butuh.status-interval membakar CPU dan memperlambat semuanya. Pindahkan ke pane, atau kurangi frekuensinya lewat status-interval yang lebih besar.kill-server sebagai pembersih harian. Membunuh seluruh server untuk "membersihkan" adalah tindakan brutal yang menghapus semua session. Pilih kill-session -a atau kill-session -t <nama> yang lebih presisi.tmux ls secara berkala dan akhiri session yang tidak lagi dibutuhkan.~/.tmux.conf lalu bertanya-tanya mengapa tidak berefek — karena history-limit dan beberapa opsi lain butuh pane/window baru. Jalankan tmux source-file ~/.tmux.conf dan buat pane baru untuk memverifikasi.time, bandingkan sebelum-sesudah perubahan, dan biarkan data yang memutuskan — bukan perasaan.Pada episode 24 ini, kalian telah mempelajari cara membuat tmux lebih ringan dan terkelola: mengurangi startup time dengan mengaudit plugin dan format status bar, membatasi history-limit agar scrollback tidak membengkak, mematikan aggressive-resize dan monitor-activity yang mahal, menaikkan status-interval untuk meredam eksekusi perintah berulang, serta mengelola lifecycle server — membersihkan session mati, membedakan kill-session dan kill-server, dan menerapkan best practice di mesin dengan resource terbatas.
Poin kunci yang perlu kalian bawa:
time tmux ...), baru ubah; jangan mengoptimasi berdasarkan perasaan.history-limit, status-interval, monitor-activity, dan aggressive-resize adalah tuas performa utama.kill-session itu presisi, kill-server itu nuklir; gunakan sesuai konteks.Dengan server yang ringan dan bersih, kalian siap melanjutkan ke babak berikutnya. Di episode 25 selanjutnya kita akan membahas integrasi tmux dengan editor & developer ecosystem — navigasi seamless antara pane dan Neovim/VS Code dengan vim-tmux-navigator, integrasi lazygit, dan session switcher berbasis fzf dengan display-popup. Karena terminal yang ringan akan terasa jauh lebih produktif ketika ia terhubung mulus dengan editor favorit kalian. Pastikan tetap semangat!