نسخ تقرير 2015 بواسطة Ilya Kosmodemyansky "ضبط Linux لتحسين أداء PostgreSQL"
إخلاء المسؤولية: ألاحظ أن هذا التقرير مؤرخ في نوفمبر 2015 - لقد مرت أكثر من 4 سنوات ومر الكثير من الوقت. الإصدار 9.4 الذي تمت مناقشته في التقرير لم يعد مدعومًا. على مدار السنوات الأربع الماضية ، كان هناك 4 إصدارات جديدة من PostgreSQL و 5 إصدارًا من Linux kernel. إذا أعدت كتابة هذه الأماكن ، فسوف ينتهي بك الأمر بتقرير مختلف. ولكن هنا ضبط Linux أساسي لـ PostgreSQL ، والذي لا يزال مناسبًا حتى اليوم.
اسمي إيليا كوسموديميانسكي. أعمل في شركة PostgreSQL-Consulting. والآن سأتحدث قليلاً عما يجب فعله مع Linux فيما يتعلق بقواعد البيانات بشكل عام و PostgreSQL بشكل خاص ، لأن المبادئ متشابهة تمامًا.
ما الذي سيتم مناقشته؟ إذا كنت تتعامل مع PostgreSQL ، فأنت بحاجة إلى أن تكون مشرفًا في UNIX إلى حد ما. ماذا يعني ذلك؟ إذا قارنا Oracle و PostgreSQL ، فأنت بحاجة إلى أن تكون 80٪ مسؤول قاعدة بيانات DBA و 20٪ مسؤول Linux.
تعد PostgreSQL أكثر صعوبة بقليل. مع PostgreSQL ، يجب أن تكون لديك فكرة أفضل عن كيفية عمل Linux. وفي الوقت نفسه ، اركض قليلاً خلف القاطرة ، لأنه تم تحديث كل شيء بشكل رائع مؤخرًا. وتظهر النوى الجديدة ، وتظهر وظائف جديدة ، ويحسن الأداء ، وما إلى ذلك.
لماذا نتحدث عن لينكس؟ ليس على الإطلاق لأننا حاضرون في مؤتمر لينكس بيتر ، ولكن لأنه في الظروف الحديثة ، فإن أحد أكثر أنظمة التشغيل المبررة للعمل مع قواعد البيانات بشكل عام ومع PostgreSQL بشكل خاص هو Linux. لأن FreeBSD ، للأسف ، يتطور في اتجاه غريب للغاية. وستكون هناك مشاكل في الأداء والعديد من الأشياء الأخرى. يعد أداء PostgreSQL على Windows موضوعًا قاسيًا منفصلاً بشكل عام ، ويستند إلى حقيقة أن Windows ليس لديه ذاكرة مشتركة مثل UNIX ، وأن PostgreSQL هو كل شيء عن هذا العمل ، لأنه نظام متعدد العمليات.
وأعتقد أن الأنواع الغريبة مثل سولاريس هي أقل اهتمامًا للجميع ، فلنذهب.
يحتوي توزيع Linux الحديث على أكثر من 1 خيار syctl ، اعتمادًا على كيفية بناء النواة. في الوقت نفسه ، إذا نظرنا إلى أنواع مختلفة من المكسرات ، فلا يزال هناك العديد من الطرق لتعديل شيء ما. هناك خيارات نظام الملفات حول كيفية التحميل. إذا كانت لديك أسئلة حول كيفية البدء: ما الذي يجب تمكينه في BIOS ، وكيفية تكوين الجهاز ، وما إلى ذلك.
هذا حجم كبير جدًا ، يمكن الحديث عنه لعدة أيام ، وليس في تقرير قصير واحد ، لكنني سأركز الآن على أشياء مهمة ، وكيفية تجنب تلك المنافع التي لن تسمح لك بتشغيل قاعدة بيانات على Linux بشكل جيد إذا أنت لا تصلحهم. وفي الوقت نفسه ، هناك نقطة مهمة وهي أن العديد من المعلمات الافتراضية غير مدرجة في الإعدادات الصحيحة لقاعدة البيانات. أي أنه سيعمل بشكل افتراضي بشكل سيئ أو لن يعمل على الإطلاق.
ما هي أهداف الضبط التقليدية على Linux؟ أعتقد أنه نظرًا لأنكم جميعًا تتعاملون مع إدارة Linux ، فلا داعي لشرح الأهداف.
يمكنك ضبط:
- وحدة المعالجة المركزية.
- ذاكرة.
- تخزين.
- آخر. سنتحدث عن هذا في النهاية لتناول وجبة خفيفة. حتى ، على سبيل المثال ، يمكن أن تؤثر الإعدادات مثل سياسة توفير الطاقة على الأداء بطريقة غير متوقعة للغاية وغير ممتعة للغاية.
ما هي خصائص PostgreSQL وقاعدة البيانات بشكل عام؟ تكمن المشكلة في أنه لا يمكنك تعديل بعض العناصر المحددة وترى أن أداؤنا قد تحسن كثيرًا.
نعم ، توجد مثل هذه الأدوات ، لكن قاعدة البيانات شيء معقد. تتفاعل مع جميع الموارد التي يمتلكها الخادم وتفضل التفاعل بالكامل. إذا نظرت إلى إرشادات Oracle الحالية حول كيفية استخدام نظام تشغيل مضيف ، فإنها تشبه نكتة رائد الفضاء المنغولي - أطعم الكلب ولا تلمس أي شيء. دعونا نعطي قاعدة البيانات كل الموارد ، قاعدة البيانات نفسها ستدمر كل شيء.
من حيث المبدأ ، فإن الوضع هو نفسه تمامًا مع PostgreSQL إلى حد ما. يكمن الاختلاف في حقيقة أن القاعدة أيضًا غير قادرة على أخذ جميع الموارد لنفسها ، أي أنك في مكان ما على مستوى Linux تحتاج إلى فرزها بنفسك.
الفكرة الرئيسية ليست اختيار هدف واحد والبدء في ضبطه ، على سبيل المثال ، الذاكرة أو وحدة المعالجة المركزية أو شيء من هذا القبيل ، ولكن لتحليل عبء العمل ومحاولة تحسين الإنتاجية قدر الإمكان بحيث يكون الحمل الذي أنشأه المبرمجون الجيدون. لنا ، بما في ذلك مستخدمينا.
هذه صورة لشرح ما هو عليه. يوجد مخزن مؤقت لنظام التشغيل Linux ويوجد ذاكرة مشتركة وهناك مخازن PostgreSQL مشتركة. على عكس Oracle ، تعمل PostgreSQL مباشرة فقط من خلال المخزن المؤقت لـ kernel ، أي أنه من أجل وصول صفحة من القرص إلى ذاكرتها المشتركة ، يجب أن تمر عبر المخزن المؤقت لـ kernel وتعود إلى نفس الموقف تمامًا.
الأقراص تعيش في ظل هذا النظام. رسمته على شكل أقراص. في الواقع ، قد يكون هناك جهاز تحكم RAID ، وما إلى ذلك.
ويحدث هذا المدخلات والمخرجات بطريقة أو بأخرى من خلال هذا العمل.
PostgreSQL هي قاعدة بيانات كلاسيكية. إنه داخل الصفحة. وكل المدخلات والمخرجات تحدث بمساعدة الصفحات. نرفع الكتل في الذاكرة بالصفحات. وإذا لم يحدث شيء ، فقد قرأناها للتو ، ثم تغرقوا تدريجياً من ذاكرة التخزين المؤقت هذه ، من المخازن المؤقتة المشتركة وتعود إلى القرص.
إذا استبدلنا شيئًا ما في مكان ما ، فسيتم وضع علامة على صفحتنا بأكملها على أنها متسخة. قمت بتمييزها باللون الأزرق هنا. وهذا يعني أنه يجب مزامنة هذه الصفحة مع تخزين الكتلة. أي عندما جعلناه متسخًا ، أدخلنا في WAL. وفي لحظة معينة من الزمن ، ظهرت ظاهرة تسمى نقطة التفتيش. وهذا السجل سجل المعلومات التي جاء بها. وهذا يعني أن جميع الصفحات المتسخة التي كانت موجودة هنا في تلك اللحظة في هذه المخازن المؤقتة المشتركة تمت مزامنتها مع قرص التخزين باستخدام fsync من خلال المخزن المؤقت لـ kernel.
لما هذا؟ إذا فقدنا الجهد ، فلن نحصل على الحالة التي فقدت فيها جميع البيانات. الذاكرة الثابتة ، التي أخبرنا عنها الجميع ، هي حتى الآن في نظرية قواعد البيانات - هذا مستقبل مشرق ، ونحن بالطبع نسعى لتحقيقه ونحبه ، لكن حتى الآن لا يزالون يعيشون في أقل من 20 عامًا. وبالطبع كل هذا يحتاج إلى المراقبة.
ومهمة تعظيم الإنتاجية هي الضبط في كل هذه المراحل بحيث يذهب كل شيء ذهابًا وإيابًا بسرعة. الذاكرة المشتركة هي في الأساس ذاكرة تخزين مؤقت للصفحة. في PostgreSQL ، أرسلنا طلبًا محددًا هناك ، وحصل على هذه البيانات من القرص. دخلوا في المخازن المؤقتة المشتركة. وفقًا لذلك ، لكي يعمل هذا بشكل أفضل ، يجب أن يكون هناك الكثير من الذاكرة.
لكي يعمل كل هذا بشكل جيد وسريع ، تحتاج إلى تكوين نظام التشغيل بشكل صحيح في جميع المراحل. واختر الحديد المتوازن ، لأنه إذا كان لديك خلل في التوازن في مكان ما ، فيمكنك تكوين الكثير من الذاكرة ، ولكن سيتم تقديمه بسرعة غير كافية.
لنستعرض كل نقطة من هذه النقاط.
لكي تنتقل هذه الصفحات ذهابًا وإيابًا بشكل أسرع ، تحتاج إلى تحقيق ما يلي:
- أولاً ، تحتاج إلى العمل بكفاءة أكبر مع الذاكرة.
- ثانيًا ، يجب أن يكون هذا الانتقال أكثر فاعلية عندما تنتقل الصفحات من الذاكرة إلى القرص.
- وثالثاً ، لابد من وجود أقراص جيدة.
إذا كان لديك 512 جيجابايت من ذاكرة الوصول العشوائي في الخادم وينتهي كل هذا على محرك أقراص ثابتة SATA بدون أي ذاكرة تخزين مؤقت ، فإن خادم قاعدة البيانات بالكامل لا يتحول إلى قرع ، بل إلى قرع بواجهة SATA. سوف تصادفه مباشرة. ولن يخلصك شيء.
بالنسبة للنقطة الأولى المتعلقة بالذاكرة ، هناك ثلاثة أشياء يمكن أن تجعل الحياة صعبة للغاية.
الأول هو NUMA. NUMA هو الشيء الذي تم إنشاؤه لتحسين الأداء. اعتمادًا على حجم العمل ، يمكنك تحسين أشياء مختلفة. وفي شكله الحالي الجديد ، فإنه ليس جيدًا جدًا للتطبيقات مثل قاعدة البيانات التي تستخدم بشكل مكثف المخازن المؤقتة المشتركة لذاكرة التخزين المؤقت للصفحة.
شيء صغير. كيف نفهم أن هناك خطأ ما في NUMA؟ لديك نوع من الضربات غير السارة ، وفجأة تم تحميل وحدة المعالجة المركزية بشكل زائد. في الوقت نفسه ، تقوم بتحليل الاستعلامات في PostgreSQL وترى أنه لا يوجد شيء مماثل هناك. يجب ألا تكون هذه الطلبات مكثفة جدًا لوحدة المعالجة المركزية. يمكنك التقاطها لفترة طويلة. من الأسهل استخدام النصيحة الصحيحة من البداية حول كيفية إعداد NUMA لـ PostgreSQL.
ما الذي يحدث حقا؟ NUMA تعني الوصول إلى الذاكرة غير الموحدة. ماهي النقطة؟ لديك وحدة معالجة مركزية ، بجانبها توجد ذاكرة محلية. ويمكن لوصلات الذاكرة هذه سحب الذاكرة من وحدات المعالجة المركزية الأخرى.
اذا ركضت numactl --hardware، ثم ستحصل على مثل هذه الورقة الكبيرة. من بين أمور أخرى ، سيكون هناك مجال للمسافات. ستكون هناك أرقام - 10-20 ، شيء من هذا القبيل. هذه الأرقام ليست سوى عدد القفزات لالتقاط هذه الذاكرة البعيدة واستخدامها محليًا. فكرة جيدة في الأساس. هذا يحسن الأداء بشكل جيد في عدد من أحمال العمل.
تخيل الآن أن لديك وحدة معالجة مركزية واحدة تحاول أولاً استخدام ذاكرتها المحلية ، ثم تحاول سحب ذاكرة أخرى عبر الاتصال البيني لشيء ما. وتصل ذاكرة التخزين المؤقت لصفحة PostgreSQL بالكامل إلى وحدة المعالجة المركزية هذه - هذا كل شيء ، كم عدد الجيجابايت الموجودة هناك. تحصل دائمًا على أسوأ الحالات نظرًا لوجود ذاكرة قليلة عادةً على وحدة المعالجة المركزية مباشرةً في تلك الوحدة. وكل الذاكرة التي يتم تقديمها تمر عبر هذه الترابطات. اتضح ببطء وحزن. ولديك معالج يخدم هذه العقدة بشكل زائد باستمرار. ووقت الوصول إلى هذه الذاكرة سيء وبطيء. هذا هو نوع الموقف الذي لا تريده إذا كنت تستخدم هذه الحالة لقاعدة بيانات.
لذلك ، فإن الخيار الأكثر صحة لقاعدة البيانات هو أن نظام التشغيل Linux لا يعرف على الإطلاق ما يحدث هناك. حتى تخاطب الذكرى كما تخاطب.
لماذا هذا؟ يبدو أنه يجب أن يكون العكس. يحدث هذا لسبب واحد بسيط ، وهو أننا نحتاج إلى الكثير من الذاكرة لذاكرة التخزين المؤقت للصفحة - عشرات أو مئات الجيجابايت.
وإذا خصصنا كل هذا وقمنا بتخزين بياناتنا مؤقتًا هناك ، فسيكون الربح من استخدام ذاكرة التخزين المؤقت أكبر بكثير من المكاسب من مثل هذا الوصول إلى الذاكرة الماكرة. وبهذه الطريقة سوف نكسب بشكل لا يضاهى مقارنة بحقيقة أننا سنصل إلى الذاكرة بشكل أكثر كفاءة باستخدام NUMA.
لذلك ، هناك طريقتان في الوقت الحالي ، حتى يأتي مستقبل مشرق ، ولا تستطيع قاعدة البيانات نفسها معرفة وحدات المعالجة المركزية (CPU) التي تعمل عليها والمكان الذي تحتاج إلى سحب شيء منه.
لذلك ، فإن الطريقة الصحيحة هي تعطيل NUMA تمامًاعلى سبيل المثال عند إعادة التشغيل. في معظم الحالات ، تكون المكاسب في مثل هذه الطلبات بحيث لا يوجد شك على الإطلاق ، أيهما أفضل.
هناك خيار آخر. نحن نستخدمه في كثير من الأحيان أكثر من الأول ، لأنه عندما يأتي العميل إلينا للحصول على الدعم ، فإن إعادة تشغيل الخادم أمر كامل. لديه عمل هناك. وهم يواجهون مشاكل بسبب NUMA. لذلك ، نحاول تعطيله بطرق أقل توغلًا من إعادة التشغيل ، ولكن هنا كن حذرًا للتحقق من تعطيله. لأنه ، كما تظهر التجربة ، نقوم بتعطيل NUMA في العملية الأم لـ PostgreSQL ، وهذا أمر جيد ، لكن ليس من الضروري على الإطلاق أن يعمل هذا. نحن بحاجة إلى التحقق ومعرفة أنها قد توقفت بالفعل.
هناك وظيفة جيدة لروبرت هاس. هذا هو أحد مرتكبي PostgreSQL. أحد المطورين الرئيسيين لجميع حوصلة الطائر ذات المستوى المنخفض. وإذا اتبعت الروابط من هذا المنشور ، فإنه يصف العديد من القصص الملونة حول كيف جعلت NUMA الحياة صعبة على الناس. انظر ، ادرس قائمة التحقق الخاصة بمسؤول النظام لما يجب تهيئته على الخادم حتى تعمل قاعدة البيانات الخاصة بنا بشكل جيد. يجب تسجيل هذه الإعدادات والتحقق منها ، وإلا فلن تكون جيدة جدًا.
أوجه انتباهكم إلى حقيقة أن هذا ينطبق على جميع الإعدادات التي سأتحدث عنها. ولكن عادة ما يتم تجميع قواعد البيانات في وضع السيد والعبد للتسامح مع الخطأ. لا تنسَ عمل هذه الإعدادات على العبد ، لأنك يومًا ما ستواجه حادثًا وستنتقل إلى العبد وسيصبح السيد.
في حالات الطوارئ ، عندما يكون كل شيء سيئًا للغاية ، يرن هاتفك باستمرار ويأتي رئيسك في العمل بعصا كبيرة ، فلن يكون لديك وقت للتفكير في التحقق. ويمكن أن تكون النتائج كارثية للغاية.
اللحظة التالية صفحات ضخمة. يصعب اختبار الصفحات الضخمة بشكل منفصل ، ولا فائدة من ذلك ، على الرغم من وجود معايير يمكنها القيام بذلك. يتم البحث عنهم بسهولة في googled.
ما هي النقطة؟ لديك خادم غير مكلف للغاية يحتوي على الكثير من ذاكرة الوصول العشوائي ، على سبيل المثال ، أكثر من 30 جيجابايت. أنت لا تستخدم صفحات ضخمة. هذا يعني أنه لديك بالتأكيد زيادة في استخدام الذاكرة. وهذا الحمل بعيد عن أن يكون أكثر متعة.
لماذا هذا؟ وما يحدث؟ يخصص نظام التشغيل الذاكرة في أجزاء صغيرة. مريح جدا ، لذلك من الناحية التاريخية. وإذا دخلت في التفاصيل ، فيجب على نظام التشغيل ترجمة العناوين الافتراضية إلى عناوين فعلية. وهذه العملية ليست هي الأسهل ، لذلك يقوم نظام التشغيل بتخزين نتيجة هذه العملية مؤقتًا في Translation Lookaside Buffer (TLB).
ونظرًا لأن TLB عبارة عن ذاكرة تخزين مؤقت ، في هذه الحالة ، تنشأ جميع المشكلات الكامنة في ذاكرة التخزين المؤقت. أولاً ، إذا كان لديك الكثير من ذاكرة الوصول العشوائي (RAM) وتم تخصيصها جميعًا في أجزاء صغيرة ، فسيصبح هذا المخزن المؤقت كبيرًا جدًا. وإذا كانت ذاكرة التخزين المؤقت كبيرة ، فسيكون البحث عنها أبطأ. النفقات العامة صحية وتشغل مساحة من تلقاء نفسها ، أي أن هناك خطأ ما هو استهلاك ذاكرة الوصول العشوائي. هذا الوقت.
ثانيًا - كلما زاد حجم ذاكرة التخزين المؤقت في مثل هذه الحالة ، زاد احتمال حدوث أخطاء في ذاكرة التخزين المؤقت. وتنخفض كفاءة ذاكرة التخزين المؤقت هذه بسرعة مع نمو حجمها. لذلك جاءت أنظمة التشغيل بنهج بسيط. يستخدمه Linux لفترة طويلة. ظهرت في FreeBSD منذ وقت ليس ببعيد. لكننا نتحدث عن لينكس. هذه صفحات ضخمة.
وهنا تجدر الإشارة إلى أن الصفحات الضخمة ، كفكرة ، تم دفعها في البداية من قبل المجتمعات التي تضمنت Oracle و IBM ، أي أن مصنعي قواعد البيانات فكروا مليًا في حقيقة أن هذا سيكون مفيدًا ، بما في ذلك قواعد البيانات.
وكيف تصنع صداقات مع PostgreSQL؟ أولاً ، يجب تمكين الصفحات الضخمة في نواة Linux.
ثانيًا ، يجب تحديدها صراحةً بواسطة معلمة sysctl - كم عددها. الأرقام هنا من خادم قديم. يمكنك حساب عدد المخازن المؤقتة المشتركة لديك تقريبًا بحيث تتلاءم الصفحات الضخمة هناك.
وإذا كان لديك الخادم بالكامل مخصصًا لـ PostgreSQL ، فإن نقطة البداية الجيدة هي إما إعطاء 25٪ من ذاكرة الوصول العشوائي للمخازن المؤقتة المشتركة ، أو 75٪ إذا كنت متأكدًا من أن قاعدة البيانات الخاصة بك ستناسب هذه الـ 75٪ بالتأكيد. نقطة البداية أولا. ضع في اعتبارك ، إذا كان لديك 256 جيجابايت من ذاكرة الوصول العشوائي ، فحينئذٍ سيكون لديك 64 جيجابايت من المخازن المؤقتة sherd. احسب بالتقريب مع بعض الهامش - ما يجب أن يكون هذا الرقم مضبوطًا عليه.
قبل الإصدار 9.2 (إذا لم أكن مخطئًا ، منذ الإصدار 8.2) كان من الممكن تكوين صداقات بصفحات ضخمة PostgreSQL باستخدام مكتبة تابعة لجهة خارجية. ويجب أن يتم ذلك دائمًا. أولاً ، أنت بحاجة إلى النواة لتتمكن من تخصيص الصفحات الضخمة بشكل صحيح. وثانيًا ، حتى يتمكن التطبيق الذي يعمل معهم من استخدامها. لن يتم استخدامه بهذه الطريقة. نظرًا لأن PostgreSQL خصصت الذاكرة بأسلوب نظام 5 ، فيمكن القيام بذلك باستخدام libhugetlbfs - هذا هو الاسم الكامل للمكتبة.
9.3 حسّن أداء ذاكرة PostgreSQL وأزال طريقة تخصيص ذاكرة النظام 5. كان الجميع سعداء للغاية ، لأنه بخلاف ذلك تحاول تشغيل مثيلين من PostgreSQL على نفس الجهاز ، ويقول إنه ليس لدي ذاكرة مشتركة كافية. ويقول إنك بحاجة إلى إصلاح sysctl. وهناك مثل هذا النظام الذي ما زلت بحاجة إلى إعادة التشغيل ، وما إلى ذلك. بشكل عام ، كان الجميع سعداء. لكن تخصيص ذاكرة mmap تعطل باستخدام صفحات ضخمة. يستخدم معظم عملائنا مخازن كبيرة مشتركة. وقد أوصينا بشدة بعدم التبديل إلى 9.3 ، لأنه بدأ حساب النفقات العامة بنسب جيدة.
لكن من ناحية أخرى ، لفت المجتمع الانتباه إلى هذه المشكلة وفي 9.4 أعادوا صياغة هذا الحدث جيدًا. وفي 9.4 ، ظهرت معلمة في postgresql.conf ، حيث يمكنك تشغيل المحاولة أو تشغيلها أو إيقاف تشغيلها.
المحاولة هي الخيار الأكثر أمانًا. عندما تبدأ PostgreSQL ، عندما تخصص ذاكرة مشتركة ، فإنها تحاول الحصول على هذه الذاكرة من الصفحات الضخمة. وإذا لم ينجح الأمر ، فسيتم إرجاعه إلى التحديد المعتاد. وإذا كان لديك FreeBSD أو Solaris ، فيمكنك المحاولة ، فهو آمن دائمًا.
إذا تم تشغيله ، فلن يبدأ ببساطة إذا لم يتمكن من الاختيار من الصفحات الضخمة. هنا بالفعل - لمن وما هو أكثر لطيف. ولكن إذا حاولت ، فتأكد من أن لديك حقًا ما تريد تمييزه ، لأن هناك الكثير من المساحات لخطأ ما. حاليًا ، تعمل هذه الوظيفة فقط على Linux.
ملاحظة صغيرة أخرى قبل أن ننتقل. الصفحات الضخمة الشفافة لا تتعلق بـ PostgreSQL حتى الآن. لا يمكنه استخدامها بشكل طبيعي. ومع الصفحات الضخمة الشفافة لمثل هذا العبء ، عندما تحتاج إلى مساحة كبيرة من الذاكرة المشتركة ، فإن المزايا تأتي فقط بأحجام كبيرة جدًا. إذا كان لديك تيرابايت من الذاكرة ، فقد يلعب هذا دورًا. إذا كنا نتحدث عن المزيد من التطبيقات اليومية ، عندما يكون لديك 32 ، 64 ، 128 ، 256 جيجابايت من الذاكرة على الجهاز ، فإن الصفحات الضخمة المعتادة جيدة ، ونقوم بإيقاف تشغيل شفاف.
وآخر شيء يتعلق بالذاكرة لا يرتبط مباشرة بـ fruput ، يمكن أن يدمر الحياة كثيرًا. سوف تتأثر كل سرعة النقل بشكل كبير بحقيقة أن الخادم يتم تبديله باستمرار.
وسيكون الأمر مزعجًا للغاية في بعض النقاط. والمشكلة الرئيسية هي أن السلوك في النواة الحديثة يختلف قليلاً عن نواة Linux القديمة. وهذا الشيء ، وهو أمر غير سار إلى حد ما ، لأنه عندما نتحدث عن بعض الأعمال مع المبادلة ، فإنه ينتهي بالوصول المبكر لقاتل OOM. و OOM-killer ، الذي لم يأتِ في الوقت المناسب وتخلص من PostgreSQL ، غير سار. سيعرف الجميع عنها ، أي حتى آخر مستخدم.
ماذا يحدث؟ لديك كمية كبيرة من ذاكرة الوصول العشوائي هناك ، كل شيء يعمل بشكل جيد. ولكن لسبب ما ، يتوقف الخادم في عملية التبادل ويتباطأ بسبب هذا. يبدو أن هناك الكثير من الذاكرة ، لكن هذا يحدث.
في السابق ، نصحنا بتعيين vm.swappiness على الصفر ، أي تعطيل المبادلة. في السابق ، كان يبدو أن 32 جيجا بايت من ذاكرة الوصول العشوائي والمخازن المؤقتة المشتركة المقابلة كانت كمية ضخمة. الغرض الرئيسي من المقايضة هو الحصول على مكان لرمي قشرة إذا سقطنا. ولم يتم القيام به بشكل جيد. ثم ماذا ستفعل بهذه القشرة؟ هذه مهمة بالفعل عندما لا يكون من الواضح تمامًا سبب الحاجة إلى المبادلة ، خاصةً بهذا الحجم.
ولكن في الإصدارات الأكثر حداثة ، أي في الإصدارات الثالثة من النواة ، تغير السلوك. وإذا قمت بضبط المقايضة على الصفر ، أي إيقاف تشغيله ، فعاجلاً أم آجلاً ، حتى مع وجود بعض ذاكرة الوصول العشوائي المتبقية ، سيأتي قاتل OOM لقتل المستهلكين الأكثر كثافة. لأنه سيعتبر أنه مع مثل هذا العبء العمل لا يزال لدينا القليل من المتبقي وسنقفز ، أي لن نقتل عملية النظام ، ولكن نقتل شيئًا أقل أهمية. سيكون هذا أقل أهمية هو المستهلك الثقيل للذاكرة المشتركة ، أي مدير مكتب البريد. وبعد ذلك سيكون من الجيد إذا لم يكن من الضروري استعادة القاعدة.
لذلك ، الآن الافتراضي ، بقدر ما أتذكر ، معظم التوزيعات في مكان ما حوالي 6 ، أي في أي نقطة تبدأ في استخدام المبادلة ، اعتمادًا على مقدار الذاكرة المتبقية. ننصح الآن بتعيين vm.swappiness = 1 ، لأنه يقوم بإيقاف تشغيله عمليًا ، لكنه لا يعطي تأثيرات مثل قاتل OOM غير المتوقع الذي جاء وقتل كل شيء.
ماذا بعد؟ عندما نتحدث عن أداء قواعد البيانات وبشكل تدريجي ، نحن مثل الأقراص ، يبدأ الجميع في الاستيلاء على رؤوسهم. لأن حقيقة أن القرص بطيء والذاكرة سريعة أصبحت مألوفة للجميع منذ الطفولة. والجميع يعلم أنه ستكون هناك مشكلات في أداء القرص في قاعدة البيانات.
لا تكمن مشكلة أداء PostgreSQL الرئيسية مع ارتفاعات نقاط التفتيش في أن القرص بطيء. هذا على الأرجح بسبب حقيقة أن الذاكرة وعرض النطاق الترددي للقرص غير متوازنين. ومع ذلك ، قد لا تكون متوازنة في أماكن مختلفة. لم يتم تكوين PostgreSQL ، ولم يتم تكوين نظام التشغيل ، ولم يتم تكوين الأجهزة والأجهزة خاطئة. ولا تحدث هذه المشكلة إلا إذا سارت الأمور كما ينبغي ، أي إما أنه لا يوجد تحميل ، أو أن الإعدادات والأجهزة تم اختيارها جيدًا.
ما هو وكيف يبدو؟ عادةً ما يكون الأشخاص الذين يعملون مع PostgreSQL قد دخلوا في هذا العمل أكثر من مرة. سأشرح. كما قلت ، تقوم PostgreSQL بشكل دوري بعمل نقاط تفتيش لتفريغ الصفحات المتسخة في الذاكرة المشتركة على القرص. إذا كان لدينا قدر كبير من الذاكرة المشتركة ، عندها تبدأ نقطة التفتيش في التأثير بشكل مكثف على القرص ، لأن fsync يفرغ هذه الصفحات. يصل إلى المخزن المؤقت kernel ويتم كتابته على القرص باستخدام fsync. وإذا كان حجم هذه الحالة كبيرًا ، فيمكننا ملاحظة تأثير غير سار ، أي الاستخدام الكبير جدًا للأقراص.
هنا لدي صورتان. سأشرح الآن ما هو عليه. هذان رسمان بيانيان مرتبطان بالزمن. الرسم البياني الأول هو استخدام القرص. هنا تصل إلى ما يقرب من 90٪ في هذا الوقت. إذا كان لديك انخفاض في قاعدة البيانات مع الأقراص المادية ، مع استخدام وحدة تحكم RAID بنسبة 90٪ ، فهذه أخبار سيئة. هذا يعني أنه سيأتي أكثر من ذلك بقليل و 100 وسيتوقف الإدخال / الإخراج.
إذا كان لديك مجموعة أقراص ، فهناك قصة مختلفة قليلاً. هناك يعتمد على كيفية تكوينه ونوع المصفوفة وما إلى ذلك.
وبالتوازي ، تم تكوين رسم بياني هنا من عرض postgres الداخلي ، والذي يخبرنا بكيفية حدوث نقطة التفتيش. واللون الأخضر هنا يوضح عدد المخازن المؤقتة لهذه الصفحات القذرة التي وصلت في تلك اللحظة إلى نقطة التفتيش هذه للمزامنة. وهذا هو الشيء الرئيسي الذي يجب معرفته هنا. نرى أن لدينا الكثير من الصفحات هنا وفي وقت ما واجهنا رسومًا ، أي ، كتبنا وكتبنا ، هنا من الواضح أن نظام القرص مشغول جدًا. ونقطة التفتيش لدينا لها تأثير قوي للغاية على القرص. من الناحية المثالية ، يجب أن يبدو الموقف أكثر مثل هذا ، أي كان لدينا سجل أقل هنا. ويمكننا إصلاحه بالإعدادات بحيث يستمر على هذا النحو. هذا يعني أن إعادة التدوير صغيرة ، لكن في مكان ما نكتب شيئًا هنا.
ما الذي يجب عمله للتغلب على هذه المشكلة؟ إذا كنت قد أوقفت IO ضمن قاعدة البيانات ، فهذا يعني أن جميع المستخدمين الذين أتوا لتنفيذ طلباتهم سينتظرون.
إذا نظرت من وجهة نظر Linux ، إذا كنت قد حصلت على أجهزة جيدة ، وقمت بتكوينها بشكل صحيح ، وضبطت PostgreSQL بشكل طبيعي بحيث تقلل نقاط التفتيش هذه في كثير من الأحيان ، وتوزعها في الوقت بين بعضها البعض ، ثم تدخل إلى معلمات دبيان الافتراضية . هذه هي الصورة لمعظم توزيعات Linux: vm.dirty_ratio = 20، vm.dirty_background_ratio = 10.
ماذا يعني ذلك؟ منذ kernel 2.6 ، ظهر تدفق شيطاني واحد. Pdglush ، اعتمادًا على من يستخدم ماذا ، والذي يعمل في الخلفية بإلقاء الصفحات القذرة من المخزن المؤقت للنواة وإلقاء الصفحات القذرة عندما يكون ذلك ضروريًا ، بغض النظر عن أي شيء ، عندما لا يساعد رمي الخلفية.
متى تأتي الخلفية؟ عندما يتم احتلال 10٪ من إجمالي ذاكرة الوصول العشوائي الموجودة على الخادم بواسطة الصفحات المتسخة في المخزن المؤقت لـ kernel ، يتم استدعاء وظيفة الغش الخاصة في الخلفية. لماذا هي الخلفية؟ يأخذ كمعلمة كم عدد الصفحات لشطبها. ودعنا نقول ، يكتب من الصفحات N. ولفترة ، هذا الشيء ينام. ثم تعود وتكتب المزيد من الصفحات.
هذه قصة بسيطة للغاية. هنا تكون المهمة مثل حوض السباحة ، عندما يصب في أنبوب واحد ، يصب في أنبوب آخر. جاءت نقطة التفتيش الخاصة بنا وإذا أرسلت بضع صفحات قذرة للتخلص منها ، فسيتم حل هذا الأمر برمته بشكل تدريجي من مخزن النواة المؤقت.
إذا استمرت هذه الصفحات القذرة في التراكم ، فإنها تتراكم بنسبة تصل إلى 20٪ ، وبعد ذلك تكون أولوية نظام التشغيل هي شطب كل شيء على القرص ، لأن الطاقة ستخرج ، وسيكون كل شيء سيئًا بالنسبة لنا. سوف نفقد هذه البيانات ، على سبيل المثال.
ما هي خدعة؟ الحيلة هي أن هذه المعلمات في العالم الحديث من 20 و 10٪ من ذاكرة الوصول العشوائي الموجودة على الجهاز ، هي وحشية للغاية من حيث سرعة نقل أي نظام قرص لديك.
تخيل أن لديك 128 جيجابايت من ذاكرة الوصول العشوائي. 12,8 جيجا بايت تأتي إلى نظام القرص الخاص بك. وبغض النظر عن ذاكرة التخزين المؤقت الموجودة لديك ، بغض النظر عن المصفوفة التي لديك هناك ، فإنها لن تصمد كثيرًا.
لذلك ، نوصي بتعديل هذه الأرقام فورًا اعتمادًا على إمكانيات وحدة تحكم RAID الخاصة بك. لقد قدمت على الفور توصية هنا لوحدة تحكم بها 512 ميجابايت من ذاكرة التخزين المؤقت.
كل شيء يعتبر بسيطًا جدًا. يمكنك وضع vm.dirty_background بالبايت. وتتجاوز هذه الإعدادات الإعدادين السابقين. إما أن تكون النسبة افتراضيًا ، أو يتم تنشيط تلك التي تحتوي على بايت ، فعندئذٍ ستعمل تلك التي تحتوي على بايت. ولكن نظرًا لأنني مستشار DBA وأعمل مع عملاء مختلفين ، فأنا أحاول وضع القش ، وبالتالي ، إذا كان بالبايت ، فعندئذٍ بالبايت. لم يقدم أحد أي ضمان بأن المشرف الجيد لن يضيف ذاكرة إلى الخادم ، ولن يعيد تشغيله ، وسيظل الرقم كما هو. ما عليك سوى حساب هذه الأرقام بحيث يتلاءم كل شيء مع الضمان.
ماذا يحدث إذا كنت لا تناسبك؟ لقد كتبت أن ذلك يوقف بشكل فعال أي احمرار ، لكنه في الحقيقة شكل من أشكال الكلام. يعاني نظام التشغيل من مشكلة كبيرة - فهو يحتوي على الكثير من الصفحات القذرة ، لذا فإن الإدخال / الإخراج الذي يولده عملاؤك يتوقف بشكل فعال ، أي أن التطبيق قد حان لإرسال استعلام SQL إلى قاعدة البيانات ، فهو ينتظر. أي إدخال / إخراج لها يكون في أدنى أولوية ، لأن القاعدة مشغولة بنقطة التفتيش. وعندما تنتهي ، يصبح الأمر غير مفهوم تمامًا. وعندما تصل إلى تدفق غير خلفي أو غير خلفي ، فهذا يعني أن كل عمليات الإدخال والإخراج الخاصة بك مشغولة به. وحتى تنتهي ، لن تفعل شيئًا.
هناك نقطتان أكثر أهمية خارج نطاق هذا التقرير. يجب أن تتطابق هذه الإعدادات مع الإعدادات في postgresql.conf ، أي إعدادات نقاط التفتيش. ويجب تكوين نظام القرص الخاص بك بشكل مناسب. إذا كان لديك ذاكرة تخزين مؤقت على RAID ، فيجب أن تحتوي على بطارية. يشتري الناس RAID بذاكرة تخزين مؤقت جيدة بدون بطارية. إذا كان لديك SSD في RAID ، فيجب أن تكون من نوع الخادم ، ويجب أن يكون هناك مكثفات. ها هي قائمة المراجعة الموسعة. يوجد في هذا الرابط تقريري حول كيفية إعداد أداء القرص في PostgreSQL. كل تلك القوائم المرجعية موجودة هناك.
ما الذي يمكن أن يجعل الحياة صعبة للغاية؟ هذان خياران. إنها جديدة نسبيًا. بشكل افتراضي ، يمكن تضمينها في تطبيقات مختلفة. ويمكن أن تعقد الحياة بنفس القدر إذا تم تشغيلها بشكل غير صحيح.
هناك قطعتان جديدتان نسبيًا. لقد ظهرت بالفعل في النوى الثالثة. هذه هي Sched_migration_cost بالنانو ثانية و Schedule_autogroup_enabled وهي واحدة بشكل افتراضي.
وكيف يفسدون الحياة؟ ما هو Sched_migration_cost؟ يمكن لجدولة Linux ترحيل عملية من وحدة المعالجة المركزية إلى أخرى. وبالنسبة إلى PostgreSQL ، التي تنفذ الاستعلامات ، فإن الترحيل إلى وحدة معالجة مركزية أخرى هو سبب غير مفهوم تمامًا. من وجهة نظر نظام التشغيل ، عند تبديل النوافذ بين openoffice و Terminal ، قد يكون هذا جيدًا ، لكن لقاعدة البيانات - إنها سيئة للغاية. لذلك ، تتمثل إحدى السياسات المعقولة في تعيين تكلفة الترحيل إلى قيمة كبيرة ، لا تقل عن بضعة آلاف من النانو ثانية.
ماذا يعني هذا بالنسبة للجدول؟ من المفترض أن هذه العملية لا تزال ساخنة خلال هذا الوقت. هذا يعني أنه إذا كان لديك نوع من المعاملات الطويلة تفعل شيئًا ما لفترة طويلة ، فسيفهم المجدول ذلك. سيفترض أنه حتى انقضاء هذه المهلة ، فلن تحتاج هذه العملية إلى الترحيل إلى أي مكان. إذا قامت العملية بشيء ما في نفس الوقت ، فلن يتم ترحيلها في أي مكان ، وسوف تنتهي بهدوء على وحدة المعالجة المركزية التي تم تخصيصها لها. والنتيجة ممتازة.
النقطة الثانية هي المجموعة التلقائية. هناك فكرة جيدة لأحمال عمل محددة لا تتعلق بقواعد البيانات الحديثة - وهذا هو تجميع العمليات بواسطة المحطة الافتراضية التي يتم إطلاقها منها. إنه مناسب لبعض المهام. من الناحية العملية ، PostgreSQL هو نظام متعدد العمليات مسبقًا يتم تشغيله من محطة طرفية واحدة. لديك كاتب قفل ، ونقطة فحص ، وجميع طلبات العملاء الخاصة بك مجمعة في برنامج جدولة واحد ، لكل وحدة معالجة مركزية. وسوف ينتظرون معًا هناك عندما يكون حرا ، من أجل التدخل في بعضهم البعض وإبقائه مشغولًا لفترة أطول. هذه قصة غير ضرورية تمامًا في حالة وجود مثل هذا الحمل وبالتالي يجب إيقاف تشغيلها.
أجرى زميلي أليكسي ليسوفسكي اختبارات باستخدام أداة pgbench بسيطة ، حيث زاد تكلفة الهجرة بترتيب من حيث الحجم وأوقف تشغيل المجموعة التلقائية. تبين أن الفرق في قطعة الحديد السيئة هو 10٪ تقريبًا. هناك مناقشة في القائمة البريدية postgres حيث يقوم الأشخاص بالإبلاغ عن نتائج مثل تغييرات مماثلة في سرعة الاستعلام تأثر 50٪. هناك عدد غير قليل من هذه القصص.
وأخيراً ، حول سياسة توفير الطاقة. من الجيد أنه يمكن الآن استخدام Linux على جهاز كمبيوتر محمول. ومن المفترض أن تستهلك البطارية جيدًا. لكن فجأة اتضح أن هذا يمكن أن يحدث أيضًا على الخادم.
علاوة على ذلك ، إذا قمت باستئجار خوادم من مضيف ما ، فإن المضيفين "الجيدين" لا يهتمون بأداء أفضل. مهمتهم هي التأكد من استخدام الحديد الخاص بهم بأكبر قدر ممكن من الكفاءة. لذلك ، بشكل افتراضي ، يمكنهم تشغيل وضع توفير طاقة الكمبيوتر المحمول على نظام التشغيل.
إذا كنت تستخدم هذا على خادم قاعدة بيانات محملة بكثافة ، فإن اختيارك هو acpi_cpufreq + permormance. حتى في حالة الطلب ، ستكون هناك مشاكل بالفعل.
Intel_pstate هو محرك مختلف قليلاً. والآن يتم إعطاء الأفضلية لهذا ، كما هو الحال في وقت لاحق وأفضل عامل.
وبالتالي ، فإن الحاكم هو الأداء فقط. عند الطلب ، وحفظ الطاقة وكل ما تبقى - هذا ليس عنك.
يمكن أن تختلف نتائج التحليل التوضيحي PostgreSQL بعدة أوامر من حيث الحجم إذا قمت بتشغيل توفير الطاقة ، لأنه من الناحية العملية سيكون لديك فصل وحدة المعالجة المركزية تحت قاعدة البيانات بطريقة لا يمكن التنبؤ بها تمامًا.
يمكن تمكين هذه الأشياء بشكل افتراضي. انظر بعناية لمعرفة ما إذا كان قد تم تمكينه افتراضيًا. هذا يمكن أن يكون مشكلة كبيرة حقا.
وفي النهاية ، أردت أن أتوجه بالشكر إلى الرجال من فريق PosgreSQL-Consulting DBA ، وهم ماكس بوغوك وأليكسي ليسوفسكي ، الذين يملأون المطبات يوميًا في هذا العمل. ولعملائنا ، نحاول تقديم الأفضل ، حتى يعمل كل شيء لصالحهم. الأمر يشبه تعليمات أمن الطيران. كل شيء هنا مكتوب بالدم. يتم اكتشاف كل من هذه المكسرات في عملية نوع من المشاكل. أنا سعيد لمشاركتها معك.
الأسئلة:
شكرًا لك! على سبيل المثال ، إذا أرادت إحدى الشركات توفير المال واستضافة قاعدة البيانات ومنطق التطبيق على نفس الخادم ، أو إذا كانت الشركة تتبع اتجاه الموضة لبنيات الخدمات المصغرة التي تعمل فيها PostgreSQL في حاوية. ما هي النقطة؟ يؤثر Sysctl عالميًا على النواة بأكملها. لم أسمع أن sysctls هي افتراضية بطريقة ما بحيث تعمل بشكل منفصل على الحاوية. لا يوجد سوى مجموعة cgroup وجزء منها فقط لديه السيطرة. كيف يمكنك التعايش مع هذا؟ أو إذا كنت تريد الأداء ، فقم بتشغيل PostgreSQL على خادم حديد منفصل وقم بضبطه؟
لقد أجبنا على سؤالك بثلاث طرق. إذا لم نتحدث عن خادم حديدي يمكن ضبطه ، وما إلى ذلك ، فاسترخ ، فسيعمل كل شيء بشكل جيد بدون هذه الإعدادات. إذا كان لديك مثل هذا الحمل الذي تحتاج إلى القيام بهذه الإعدادات ، فستأتي إلى خادم الحديد قبل هذه الإعدادات.
ما المشكلة؟ إذا كان هذا جهازًا افتراضيًا ، فعلى الأرجح ستواجه العديد من المشكلات ، على سبيل المثال ، مع حقيقة أن معظم الأجهزة الافتراضية لديها زمن انتقال غير متسق للقرص. حتى إذا كانت سرعة نقل القرص جيدة ، فإن عملية إدخال / إخراج واحدة فاشلة لا تؤثر بشكل كبير على متوسط الإنتاجية التي حدثت في وقت نقطة التفتيش أو في وقت الكتابة إلى WAL ، فستعاني قاعدة البيانات بشكل كبير من ذلك. وستلاحظ هذا قبل أن تواجه هذه المشاكل.
إذا كان لديك NGINX على نفس الخادم ، فستواجه نفس المشكلة أيضًا. سيقاتل من أجل الذاكرة المشتركة. ولن تصل إلى المشاكل الموضحة هنا.
ولكن من ناحية أخرى ، ستظل بعض هذه المعلمات ذات صلة بك. على سبيل المثال ، مع sysctl ، اضبط dirty_ratio بحيث لا يكون مجنونا - على أي حال ، سيساعد هذا. بطريقة أو بأخرى ، سيكون لديك تفاعل مع القرص. وسيكون من الخطأ. هذا بشكل عام هو الافتراضي للمعلمات التي أظهرتها. وعلى أي حال ، من الأفضل تغييرها.
ومع NUMA يمكن أن تكون هناك مشاكل. VmWare ، على سبيل المثال ، يعمل بشكل جيد مع NUMA مع الإعدادات المعاكسة تمامًا. وهنا عليك أن تختار - خادم حديدي أو خادم غير حديدي.
لدي سؤال متعلق بـ Amazon AWS. لديهم صور تم تكوينها مسبقًا. واحد منهم يسمى Amazon RDS. هل هناك أي إعدادات مخصصة لنظام التشغيل الخاص بهم؟
هناك إعدادات ، لكنها إعدادات مختلفة. نقوم هنا بتكوين نظام التشغيل من حيث كيفية استخدام قاعدة البيانات لهذه الأعمال. وهناك معلمات تحدد إلى أين يجب أن نذهب الآن ، مثل هذا التشكيل. وهذا يعني أننا بحاجة إلى الكثير من الموارد ، وسوف نبتلعها الآن. بعد ذلك ، تقوم Amazon RDS بتثبيت هذه الموارد ، وينخفض الأداء هناك. هناك قصص منفصلة عن كيفية بدء الناس في الكيمياء مع هذه المسألة. في بعض الأحيان بنجاح كبير. لكن لا علاقة له بإعدادات نظام التشغيل. إنه مثل القرصنة السحابية. إنها قصة مختلفة.
لماذا لا يكون للصفحات الشفافة الضخمة أي تأثير مقارنة بـ Huge TLB؟
لا تعطي. يمكن تفسير ذلك بعدة طرق. لكن في الحقيقة هم فقط لا يعطونها. ما هو تاريخ PostgreSQL؟ عند بدء التشغيل ، يخصص جزءًا كبيرًا من الذاكرة المشتركة. شفافة فهي في نفس الوقت أو غير شفافة - لا يهم على الإطلاق. حقيقة أنها تبرز في البداية تفسر كل شيء. وإذا كان هناك الكثير من الذاكرة وتحتاج إلى إعادة إنشاء مقطع الذاكرة المشتركة ، فستكون الصفحات الضخمة الشفافة ذات صلة. في PostgreSQL ، يتم تمييزها في البداية بقطعة ضخمة وهذا كل شيء ، وبعد ذلك لا يحدث شيء مميز هناك. يمكنك بالطبع استخدامه ، ولكن هناك فرصة للحصول على ذاكرة مشتركة عند إعادة تخصيص شيء ما. لا تعرف PostgreSQL عن هذا الأمر.
المصدر: www.habr.com