Sebuah benchmark terbaru telah mengungkapkan kesenjangan performa yang mengejutkan antara OpenBSD dan Linux ketika membuat network socket dalam aplikasi multi-threaded. Tes yang melibatkan dua thread yang masing-masing membuat 256 TCP socket menunjukkan OpenBSD menyelesaikan tugas dalam waktu sekitar 2-6 milidetik sementara Linux membutuhkan 17-26 milidetik - perbedaan hingga 10 kali lebih cepat.
Hasil Perbandingan Performa:
- Performa Linux: 17-26 milidetik (0.017770s - 0.026309s)
- Performa OpenBSD: 2-6 milidetik (0.002326s - 0.006096s)
- Perbedaan Kecepatan: Hingga 10x lebih cepat pada OpenBSD
- Skenario Pengujian: 2 thread yang masing-masing membuat 256 socket TCP (total 512 file descriptor)
Akar Masalah: Ekspansi Tabel File Descriptor
Perbedaan performa berasal dari cara setiap sistem operasi menangani ekspansi tabel file descriptor ketika melibatkan multiple thread. Di Linux , tabel file descriptor dimulai dengan 256 slot secara default. Ketika dua thread membuat 256 socket masing-masing (total 512 file descriptor), sistem harus memperluas tabel ini di tengah proses.
Selama ekspansi ini, kernel Linux memeriksa apakah multiple thread berbagi tabel file descriptor yang sama. Ketika mendeteksi akses bersama (seperti yang ditunjukkan oleh reference count lebih besar dari 1), sistem memanggil fungsi yang disebut synchronize_rcu() untuk memastikan thread safety. Fungsi ini menunggu periode grace RCU penuh untuk selesai, yang dapat memakan waktu beberapa milidetik dan menciptakan bottleneck performa yang diamati.
RCU (Read-Copy-Update) adalah metode sinkronisasi yang memungkinkan multiple thread membaca data dengan aman sementara satu thread memperbarui data tersebut, tetapi memerlukan periode tunggu untuk memastikan semua pembaca telah selesai.
Detail Teknis:
- Ukuran Tabel FD Default Linux: 256 slot
- Pemicu Bottleneck: Ekspansi tabel file descriptor ketika reference count > 1
- Metode Sinkronisasi Linux: RCU (Read-Copy-Update) dengan panggilan
synchronize_rcu() - Metode Sinkronisasi OpenBSD: Read-write locks tradisional
- Solusi Workaround: Pra-ekspansi tabel FD menggunakan
dup2(0, 666)sebelum pembuatan thread
Pendekatan OpenBSD yang Lebih Sederhana
OpenBSD mengambil pendekatan yang sama sekali berbeda. Alih-alih menggunakan sinkronisasi RCU , sistem ini mengandalkan read-write lock tradisional ketika memodifikasi tabel file descriptor. Metode ini menghindari penundaan sinkronisasi yang panjang yang mengganggu Linux dalam skenario spesifik ini, menghasilkan waktu pembuatan socket yang jauh lebih cepat.
Benchmark ini juga mendemonstrasikan solusi untuk masalah Linux . Dengan memperluas tabel file descriptor terlebih dahulu menggunakan dup2(0, 666) sebelum membuat thread tambahan, penalti performa hilang karena tabel tidak lagi perlu ekspansi selama pembuatan socket.
Wawasan Komunitas dan Implikasi yang Lebih Luas
Penemuan ini telah memicu diskusi menarik tentang trade-off desain sistem operasi. Meskipun benchmark ini menunjukkan keunggulan OpenBSD dalam skenario spesifik, anggota komunitas mencatat bahwa Linux umumnya mengungguli OpenBSD dalam sebagian besar workload lain dengan margin yang signifikan. Sistem RCU yang menyebabkan perlambatan khusus ini sebenarnya memberikan manfaat dalam banyak situasi lain.
Judul yang lebih baik: program tes patologis yang dimaksudkan untuk Linux tidak memicu perilaku patologis pada OpenBSD
Benchmark ini menyoroti bagaimana keputusan desain kernel yang berbeda dapat menciptakan karakteristik performa yang tidak terduga. Meskipun pendekatan RCU Linux menawarkan keuntungan dalam banyak skenario, sistem ini dapat menciptakan bottleneck dalam kasus edge spesifik seperti alokasi file descriptor yang cepat dalam program multi-threaded.
Temuan ini berfungsi sebagai pengingat bahwa performa sistem operasi sangat bergantung pada workload, dan bahwa benchmark sederhana dapat mengungkapkan perbedaan arsitektur yang menarik antara sistem yang mungkin tidak terlihat.
Referensi: Is OpenBSD 10x faster than Linux?