Tuning Firebird dan Linux untuk database berukuran 691 GB dengan 1000+ pengguna

Firebird adalah DBMS terbuka yang sangat populer di Rusia, dan meskipun tidak ada kampanye pemasaran yang bising, Firebird digunakan dalam sejumlah besar sistem kritis, terutama dalam sistem otomatisasi medis dan negara.

Ukuran basis data dan jumlah pengguna aktif dalam sistem seperti itu biasanya cukup besar, jadi dalam artikel ini saya akan berbicara tentang pengalaman mengoptimalkan pengaturan Firebird dan Linux berdasarkan contoh spesifik dari basis data Firebird besar di BeZdorov (Ingosstrakh), AlfaZdrav , dan saya akan menyentuh pengalaman perusahaan pengoptimalan lainnya. Firebird + Linux.

Mari kita melihat lebih dekat pada subjek optimasi - Firebird 3.0.5 DBMS (dengan ekstensi HQbird), melayani basis data 691GB (saat ini) dengan 1000-1100 pengguna harian, berjalan pada Linux CentOS 7, server menggunakan besi HP DL380. Replikasi ke server cadangan dikonfigurasikan untuk basis data (pertanyaan replikasi berada di luar cakupan artikel ini).

DBMS melayani sistem informasi medis Infoklinika (diproduksi oleh perusahaan Rusia Smart Delta Systems ), yang merupakan salah satu sistem informasi medis paling populer di Rusia.

Mari kita lihat detailnya (screenshot diambil dari HQbird nanti) dari operasi database ini:

Data dimasukkan secara intensif ke dalam basis data - keuntungan harian sekitar 0,4 - 0,5 GB



1000-1100 koneksi adalah beban harian yang biasa:



Meskipun pertumbuhan intensif dan pekerjaan aktif, database tidak mengandung sejumlah besar versi catatan sampah - keduanya berkat aplikasi yang ditulis dengan pengetahuan yang baik tentang arsitektur multi-versi, dan karena pengumpulan sampah yang dikonfigurasi dengan benar:



Penanda Transaksi di Zona Hijau:



By the way, perhatikan bahwa data dalam database adalah string, gumpalan hadir, tetapi ada beberapa dari mereka - hanya 10 GB dari 690 GB dari ukuran total.

Sifat beban basis data adalah campuran, 75% operasi baca dan 25% tulis:

Besi

Server yang melayani sistem ini tidak buruk, tetapi jauh dari top-end:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards 

Subsistem disk terdiri dari dua bagian: disk 745Gb lokal dan koneksi 2 saluran serat ganda ke SAN, dengan partisi 1,8Tb.

Sistem operasi

Menggunakan CentOS 7, versi kernel:

 Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019 

Untuk pertanyaan logis, mengapa kernel paling modern dan CentOS 8 tidak digunakan, jawabannya juga logis - migrasi sistem kritis hanya terjadi setelah rilis beberapa rilis minor dan pengujian yang ketat - ini adalah salah satu kasus ketika bug yang dikenal lebih baik daripada dua yang tidak diketahui.

Namun, perlu dicatat bahwa hingga 2017 sistem bekerja pada CentOS 6.x, dan setelah migrasi, peningkatan yang signifikan dalam indikator kinerja dicatat.

Pengaturan Linux

Kustomisasi Linux yang Sangat Penting untuk Firebird

Ada 2 parameter yang harus ditingkatkan pada semua server Linux tempat Firebird berjalan - jumlah area memori virtual (VMA) dan jumlah file yang terbuka untuk proses Firebird.

1. VMA

Nomor VMA default adalah 64K, harus ditingkatkan 4 kali, untuk ini, tambahkan baris di sysctl.conf

 vm.max_map_count=262144 

Untuk memeriksa nilai saat ini, gunakan perintah

 sysctl vm.max_map_count 

2. Max Buka File

Firebird membuka hingga 20 deskriptor (pegangan file) untuk setiap koneksi ke basis data (mengingat fakta bahwa di Linux semua sumber daya terlihat seperti file), sehingga jumlah maksimum file yang terbuka secara default (biasanya 4.096) dapat sangat cepat habis.

