Penggunaan %CPU itu Bohong

• Secara umum, batas performa server dinilai dari tingkat penggunaan % CPU pada alat pemantauan seperti top, tetapi pada kenyataannya metrik ini tidak mencerminkan performa secara linear
• Hasil pengujian dengan stress-ng pada lingkungan Ryzen 9 5900X menunjukkan bahwa saat penggunaan 50%, beban kerja nyata sudah mencapai 60~100%, sehingga ada selisih besar dengan metrik tersebut
• Penyebab utamanya adalah hyper-threading dan turbo boost, di mana berbagi sumber daya antar core logis dan perubahan kecepatan clock mendistorsi metrik
• Karena itu, alih-alih hanya melihat penggunaan CPU, membandingkan benchmark beban kerja nyata yang dapat diproses dengan throughput saat ini adalah indikator yang lebih akurat
• Jika penggunaan CPU ditafsirkan secara linear, estimasi performa bisa sangat meleset, sehingga saat merencanakan sistem diperlukan pendekatan berbasis benchmark

---

Ketidaksesuaian antara angka penggunaan CPU server dan throughput nyata

• Saat mengoperasikan server, banyak orang ingin memastikan apakah sistem sudah mendekati penggunaan maksimum
• Umumnya mereka merujuk pada nilai tertinggi di antara penggunaan jaringan, memori, dan CPU melalui alat pemantauan seperti top
• Namun dalam praktiknya muncul masalah bahwa angka penggunaan CPU dan jumlah pekerjaan yang benar-benar bisa diproses tidak meningkat secara linear

Lingkungan dan metode pengujian

• Eksperimen berbasis Ubuntu desktop + Ryzen 9 5900X (12 core/24 thread)
• Precision Boost Overdrive (Turbo) diaktifkan
• Mensimulasikan berbagai beban dengan stress-ng (1~24 worker, penggunaan 1~100%)
• Metrik pengukuran: penggunaan CPU yang dilaporkan sistem dan jumlah komputasi nyata (Bogo ops)

Ringkasan hasil

• Beban CPU umum: pada penggunaan 50%, throughput nyata 60~65%
• Operasi integer 64-bit: pada penggunaan 50%, throughput nyata 65~85%
• Operasi matriks (Matrix math): pada penggunaan 50%, throughput nyata 80~100%
  • Dalam praktiknya, walaupun worker tambahan tidak lagi berkontribusi pada performa, penggunaan CPU tetap naik

Analisis penyebab

• Hyper-threading

  • Struktur 12 core fisik + 12 core logis
  • Hingga 12 worker dapat ditempatkan optimal pada core fisik, tetapi jika melebihi itu performa turun karena berbagi core logis
  • Khususnya pada operasi SIMD (operasi matriks), karena sumber daya dibagi, peningkatan performa tidak terjadi

• Turbo boost

  • Pada beban rendah 4.9GHz → saat full load 4.3GHz, terjadi penurunan clock 15%
  • Hal ini mendistorsi rumus perhitungan penggunaan CPU (= busy cycles / total cycles)
    • Saat penyebut (jumlah total siklus) menurun, kenaikan penggunaan tampak lebih besar daripada kenaikan beban kerja nyata

Implikasi

• Penggunaan CPU bukan indikator performa absolut
• Saat menghitung kapasitas server dan memprediksi performa:
  • 1. Ukur throughput maksimum dengan benchmark
  • 2. Pantau throughput aktual secara real-time
  • 3. Bandingkan keduanya untuk menilai apakah sudah mendekati batas performa
• Karena perbedaannya bisa besar tergantung arsitektur CPU (AMD vs Intel), efisiensi hyper-threading, dan cara kerja turbo, diperlukan analisis per prosesor

Kesimpulan

• Penggunaan CPU pada dasarnya hanya rasio siklus sibuk, bukan cerminan akurat dari performa pemrosesan nyata
• Dengan pemanfaatan yang efisien, bahkan pada "penggunaan 50%", sistem bisa saja sudah berada di 80~100% dari performa maksimum
• Karena itu, pemantauan performa dan perencanaan sistem sebaiknya berfokus pada throughput beban kerja berbasis benchmark, bukan pada penggunaan CPU

[ifmkl]

