ضبط Firebird و Linux لقاعدة بيانات بحجم 691 جيجابايت مع 1000+ مستخدم

Firebird هو نظام DBMS مفتوح شائع جدًا في روسيا ، وعلى الرغم من عدم وجود حملات تسويقية صاخبة ، فإنه يستخدم في عدد كبير من الأنظمة المهمة ، خاصة في أنظمة التشغيل الآلي الطبية والحكومية.

حجم قاعدة البيانات وعدد المستخدمين النشطين في مثل هذه الأنظمة عادة ما يكون كبيرًا جدًا ، لذلك في هذه المقالة سأتحدث عن تجربة تحسين إعدادات Firebird و Linux استنادًا إلى أمثلة محددة لقواعد بيانات Firebird الكبيرة في BeZdorov (Ingosstrakh) و AlfaZdrav ، وسأتطرق إلى تجربة شركات التحسين الأخرى Firebird + Linux.

دعونا نلقي نظرة فاحصة على موضوع التحسين - Firebird 3.0.5 DBMS (مع ملحقات HQbird) ، يقدم قاعدة بيانات 691GB (حاليًا) مع 1000-1100 مستخدمًا يوميًا ، يعمل على Linux CentOS 7 ، يستخدم الخادم مكواة HP DL380. تم تكوين النسخ المتماثل إلى خادم النسخ الاحتياطي لقاعدة البيانات (مسألة النسخ المتماثل خارج نطاق هذه المقالة).

يخدم نظام DBMS نظام المعلومات الطبية Infoklinika (الذي أنتجته شركة Smart Delta Systems الروسية) ، وهو أحد أنظمة المعلومات الطبية الأكثر شعبية في روسيا.

دعنا نلقي نظرة على التفاصيل (يتم أخذ لقطات الشاشة من HQbird لاحقًا) لتشغيل قاعدة البيانات هذه:

يتم إدراج البيانات بشكل مكثف في قاعدة البيانات - مكسب يومي من حوالي 0.4 - 0.5 غيغابايت



الاتصالات 1000-1100 هي الحمل اليومي المعتاد:



على الرغم من النمو المكثف والعمل النشط ، لا تحتوي قاعدة البيانات على أي قدر كبير من إصدارات البيانات المهملة من السجلات - سواء بفضل التطبيقات المكتوبة بمعرفة جيدة بالهيكل متعدد الإصدارات وبسبب تجميع البيانات المهملة بشكل صحيح:



علامات المعاملات في المنطقة الخضراء:



بالمناسبة ، لاحظ أن البيانات الموجودة في قاعدة البيانات هي سلسلة ، النقطات موجودة ، ولكن هناك القليل منها - 10 غيغابايت فقط من 690 غيغابايت من الحجم الكلي.

طبيعة تحميل قاعدة البيانات مختلطة ، 75٪ من عمليات القراءة و 25٪ من الكتابة:



حديد


الخادم الذي يخدم هذا النظام ليس سيئًا ، لكنه بعيد عن النهاية:

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

يتكون النظام الفرعي للقرص من جزأين: قرص 745 جيجا بايت محلي واتصال ثنائي القناة الليفية بـ SAN ، مع قسم سعة 1.8 تيرابايت.

نظام التشغيل


باستخدام CentOS 7 ، إصدار 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 

بالنسبة للسؤال المنطقي ، لماذا لا يتم استخدام النواة الأكثر حداثة و CentOS 8 ، فإن الجواب منطقي أيضًا - لا يحدث هجرة الأنظمة الحرجة إلا بعد إصدار العديد من الإصدارات الثانوية والاختبارات الصارمة - هذه واحدة من تلك الحالات عندما يكون الخطأ المعروف أفضل من مجهولين.

ومع ذلك ، تجدر الإشارة إلى أنه حتى عام 2017 ، كان النظام يعمل على نظام CentOS 6.x ، وبعد الترحيل ، لوحظ تحسن كبير في مؤشرات الأداء.

إعداد Linux


التخصيص لينكس أساسي للغاية لفايربيرد


هناك معلمتان يجب زيادتهما على جميع خوادم Linux حيث يعمل Firebird - عدد مناطق الذاكرة الظاهرية (VMA) وعدد الملفات المفتوحة لعملية Firebird.

1. VMA

رقم VMA الافتراضي هو 64 كيلو بايت ، ويجب زيادته 4 مرات ، لهذا ، أضف السطر في sysctl.conf

 vm.max_map_count=262144 

للتحقق من القيمة الحالية ، استخدم الأمر

 sysctl vm.max_map_count 

2. ماكس فتح الملفات

يفتح Firebird ما يصل إلى 20 واصفًا (مقابض الملفات) لكل اتصال بقاعدة البيانات (مع الأخذ في الاعتبار أن كافة الموارد في Linux تبدو كملفات) ، وبالتالي يمكن استنفاد الحد الأقصى لعدد الملفات المفتوحة افتراضيًا (عادة 4096) بسرعة كبيرة.