Untuk memeriksa jumlah file yang tersedia untuk Firebird, yang terbaik adalah melihat batas-batas file executable Firebird:

 cat /proc/$(pgrep firebird)/limits 

di mana memeriksa nilai untuk Max Open Files dan meningkatkannya jika perlu.

Untuk meningkatkan parameter Max Open Files untuk Firebird, kami menambahkan baris ke file firebird-superserver.service di bagian [layanan]:

 LimitNOFILE=49999 

Pengaturan Linux opsional

Di server ini, kami juga membuat pengaturan berikut

1. Mengurangi swapiness

Karena server didedikasikan khusus untuk DBMS Firebird, dan kami ingin menggunakan RAM secara efisien di bawah cache DBMS dan cache file sistem operasi, kami mengurangi swapiness dari default 60% menjadi 10%, untuk ini kami menambahkan sysctl.conf

 vm.swappiness=10 

2. Meningkatkan ukuran memori minimum yang dicadangkan untuk proses OS khusus

 vm.min_free_kbytes=1048576 

yaitu 1GB memori. Pengaturan ini secara tidak langsung memengaruhi defragmentasi memori.

Harap dicatat bahwa pengaturan ini bersifat individual - mengingat bahwa kami memiliki 320GB RAM, 1GB tidak terlalu banyak, tetapi dalam kasus jumlah memori yang kecil (misalnya, 32GB), 1GB mungkin terlalu banyak.

3. Mengurangi keepalive

Firebird bergantung pada interval keepalive untuk memeriksa status koneksi, dan nilai default keepalive bisa sangat besar. Membatasinya hingga 300 detik, kami menyingkirkan koneksi yang menggantung

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15 

Lebih Banyak Tuning Linux

Mengapa kita terbatas pada sejumlah kecil pengaturan Linux?

Pertama, kami mengambil pendekatan konservatif untuk mengatur server dengan Linux (yang semakin baik dengan setiap versi baru), dan kedua, basis data Firebird ini tidak terlalu besar atau paling banyak dimuat, dan Linux berupaya dengan pengaturan yang ditentukan dengan tugas Anda.

Tentu saja, ada beberapa pengaturan yang dapat digunakan untuk mengoptimalkan pekerjaan Firebird di Linux - misalnya, sejumlah hal menarik disajikan dalam presentasi tentang basis data Firebird 3 TB (RedBaza) di Layanan Federal Bailiff.

Konfigurasikan Firebird

File konfigurasi komunitas Firebird dengan firebirdsql.org dikonfigurasi dengan sangat konservatif, dan pada server yang kurang lebih kuat Anda perlu mengubah file konfigurasi dan dengan hati-hati memilih arsitektur yang digunakan (dalam Firebird 3.0 ada 2 jenis koneksi: Embedded dan NetworkServer, dan 3 jenis arsitektur: SuperServer , SuperClassic, Klasik).
Selain itu, Anda harus menggunakan pengaturan untuk setiap basis data - mis. letakkan pengaturan kritis di databases.conf, dengan referensi ke database tertentu.

Dalam kasus kami, kami memilih arsitektur SuperServer, yang paling populer di versi 3.0, karena secara efisien menggunakan prosesor multi-core dan memiliki cache yang dibagikan untuk semua koneksi (tetapi terpisah untuk setiap database).

Berikut ini adalah file konfigurasi (hanya nilai terkait kinerja):

firebird.conf - file konfigurasi untuk semua database di server

 DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries 

Dalam hal kinerja, parameter utama di sini adalah:

1. DefaultDbCachePages = 50K # diukur dalam halaman, pada DB, pada halaman 16K = 0.8Gb

Ukuran cache halaman DefaultDbCachePages di firebird.conf secara khusus diatur secara default ke 800Mb sehingga database pengujian yang tidak sengaja berantakan di server tidak mencoba untuk mengambil sejumlah besar RAM.

2. FileSystemCacheThreshold = 300K # halaman

Penting untuk mengatur parameter ini ke nilai yang lebih besar dari DefaultDBCachePages untuk memungkinkan penggunaan cache file OS.