Dalam lingkungan konfigurasi HPC yang sebenarnya, klaster pada dasarnya dibangun dengan hyper-threading dimatikan.

[GN⁺]

Komentar Hacker News

• Saya rasa CPU utilization bukanlah kebohongan karena ia memang mengukur besaran yang didefinisikan dengan jelas, tetapi saat orang mencoba membuat model kapasitas lalu mengekstrapolasikannya, mereka mengalami ketidaksesuaian antara kenyataan dan ekspektasi
  Hyperthreading (SMT) dan Turbo (clock scaling) hanyalah sebagian dari banyak variabel yang menyebabkan nonlinieritas, dan bandwidth memori yang dibagi antar-core, kapasitas interconnect, cache prosesor, dan sebagainya juga merupakan sumber daya yang akan “terkuras” seiring meningkatnya beban
  Di sisi perangkat lunak pun, misalnya fenomena seperti spinlock dapat memberi dampak nonlinier pada utilization
  Sebagian besar metrik CPU utilization mengambil rata-rata panjang dalam hitungan beberapa detik hingga 1 menit, padahal hal-hal yang penting bagi performa server sensitif-latensi terjadi dalam puluhan hingga ratusan milidetik
  Karena itu, utilization dengan rata-rata beberapa detik tidak bisa membedakan pola burst dan pola yang halus
  Tetapi pendekatan yang diusulkan, yaitu “benchmark seberapa banyak pekerjaan yang bisa dilakukan server sebelum muncul error atau latensi yang tak dapat diterima”, pada dasarnya juga tidak stabil
  Saat mencoba mencari titik ketika server mulai menjadi tidak stabil, hasil pengukuran menjadi sangat noisy, dan dalam teori antrean pun semua noise diperkuat saat mendekati titik kritis
  Selain itu, “jumlah pekerjaan yang sedang dilakukan server saat ini” sendiri juga sering kali didefinisikan secara tidak stabil (RPS? biaya tiap request berbeda-beda, dan IPC juga berubah menurut waktu)
  Pada akhirnya, confidence interval yang keluar dari pendekatan load test pun tidak jauh berbeda dengan membuat model empiris dari metrik utilization. Asumsinya adalah utilization diukur dengan benar

  • Jika Anda tahu cara memakai perf atau ftrace, Anda bisa mendapatkan metrik prosesor yang sangat rinci dalam waktu singkat dan langsung melihat berbagai penyebab seperti CPU stall akibat cache miss atau memory access, dampak scheduler, dan lain-lain
    Tetapi kebanyakan orang, bahkan jika diberi metrik seperti IPC atau cache hit rate, tetap tidak tahu harus melakukan apa dengannya
    Pada akhirnya, yang benar-benar dipedulikan kebanyakan orang adalah latensi dan utilization
    Secara kasar, pada mayoritas workload, biasanya tidak ada masalah besar pada latensi sampai CPU utilization melewati 80%
    Namun di atas utilization itu, dampaknya mulai serius terhadap latensi workload
    Seberapa besar dampaknya terhadap latensi hanya bisa diketahui dengan mengukur workload masing-masing secara langsung
    Seberapa sensitif Anda terhadap latensi juga berbeda menurut organisasi dan tujuan, dan kadang throughput optimization justru bisa lebih penting
    Jika Anda peduli pada latensi dan throughput sekaligus, ukur keduanya dan tentukan sendiri trade-off yang tepat

  • Saya rasa salah satu poin intinya adalah bahwa definisi “jumlah pekerjaan” itu sendiri goyah
    Misalnya, berbeda apakah ini layanan public-facing yang menangani request pengguna nyata, atau workload pelatihan AI di backend yang menghitung data yang sudah ditumpuk dengan santai
    Pendekatan saya adalah, di lingkungan CPU modern multicore dan hyperthreaded yang burst-nya hampir tak terhindarkan, CPU utilization 60% sudah saya anggap sebagai server dengan “beban tinggi”
    Jika nilainya di atas 60% selama bagian besar dari hari itu, saya menganggap membagi pekerjaannya adalah langkah yang tepat (terutama untuk layanan yang merespons request pengguna)
    Dulu, patokan seperti ini sering membuat orang memikirkan cloud autoscaling
    Sekarang, server dengan lebih dari 100 core pun bisa dicoba dengan kisaran harga sekitar 30 ribu dolar, jadi situasinya makin rumit
    Kalau sekarang, saya cenderung memilih pendekatan hybrid: agak overprovision pada hardware server nyata, lalu scale out ke layanan cloud (atau internal cloud berbasis Kubernetes) sesuai kebutuhan
    Pada masa awalnya, StackOverflow mengelola trafik yang luar biasa besar secara efisien dengan rak khusus dan uplink 10Gbps, dan sekarang operasi seperti itu bahkan lebih mudah dilakukan
    Kesimpulannya, menurut standar saya, jika CPU load bertahan di 65% selama lebih dari 30 menit, itu sudah saya anggap sebagai penggunaan efektif 100% dan berarti perlu scale up dalam waktu dekat

  • Dalam keynote IEEE Hot Interconnects terbaru, kasus tuning latensi Ultra Ethernet juga disebutkan
    Dalam interval 2 detik atau 5 detik mungkin terlihat datar, tetapi jika dilihat pada skala 100ms, fenomena frame burst tampak jelas
    Artinya, jika measurement window saat profiling tidak cocok dengan workload nyata, kita bisa salah mengambil keputusan karena false negative, dan ini justru memperburuk masalah

  • Saya sepenuhnya setuju dengan poin yang disebutkan
    Karena sifat CPU utilization yang tidak linier, angka % itu sendiri menjadi tidak selaras dengan kenyataan
    Jadi, yang disebut “bohong” adalah CPU utilization yang diukur hanya dalam satuan %

  • Jika dua workload sama-sama mencatat penggunaan CPU 100%, tetapi salah satunya mengonsumsi daya jauh lebih besar dan menaikkan suhu CPU secara drastis, bukankah itu menimbulkan pertanyaan apakah workload tersebut sebenarnya memanfaatkan lebih banyak sumber daya transistor?

