مقارنة PostgreSQL مع صفحات لينكس الكبيرة

يوفر Linux kernel مجموعة واسعة من خيارات التكوين التي يمكن أن تؤثر على الأداء. الأمر كله يتعلق بالحصول على التكوين الصحيح للتطبيق وعبء العمل. مثل أي قاعدة بيانات أخرى ، يستخدم PostgreSQL نواة Linux من أجل التكوين الأمثل. يمكن أن تؤدي الإعدادات المضبوطة بشكل سيء إلى ضعف الأداء. لذلك ، من المهم قياس أداء قاعدة البيانات بعد كل جلسة توليف لتجنب تدهور الأداء. في أحد مطبوعاتي السابقة ، "ضبط معلمات Kernel Linux الخاصة بتحسين PostgreSQL" ، وصفت بعضًا من معلمات kernel Linux الأكثر فائدة وكيف يمكن أن تساعدك في تحسين أداء قاعدة البيانات. سأقوم الآن بمشاركة نتائج الاختبار الخاصة بي بعد إعداد صفحات Linux كبيرة بحجم عمل PostgreSQL مختلف. لقد أجريت مجموعة شاملة من الاختبارات لمختلف أحجام تحميل PostgreSQL والعدد المتزامن من العملاء.

آلة الاختبار

• خادم سوبرمايكرو:
  
  • Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
  • 2 مآخذ / 28 النوى / 56 المواضيع
  • الذاكرة: 256 جيجابايت من ذاكرة الوصول العشوائي
  • سعة التخزين: SAMSUNG SM863 1.9TB Enterprise SSD
  • نظام الملفات: ext4 / xfs
• OS: أوبونتو 16.04.4 ، نواة 4.13.0-36 عام
• PostgreSQL: الإصدار 11

إعدادات نواة لينكس

لقد استخدمت إعدادات kernel الافتراضية دون أي تحسين / توليف بخلاف تعطيل الصفحات الكبيرة الشفافة (Transparent HugePages). يتم تمكين الصفحات الكبيرة الشفافة افتراضيًا وتمييز حجم الصفحة ، والذي قد لا ينصح باستخدامه من قبل قاعدة البيانات. تتطلب قواعد البيانات عادةً صفحات كبيرة الحجم ثابتة لا تغطيها صفحات كبيرة شفافة. لذلك ، يوصى دائمًا بتعطيل هذه الميزة واستخدام الصفحات الكبيرة الكلاسيكية افتراضيًا.

إعدادات بوستجرس

لقد استخدمت إعدادات PostgreSQL الموحدة لجميع الاختبارات لتسجيل أعباء عمل PostgreSQL مختلفة مع إعدادات مختلفة لصفحات Linux الكبيرة. فيما يلي إعداد PostgreSQL المستخدم في جميع الاختبارات:

^{postgresql.conf}

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 . يعمل pgbench مع عامل مقياس ، مع عامل مقياس واحد حوالي 16 ميغابايت من عبء العمل.

الصفحات الكبيرة (HugePages)

يستخدم Linux ، افتراضيًا ، صفحات ذاكرة بحجم 4K مع صفحات كبيرة. يحتوي BSD على الصفحات الفائقة ، بينما يحتوي Windows على الصفحات الكبيرة. PostgreSQL يدعم الصفحات الكبيرة فقط (Linux). في حالات الاستخدام العالي للذاكرة ، تقلل الصفحات الصغيرة من الأداء. عن طريق تثبيت صفحات كبيرة ، يمكنك زيادة الذاكرة المخصصة للتطبيق ، وبالتالي تقليل تكاليف التشغيل التي تنشأ أثناء التخصيص / المبادلة ؛ وهذا هو ، يمكنك زيادة الإنتاجية باستخدام صفحات كبيرة.

فيما يلي الإعداد للصفحات الكبيرة عند استخدام حجم صفحة كبير يبلغ 1 غيغابايت. يمكنك دائمًا الحصول على هذه المعلومات من / proc.

^{$ cat / proc / meminfo | grep - أنا ضخمة}

 AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB 

