MySQL Load 500% di Server 80 Core — Analisis Config &

Saya masih ingat malam itu — jam 2 pagi, HP berdering, monitoring system alert masuk bertubi-tubi. MySQL load average naik drastis sampai 500%, website client pada down semua. Saya langsung SSH ke server, cek top, dan ternyata benar — mysqld process monopoli CPU kayak lagi festival sendirian. Yang bikin saya geleng-geleng? Server ini bukan server receh. Ini server dengan 80 core CPU dan 256GB RAM. Kok bisa MySQL sampai load segitu parah di hardware sebesar itu?

Bayangin kamu punya jalan tol 10 jalur yang lebar dan mulus, tapi tiba-tiba ada 500 mobil mau masuk sekaligus dari satu pintu masuk. Pasti macet parah, kan? Itu persis yang terjadi di MySQL kamu — bukan masalah jalannya yang sempit, tapi cara mobilnya diatur yang bermasalah. MySQL di server besar tanpa optimasi config itu ibarat jalan tol 10 jalur yang pintu masuknya cuma cukup untuk 1 mobil. Semua menumpuk di situ.

Gejala MySQL Load 500%

Sebelum kita bedah config, penting untuk kamu tahu dulu gejala-gejala yang biasanya muncul saat MySQL mulai bermasalah. Load 500% itu bukan angka kecil — itu artinya ada 5x lebih banyak proses yang menunggu giliran diproses oleh CPU daripada jumlah core yang tersedia. Di server 80 core, load 500% berarti sekitar 400 proses lagi antri.

Gejala yang paling sering saya temui:

• Website lambat responsnya — waktu load naik dari biasanya 200ms jadi 5-10 detik
• Error “Too many connections” di log MySQL
• Load average di server naik tajam — dari biasanya 10-20 jadi 400+
• Query yang seharusnya cepat malah lambat — SELECT sederhana bisa makan waktu berdetik-detik
• Proses”sleeping” menumpuk di output SHOW PROCESSLIST
• Swap usage meningkat — padahal RAM masih available banyak

Kalau kamu lihat semua gejala ini muncul bersamaan, kemungkinan besar root cause-nya ada di konfigurasi MySQL yang belum optimal untuk spesifikasi server kamu. Dan ini masalah yang sangat umum terjadi di server shared hosting atau VPS yang RAM-nya besar tapi config MySQL-nya masih pakai bawaan.

Server 80 Core 256GB RAM — Kok Bisa MySQL Load Tinggi?

Ini yang sering jadi misteri bagi banyak administrator server. Kok bisa server dengan spesifikasi monster kayak gini bisa kena masalah MySQL? Bukankah hardware sebesar itu seharusnya sanggup handle beban apapun?

Jawabannya: hardware tidak menentukan performa MySQL — konfigurasi yang menentukan.

MySQL punya banyak parameter yang mengontrol bagaimana dia menggunakan resource yang tersedia. Kalau kamu tidak mengkonfigurasi parameter-parameter ini dengan benar, MySQL akan membatasi dirinya sendiri meskipun CPU dan RAM tersedia banyak. Ibarat punya mobil Lamborghini tapi gas-nya dibatasi sampai 30 km/jam.

Beberapa parameter kritis yang sering jadi bottleneck:

• innodb_buffer_pool_size — Jika terlalu kecil, MySQL harus terus-menerus baca data dari disk, yang jauh lebih lambat dari RAM
• max_connections — Jika terlalu kecil, koneksi baru ditolak meskipun server masih punya banyak resource
• table_open_cache — Jika terlalu kecil, MySQL harus terus buka-tutup file tabel, yang sangat memakan waktu
• tmp_table_size — Jika terlalu kecil, MySQL terpaksa pakai disk untuk temporary tables, yang sangat lambat

Ini yang saya alami di server tersebut — config MySQL masih pakai setting bawaan atau setting lama yang tidak disesuaikan dengan spesifikasi server yang sebenarnya. Hasilnya? MySQL hanya menggunakan sebagian kecil dari 256GB RAM yang tersedia.

Review Config MySQL yang Sudah Diterapkan

Oke, sekarang kita bedah config yang sudah kamu terapkan. Saya akan analisis bagian per bagian mana yang sudah benar dan mana yang masih perlu di-tweak.

Config yang sudah diterapkan:

[mysqld]
# Logging
log-error = /var/lib/mysql/server-01.err

# Performance
performance-schema = 0

# Buffer pool
innodb_buffer_pool_size = 5G
innodb_file_per_table = 1

# Koneksi
max_connections = 1024
max_allowed_packet = 256M
open_files_limit = 80000

# Storage engine
default-storage-engine = InnoDB