• Walaupun CPU utilization bukan metrik yang sempurna, dalam praktiknya ia tetap berguna
  Bahkan dari pengalaman kerja SRE yang sederhana, untuk task yang CPU-bound, saya menggabungkan angka CPU utilization ke teori antrean untuk menghitung ukuran server sebelum event besar, dan bahkan dengan patokan %CPU yang saya usulkan secara jauh lebih konservatif dibanding pendekatan yang lebih “tradisional”, hasilnya tetap jauh lebih hemat biaya dan bagus
  Intinya, jika metrik yang agak tidak akurat pun berguna di lapangan, jangan terlalu khawatir dan cobalah memakainya
  Meski begitu, alasan kami selalu menjaga CPU utilization production agar tidak melewati 40% adalah untuk menyediakan sedikit headroom dalam berbagai situasi
  Sayangnya, penulis kurang memberikan dasar logis tentang mengapa “utilization tinggi harus dihindari dari sudut pandang teori antrean”

  • Saya rasa metrik yang agak longgar pun cukup jika digunakan secara tepat di lapangan
    Misalnya, entah kita memakai rata-rata sederhana/nilai maksimum dari percentile metric per host, atau menghitungnya sebagai percentile saat histogram tingkat host diagregasi di tahap akhir, dalam praktik kerja saya peralihan antara keduanya tidak terlalu mengubah operasi nyata
    Ada sebagian orang yang terlalu peduli apakah sesuatu benar atau salah secara matematis, tetapi dalam operasi dunia nyata, sering kali dampaknya kecil

  • 40% sebenarnya terasa seperti tingkat utilization yang cukup longgar (banyak ruang)

  • Saya rasa melihat CPU% bersama loadavg bisa memberi gambaran kondisi sistem yang cukup baik
    Jika loadavg tinggi tetapi CPU% rendah, sistem mungkin tersendat pada jaringan atau I/O, atau sedang menunggu pada system call, dan sebagainya
    Dalam kasus seperti itu, jika hanya melihat CPU%, kita bisa melewatkan bagian yang sebenarnya sedang kesulitan

  • Rasanya saya pernah mendengar cerita yang persis sama
    Aneh juga bahwa isi yang disebut penulis seolah baru ditemukan sekarang, padahal itu sudah diulang-ulang selama puluhan tahun dalam buku teori antrean