3. TempCacheLimit = 20480M # byte

Parameter ini menetapkan ukuran memori untuk kueri dengan sort (dan beberapa operasi lainnya), dan bersifat individual untuk setiap sistem.
Sebagai hasil dari pemantauan ukuran, kami menemukan bahwa 20GB optimal untuk database ini.

4. LockMemSize dan LockHashSlots - parameter dari tabel kunci

Parameter ini menentukan ukuran awal tabel kunci dan jumlah slot untuk menghitung fungsi hash.

5. WireCompression = Benar

Mengkonfigurasi kompres lalu lintas antara klien dan server, ini sangat berguna dengan Execute Statement On External, yang menjalankan aplikasi klien.

Parameter yang tersisa dijelaskan dalam firebird.conf itu sendiri dan dokumentasi terkait Firebird dan HQbird.

Kami membuat pengaturan paling penting di databases.conf , dengan basis data yang tepat

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M } 

Seperti yang bisa Anda tebak, kesulitan utama dalam hal ini adalah bagaimana cara menghitung dengan benar ukuran memori yang dialokasikan oleh basis data besar kami.

Untuk Firebird 3.0 dengan arsitektur SuperServer, ada dua pendekatan - konservatif, yang digunakan pada server dengan jumlah RAM yang kecil (hingga 32GB inklusif), yang terdiri dari mengalokasikan tidak lebih dari 25% RAM untuk cache halaman, dan sisanya bergantung pada sistem operasi file sistem, dan fine-tuning, ketika kita secara tepat menentukan ukuran optimal untuk menyortir, mengalokasikan ukuran memori tertentu untuk kernel OS, cadangan sejumlah memori untuk operasi file besar-besaran (misalnya, cadangan), sisanya dialokasikan untuk cache halaman.

Dalam kasus kedua, tidak mungkin untuk segera mendapatkan ukuran cache yang optimal, karena sifat beban dapat sangat berbeda untuk berbagai jenis database, tetapi setelah beberapa iterasi Anda dapat mencapai hasil yang sangat baik.

Kesalahan umum dalam mengonfigurasi Firebird

Kesalahan umum meliputi:

1) Ukuran cache halaman secara eksplisit ditentukan pada halaman header DB, yang menimpa nilai yang ditentukan dalam firebird.conf dan databases.conf.

Terutama sering kesalahan ini terjadi ketika mengubah arsitektur dari Classic / SuperClassic ke SuperServer - jika ukuran cache untuk koneksi Classic / SuperClassic berfungsi dengan baik dengan ukuran kecil (500-2000 halaman) yang ditunjukkan dengan jelas, maka diperlukan cache yang lebih besar untuk SuperServer.
Untuk memeriksa, jalankan perintah

 gstat -h databasepathname 

dan periksa nilai Page Buffers - itu harus 0, maka Firebird akan menggunakan nilai-nilai dari databases.conf atau firebird.conf.

Untuk mengatur ulang pengaturan cache halaman pada halaman header, jalankan perintah

 gfix -buff 0 databasepathname 

2) Ketika meningkatkan cache halaman, mereka lupa untuk meningkatkan FileSystemCacheThreshold, yang mengarah pada pemutusan cache file, yang mengurangi kinerja.

3) Menggunakan ukuran halaman database default (4096 atau 8192), sedangkan untuk database besar Anda perlu menggunakan 16K.

Kesimpulan

Secara umum, 1000+ pengguna Firebird menggunakan besi, sesuai dengan beban yang dikonfigurasikan oleh Linux dan dikonfigurasikan oleh Firebird, bekerja tanpa masalah. Ada margin pada server ini dalam hal kinerja, yang diuji pada beban puncak hingga 1500-1800 pengguna.

Di antara distribusi Linux untuk basis data Firebird dengan beban yang serupa, yang paling populer adalah CentOS 7, versi yang direkomendasikan adalah Firebird 3.0.

Jika Anda memiliki pertanyaan, dengan senang hati saya akan menjawab di komentar, atau melalui email ak@ibase.ru.