# Query cache nonaktif
query_cache_type = 0
query_cache_size = 0
query_cache_limit = 0
key_buffer_size = 32M

# Timeout
wait_timeout = 30
interactive_timeout = 30

# Table caching
table_open_cache = 4096
table_definition_cache = 4096

# Max execution time
max_statement_time = 30

# Temp tables
tmp_table_size = 128M
max_heap_table_size = 128M

# InnoDB tweaks
innodb_stats_on_metadata = 0
innodb_flush_method = O_DIRECT

Sekarang saya bahas satu per satu.

Bagian yang Sudah Benar

query_cache_type = 0 — Ini sudah tepat. Query Cache di MySQL 5.7 dan 8.0 memang sudah deprecated dan sering jadi penyebab lock contention di server dengan banyak koneksi. Nonaktifkan adalah keputusan yang tepat.

innodb_flush_method = O_DIRECT — Bagus. Ini menghindari double buffering dengan OS page cache, yang artinya InnoDB flush langsung ke disk. Cocok untuk server yang punya dedicated storage.

innodb_stats_on_metadata = 0 — Benar. Ini mencegah MySQL update statistics setiap kali kamu jalankan SHOW STATUS, yang bisa bikin query plan berubah-ubah.

wait_timeout = 30 — Sudah cukup agresif dan bagus untuk shared hosting. Koneksi idle tidak akan menumpuk.

innodb_file_per_table = 1 — Standar best practice. Setiap tabel punya file .ibd sendiri, lebih mudah di-maintain.

Bagian yang Perlu Di-Tweak

Nah, di sinilah masalah utamanya. Beberapa setting masih terlalu kecil untuk server dengan 256GB RAM dan 80 core CPU.

Yang Perlu Di-Tweak: Optimasi Config MySQL

1. innodb_buffer_pool_size — Masih Terlalu Kecil

Ini adalah parameter paling kritis dalam optimasi MySQL. Saat ini kamu set ke 5GB, padahal server punya 256GB RAM. Artinya kamu hanya menggunakan sekitar 2% dari total RAM yang tersedia untuk buffer pool MySQL.

InnoDB Buffer Pool adalah tempat MySQL menyimpan data dan index di RAM agar tidak perlu baca dari disk setiap kali ada query. Semakin besar buffer pool, semakin banyak data yang bisa di-cache di RAM, dan semakin cepat query kamu.

Rekomendasi: Untuk dedicated MySQL server, buffer pool idealnya 60-70% dari total RAM. Untuk server shared hosting yang juga menjalankan web server dan layanan lain, kamu bisa mulai dari 50-60% RAM.

Untuk server 256GB RAM yang juga menjalankan LiteSpeed dan layanan lainnya:

# Untuk server 256GB RAM
dedicated untuk MySQL:
innodb_buffer_pool_size = 160G

# Untuk server 256GB RAM shared
(dengan LiteSpeed, dll):
innodb_buffer_pool_size = 128G

Dengan buffer pool 128GB, hampir semua data aktif kamu bisa muat di RAM. Ini akan mengurangi disk I/O secara drastis dan load average akan turun signifikan.

Peringatan: Jangan langsung setting buffer pool terlalu besar tanpa testing. Mulai dari 128G dulu, monitor beberapa hari, lalu naikkan bertahap jika masih ada headroom. Terlalu besar buffer pool bisa menyebabkan swapping yang justru memperlambat server.

2. max_connections & Thread Cache

max_connections = 1024 sudah cukup untuk kebanyakan kasus. Tapi yang sering terlupakan adalah thread_cache_size. Di config kamu saat ini, thread_cache_size tidak didefinisikan, artinya pakai default MySQL yang biasanya kecil.

Thread cache berfungsi agar MySQL tidak harus membuat thread baru setiap kali ada koneksi baru. Di server dengan banyak koneksi seperti shared hosting, ini bisa menghemat banyak overhead.

# Tambahkan ini:
thread_cache_size = 64
table_open_cache_instances = 16

Dengan 80 core CPU, table_open_cache_instances = 16 memungkinkan MySQL mengakses table cache secara paralel tanpa contention. Ini sangat penting untuk performa di server multi-core.

3. table_open_cache & table_definition_cache

Saat ini kamu sudah set ke 4096, yang cukup untuk server dengan beberapa ratus database. Tapi untuk server shared hosting dengan banyak database dan tabel, kamu bisa menaikkannya:

# Untuk server dengan banyak database
table_open_cache = 16384
table_definition_cache = 16384

Cara mengetahui apakah table_open_cache kamu cukup:

mysql -e "SHOW GLOBAL STATUS LIKE 'Open_tables';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Opened_tables';"

Jika Opened_tables terus meningkat dengan cepat, berarti table_open_cache kamu kurang besar. Idealnya, ratio Opened_tables per hari harus sedikit mungkin. KalauOpened_tables mencapai ratusan ribu per hari, kamu perlu naikkan table_open_cache.

4. tmp_table_size & max_heap_table_size

Saat ini kamu set ke 128MB. Untuk server 256GB RAM, ini masih bisa dinaikkan. Temporary tables digunakan oleh MySQL saat menjalankan query kompleks seperti JOIN, GROUP BY, atau ORDER BY pada dataset besar.

# Naikkan untuk query kompleks
tmp_table_size = 512M
max_heap_table_size = 512M

Dengan 512MB, MySQL bisa menampung lebih banyak temporary table di RAM tanpa harus ke disk. Ini sangat membantu untuk query analitik atau laporan yang sering dijalankan di shared hosting.

Catatan penting: tmp_table_size dan max_heap_table_size harus di-set SAMA. MySQL akan menggunakan nilai yang lebih kecil dari keduanya.

5. open_files_limit

80000 sudah cukup besar, tapi pastikan OS juga mengizinkan limit ini. Cek di system:

# Cek limit file descriptors di OS
cat /proc/$(pgrep -o mysqld)/limits | grep "Max open files"

Jika Max open files di bawah 80000, kamu perlu menaikkan limit di OS juga. Di systemd-based systems:

# Tambahkan di /etc/systemd/system/mysqld.service.d/override.conf
[Service]
LimitNOFILE=100000

# Lalu reload
systemctl daemon-reload
systemctl restart mysqld

6. innodb_flush_method & I/O Settings

innodb_flush_method = O_DIRECT sudah benar. Tapi ada beberapa parameter I/O tambahan yang bisa membantu:

# Optimasi I/O untuk NVMe/SSD
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 2

innodb_flush_log_at_trx_commit = 2 — Ini trade-off antara keamanan data dan performa. Dengan setting 2, MySQL flush log ke disk setiap detik, bukan setiap commit. Ini jauh lebih cepat tapi ada risiko kehilangan data 1 detik terakhir jika server crash. Untuk shared hosting yang bukan financial system, ini trade-off yang sangat worth it.

innodb_io_capacity — Sesuaikan dengan kemampuan storage kamu. Untuk NVMe, 4000-10000. Untuk SSD, 1000-4000. Untuk HDD, 200-400.

7. Timeout Settings

wait_timeout = 30 dan interactive_timeout = 30 sudah bagus untuk shared hosting. Tapi pastikan max_statement_time juga aktif:

# Pastikan max statement time aktif
max_statement_time = 30

# Tambahkan juga:
lock_wait_timeout = 10

lock_wait_timeout = 10 memastikan jika ada query yang menunggu lock terlalu lama, dia akan di-cancel setelah 10 detik. Ini mencegah satu query nakal mengunci resource untuk waktu yang lama.

Config MySQL Rekomendasi Final

Berdasarkan analisis di atas, berikut config MySQL yang saya rekomendasikan untuk server 80 core 256GB RAM yang menjalankan shared hosting dengan LiteSpeed:

[client-server]
!includedir /etc/my.cnf.d

[mysqld]
# Logging
log-error = /var/lib/mysql/server-01.err

# Performance Schema (nonaktif untuk hemat resource)
performance-schema = 0

# ===== BUFFER POOL =====
# Untuk server 256GB RAM (shared hosting)
innodb_buffer_pool_size = 128G
innodb_buffer_pool_instances = 32
innodb_file_per_table = 1

# ===== CONNECTIONS =====
max_connections = 1024
thread_cache_size = 64
max_allowed_packet = 256M

# ===== FILE HANDLING =====
open_files_limit = 100000
table_open_cache = 16384
table_definition_cache = 16384
table_open_cache_instances = 16

# ===== STORAGE ENGINE =====
default-storage-engine = InnoDB

# ===== SQL MODE =====
sql_mode = "ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

# ===== QUERY CACHE (DISABLED) =====
query_cache_type = 0
query_cache_size = 0
query_cache_limit = 0
key_buffer_size = 32M

# ===== TIMEOUTS =====
wait_timeout = 30
interactive_timeout = 30
max_statement_time = 30
lock_wait_timeout = 10

# ===== TEMP TABLES =====
tmp_table_size = 512M
max_heap_table_size = 512M

# ===== INNODB TWEAKS =====
innodb_stats_on_metadata = 0
innodb_flush_method = O_DIRECT
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 2G
innodb_log_buffer_size = 256M

# ===== SAFETY =====
skip-name-resolve

Monitoring & Verifikasi Setelah Perubahan