• Saya teringat tulisan Brendan Gregg, "CPU Utilization is Wrong"
  Inti blog itu adalah bahwa CPU utilization hanya memakai “keadaan” bahwa CPU sibuk sebagai metrik, dan bahkan saat CPU berada dalam kondisi menunggu pun itu tetap dianggap busy
  Lalu IPC adalah ukuran untuk memahami jumlah kerja efektif yang sebenarnya tersembunyi di dalam keadaan busy tersebut

  • Saya penasaran kenapa orang-orang bernama Brendan begitu tertarik pada masalah CPU utilization
    Kalau ada Brendan lain, semoga bisa menjelaskannya

• Saya rasa performa yang diberikan hyperthread tidak boleh dihitung sebagai dua kali lipat
  Dalam kenyataan, bahkan jika hyperthread dimanfaatkan dengan baik, sering kali tambahan performanya hanya sekitar 15~30%. Sebaliknya, latensinya bisa menjadi dua kali lipat
  Saat core utilization meningkat, penurunan clock juga wajib diperhitungkan, jadi dalam praktik kita harus selalu sadar bahwa ini nonlinier
  Hanya dengan informasi yang disediakan OS pun, jika efek hyperthread dan penurunan clock ikut dihitung, kita bisa membuat estimasi utilization yang jauh lebih akurat
  Lebih dari itu, saya rasa memodelkan fenomena seperti batasan cache/bandwidth memori atau pipeline stall yang menyebabkan penurunan performa juga bukan hal yang terlalu sulit

  • Faktor yang membuat situasi lebih rumit adalah efisiensi hyperthread sangat berbeda-beda menurut arsitektur CPU dan workload
    Misalnya, implementasi AMD (terutama Zen terbaru) cenderung memberi performa yang jauh lebih independen daripada Intel (dengan asumsi tidak ada bottleneck bandwidth memori)

  • Jika aplikasinya memory-bound, lebih mudah melihat scaling yang lebih baik dengan hyperthread
    Proyek renderer yang pernah saya tangani sebelumnya bersifat memory-bound, jadi saya mengalami peningkatan performa 60~70% hanya dari hyperthread

  • Dulu saya pernah menjalankan benchmark sederhana dengan POV-Ray pada i7-3770K (4C/8T)
    Dari 1 thread ke 2 thread tepat dua kali lipat, dari 2 ke 4 juga dua kali lipat, tetapi dari 4 ke 8 hanya naik 15%
    Kalau itu benchmark aneh yang secara artifisial mengulang cache miss, mungkin SMT bisa menarik performa hampir dua kali lipat, tetapi saya ragu seberapa realistisnya
    Tambahan, saya sedang mempertimbangkan untuk menjalankan lagi tes POV-Ray itu. Sudah lama sekali jadi terasa nostalgia

• Penulis tampaknya menyadari bahwa performa tidak meningkat secara linier sesuai angka %CPU utilization, lalu menyimpulkan bahwa %CPU utilization itu sendiri adalah “kebohongan”
  Bahkan tanpa hyperthreading dan penurunan clock pun, dalam kasus yang terlihat minim variabel seperti Apple silicon, scaling yang benar-benar proporsional juga tidak muncul
  Saat mulai memakai banyak core sekaligus, bottleneck pada sumber daya selain CPU seperti overhead pengiriman data sering menimbulkan masalah, sehingga situasi serupa cukup sering terjadi

  • Apple silicon juga mengalami penurunan clock yang cukup besar, terutama pada model tanpa kipas (pendinginan pasif)

