يوفر Linux kernel مجموعة واسعة من خيارات التكوين التي يمكن أن تؤثر على الأداء. الشيء الرئيسي هو اختيار التكوين الصحيح للتطبيق وعبء العمل. مثل أي قاعدة بيانات أخرى ، يحتاج PostgreSQL إلى الضبط الأمثل لنواة Linux. يمكن أن تؤدي الإعدادات غير الصحيحة إلى ضعف الأداء. من المهم إجراء تحليل مقارن لأداء قاعدة البيانات بعد كل جلسة توليف. في أحد مشاركاتي السابقة ، بعنوان "Tune Linux Kernel Parameters For PostgreSQL Optimization" ، وصفت بعضًا من معلمات kernel Linux الأكثر فائدة وكيفية مساعدتها في تحسين أداء قاعدة البيانات. سوف أشارك الآن نتائج الاختبار المقارن بعد تكوين HugePages على Linux تحت العديد من أحمال PostgreSQL. أجريت مجموعة اختبار كاملة تحت أعباء عمل PostgreSQL مختلفة مع عدد مختلف من العملاء المتزامنين.
جهاز الكمبيوتر الذي تم إجراء الاختبار
- خادم سوبرمايكرو:
- وحدة المعالجة المركزية Intel® Xeon® E5-2683 v3 @ 2.00 جيجاهرتز
- 2 مآخذ / 28 النوى / 56 المواضيع
- الذاكرة: 256 جيجابايت من ذاكرة الوصول العشوائي
- سعة التخزين: SAMSUNG SM863 1.9 TB Enterprise SSD
- نظام الملفات: ext4 / xfs
- OS: أوبونتو 16.04.4 ، نواة 4.13.0-36 عام
- PostgreSQL: الإصدار 11
إعدادات نواة لينكس
لقد استخدمت معلمات kernel الافتراضية دون أي تحسين / التغيير والتبديل ، معطل فقط HugePages شفاف. يتم تمكين هذه التقنية بشكل افتراضي وتحديد الصفحات ذات الحجم غير المستحسن لقواعد البيانات. بشكل عام ، تحتاج قواعد البيانات إلى HugePages ذات حجم ثابت ، لكن لا يمكن لـ HugePages الشفافة أن توفرها. لذلك ، يوصى دائمًا بتعطيل هذه الميزة وتثبيت HugePages الكلاسيكي افتراضيًا.
إعدادات بوستجرس
لقد استخدمت نفس إعدادات PostgreSQL لجميع الاختبارات لتسجيل أعباء عمل PostgreSQL مختلفة مع إعدادات Linux HugePages مختلفة. لجميع الاختبارات ، تم تطبيق إعدادات PostgreSQL التالية:
shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON'
مخطط الاختبار
يلعب مخطط الاختبار دورًا مهمًا. يتم إجراء جميع الاختبارات ثلاث مرات ، ومدة كل تشغيل 30 دقيقة. بناءً على نتائج هذه الاختبارات الثلاثة ، استنتجت متوسط القيمة. تم إجراء الاختبار باستخدام أداة PostgreSQL pgbench ، وهي تعمل مع عامل تحجيم بزيادات تبلغ حوالي 16 ميغابايت من التحميل.
ضخمة
افتراضيًا ، يستخدم Linux صفحات ذاكرة 4K ، فضلاً عن تقنية HugePages. يستخدم BSD تقنية الصفحات الفائقة ويستخدم Windows الصفحات الكبيرة. PostgreSQL يدعم فقط تقنية HugePages (Linux). في الحالات التي يكون فيها حجم الذاكرة المستخدمة كبيرًا ، تقلل الصفحات الأصغر من الأداء. باستخدام HugePages ، يمكنك زيادة الذاكرة المخصصة للتطبيق ، وبالتالي تقليل "الحمل" الذي يحدث أثناء عملية التخصيص / التبديل. وبالتالي ، HugePages زيادة الإنتاجية.
فيما يلي إعدادات HugePages بحجم 1 جيجابايت. هذه المعلومات متاحة في أي وقت باستخدام / proc.
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
كتبت المزيد عن HugePages في منشور سابق.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
بشكل عام ، يبلغ حجم HugePages 2 ميغابايت و 1 غيغابايت ، لذلك فمن المنطقي استخدام 1 غيغابايت.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/
نتائج الاختبار
يوضح هذا الاختبار التأثير الكلي لاستخدام HugePages من مختلف الأحجام. تم إنشاء مجموعة الاختبار الأولى بحجم صفحة 4K - يتم استخدامه افتراضيًا في نظام Linux - وبدون تنشيط HugePages. اسمحوا لي أن أذكركم: لقد قمت بتعطيل خيار شفاف HugePages طوال مدة الاختبارات.
ثم تم إجراء مجموعة ثانية من الاختبارات لـ HugePages بحجم 2 ميغابايت. أخيرًا ، تم تشغيل مجموعة ثالثة من الاختبارات لـ 1GB HugePages.
لجميع الاختبارات المقارنة ، تم استخدام PostgreSQL DBMS 11. وتشمل مجموعات مجموعات من مختلف أحجام قاعدة البيانات وعملاء مختلفين. يوضح الرسم البياني أدناه نتائج مقارنة الأداء باستخدام هذه الاختبارات: TPS (عدد المعاملات في الثانية) - على طول المحور Y ، وحجم قاعدة البيانات وعدد العملاء لقاعدة بيانات ذات حجم معين - على طول المحور X.
من الرسم البياني أعلاه ، يمكن ملاحظة أنه من خلال استخدام HugePages ، يزداد الربح مع زيادة عدد العملاء وحجم قاعدة البيانات ، طالما ظل هذا الحجم داخل المخزن المؤقت المشترك المخصص مسبقًا.
هذا الاختبار مقارنة TPS وعدد العملاء. في هذه الحالة ، حجم قاعدة البيانات 48 غيغابايت. يُظهر المحور Y TPS ، ويظهر المحور X عدد العملاء المتصلين. حجم قاعدة البيانات صغير بما يكفي لتناسب مخزن مؤقت مشترك بحجم ثابت 64 جيجابايت.
عندما يكون حجم HugePages 1 غيغابايت ، يزداد كسب الأداء المقارن مع زيادة عدد العملاء.
الرسم البياني التالي هو نفس الرسم البياني السابق ، ولكن حجم قاعدة البيانات 96 غيغابايت. هذا أكبر من حجم المخزن المؤقت الكلي الثابت 64 جيجابايت.
الشيء الرئيسي الذي يجب ملاحظته هنا: يزيد الأداء مع HugePages من 1 غيغابايت مع زيادة عدد العملاء ويوفر في نهاية المطاف أداء أفضل من استخدام HugePages من 2 ميغابايت أو صفحات قياسية 4 كيلوبايت.
يوضح هذا الاختبار نسبة TPS إلى حجم قاعدة البيانات. في هذه الحالة ، يبلغ عدد العملاء المتصلين 32. على المحور Y ، يتم عرض TPS ، وعلى المحور X ، أحجام قاعدة البيانات.
كما هو متوقع ، عندما يتجاوز حجم قاعدة البيانات حجم HugePages المخصص مسبقًا ، يتم تقليل الأداء بشكل كبير.
الخاتمة
واحدة من توصياتي الرئيسية هي تعطيل HugePages الشفافة. ستحصل على أكبر دفعة أداء إذا تم وضع قاعدة البيانات في مخزن مؤقت مشترك مع تمكين HugePages. يتم تحديد الحجم الأمثل لـ HugePages بواسطة التجربة والخطأ ، ولكن من المحتمل أن يؤدي هذا النهج إلى تحقيق مكسب كبير في TPS ، عندما يكون حجم قاعدة البيانات كبيرًا بدرجة كافية ، ولكن في نفس الوقت يسمح لها بتلائم مخزن مؤقت مشترك.