للتحقق من عدد الملفات المتوفرة في Firebird ، من الأفضل إلقاء نظرة على حدود الملف القابل للتنفيذ في Firebird:

 cat /proc/$(pgrep firebird)/limits 

أين يمكن التحقق من قيمة ملفات Max المفتوحة وزيادة هذه الملفات إذا لزم الأمر.

لزيادة المعلمة Max Open Files for Firebird ، أضفنا السطر إلى ملف firebird-superserver.service في قسم [service]:

 LimitNOFILE=49999 

إعداد Linux اختياري


على هذا الخادم ، قمنا أيضًا بالإعدادات التالية

1. انخفاض التبادل

نظرًا لأن الخادم مخصص حصريًا لـ Firebird DBMSs ، ونتمنى استخدام ذاكرة الوصول العشوائي بكفاءة في ذاكرة التخزين المؤقت DBMS وذاكرة التخزين المؤقت لنظام التشغيل ، فنحن نخفف من نسبة التبادل من 60٪ إلى 10٪ الافتراضية ، ولهذا أضفنا sysctl.conf

 vm.swappiness=10 

2. زيادة الحد الأدنى لحجم الذاكرة المحجوزة لعمليات OS الخاصة

 vm.min_free_kbytes=1048576 

أي 1GB من الذاكرة. يؤثر هذا الإعداد بشكل غير مباشر على إلغاء تجزئة الذاكرة.

يرجى ملاحظة أن هذا الإعداد فردي - نظرًا لأن لدينا ذاكرة وصول عشوائي (RAM) تبلغ 320 جيجابايت ، وليس 1 جيجابايت كثيرًا ، ولكن في حالة وجود مقدار صغير من الذاكرة (على سبيل المثال ، 32 جيجابايت) ، يمكن أن يكون 1 جيجابايت أكبر من اللازم.

3. انخفاض keepalive

يعتمد Firebird على فترات keepalive للتحقق من حالة الاتصال ، ويمكن أن تكون القيمة الافتراضية لـ keepalive كبيرة جدًا. يقتصر ذلك على 300 ثانية ، نتخلص من تعليق الاتصالات

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

المزيد من ضبط لينكس


لماذا نحن مقيدون بهذا العدد الصغير من إعدادات Linux؟

أولاً ، نتبع نهجًا متحفظًا لضبط الخوادم باستخدام Linux (والذي يتحسن وأفضل مع كل إصدار جديد) ، وثانياً ، قاعدة بيانات Firebird هذه ليست كبيرة للغاية ولا الأكثر تحميلًا ، ويتوافق Linux مع الإعدادات المحددة مع المهام الخاصة بك.

بالطبع ، هناك بعض الإعدادات الإضافية التي يمكن استخدامها لتحسين عمل Firebird على نظام Linux - على سبيل المثال ، تم تقديم عدد من الأشياء المهمة في العرض التقديمي حول قاعدة بيانات 3 TB Firebird (RedBaza) في Federal Bailiff Service.

تكوين فايربيرد


يتم تكوين ملفات التكوين لمجتمع Firebird مع firebirdsql.org بشكل متحفظ للغاية ، وعلى خادم أكثر أو أقل قوة تحتاج إلى تغيير ملفات التكوين واختيار بعناية الهندسة المستخدمة (في Firebird 3.0 هناك نوعان من الاتصالات: Embedded و NetworkServer ، و 3 أنواع من البنيات: SuperServer ، كلاسيك كلاسيك).
أيضًا ، يجب عليك استخدام الإعدادات لكل قاعدة بيانات - أي وضع الإعدادات الحرجة في database.conf ، مع الإشارة إلى قاعدة بيانات محددة.

في حالتنا ، اخترنا بنية SuperServer ، والأكثر شعبية في الإصدار 3.0 ، لأنه يستخدم معالجات متعددة النواة بكفاءة ولديه ذاكرة تخزين مؤقت مشتركة لكافة الاتصالات (ولكن منفصلة لكل قاعدة بيانات).

فيما يلي ملفات التكوين (القيم المتعلقة بالأداء فقط):

firebird.conf - ملف التكوين لجميع قواعد البيانات على الخادم

 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 

من حيث الأداء ، المعلمات الرئيسية هنا هي:

1. DefaultDbCachePages = 50K # يتم قياسه في الصفحات ، على قاعدة بيانات ، في الصفحة 16 كيلو = 0.8 جيجا بايت

يتم تعيين حجم ذاكرة التخزين المؤقت لصفحة DefaultDbCachePages في firebird.conf بشكل افتراضي بشكل افتراضي إلى 800 ميغابايت بحيث لا تحاول قاعدة بيانات الاختبار التي تشوش بطريق الخطأ على الخادم تناول كمية كبيرة من ذاكرة الوصول العشوائي.

2. FileSystemCacheThreshold = 300K # صفحات

من المهم تعيين هذه المعلمة على قيمة أكبر من DefaultDBCachePages لتمكين استخدام ذاكرة التخزين المؤقت لملف نظام التشغيل.

3. TempCacheLimit = 20480M # بايت