• Istilah core yang digunakan penulis membingungkan dan tidak sesuai standar
  Ia menyebut 5900X sebagai sistem 24 core, padahal sebenarnya strukturnya adalah 12 core fisik dengan 24 hyperthread
  Dua belas di antaranya adalah core fisik, dan 12 sisanya adalah thread yang menempel dan berjalan pada masing-masing core itu
  Walaupun instruction pipeline ada 2 set, functional unit internalnya tetap dibagi bersama

  • Beberapa tahun lalu, saat mencoba menjelaskan hyperthreading kepada adik saya yang kurang paham, analogi yang paling membekas adalah seperti tisu gulung dua lapis
    Kita tidak bisa memisahkan 24 lembar itu satu per satu, tetapi mirip dengan memakai 12 buah secara dua kali lebih berguna

  • Setelah menerima masukan, saya mengubah deskripsinya menjadi 12 core / 24 thread
    Tetapi memang membingungkan karena OS saya menampilkan utilization sebagai 24 core

  • Menarik juga kalau Intel suatu hari merilis software-defined core
    Kebalikan logis dari hyperthreading: dua atau lebih core berbagi sumber daya lalu berubah menjadi “satu core besar”
    Lihat tautan paten berikut
    https://patents.google.com/patent/EP4579444A1/en

  • Jika sepasang SMT menjalankan workload dengan jenis yang sama, efek SMT menurun karena terjadi perebutan sumber daya internal dan execution unit
    Jika workload-nya benar-benar berbeda, boost-nya justru bisa lebih besar
    Sekarang, dengan CPU modern yang punya P-core, E-core, turbo/non-turbo, dan variabel lain, situasinya menjadi lebih rumit
    Ada penelitian yang menyebut penambahan SMT memberi peningkatan performa per watt yang lebih besar daripada penambahan turbo, dan itu sangat menarik

• Ini benar-benar terasa relevan
  Dulu suatu hari, ketika CPU server sudah terisi sampai 60% dan saya menjelaskan ke manajer bahwa sebenarnya sudah tidak ada banyak ruang lagi, dia menatap saya dengan ekspresi aneh
  Rasanya akan sangat membantu jika waktu itu ada penjelasan seperti ini

  • Menjelaskannya bersama teori antrean akan sangat efektif
    Di bawah 60%, delay antrean pada dasarnya bisa diabaikan
    Saat melewati 70%, latensi mulai terasa jelas, dan mulai 80% hampir menjadi dua kali lipat
    Dalam pengalaman saya sendiri, targetnya disetel di 65% berdasarkan waktu P95, dan ini hampir selaras dengan patokan teoritis
    Kesimpulannya, “60% adalah batas penggunaan, 80% adalah titik ledakan latensi” adalah aturan praktis di lapangan

  • Tetapi ini bisa benar-benar berbeda tergantung workload
    Terutama di zaman sekarang ketika CPU server punya 32 core per mesin, menurut saya itu makin benar

• CPU utilization sering kali tidak bekerja seperti yang diharapkan
  Awalnya saya mengira tulisan seperti ini akan membahas angka utilization yang beredar di Linux/Windows, tetapi pada kenyataannya sering ada kasus CPU tampak senggang atau downclock karena bottleneck RAM
  Sebenarnya CPU utilization hanya menghitung seberapa banyak thread yang ditugaskan OS (baik Windows maupun Linux) ke setiap core
  Namun thread ini tetap tercatat sebagai utilization bahkan jika ia 100% hanya menunggu di memcpy
  Kelebihan hyperthread adalah, jika satu thread terikat pada unit AVX/vector dan thread lain terikat pada memcpy/RAM sederhana, pemanfaatan masing-masing unit bisa ditingkatkan sehingga performa total dan utilization ikut naik
  Pada akhirnya, CPU Utilization telah lama menjadi topik yang sulit dipahami secara intuitif, dan sudut pandang baru terus ditemukan setiap saat
  Tetap saja, ini selalu topik yang menarik

• Yang benar-benar “bohong” adalah kepercayaan bahwa hyperthread core bekerja sama persis dengan core sungguhan
  Pada akhirnya, karena sudah dipakai terus selama lebih dari 20 tahun, orang lupa pada sifat aslinya, lalu berulang kali menyadari kenapa hasil pengukuran performa terasa aneh
  Satu hal lagi, prosesor pada dasarnya hanya “sedang berjalan” (100%) atau “sedang menunggu” (0%)
  Memberi angka % di antaranya pada akhirnya hanyalah nilai rata-rata untuk satu satuan waktu tertentu

• Saya pernah mengalami percakapan seperti ini
  Manajer: CPU utilization 100%, jadi bukankah kita harus pindah ke instance yang lebih besar?
  Saya: "Tapi apakah CPU ini benar-benar sedang melakukan pekerjaan yang berguna?"
  Pada akhirnya, karena busy waiting juga tercatat sebagai CPU utilization, ada kasus di mana angkanya naik walaupun tidak ada hubungannya dengan kerja efektif yang sebenarnya

[jjjajh]

Itu ungkapan yang benar.