Setelah kamu apply config di atas dan restart MySQL, jangan langsung senang — kamu perlu monitoring dulu beberapa hari untuk memastikan semuanya stabil.

Beberapa command monitoring yang wajib kamu jalankan:

# 1. Cek status MySQL setelah restart
mysqladmin -u root -p status

# 2. Cek buffer pool hit ratio
# (harus di atas 99% untuk performa optimal)
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"

# Hit ratio = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
# Jika di atas 99%, buffer pool sudah cukup besar

# 3. Cek apakah ada query yang belum di-index
mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"

# 4. Cek koneksi aktif vs max
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';"
mysql -e "SHOW GLOBAL VARIABLES LIKE 'max_connections';"

# 5. Cek table cache hit ratio
mysql -e "SHOW GLOBAL STATUS LIKE 'Open_tables';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Opened_tables';"

# 6. Monitor swap — harus minimal
free -m

# 7. Cek apakah ada query yang kena max_statement_time
mysql -e "SHOW GLOBAL STATUS LIKE 'Max_statement_time_exceeded';"

# 8. Monitor InnoDB row operations
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_rows_%';"

Yang paling penting diperhatikan:

Metric	Target	Apa yang Terjadi Jika Tidak Terpenuhi
Innodb Buffer Pool Hit Ratio	> 99%	Banyak disk reads, load naik
Threads_connected	< 80% max_connections	Bisa kehabisan koneksi
Slow_queries	Minimal	Ada query yang perlu di-index
Swap usage	< 100MB	Buffer pool terlalu besar
Opened_tables	Stagnan/harian rendah	table_open_cache kurang besar

Untuk monitoring real-time, kamu bisa gunakan command ini:

# Monitor real-time dengan watch
watch -n 5 "mysql -e 'SHOW GLOBAL STATUS LIKE \"Threads_connected\";'
mysqladmin status"

# Atau gunakan tools seperti
top, htop, iotop untuk monitor
resource usage secara real-time

Pro Tips & Warnings

Dari pengalaman saya handle ratusan server, berikut beberapa tips yang sering dilupakan:

• Jangan restart MySQL saat peak hour — Apply config changes saat traffic rendah, idealnya tengah malam. Buffer pool perlu waktu untuk warming up setelah restart, jadi jika kamu restart saat traffic tinggi, performa akan menurun sementara.
• Monitor dulu 24-48 jam sebelum menaikkan lagi — Setelah apply config baru, jangan langsung naikkan parameter lain. Biarkan MySQL stabil dulu.
• innodb_buffer_pool_size harus kelipatan dari innodb_buffer_pool_instances — Jika kamu set 32 instances, buffer pool harus bisa dibagi rata. 128G / 32 = 4GB per instance, yang sangat reasonable.
• Gunakan innodb_flush_log_at_trx_commit = 2 dengan bijak — Ini aman untuk shared hosting, tapi JANGAN untuk application yang memproses transaksi finansial. Untuk payment gateway, tetap pakai setting 1.
• Cek slow query log — Setelah optimasi config, pastikan juga tidak ada query yang lambat karena belum di-index:

# Aktifkan slow query log
mysql -e "SET GLOBAL slow_query_log = 'ON';"
mysql -e "SET GLOBAL long_query_time = 2;"
mysql -e "SET GLOBAL slow_query_log_file =
'/var/log/mysql/slow-query.log';"

# Setelah beberapa hari, cek slow query log
grep -c "Query_time" /var/log/mysql/slow-query.log

• Backup config sebelum berubah — Selalu simpan backup config lama. Kalau ada yang tidak beres, kamu bisa langsung rollback:

cp /etc/my.cnf /etc/my.cnf.bak.$(date +%Y%m%d)
cp /etc/my.cnf.d/mysqld.cnf /etc/my.cnf.d/mysqld.cnf.bak.$(date +%Y%m%d)

FAQ

Artikel Terkait

• Optimasi MySQL untuk VPS dengan RAM Terbatas
• Cara Monitoring Server Linux dari A sampai Z
• Optimasi LiteSpeed Cache untuk WordPress
• Mengatasi MySQL Slow Query di Shared Hosting
• WordPress Load Tinggi — Penyebab & Solusi Lengkap

Masalah MySQL load tinggi memang bikin pusing, tapi dengan config yang tepat, server 80 core 256GB RAM kamu seharusnya bisa handle ribuan website tanpa masalah. Kuncinya adalah menyesuaikan config dengan spesifikasi hardware yang sebenarnya, bukan pakai setting default yang seadanya. Kalau butuh bantuan monitoring atau optimasi server, jangan ragu untuk hubungi tim NOC kami.