استنادًا إلى مقال بيتر زايتسيف حول معوقات أداء MySQL ، أريد أن أتحدث قليلاً عن PostgreSQL.
غالبًا ما تُستخدم أطر عمل ORM للعمل مع PostgreSQL هذه الأيام. عادة ما تعمل بشكل جيد ، ولكن بمرور الوقت يزداد الحمل ويصبح من الضروري ضبط خادم قاعدة البيانات. بقدر موثوقية PostgreSQL ، يمكن أن يتباطأ مع زيادة حركة المرور.
هناك طرق عديدة للتخلص من معوقات الأداء ، ولكن في هذه المقالة سنركز على ما يلي:
- معلمات الخادم
- إدارة الاتصال
- إعداد الفراغ التلقائي
- إعداد الفراغ التلقائي الإضافي
- طاولات النفخ (سخام)
- النقاط الساخنة في البيانات
- خوادم التطبيقات
- تكرار
- بيئة الخادم
حول "الفئات" و "التأثير المحتمل"
يشير "التعقيد" إلى مدى سهولة تنفيذ الحل المقترح. و "التأثير المحتمل" يعطي مؤشرا على درجة التحسن في أداء النظام. ومع ذلك ، نظرًا لعمر النظام ونوعه والديون الفنية وما إلى ذلك. يمكن أن يكون الوصف الدقيق للتعقيد والتأثير مشكلة. بعد كل شيء ، في المواقف الصعبة ، يكون الخيار النهائي لك دائمًا.
التصنيفات:
- تعقيد
- منخفض
- معدل
- عالي
- منخفض - متوسط - مرتفع
- التأثير المحتمل
- منخفض
- المتوسط
- عالي
- منخفض - متوسط - مرتفع
معلمات الخادم
مستوى الصعوبة: منخفض.
التأثير المحتمل: مرتفع.
منذ وقت ليس ببعيد ، كانت هناك أوقات يمكن فيها تشغيل الإصدارات الحالية من postgres على i386. منذ ذلك الحين ، تم تغيير الإعدادات الافتراضية ، لكنها ما زالت مهيأة لاستخدام أقل قدر من الموارد.
من السهل جدًا تغيير هذه الإعدادات وعادة ما يتم تكوينها أثناء التثبيت الأولي. يمكن أن تؤدي القيم غير الصحيحة لهذه المعلمات إلى ارتفاع استخدام وحدة المعالجة المركزية والإدخال / الإخراج:
- المعلمة الفعالة_حجم التخزين المؤقت ~ 50 إلى 75٪
- المعلمة shared_buffers ~ 1/4 - 1/3 مقدار ذاكرة الوصول العشوائي
- المعلمة work_mem ~ 10 ميجابايت
يمكن حساب القيمة الموصى بها لـ Effective_cache_size ، على الرغم من أنها نموذجية ، بشكل أكثر دقة إذا أشرنا إلى "top" - free + cached .
يعد حساب قيمة Shared_buffers لغزًا مثيرًا للاهتمام. يمكنك النظر إليه من جانبين: إذا كان لديك قاعدة بيانات صغيرة ، فيمكنك تعيين قيمة Shared_buffers كبيرة بما يكفي لتناسب قاعدة البيانات بأكملها في ذاكرة الوصول العشوائي. من ناحية أخرى ، يمكنك تكوين تحميل الجداول والفهارس المستخدمة بشكل متكرر فقط في الذاكرة (تذكر 80/20). في السابق ، كان يوصى بتعيين القيمة على 1/3 من مقدار ذاكرة الوصول العشوائي ، ولكن بمرور الوقت ، مع زيادة حجم الذاكرة ، تم تقليلها إلى 1/4. إذا تم تخصيص القليل من الذاكرة ، فسوف يزداد حمل الإدخال / الإخراج والمعالج. سيتم الإشارة إلى تخصيص الكثير من الذاكرة من خلال الوصول إلى هضبة المعالج وحمل الإدخال / الإخراج.
هناك عامل آخر يجب مراعاته وهو ذاكرة التخزين المؤقت لنظام التشغيل . نظرًا لذاكرة الوصول العشوائي (RAM) الكافية ، سيقوم Linux بتخزين الجداول والفهارس في الذاكرة مؤقتًا ، واعتمادًا على كيفية التهيئة ، قد يجعل PostgreSQL يعتقد أنه يقرأ البيانات من القرص بدلاً من ذاكرة الوصول العشوائي. توجد الصفحة نفسها في كل من المخزن المؤقت postgres وذاكرة التخزين المؤقت لنظام التشغيل ، وهذا أحد أسباب عدم جعل التخزين المؤقت المشترك كبيرًا جدًا. باستخدام ملحق pg_buffercacheيمكنك مشاهدة استخدام ذاكرة التخزين المؤقت في الوقت الفعلي. تحدد
المعلمة work_mem مقدار الذاكرة المستخدمة لعمليات الفرز. يضمن تعيين هذه القيمة منخفضة جدًا أداءً ضعيفًا ، حيث سيتم إجراء الفرز باستخدام الملفات المؤقتة على القرص. من ناحية أخرى ، على الرغم من أن تعيين قيمة كبيرة لا يؤثر على الأداء ، مع وجود عدد كبير من الاتصالات ، هناك خطر نفاد ذاكرة الوصول العشوائي. من خلال تحليل الذاكرة المستخدمة في جميع الطلبات والجلسات ، يمكنك حساب القيمة المطلوبة.
باستخدام EXPLAIN ANALYZE ، يمكنك معرفة كيفية إجراء عمليات الفرز ، وعن طريق تغيير قيمة الجلسة ، يمكنك تحديد وقت بدء التدفق إلى القرص.
يمكنك أيضًا استخدام المعايير الأنظمة.
إدارة الاتصال
مستوى الصعوبة: منخفض.
التأثير المحتمل:
عادة ما يرتبط الحمل المنخفض - المتوسط - العالي بزيادة جلسات العميل لكل وحدة زمنية. يمكن أن يؤدي الكثير منها إلى منع العمليات أو التسبب في حدوث تأخيرات أو حتى حدوث أخطاء.
الحل البسيط هو زيادة الحد الأقصى لعدد الاتصالات المتزامنة:
# postgresql.conf: default is set to 100<br />max_connections
لكن النهج الأكثر كفاءة هو تجميع الاتصالات . هناك العديد من الحلول ، ولكن الأكثر شعبية هو pgbouncer . يمكن لـ PgBouncer إدارة الاتصالات باستخدام أحد الأوضاع الثلاثة:
- (session pooling). . , . , . .
- (transaction pooling). . PgBouncer , , .
- (statement pooling). . . , .
تحتاج أيضًا إلى الانتباه إلى طبقة المقابس الآمنة (SSL). عند التمكين ، ستستخدم الاتصالات SSL بشكل افتراضي ، مما سيزيد من الحمل على المعالج مقارنة بالاتصالات غير المشفرة. بالنسبة للعملاء العاديين ، يمكنك تكوين المصادقة المستندة إلى المضيف بدون SSL (
pg_hba.conf) ، واستخدام SSL للمهام الإدارية أو لتدفق النسخ المتماثل.
إعداد الفراغ التلقائي
الصعوبة: متوسطة.
التأثير المحتمل: منخفض - متوسط.
يعد التحكم في التزامن متعدد الإصدارات أحد المبادئ الأساسية التي تجعل PostgreSQL حلاً شائعًا لقواعد البيانات. ومع ذلك ، فإن إحدى المشكلات المزعجة هي أنه بالنسبة لكل سجل تم تغييره أو حذفه ، يتم إنشاء نسخ غير مستخدمة ، والتي يجب التخلص منها في النهاية. يمكن أن تؤدي عملية التفريغ التلقائي التي تم تكوينها بشكل غير صحيح إلى تدهور الأداء. علاوة على ذلك ، كلما زاد تحميل الخادم ، زادت المشكلة التي تظهر.
تُستخدم المعلمات التالية للتحكم في عفريت الفراغ التلقائي:
- autovacuum_max_workers. ( ). , . . . .
- maintenance_work_mem. , . , . , .
- autovacuum_freeze_max_age TXID WRAPAROUND. , , . , , , . , txid, . / txid pg_stat_activity WRAPAROUND.
احذر من التحميل الزائد على ذاكرة الوصول العشوائي ووحدة المعالجة المركزية. كلما زادت القيمة المحددة في البداية ، زاد خطر استنفاد الموارد عندما يزداد الحمل على النظام. إذا تم الضبط على مستوى عالٍ جدًا ، يمكن أن ينخفض الأداء بشكل كبير عند تجاوز مستوى تحميل معين.
على غرار حساب work_mem ، يمكن حساب هذه القيمة حسابيًا أو يمكن إجراء معايير للحصول على القيم المثلى .
إعداد الفراغ التلقائي الإضافي
مستوى الصعوبة: مرتفع.
التأثير المحتمل: مرتفع.
يجب استخدام هذه الطريقة ، نظرًا لتعقيدها ، فقط عندما يكون أداء النظام بالفعل على وشك الحدود المادية للمضيف وقد أصبح هذا مشكلة بالفعل.
تم تكوين خيارات وقت تشغيل الفراغ التلقائي بتنسيق
postgresql.conf. لسوء الحظ ، لا يوجد حل واحد يناسب الجميع يعمل في أي نظام تحميل عالي.
خيارات التخزين للجداول . غالبًا في قاعدة البيانات ، يقع جزء كبير من الحمل على عدد قليل من الجداول. يعد تخصيص إعدادات الفراغ التلقائي للجدول طريقة رائعة لتجنب الاضطرار إلى بدء تشغيل VACUUM يدويًا ، مما قد يؤثر بشكل كبير على النظام.
يمكنك تخصيص الجداول باستخدام الأمر :
ALTER TABLE .. SET STORAGE_PARAMETERطاولات النفخ (سخام)
مستوى الصعوبة: منخفض.
التأثير المحتمل: متوسط - مرتفع.
بمرور الوقت ، يمكن أن يتدهور أداء النظام بسبب سياسات التنظيف غير الملائمة بسبب كثرة الجداول. لذا ، حتى إعداد البرنامج الخفي للفراغ التلقائي وبدء تشغيل VACUUM يدويًا لا يحل المشكلة. في هذه الحالات ، يأتي امتداد pg_repack للإنقاذ .
باستخدام امتداد pg_repack ، يمكنك إعادة بناء الجداول والفهارس وإعادة تنظيمها في الإنتاج
النقاط الساخنة في البيانات
مستوى الصعوبة: مرتفع.
التأثير المحتمل: منخفض - متوسط - مرتفع.
كما هو الحال مع MySQL ، تعتمد PostgreSQL على تدفقات البيانات الخاصة بك للتخلص من النقاط الفعالة وقد تغير بنية نظامك.
بادئ ذي بدء ، يجب الانتباه إلى ما يلي:
- المؤشرات . تأكد من وجود فهارس على الأعمدة التي يتم البحث عنها. يمكنك استخدام كتالوجات النظام وطرق العرض للمراقبة والتحقق من أن الاستعلامات تستخدم الفهارس. استخدم ملحقات pg_stat_statement و pgbadger لتحليل أداء الاستعلام.
- كومة فقط Tuples (HOT) . قد يكون هناك عدد كبير جدًا من الفهارس. يمكنك تقليل الانتفاخ المحتمل وتقليل حجم الجدول بإسقاط الفهارس غير المستخدمة.
- . , , . , , , . , . , , .
- . postgres. , .
- . , . . , !
مستوى الصعوبة: منخفض.
التأثير المحتمل: مرتفع.
تجنب تشغيل التطبيقات (PHP و Java و Python) و postgres على نفس المضيف. كن حذرًا مع التطبيقات بهذه اللغات ، حيث يمكن أن تستهلك كميات كبيرة من ذاكرة الوصول العشوائي ، وخاصة أداة تجميع البيانات المهملة ، مما يستلزم التنافس مع أنظمة قواعد البيانات على الموارد وانخفاض الأداء العام.
تكرار
مستوى الصعوبة: منخفض.
التأثير المحتمل: مرتفع.
النسخ المتزامن وغير المتزامن. تدعم الإصدارات الحديثة من postgres النسخ المتماثل المنطقي والمتدفق في كلا الوضعين المتزامن وغير المتزامن. بينما يكون وضع النسخ المتماثل الافتراضي غير متزامن ، فإنك تحتاج إلى مراعاة الآثار المترتبة على استخدام النسخ المتماثل المتزامن ، خاصة على الشبكات ذات زمن الانتقال الكبير.
بيئة الخادم
أخيرًا وليس آخرًا ، إنها زيادة بسيطة في سعة المضيف. دعنا نلقي نظرة على تأثير كل مورد من حيث أداء PostgreSQL:
- . , . . , , -.
- . , , . .
- . .
- -, ,
- .
- . , .
- .
- . .
- WAL-, , , . , (log shipping) , , .
: