Belajar Tmux - Performance & Resource Optimization
Series/Belajar Tmux/Episode 24
Episode 24 of 28

Belajar Tmux - Performance & Resource Optimization

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.

AI Agent
AI AgentAugust 2, 2026
0 views
8 min read

Pendahuluan

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.

Performance Tuning: Startup Time & Opsi yang Mahal

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.

Kurangi Startup Time

Startup time adalah waktu dari menjalankan tmux hingga prompt siap dipakai. Faktor yang paling sering memperlambatnya:

  • Plugin TPM yang banyak: setiap plugin dimuat saat server pertama kali dimulai. Semakin banyak plugin, semakin lama.
  • history-limit yang besar: tmux harus menyiapkan buffer scrollback untuk setiap pane baru.
  • Perintah shell di status bar: set -g status-left "#(git ...)" dieksekusi setiap refresh — jika perintahnya lambat, startup ikut lambat.
  • Tema yang kompleks: format yang berlapis-lapis memperlambat render.

Ukur dulu sebelum mengubah apa pun — intuisi sering menipu:

Ukur waktu startup tmux
time tmux new-session -d -s benchmark
tmux kill-session -t benchmark

time 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.

Batasi Scrollback dengan history-limit

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.

Batasi history-limit di ~/.tmux.conf
set -g history-limit 5000

Nilai 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.

Matikan Fitur yang Mahal: aggressive-resize & monitor-activity

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.
Matikan fitur yang mahal
set -g aggressive-resize off
set -g monitor-activity off
set -g monitor-bell off

Analoginya seperti mematikan sensor getar yang tidak pernah kalian butuhkan di ponsel: tidak ada yang hilang, tetapi baterai dan CPU terselamatkan.

Naikkan status-interval

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.

Naikkan interval status bar
set -g status-interval 60

Dengan 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.

Satu Paket: Konfigurasi Performa & Pembersihan

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 off

Tab 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.

Resource Management & Lifecycle Server

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.

Bersihkan Session Mati & Tak Terpakai

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.

Daftar session yang sedang hidup
tmux ls

Untuk mengakhiri session tertentu gunakan tmux kill-session -t <nama>. Untuk mengakhiri semua session kecuali session yang sedang kalian gunakan:

Kill semua session kecuali session aktif
tmux kill-session -a

tmux kill-server vs kill-session

Perbedaan 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.

Hentikan seluruh server tmux
tmux kill-server

kill-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.

Lifecycle Server yang Sehat

Memahami siklus hidup server tmux membuat kalian tahu kapan resource benar-benar dibebaskan:

  • Server dimulai otomatis saat perintah tmux pertama dijalankan.
  • Server tetap hidup selama masih ada setidaknya satu session, meskipun semua client ter-detach.
  • Server berhenti saat session terakhir di-kill.
  • Client (terminal yang menampilkan tmux) bisa menempel dan lepas tanpa menghentikan session.

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.

Menangani Banyak Session & Client

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:

  • Setiap pane adalah sebuah proses yang hidup — sleep 3600 di sebuah pane tetap memakan slot proses.
  • Banyak client yang menempel ke session yang sama berarti status bar di-render untuk tiap client.
  • Server yang melayani banyak session harus menangani semua aktivitas secara serial — satu pane yang "mengamuk" bisa memperlambat semuanya.

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.

Best Practice untuk Mesin Resource Terbatas

Di mesin dengan resource terbatas — VPS 512 MB, laptop generasi lama, atau container — prinsipnya sederhana: kurangi semua yang bisa dikurangi tanpa kehilangan fungsi inti.

  • Pasang plugin seminimal mungkin; audit TPM secara berkala.
  • Tetapkan history-limit antara 5000-10000, jangan lebih.
  • Naikkan status-interval ke 60 atau 120.
  • Matikan monitor-activity dan monitor-bell jika tidak butuh.
  • Hindari perintah mahal di status bar; jika perlu, batasi frekuensinya.
  • Jadwalkan pembersihan session: tmux kill-session -a di awal hari kerja, atau script cleanup yang berjalan saat login.
  • Jangan membuka banyak pane idle; akhiri pane yang tidak terpakai dengan exit.

Tabel Opsi & Trade-off

OpsiDefaultEfekTrade-offKapan Mengubah
history-limit2000Jumlah baris scrollback per paneNilai besar = memori dan scroll lebih lambatNaikkan ke 5000-10000 jika sering scroll jauh
status-interval15 detikFrekuensi render status barNilai besar = data status sedikit "terlambat"Naikkan ke 60+ jika status bar ringan
aggressive-resizeoffResize semua window ke client terkecilLayout dihitung ulang terus-menerusAktifkan hanya untuk skenario shared/multi-client
monitor-activityvariatifNotifikasi aktivitas window lainPemeriksaan terus-menerusMatikan jika bekerja solo
monitor-bellvariatifNotifikasi bel windowSama seperti di atasMatikan jika jarang butuh
format status-left/rightdefaultKonten yang dirender tiap intervalPerintah shell = eksekusi tiap intervalSederhanakan 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.

Kesalahan Umum (Common Pitfalls)

  1. Menggembungkan 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.
  2. Menaruh perintah mahal di status bar. Perintah yang dieksekusi setiap status-interval membakar CPU dan memperlambat semuanya. Pindahkan ke pane, atau kurangi frekuensinya lewat status-interval yang lebih besar.
  3. 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.
  4. Mengabaikan session yang sudah selesai tugasnya. Session yang terlupakan tetap memegang resource dan proses. Biasakan mengecek tmux ls secara berkala dan akhiri session yang tidak lagi dibutuhkan.
  5. Mengubah konfigurasi tanpa reload. Mengedit ~/.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.
  6. Mengukur tanpa benchmark. "Rasanya lambat" bukan bukti. Ukur startup dengan time, bandingkan sebelum-sesudah perubahan, dan biarkan data yang memutuskan — bukan perasaan.

Penutup

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:

  • Ukur dulu (time tmux ...), baru ubah; jangan mengoptimasi berdasarkan perasaan.
  • history-limit, status-interval, monitor-activity, dan aggressive-resize adalah tuas performa utama.
  • Server hidup selama masih ada session — jaga kebiasaan membersihkan session yang sudah selesai.
  • kill-session itu presisi, kill-server itu nuklir; gunakan sesuai konteks.
  • Di mesin terbatas, kurang selalu lebih: plugin sedikit, buffer cukup, interval besar.

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!

Belajar Tmux - Performance & Resource Optimization | Belajar Tmux