لمزيد من المعلومات على الصفحات الكبيرة ، يرجى قراءة منشور المدونة السابق.

https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

عادةً ما تكون الصفحات الكبيرة 2 ميجا بايت و 1 جيجا بايت ، لذلك من المنطقي استخدام 1 جيجا بايت بدلاً من 2 ميغا بايت الأصغر بكثير.

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/

نتائج الاختبار

يوضح هذا الاختبار التأثير الكلي للأحجام المختلفة للصفحات الكبيرة. تم إنشاء مجموعة الاختبار الأولى بحجم الصفحة الافتراضي على Linux 4K دون تضمين صفحات كبيرة. لاحظ أن الصفحات الضخمة الشفافة تم تعطيلها أيضًا وبقيت معطلة خلال كل هذه الاختبارات.

ثم تم إجراء المجموعة الثانية من الاختبارات على صفحات كبيرة بحجم 2 ميجابايت. أخيرًا ، يتم تشغيل المجموعة الثالثة من الاختبارات بصفحات كبيرة تبلغ 1 غيغابايت.

تم إجراء جميع هذه الاختبارات في الإصدار 11 من PostgreSQL. تتضمن المجموعات مزيجًا من أحجام مختلفة من قاعدة البيانات والعملاء. يوضح الرسم البياني أدناه نتائج الأداء المقارنة لهذه الاختبارات مع TPS (المعاملات في الثانية) على المحور ص ، وحجم قاعدة البيانات وعدد العملاء لكل حجم قاعدة البيانات على المحور X.



يمكن أن نرى من الرسم البياني أعلاه أن زيادة الأداء في الصفحات الكبيرة تزداد مع زيادة عدد العملاء وحجم قاعدة البيانات ، إذا ظل الحجم في المخزن المؤقت المخصص مسبقًا في الذاكرة المشتركة.

يوضح هذا الاختبار TPS مقارنة بعدد العملاء. في هذه الحالة ، حجم قاعدة البيانات 48 غيغابايت. على المحور Y ، لدينا TPS ، وعلى المحور X ، لدينا عدد العملاء المتصلين. حجم قاعدة البيانات صغير بما يكفي لاحتواء في مخزن مؤقت مشترك تم تعيينه على 64 جيجابايت.



إذا تم تعيين الصفحات الكبيرة على 1 غيغابايت ، فكلما زاد عدد العملاء ، زاد كسب الأداء النسبي.

الرسم البياني التالي هو نفسه الرسم البياني أعلاه ، باستثناء حجم قاعدة البيانات 96 جيجابايت. هذا يتجاوز حجم المخزن المؤقت المشترك ، الذي تم تعيينه إلى 64 جيجابايت.



الملاحظة الرئيسية هنا هي أن الأداء مع الصفحات الكبيرة من 1 غيغابايت يزيد مع زيادة عدد العملاء ، وفي نهاية المطاف يعطي أداء أكثر من الصفحات الكبيرة من 2 ميغابايت أو حجم الصفحة القياسي من 4 كيلو بايت.

يعرض هذا الاختبار TPS اعتمادًا على حجم قاعدة البيانات. في هذه الحالة ، يبلغ عدد العملاء المتصلين 32. على المحور ص ، لدينا TPS ، وعلى المحور X - أحجام قاعدة البيانات.



كما هو متوقع ، عندما تتجاوز قاعدة البيانات الصفحات الكبيرة المخصصة مسبقًا ، يتم تقليل الأداء بشكل كبير.

ملخص

واحدة من توصياتي الرئيسية هي أنه يجب علينا تعطيل HugePages الشفافة. سترى أكبر مكاسب في الأداء عند وضع قاعدة البيانات في مخزن مؤقت مشترك مع تمكين الصفحات الكبيرة. يتطلب اختيار حجم الصفحات الكبيرة قدرًا ضئيلًا من التجربة والخطأ ، ولكن هذا قد يؤدي إلى زيادة كبيرة في TPS عندما يكون حجم قاعدة البيانات كبيرًا ، لكنه يظل صغيرًا بما يكفي ليناسب مساحة مؤقتة مشتركة.