تقوم هذه المعلمة بتعيين حجم الذاكرة للاستعلامات ذات الأنواع (وبعض العمليات الأخرى) ، وهي فردية لكل نظام.
نتيجة لمراقبة حجم الأنواع ، وجدنا أن 20 جيجابايت هي الأمثل لقاعدة البيانات هذه.

4. LockMemSize و LockHashSlots - معلمات الجدول قفل

تحدد هذه المعلمات الحجم الأولي لجدول القفل وعدد فتحات حساب دالة التجزئة.

5. WireCompression = صحيح

تكوين ضغطات حركة المرور بين العملاء والخوادم ، وهذا مفيد بشكل خاص مع Execute Statement On External المكثف ، الذي يقوم بتشغيل تطبيق العميل.

يتم وصف المعلمات المتبقية في firebird.conf نفسه والوثائق ذات الصلة من Firebird و HQbird.

لقد صنعنا أهم الإعدادات في قواعد البيانات . مع وجود قاعدة بيانات دقيقة

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

كما يمكنك أن تخمن ، فإن الصعوبة الرئيسية في هذه الحالة هي كيفية حساب حجم الذاكرة المخصصة بواسطة قاعدة البيانات الكبيرة لدينا بشكل صحيح.

بالنسبة إلى Firebird 3.0 مع بنية SuperServer ، هناك طريقتان - متحفظتان ، يتم استخدامهما على الخوادم التي تحتوي على كمية صغيرة من ذاكرة الوصول العشوائي (حتى 32 جيجا بايت شاملة) ، والذي يتألف من تخصيص أكثر من 25٪ من ذاكرة الوصول العشوائي لذاكرة التخزين المؤقت للصفحة ، والباقي يعتمد على نظام تشغيل الملفات الأنظمة ، والضبط الدقيق ، عندما نحدد بدقة الحجم الأمثل للأنواع ، نخصص حجمًا معينًا من الذاكرة لنظام التشغيل OS kernel ، نحتفظ بقدر معين من الذاكرة لعمليات الملفات الضخمة (على سبيل المثال ، النسخ الاحتياطي) ، ما تبقى المخصصة لذاكرة التخزين المؤقت الصفحة.

في الحالة الثانية ، لا يمكن الحصول على حجم التخزين المؤقت الأمثل على الفور ، حيث يمكن أن تختلف طبيعة التحميل اختلافًا كبيرًا في أنواع مختلفة من قواعد البيانات ، ولكن بعد عدة تكرارات يمكنك تحقيق نتيجة ممتازة.

الأخطاء الشائعة في تكوين Firebird


الأخطاء النموذجية تشمل ما يلي:

1) حجم ذاكرة التخزين المؤقت للصفحة المحددة بشكل صريح في صفحة رأس قاعدة البيانات ، والتي تتجاوز القيم المحددة في firebird.conf و database.conf.

غالبًا ما يحدث هذا الخطأ عند تغيير البنية من Classic / SuperClassic إلى SuperServer - إذا كان حجم ذاكرة التخزين المؤقت لاتصال Classic / SuperClassic يعمل بشكل جيد مع حجم صغير (500-2000 صفحة) مبين بوضوح ، ثم هناك حاجة إلى ذاكرة تخزين مؤقت أكبر بكثير لـ SuperServer.
للتحقق ، قم بتشغيل الأمر

 gstat -h databasepathname 

وتحقق من قيمة " Page Buffers - يجب أن تكون 0 ، ثم سيستخدم Firebird القيم من قواعد البيانات .conf أو firebird.conf.

لإعادة تعيين إعداد ذاكرة التخزين المؤقت للصفحة في صفحة الرأس ، قم بتشغيل الأمر

 gfix -buff 0 databasepathname 

2) عند زيادة ذاكرة التخزين المؤقت للصفحة ، ينسون زيادة FileSystemCacheThreshold ، مما يؤدي إلى قطع اتصال ذاكرة التخزين المؤقت للملف ، مما يقلل من الأداء.

3) استخدام حجم صفحة قاعدة البيانات الافتراضية (4096 أو 8192) ، بينما تحتاج إلى استخدام 16 كيلو بايت لقواعد البيانات الكبيرة.

استنتاج


بشكل عام ، يعمل أكثر من 1000 مستخدم Firebird على الحديد ، وهو ما يتوافق مع الحمل الذي تم تكوينه بواسطة Linux والذي تم تكوينه بواسطة Firebird ، دون مشاكل. هناك هامش على هذا الخادم من حيث الأداء ، والذي تم اختباره في ذروة الأحمال لما يصل إلى 1500-1800 مستخدم.

من بين توزيعات Linux لقاعدة بيانات Firebird ذات التحميل المماثل ، الأكثر شيوعًا هو CentOS 7 ، والإصدار الموصى به هو Firebird 3.0.

إذا كانت لديك أسئلة ، سأكون سعيدًا بالإجابة في التعليقات ، أو عبر البريد الإلكتروني ak@ibase.ru.

Source: https://habr.com/ru/post/ar476636/


All Articles