أقترح عليك قراءة نص تقرير نيكولاي ساموخفالوف "النهج الصناعي لضبط PostgreSQL: تجارب على قواعد البيانات"
Shared_buffers = 25% – هل هي كثيرة أم قليلة؟ أو مجرد حق؟ كيف يمكنك معرفة ما إذا كانت هذه التوصية - التي عفا عليها الزمن - مناسبة لحالتك الخاصة؟
حان الوقت للتعامل مع مسألة تحديد معلمات postgresql.conf "مثل شخص بالغ". ليس بمساعدة "الموالفات التلقائية" العمياء أو النصائح القديمة من المقالات والمدونات، ولكن بناءً على:
- تجارب تم التحقق منها بدقة على قواعد البيانات، ويتم إجراؤها تلقائيًا وبكميات كبيرة وفي ظل ظروف أقرب ما يمكن إلى تلك "القتالية"،
- فهم عميق لميزات نظام إدارة قواعد البيانات ونظام التشغيل.
باستخدام نانسي CLI ()، سنلقي نظرة على مثال محدد - المخازن المؤقتة المشتركة سيئة السمعة - في مواقف مختلفة، في مشاريع مختلفة ونحاول معرفة كيفية اختيار الإعداد الأمثل للبنية التحتية وقاعدة البيانات والتحميل.
سنتحدث عن التجارب مع قواعد البيانات. هذه قصة تستمر ما يزيد قليلاً عن ستة أشهر.
قليلا عني. خبرة مع Postgres لأكثر من 14 عامًا. تم تأسيس عدد من شركات التواصل الاجتماعي. كان Postgres ويستخدم في كل مكان.
وأيضا مجموعة RuPostgres على Meetup، المركز الثاني في العالم. نحن نقترب ببطء من 2 شخص. RuPostgres.org.
وعلى أجهزة الكمبيوتر الخاصة بالمؤتمرات المختلفة، بما في ذلك Highload، فأنا مسؤول عن قواعد البيانات، ولا سيما Postgres منذ البداية.
وفي السنوات القليلة الماضية، قمت بإعادة تشغيل ممارستي الاستشارية في Postgres على بعد 11 منطقة زمنية من هنا.
وعندما قمت بذلك قبل بضع سنوات، حصلت على فترة راحة من العمل اليدوي النشط مع Postgres، ربما منذ عام 2010. لقد فوجئت بمدى ضآلة التغيير في روتين العمل الخاص بمسؤولي قواعد البيانات، وكم العمل اليدوي الذي لا يزال يتعين استخدامه. واعتقدت على الفور أن هناك خطأ ما هنا، وأحتاج إلى أتمتة المزيد من كل شيء.
وبما أن كل شيء كان بعيدًا، كان معظم العملاء في السحاب. ومن الواضح أن الكثير قد أصبح آليًا بالفعل. المزيد عن هذا لاحقا. وهذا يعني أن كل هذا أدى إلى فكرة أنه يجب أن يكون هناك عدد من الأدوات، أي نوع من النظام الأساسي الذي سيؤدي إلى أتمتة جميع إجراءات DBA تقريبًا بحيث يمكن إدارة عدد كبير من قواعد البيانات.
لن يتضمن هذا التقرير:
- "الرصاص الفضي" وعبارات مثل - قم بتعيين 8 جيجابايت أو 25% من المخزن المؤقت المشترك وستكون بخير. لن يكون هناك الكثير حول Shared_buffers.
- المتشددين "الباطن".
وماذا سيحدث؟
- ستكون هناك مبادئ تحسين نطبقها ونطورها. سيكون هناك جميع أنواع الأفكار التي تنشأ على طول الطريق والأدوات المختلفة التي ننشئها في الغالب في المصدر المفتوح، أي أننا نصنع الأساس في المصدر المفتوح. علاوة على ذلك، لدينا تذاكر، وجميع الاتصالات مفتوحة المصدر تقريبًا. يمكنك أن ترى ما نقوم به الآن، وماذا سيكون في الإصدار التالي، وما إلى ذلك.
- سيكون هناك أيضًا بعض الخبرة في استخدام هذه المبادئ، هذه الأدوات في عدد من الشركات: من الشركات الناشئة الصغيرة إلى الشركات الكبيرة.
كيف يتطور كل هذا؟
أولاً، المهمة الرئيسية لمسؤول قواعد البيانات، بالإضافة إلى ضمان إنشاء المثيلات ونشر النسخ الاحتياطية وما إلى ذلك، هي العثور على الاختناقات وتحسين الأداء.
الآن تم إعداده على هذا النحو. ننظر إلى الرصد، نرى شيئًا ما، لكننا نفتقد بعض التفاصيل. نبدأ في الحفر بعناية أكبر، عادةً بأيدينا، ونفهم ما يجب فعله به بطريقة أو بأخرى.
وهناك نهجان. Pg_stat_statements هو الحل الافتراضي لتحديد الاستعلامات البطيئة. وتحليل سجلات Postgres باستخدام pgBadger.
كل نهج له عيوب خطيرة. في النهج الأول، قمنا بطرح جميع المعلمات. وإذا رأينا المجموعات SELECT * FROM الجدول حيث يساوي العمود "؟" أو "$" منذ Postgres 10. لا نعرف ما إذا كان هذا فحص فهرس أم فحص تسلسلي. ذلك يعتمد كثيرا على المعلمة. إذا قمت باستبدال قيمة نادرًا ما تتم مواجهتها هناك، فسيتم إجراء فحص للفهرس. إذا قمت باستبدال قيمة تشغل 90% من الجدول هناك، فسيكون المسح التسلسلي واضحًا، لأن Postgres يعرف الإحصائيات. وهذا عيب كبير في pg_stat_statements، على الرغم من أن بعض العمل جارٍ.
أكبر عيب في تحليل السجل هو أنه لا يمكنك تحمل تكلفة "log_min_duration_statement = 0" كقاعدة. وسنتحدث عن هذا أيضًا. وبناء على ذلك، فإنك لا ترى الصورة كاملة. وبعض الاستعلامات، التي تكون سريعة جدًا، قد تستهلك قدرًا هائلاً من الموارد، لكنك لن تراها لأنها أقل من الحد الخاص بك.
كيف يحل مسؤولو قواعد البيانات المشكلات التي يجدونها؟
على سبيل المثال، وجدنا بعض المشاكل. ما الذي يتم عمله عادة؟ إذا كنت مطورًا، فسوف تفعل شيئًا في بعض الحالات ليس بنفس الحجم. إذا كنت DBA، فلديك التدريج. ولا يمكن أن يكون هناك سوى واحد. وكان متأخرا ستة أشهر. وتعتقد أنك ستذهب إلى الإنتاج. وحتى مسؤولي قواعد البيانات ذوي الخبرة يقومون بعد ذلك بفحص الإنتاج على نسخة طبق الأصل. ويحدث أنهم يقومون بإنشاء فهرس مؤقت، والتأكد من أنه يساعد، وإسقاطه وإعطائه للمطورين حتى يتمكنوا من وضعه في ملفات الترحيل. هذا هو نوع الهراء الذي يحدث الآن. وهذه مشكلة.
- ضبط التكوينات.
- تحسين مجموعة الفهارس.
- قم بتغيير استعلام SQL نفسه (هذه هي الطريقة الأكثر صعوبة).
- أضف سعة (أسهل طريقة في معظم الحالات).
هناك الكثير يحدث مع هذه الأشياء. هناك الكثير من المقابض في Postgres. هناك الكثير لنعرفه. هناك العديد من الفهارس في Postgres، وذلك بفضل منظمي هذا المؤتمر أيضًا. وكل هذا يجب أن يكون معروفًا، وهذا ما يجعل غير مسؤولي قواعد البيانات يشعرون وكأن مسؤولي قواعد البيانات يمارسون السحر الأسود. أي أنك تحتاج إلى الدراسة لمدة 10 سنوات لتبدأ في فهم كل هذا بشكل طبيعي.
وأنا مقاتل ضد هذا السحر الأسود. أريد أن أفعل كل شيء حتى تكون هناك تكنولوجيا، ولا يوجد حدس في كل هذا.
أمثلة الحياة
لقد لاحظت ذلك في مشروعين على الأقل، بما في ذلك مشروعي الخاص. يخبرنا منشور مدونة آخر أن القيمة 1 لـ default_statistict_target جيدة. حسنًا، فلنجرب ذلك في الإنتاج.
وها نحن هنا، باستخدام أداتنا بعد عامين، بمساعدة التجارب على قواعد البيانات التي نتحدث عنها اليوم، يمكننا مقارنة ما كان وما أصبح.
ولهذا نحن بحاجة إلى إنشاء تجربة. يتكون من أربعة أجزاء.
- الأول هو البيئة. نحن بحاجة إلى قطعة من الأجهزة. وعندما أتيت إلى بعض الشركات وأوقع عقدًا، أقول لهم أن يعطوني نفس الأجهزة المستخدمة في الإنتاج. لكل من أسيادك، أحتاج على الأقل إلى قطعة واحدة من الأجهزة مثل هذه. إما أن يكون هذا جهازًا افتراضيًا في Amazon أو Google، أو أحتاج إلى نفس قطعة الأجهزة بالضبط. وهذا هو، أريد إعادة خلق البيئة. وفي مفهوم البيئة قمنا بتضمين الإصدار الرئيسي من Postgres.
- والجزء الثاني هو موضوع بحثنا. هذه قاعدة بيانات. يمكن إنشاؤه بعدة طرق. سأريكم كيف.
- الجزء الثالث هو الحمل. هذه هي اللحظة الأكثر صعوبة.
- والجزء الرابع هو ما نتحقق منه، أي ما سنقارنه بماذا. لنفترض أنه يمكننا تغيير معلمة واحدة أو أكثر في التكوين، أو يمكننا إنشاء فهرس، وما إلى ذلك.
نحن نطلق تجربة. هنا pg_stat_statements. على اليسار ما حدث. على اليمين - ماذا حدث.
على اليسار default_statistics_target = 100، على اليمين = 1. نرى أن هذا ساعدنا. وبشكل عام، تحسن كل شيء بنسبة 000%.
لكن إذا انتقلنا للأسفل، فستجد مجموعات من الطلبات من pgBadger أو من pg_stat_statements. هناك خياران. سنرى أن بعض الطلبات قد انخفضت بنسبة 88%. وهنا يأتي النهج الهندسي. يمكننا أن نحفر أكثر في الداخل لأننا نتساءل لماذا غرقت. عليك أن تفهم ما حدث مع الإحصائيات. لماذا يؤدي المزيد من الدلاء في الإحصائيات إلى نتائج أسوأ.
أو لا يمكننا الحفر، ولكن نقوم بإجراء "ALTER TABLE ... ALTER COLUMN" ونعيد 100 مجموعة إلى إحصائيات هذا العمود. وبعد ذلك، من خلال تجربة أخرى يمكننا التأكد من أن هذا التصحيح قد ساعد. الجميع. هذا نهج هندسي يساعدنا على رؤية الصورة الكبيرة واتخاذ القرارات بناءً على البيانات بدلاً من الحدس.
بضعة أمثلة من مناطق أخرى. كانت هناك اختبارات CI قيد الاختبار لسنوات عديدة. ولن يعيش أي مشروع بكامل قواه العقلية بدون اختبارات آلية.
في صناعات أخرى: في الطيران، في صناعة السيارات، عندما نختبر الديناميكا الهوائية، لدينا أيضًا الفرصة لإجراء التجارب. لن نطلق شيئًا ما من رسم مباشر إلى الفضاء، أو لن نضع سيارة ما على المسار على الفور. على سبيل المثال، هناك نفق الرياح.
يمكننا استخلاص استنتاجات من ملاحظات الصناعات الأخرى.
أولاً، لدينا بيئة خاصة. إنه قريب من الإنتاج، لكنه ليس قريبًا. وتتمثل ميزتها الرئيسية في أنها ينبغي أن تكون رخيصة الثمن وقابلة للتكرار ومؤتمتة قدر الإمكان. ويجب أن تكون هناك أيضًا أدوات خاصة لإجراء التحليل التفصيلي.
على الأرجح، عندما نطلق طائرة ونطير، تكون لدينا فرصة أقل لدراسة كل ملليمتر من سطح الجناح مقارنة بنفق الرياح. لدينا المزيد من أدوات التشخيص. يمكننا أن نحمل المزيد من الأشياء الثقيلة التي لا نستطيع أن نضعها على متن طائرة في الهواء. الشيء نفسه مع بوستجرس. يجوز لنا، في بعض الحالات، تمكين تسجيل الاستعلام الكامل أثناء التجارب. ونحن لا نريد أن نفعل هذا في الإنتاج. قد نخطط أيضًا لتمكين هذا باستخدام auto_explain.
وكما قلت، المستوى العالي من الأتمتة يعني أننا نضغط على الزر ونكرر الأمر. هكذا ينبغي أن يكون الأمر، بحيث يكون هناك الكثير من التجارب، بحيث يكون قيد البث.
نانسي CLI - تأسيس "مختبر قاعدة البيانات"
وهكذا فعلنا هذا الشيء. أي أنني تحدثت عن هذه الأفكار في يونيو، منذ عام تقريبًا. ولدينا بالفعل ما يسمى Nancy CLI في المصدر المفتوح. هذا هو الأساس لبناء مختبر قاعدة البيانات.
- إنه مفتوح المصدر، على Gitlab. يمكنك قول ذلك، يمكنك تجربته. لقد قدمت رابطا في الشرائح. يمكنك النقر عليه وسيكون هناك من جميع النواحي.
وبطبيعة الحال، لا يزال هناك الكثير قيد التطوير. هناك الكثير من الأفكار هناك. ولكن هذا شيء نستخدمه كل يوم تقريبًا. وعندما تكون لدينا فكرة - لماذا عندما نحذف 40 سطرًا، يعود الأمر كله إلى الإدخال/الإخراج، عندها يمكننا إجراء تجربة والنظر بمزيد من التفصيل لفهم ما يحدث ثم محاولة إصلاحه بسرعة. أي أننا نقوم بالتجربة. على سبيل المثال، نقوم بتعديل شيء ما ونرى ما سيحدث في النهاية. ونحن لا نفعل هذا في الإنتاج. وهذا هو جوهر الفكرة.
أين يمكن أن يعمل هذا؟ يمكن أن يعمل هذا محليًا، أي يمكنك القيام بذلك في أي مكان، ويمكنك حتى تشغيله على جهاز MacBook. نحن بحاجة إلى عامل ميناء، دعونا نذهب. هذا كل شئ. يمكنك تشغيله في بعض الحالات على قطعة من الأجهزة، أو في جهاز افتراضي، في أي مكان.
وهناك أيضًا فرصة للتشغيل عن بعد في Amazon في مثيل EC2، في المواقع. وهذه فرصة رائعة جدًا. على سبيل المثال، أجرينا بالأمس أكثر من 500 تجربة على مثيل i3، بدءًا من الأصغر وانتهاءً بـ i3-16-xlarge. و500 تجربة كلفتنا 64 دولارًا. استمرت كل منها 15 دقيقة. وهذا هو، نظرا لحقيقة أن البقع تستخدم هناك، فهي رخيصة للغاية - خصم 70٪، فواتير أمازون في الثانية. يمكنك أن تفعل الكثير. يمكنك إجراء بحث حقيقي.
ويتم دعم ثلاثة إصدارات رئيسية من Postgres. ليس من الصعب جدًا إنهاء بعض الإصدارات القديمة والإصدار الثاني عشر الجديد أيضًا.
يمكننا تعريف كائن بثلاث طرق. هذا:
- تفريغ / ملف SQL.
- الطريقة الرئيسية هي استنساخ دليل PGDATA. وكقاعدة عامة، يتم أخذها من خادم النسخ الاحتياطي. إذا كان لديك نسخ احتياطية ثنائية عادية، فيمكنك إجراء النسخ من هناك. إذا كان لديك سحاب، فإن مكتب سحابي مثل أمازون وجوجل سوف يقوم بذلك نيابةً عنك. هذه هي الطريقة الأكثر أهمية لاستنساخ الإنتاج الحقيقي. هذه هي الطريقة التي تتكشف.
- والطريقة الأخيرة مناسبة للبحث عندما تريد فهم كيفية عمل شيء ما في Postgres. هذا هو بغبنش. يمكنك إنشاء باستخدام pgbench. إنه مجرد خيار "db-pgbench" واحد. تقول له ما هو المقياس. وسيتم إنشاء كل شيء في السحابة، كما ذكرنا.
وتحميل:
- يمكننا تنفيذ التحميل في موضوع SQL واحد. هذه هي الطريقة الأكثر بدائية.
- ويمكننا محاكاة الحمل. ويمكننا تقليدها أولاً بالطريقة التالية. نحن بحاجة لجمع كل السجلات. وهذا مؤلم. سأوضح لك السبب. وباستخدام pgreplay نلعب، وهو مدمج في نانسي.
- أو خيار آخر. ما يسمى بالحمل الحرفي، والذي نقوم به بقدر معين من الجهد. من خلال تحليل حملنا الحالي على نظام القتال، نقوم بسحب المجموعات العليا من الطلبات. وباستخدام pgbench يمكننا محاكاة هذا الحمل في المختبر.
- إما أن يتعين علينا تنفيذ نوع ما من SQL، أي أننا نتحقق من نوع ما من الترحيل، وننشئ فهرسًا هناك، وننفذ ANALAZE هناك. وننظر إلى ما حدث قبل الفراغ وبعد الفراغ. بشكل عام، أي SQL.
- إما أن نقوم بتغيير معلمة واحدة أو أكثر في ملف config. يمكننا أن نطلب منا التحقق، على سبيل المثال، من 100 قيمة في أمازون لقاعدة بياناتنا التي تبلغ تيرابايت. وفي غضون ساعات قليلة سوف تحصل على النتيجة. كقاعدة عامة، سوف يستغرق الأمر عدة ساعات لنشر قاعدة بيانات تيرابايت. ولكن هناك تصحيحًا قيد التطوير، لدينا سلسلة ممكنة، أي أنه يمكنك دائمًا استخدام نفس pgdata على نفس الخادم والتحقق منه. سيتم إعادة تشغيل Postgres وسيتم إعادة تعيين ذاكرة التخزين المؤقت. ويمكنك قيادة الحمولة.
- يصل الدليل مع مجموعة من الملفات المختلفة، بدءًا من لقطات pgالقانون الأساسي***. والشيء الأكثر إثارة للاهتمام هو pg_stat_statements، pg_stat_kcacke. هذان امتدادان يقومان بتحليل الطلبات. ولا يحتوي pg_stat_bgwriter على إحصائيات pgwriter فحسب، بل يحتوي أيضًا على نقاط التفتيش وكيف تحل الواجهات الخلفية نفسها محل المخازن المؤقتة القذرة. وكل ذلك مثير للاهتمام. على سبيل المثال، عندما نقوم بإعداد Shared_Buffers، من المثير للاهتمام أن نرى مقدار استبدال الجميع.
- سجلات Postgres تصل أيضًا. سجلان - سجل التحضير وسجل تشغيل التحميل.
- ميزة جديدة نسبيًا هي FlameGraphs.
- أيضًا، إذا استخدمت خيارات pgreplay أو pgbench لتشغيل التحميل، فسيكون مخرجاتها أصلية. وسوف ترى الكمون وTPS. سيكون من الممكن أن نفهم كيف رأوا ذلك.
- معلومات النظام.
- فحوصات وحدة المعالجة المركزية ووحدة الإدخال والإخراج الأساسية. ينطبق هذا أكثر على مثيل EC2 في Amazon، عندما تريد تشغيل 100 مثيل متطابق في سلسلة رسائل وتشغيل 100 عملية تشغيل مختلفة هناك، فسيكون لديك 10 تجربة. وتحتاج إلى التأكد من عدم مواجهتك لمثال معيب تم قمعه بالفعل من قبل شخص ما. ينشط آخرون على هذه القطعة من الأجهزة ولم يتبق لديك سوى القليل من الموارد. من الأفضل تجاهل مثل هذه النتائج. وبمساعدة sysbench من Alexey Kopytov، نقوم بإجراء العديد من الفحوصات القصيرة التي ستأتي ويمكن مقارنتها مع الآخرين، أي سوف تفهم كيف تتصرف وحدة المعالجة المركزية وكيف يتصرف IO.
ما هي الصعوبات التقنية بناءً على مثال الشركات المختلفة؟
لنفترض أننا نريد تكرار الحمل الحقيقي باستخدام السجلات. إنها فكرة رائعة إذا كانت مكتوبة على pgreplay مفتوح المصدر. نحن نستخدمه. ولكن لكي يعمل بشكل جيد، يجب عليك تمكين تسجيل الاستعلام الكامل باستخدام المعلمات والتوقيت.
هناك بعض التعقيدات المتعلقة بالمدة والطابع الزمني. سنقوم بإفراغ هذا المطبخ بأكمله السؤال الرئيسي هو هل تستطيع تحمله أم لا؟
المشكلة هي أنه قد لا يكون متاحا. بادئ ذي بدء، يجب أن تفهم ما الدفق الذي سيتم كتابته في السجل. إذا كان لديك pg_stat_statements، فيمكنك استخدام هذا الاستعلام (سيكون الرابط متاحًا في الشرائح) لفهم عدد البايتات التي سيتم كتابتها في الثانية تقريبًا.
نحن ننظر إلى طول الطلب. نحن نتجاهل حقيقة عدم وجود معلمات، ولكننا نعرف طول الطلب ونعرف عدد مرات تنفيذه في الثانية. بهذه الطريقة يمكننا تقدير عدد البايتات في الثانية تقريبًا. قد نخطئ مرتين، لكننا بالتأكيد سنفهم الترتيب بهذه الطريقة.
يمكننا أن نرى أنه يتم تنفيذ هذا الطلب 802 مرة في الثانية. ونرى أنه سيتم كتابة bytes_per sec – 300 كيلو بايت/ ثانية زائد أو ناقص. وكقاعدة عامة، يمكننا تحمل مثل هذا التدفق.
لكن! والحقيقة هي أن هناك أنظمة تسجيل مختلفة. وعادة ما يكون الإعداد الافتراضي للأشخاص هو "سجل النظام".
وإذا كان لديك سجل نظام، فقد تكون لديك صورة كهذه. سنستخدم pgbench، ونقوم بتمكين تسجيل الاستعلام ونرى ما سيحدث.
بدون تسجيل - هذا هو العمود الموجود على اليسار. لقد حصلنا على 161 TPS. مع سجل النظام - هذا في Ubuntu 000 على Amazon، نحصل على 16.04 TPS. وإذا قمنا بالتغيير إلى طريقتين أخريين للتسجيل، فسيكون الوضع أفضل بكثير. أي أننا توقعنا أن ينخفض، ولكن ليس بنفس الدرجة.
وفي CentOS 7، الذي يشارك فيه Journald أيضًا، حيث يحول السجلات إلى تنسيق ثنائي لسهولة البحث، وما إلى ذلك، إنه كابوس هناك، حيث نسقط 44 مرة في TPS.
وهذا ما يعيشه الناس. وغالبًا ما يكون من الصعب جدًا تغيير هذا في الشركات، وخاصة الكبيرة منها. إذا كان بإمكانك الابتعاد عن سجل النظام، فيرجى الابتعاد عنه.
- تقييم IOPS وكتابة التدفق.
- تحقق من نظام التسجيل الخاص بك.
- إذا كان الحمل المتوقع كبيرًا جدًا، ففكر في أخذ العينات.
لدينا pg_stat_statements. وكما قلت، يجب أن يكون هناك. ويمكننا أخذ ووصف كل مجموعة من الطلبات بطريقة خاصة في ملف. وبعد ذلك يمكننا استخدام ميزة مريحة للغاية في pgbench - وهي القدرة على إدراج عدة ملفات باستخدام الخيار "-f".
إنه يفهم الكثير من "-f". ويمكنك معرفة بمساعدة "@" في النهاية ما هي المشاركة التي يجب أن يمتلكها كل ملف. وهذا هو، يمكننا أن نقول أن تفعل ذلك في 10٪ من الحالات، وهذا في 20٪. وهذا سيقربنا مما نراه في الإنتاج.
كيف سنفهم ما لدينا في الإنتاج؟ ما المشاركة وكيف؟ هذا جانبا قليلا. لدينا منتج آخر . أيضا قاعدة في المصدر المفتوح. ونحن الآن نعمل على تطويره بنشاط.
لقد ولد لأسباب مختلفة قليلاً. لأسباب أن المراقبة ليست كافية. أي أنك تأتي وتنظر إلى القاعدة وتنظر إلى المشاكل الموجودة. وكقاعدة عامة، تقوم بإجراء فحص صحي. إذا كنت من ذوي الخبرة في DBA، فعليك إجراء فحص صحي. لقد نظرنا في استخدام الفهارس، وما إلى ذلك. إذا كان لديك OKmeter، فهذا رائع. هذه مراقبة رائعة لـ Postgres. OKmeter.io – الرجاء تثبيته، كل شيء يتم بشكل جيد للغاية هناك. انها مدفوعة.
إذا لم يكن لديك واحدة، فعادةً لا يكون لديك الكثير. في المراقبة، عادةً ما تكون هناك وحدة المعالجة المركزية (CPU) ووحدة الإدخال والإخراج (IO) ثم التحفظات، وهذا كل شيء. ونحن بحاجة إلى المزيد. نحتاج أن نرى كيف يعمل الفراغ التلقائي، وكيف تعمل نقطة التفتيش، وفي io نحتاج إلى فصل نقطة التفتيش عن bgwriter وعن الواجهات الخلفية، وما إلى ذلك.
المشكلة هي أنه عندما تساعد شركة كبيرة، فإنها لا تستطيع تنفيذ شيء ما بسرعة. لا يمكنهم شراء OKmeter بسرعة. ربما سوف يشترونه في ستة أشهر. لا يمكنهم تسليم بعض الطرود بسرعة.
وتوصلنا إلى فكرة أننا بحاجة إلى أداة خاصة لا تتطلب تثبيت أي شيء، أي أنه ليس عليك تثبيت أي شيء على الإطلاق عند الإنتاج. قم بتثبيته على الكمبيوتر المحمول الخاص بك، أو على خادم مراقبة حيث سيتم تشغيله. وسوف يحلل الكثير من الأشياء: نظام التشغيل، ونظام الملفات، وPostgres نفسه، وإجراء بعض الاستعلامات الخفيفة التي يمكن تشغيلها مباشرة إلى الإنتاج ولن يفشل أي شيء.
لقد أطلقنا عليه اسم فحص Postgres. من الناحية الطبية، هذا فحص صحي منتظم. إذا كان الأمر يتعلق بالسيارات، فهو مثل الصيانة. تقوم بصيانة سيارتك كل ستة أشهر أو سنة حسب العلامة التجارية. هل تقومون بالصيانة لقاعدتكم؟ بمعنى هل تقوم بإجراء بحث عميق بانتظام؟ يجب ان يتم ذلك. إذا قمت بعمل نسخ احتياطية، فقم بإجراء فحص، فهذا لا يقل أهمية.
ولدينا مثل هذه الأداة. بدأت في الظهور بنشاط منذ حوالي ثلاثة أشهر فقط. إنه لا يزال شابًا، ولكن هناك الكثير هناك.
جمع مجموعات الاستعلامات الأكثر "تأثيرًا" - تقرير K003 في فحص Postgres
وهناك مجموعة من التقارير ك. ثلاثة تقارير حتى الآن. وهناك مثل هذا التقرير K003. هناك الجزء العلوي من pg_stat_statements، مرتبة حسب Total_time.
عندما نقوم بفرز مجموعات الطلبات حسب Total_time، نرى في الأعلى المجموعة التي تقوم بتحميل نظامنا أكثر من غيرها، أي تستهلك المزيد من الموارد. لماذا أقوم بتسمية مجموعات الاستعلام؟ لأننا طردنا المعلمات. لم تعد هذه طلبات، بل مجموعات من الطلبات، أي أنها مجردة.
وإذا قمنا بالتحسين من الأعلى إلى الأسفل، فسوف نقوم بتخفيف مواردنا وتأخير اللحظة التي نحتاج فيها إلى الترقية. هذه طريقة جيدة جدًا لتوفير المال.
ربما لا تكون هذه طريقة جيدة جدًا للعناية بالمستخدمين، لأننا قد لا نرى حالات نادرة ولكنها مزعجة للغاية حيث ينتظر الشخص 15 ثانية. في المجمل، فهي نادرة جدًا لدرجة أننا لا نراها، لكننا نتعامل مع الموارد.
ماذا حدث في هذا الجدول؟ لقد التقطنا صورتين. سوف يمنحك Postgres_checkup دلتا لكل مقياس: الوقت الإجمالي، والمكالمات، والصفوف، وshared_blks_read، وما إلى ذلك. هذا كل شيء، لقد تم حساب الدلتا. المشكلة الكبيرة في pg_stat_statements هي أنها لا تتذكر متى تمت إعادة تعيينها. إذا تذكرت pg_stat_database، فلن تتذكر pg_stat_statements. ترى أن هناك رقمًا قدره 1، لكننا لا نعرف من أين أحصيناه.
وهنا نعلم أن لدينا هنا لقطتين. نحن نعلم أن الدلتا في هذه الحالة كانت 56 ثانية. فجوة قصيرة جداً. مرتبة حسب Total_time. وبعد ذلك يمكننا التمييز، أي نقسم جميع المقاييس على المدة. إذا قسمنا كل مقياس على المدة، فسنحصل على عدد المكالمات في الثانية.
بعد ذلك، Total_time في الثانية هو المقياس المفضل لدي. يتم قياسها بالثواني، في الثانية، أي عدد الثواني التي استغرقها نظامنا لتنفيذ هذه المجموعة من الطلبات في الثانية. إذا رأيت أكثر من ثانية في الثانية هناك، فهذا يعني أنه كان عليك إعطاء أكثر من نواة واحدة. وهذا مقياس جيد جدًا. يمكنك أن تفهم أن هذا الصديق، على سبيل المثال، يحتاج إلى ثلاثة نوى على الأقل.
هذه هي خبرتنا، ولم أر شيئًا مثل ذلك في أي مكان. يرجى ملاحظة - هذا شيء بسيط للغاية - ثانية في الثانية. في بعض الأحيان، عندما تكون وحدة المعالجة المركزية لديك 100%، فإنك تستغرق نصف ساعة في الثانية، أي أنك تقضي نصف ساعة في تنفيذ هذه الطلبات فقط.
بعد ذلك نرى صفوفًا في الثانية. نحن نعرف عدد الصفوف التي يتم إرجاعها في الثانية.
ثم هناك أيضًا شيء مثير للاهتمام. كم عدد المخزن المؤقت المشترك الذي نقرأه في الثانية من المخزن المؤقت المشترك نفسه. كانت النتائج موجودة بالفعل، وقمنا بأخذ الصفوف من ذاكرة التخزين المؤقت لنظام التشغيل أو من القرص. الخيار الأول سريع، والثاني قد يكون أو لا يكون سريعًا، حسب الموقف.
والطريقة الثانية للتمايز هي تقسيم عدد الطلبات في هذه المجموعة. في العمود الثاني، سيكون لديك دائمًا استعلام واحد مقسم لكل استعلام. ثم إنه أمر مثير للاهتمام - كم عدد المللي ثانية الموجودة في هذا الطلب. نحن نعرف كيف يتصرف هذا الاستعلام في المتوسط. كان مطلوبًا 101 مللي ثانية لكل طلب. هذا هو المقياس التقليدي الذي نحتاج إلى فهمه.
كم عدد الصفوف التي أعادها كل استعلام في المتوسط؟ نرى 8 عودة هذه المجموعة. في المتوسط، كم تم أخذه من ذاكرة التخزين المؤقت وقراءته. نرى أن كل شيء تم تخزينه مؤقتًا بشكل جيد. ضربات قوية للمجموعة الأولى.
والسلسلة الفرعية الرابعة في كل سطر هي النسبة المئوية من الإجمالي. لدينا مكالمات. لنفترض 1. ويمكننا أن نفهم المساهمة التي تقدمها هذه المجموعة. نرى أنه في هذه الحالة تساهم المجموعة الأولى بأقل من 000%. أي أنها بطيئة جدًا لدرجة أننا لا نراها في الصورة العامة. والمجموعة الثانية 000% على المكالمات. أي أن 0,01% من إجمالي المكالمات هي للمجموعة الثانية.
Total_time مثير للاهتمام أيضًا. لقد أمضينا 14% من إجمالي وقت العمل في المجموعة الأولى من الطلبات. والثاني - 11٪ وهكذا.
لن أخوض في التفاصيل، ولكن هناك بعض التفاصيل الدقيقة هناك. نعرض خطأ في الأعلى، لأنه عند المقارنة، قد تطفو اللقطات، أي أن بعض الطلبات قد تسقط ولا يمكن أن تكون موجودة في الثانية، في حين قد تظهر بعض الطلبات الجديدة. وهناك نحسب الخطأ. إذا رأيت 0 فهذا جيد. لا توجد أخطاء. إذا كان معدل الخطأ يصل إلى 20%، فلا بأس.
ثم نعود إلى موضوعنا. نحن بحاجة إلى صياغة عبء العمل. نأخذها من الأعلى إلى الأسفل ونذهب حتى نصل إلى 80% أو 90%. عادة ما يكون هذا 10-20 مجموعة. ونقوم بإنشاء ملفات لـ pgbench. نحن نستخدم عشوائي هناك. في بعض الأحيان، لسوء الحظ، لا يعمل. وفي Postgres 12 سيكون هناك المزيد من الفرص لاستخدام هذا النهج.
وبعد ذلك نكسب 80-90% في إجمالي الوقت بهذه الطريقة. ماذا يجب أن أضع بعد "@"؟ نحن ننظر إلى المكالمات وننظر إلى مقدار الاهتمام الموجود ونفهم أننا مدينون بالكثير من الاهتمام هنا. ومن هذه النسب يمكننا أن نفهم كيفية موازنة كل ملف من الملفات. بعد ذلك نستخدم pgbench ونذهب إلى العمل.
لدينا أيضًا K001 وK002.
K001 عبارة عن سلسلة كبيرة تحتوي على أربع سلاسل فرعية. هذه هي سمة حملنا بأكمله. انظر العمود الثاني والصف الفرعي الثاني. نرى ذلك حوالي ثانية ونصف في الثانية، أي إذا كان هناك نواتان، فسيكون ذلك جيدًا. سيكون هناك ما يقرب من 75٪ من السعة. وسوف تعمل مثل هذا. إذا كان لدينا 10 نوى، فسنكون هادئين بشكل عام. بهذه الطريقة يمكننا تقييم الموارد.
K002 هو ما أسميه فئات الاستعلام، أي SELECT، INSERT، UPDATE، DELETE. وبشكل منفصل حدد للتحديث، لأنه قفل.
وهنا يمكننا أن نستنتج أن SELECT هو القراء العاديين - 82٪ من جميع المكالمات، ولكن في نفس الوقت - 74٪ في Total_time. وهذا هو، يتم استدعاؤها كثيرا، ولكنها تستهلك موارد أقل.
ونعود إلى السؤال: “كيف يمكننا اختيار المخازن المؤقتة المشتركة المناسبة؟” ألاحظ أن معظم المعايير تعتمد على الفكرة - دعونا نرى ما سيكون عليه الإنتاجية، أي ما سيكون عليه الإنتاجية. يتم قياسه عادةً بـ TPS أو QPS.
ونحاول استخراج أكبر عدد ممكن من المعاملات في الثانية من السيارة باستخدام معلمات الضبط. هنا بالضبط 311 في الثانية للاختيار.
لكن لا أحد يقود سيارته إلى العمل ويعود إلى المنزل بأقصى سرعة. هذا سخيف. الشيء نفسه مع قواعد البيانات. ليس علينا القيادة بأقصى سرعة، ولا أحد يفعل ذلك. لا أحد يعيش في منطقة إنتاج بها وحدة معالجة مركزية 100%. على الرغم من أنه ربما يعيش شخص ما، لكنه ليس جيدا.
الفكرة هي أننا عادة نقود بنسبة 20% من طاقتنا، ويفضل ألا تزيد عن 50%. ونحن نحاول تحسين وقت الاستجابة لمستخدمينا قبل كل شيء. وهذا يعني أننا يجب أن ندير المقابض بحيث يكون هناك حد أدنى من الكمون عند سرعة 20%، بشروط. وهذه فكرة نحاول أيضًا استخدامها في تجاربنا.
وأخيرا التوصيات:
- تأكد من القيام بمختبر قاعدة البيانات.
- إذا كان ذلك ممكنا، افعل ذلك عند الطلب بحيث تتكشف لفترة من الوقت - العب ورميها بعيدا. إذا كان لديك غيوم، فهذا أمر بديهي، أي أن لديك مكانة كبيرة.
- كن فضولى. وإذا كان هناك خطأ ما، تحقق من التجارب كيف يتصرف. يمكن استخدام نانسي لتدريب نفسك على التحقق من كيفية عمل القاعدة.
- وتهدف إلى الحد الأدنى من وقت الاستجابة.
- ولا تخافوا من مصادر Postgres. عندما تعمل مع المصادر، يجب أن تعرف اللغة الإنجليزية. هناك الكثير من التعليقات هناك، كل شيء موضح هناك.
- وتحقق من صحة قاعدة البيانات بانتظام، مرة واحدة على الأقل كل ثلاثة أشهر، يدويًا، أو فحص Postgres.
الأسئلة
شكرًا جزيلاً! شيء مثير للاهتمام للغاية.
قطعتان.
نعم قطعتين. فقط أنا لم أفهم تماما. عندما نعمل أنا ونانسي، هل يمكننا تعديل معلمة واحدة فقط أو مجموعة كاملة؟
لدينا معلمة التكوين دلتا. يمكنك التوجه إلى هناك بقدر ما تريد مرة واحدة. لكن عليك أن تفهم أنه عندما تغير الكثير من الأشياء، يمكنك استخلاص استنتاجات خاطئة.
نعم. لماذا سألت؟ لأنه من الصعب إجراء التجارب عندما يكون لديك معلمة واحدة فقط. قم بتشديده، وانظر كيف يعمل. لقد أخرجته. ثم تبدأ التالي.
يمكنك تشديده في نفس الوقت، لكن ذلك يعتمد على الوضع بالطبع. ولكن من الأفضل اختبار فكرة واحدة. كانت لدينا فكرة بالأمس. كان لدينا موقف قريب جدا. كان هناك نوعان من التكوينات. ولم نتمكن من فهم سبب وجود فرق كبير. وقد نشأت فكرة أنك بحاجة إلى استخدام الانقسام من أجل فهم الفرق والعثور عليه باستمرار. يمكنك على الفور جعل نصف المعلمات متماثلة، ثم الربع، وما إلى ذلك. كل شيء مرن.
وهناك سؤال آخر. المشروع شاب ومتطور. الوثائق جاهزة بالفعل، هل هناك وصف تفصيلي؟
لقد قمت على وجه التحديد بإنشاء رابط لوصف المعلمات. انه هنا. لكن الكثير من الأشياء لم تصل بعد. أنا أبحث عن الناس مثل التفكير. وأجدهم عندما أؤدي. هذا هو بارد جدا. شخص ما يعمل معي بالفعل، ساعد شخص ما وفعل شيئا هناك. وإذا كنت مهتما بهذا الموضوع، فقم بإعطاء ملاحظات حول ما هو مفقود.
بمجرد أن نبني المختبر، ربما ستكون هناك ردود فعل. دعنا نرى. شكرًا لك!
مرحبًا! شكرا على التقرير! رأيت أن هناك دعم أمازون. هل هناك أي خطط لدعم نظام الأفضليات المعمم؟
سؤال جيد. بدأنا في القيام بذلك. وقمنا بتجميدها الآن لأننا نريد توفير المال. أي أن هناك دعمًا لاستخدام التشغيل على المضيف المحلي. يمكنك إنشاء مثيل بنفسك والعمل محليًا. بالمناسبة، هذا ما نفعله. أفعل هذا في Getlab، هناك في GSP. ولكننا لا نرى أي فائدة من إجراء مثل هذا التنسيق حتى الآن، لأن جوجل ليس لديها أماكن رخيصة. هنالك ؟؟؟ الحالات، ولكن لها حدود. أولاً، لديهم دائمًا خصم بنسبة 70% فقط ولا يمكنك اللعب بالسعر هناك. في المواقع، نقوم بزيادة السعر بنسبة 5-10% لتقليل احتمالية طردك. وهذا هو، يمكنك حفظ المواقع، ولكن يمكن أن تؤخذ منك في أي وقت. إذا قمت بالمزايدة أعلى قليلاً من الآخرين، فسوف تُقتل لاحقًا. لدى Google تفاصيل مختلفة تمامًا. وهناك قيد آخر سيء للغاية - فهم يعيشون لمدة 24 ساعة فقط. وأحيانًا نرغب في إجراء تجربة لمدة 5 أيام. ولكن يمكنك القيام بذلك في البقع، حيث تستمر البقع في بعض الأحيان لعدة أشهر.
مرحبًا! شكرا على التقرير! لقد ذكرت الفحص. كيف يمكنك حساب أخطاء stat_statements؟
سؤال جيد جدا. يمكنني أن أعرض وأخبرك بتفصيل كبير. باختصار، نحن ننظر إلى كيفية تعويم مجموعة مجموعات الطلب: كم عدد المجموعات التي سقطت وعدد المجموعات الجديدة التي ظهرت. ثم ننظر إلى مقياسين: إجمالي الوقت والمكالمات، لذلك هناك خطأان. ونحن ننظر إلى مساهمة المجموعات العائمة. هناك مجموعتان فرعيتان: أولئك الذين غادروا والذين وصلوا. دعونا نرى ما هي مساهمتهم في الصورة العامة.
ألا تخشى أن يتحول إلى هناك مرتين أو ثلاث مرات خلال الفترة الفاصلة بين اللقطات؟
يعني هل سجلوا مرة أخرى أم ماذا؟
على سبيل المثال، سبق أن تم استباق هذا الطلب مرة واحدة، ثم جاء وتم استباقه مرة أخرى، ثم جاء مرة أخرى وتم استباقه مرة أخرى. وقمت بحساب شيء هنا، وأين هو كل شيء؟
سؤال جيد، علينا أن ننظر.
فعلت شيئا مماثلا. لقد كان الأمر أسهل، بالطبع، لقد فعلت ذلك بمفردي. ولكن كان عليّ إعادة ضبط البيانات الإحصائية وإعادة ضبطها ومعرفة وقت التقاط اللقطة أن هناك أقل من جزء معين، والذي لم يصل بعد إلى الحد الأقصى لعدد البيانات الإحصائية التي يمكن أن تتراكم هناك. وما أفهمه هو أنه على الأرجح لم يتم تهجير أي شيء.
نعم نعم.
لكنني لا أفهم كيفية القيام بذلك بشكل موثوق.
لسوء الحظ، لا أتذكر بالضبط ما إذا كنا نستخدم نص الاستعلام هناك أو معرف الاستعلام مع pg_stat_statements ونركز عليه. إذا ركزنا على queryid، فمن الناحية النظرية فإننا نقارن أشياء قابلة للمقارنة.
لا، يمكن إجباره على الخروج عدة مرات بين اللقطات ثم العودة مرة أخرى.
بنفس المعرف؟
نعم.
سوف ندرس هذا. سؤال جيد. نحن بحاجة لدراستها. لكن في الوقت الحالي، ما نراه هو إما مكتوب 0...
هذه، بالطبع، حالة نادرة، لكنني صدمت عندما اكتشفت أن stat_statemetns يمكن أن يتم إزاحتها هناك.
يمكن أن يكون هناك أشياء كثيرة في Pg_stat_statements. لقد توصلنا إلى حقيقة أنه إذا كان لديك Track_utility = قيد التشغيل، فسيتم تتبع مجموعاتك أيضًا.
نعم، بالطبع.
وإذا كان لديك Java Hibernate، وهو عشوائي، فسيبدأ تحديد موقع جدول التجزئة هناك. وبمجرد إيقاف تشغيل تطبيق محمل للغاية، ينتهي بك الأمر مع 50-100 مجموعة. وكل شيء أكثر أو أقل استقرارًا هناك. إحدى طرق مكافحة ذلك هي زيادة pg_stat_statements.max.
نعم، ولكن عليك أن تعرف كم. وبطريقة ما نحن بحاجة إلى مراقبته. هذا ما افعله. أي أن لدي pg_stat_statements.max. وأرى أنني في وقت اللقطة لم أكن قد وصلت إلى 70%. حسنًا، نحن لم نخسر شيئًا. دعونا إعادة تعيين. ونحفظ مرة أخرى. إذا كانت اللقطة التالية أقل من 70، فمن المرجح أنك لم تفقد أي شيء مرة أخرى.
نعم. الافتراضي الآن هو 5. وهذا يكفي لكثير من الناس.
عادة نعم.
فيديو:
ملاحظة: بالأصالة عن نفسي، سأضيف أنه إذا كان Postgres يحتوي على بيانات سرية ولا يمكن تضمينها في بيئة الاختبار، فيمكنك استخدامها . المخطط تقريبًا كما يلي:
المصدر: www.habr.com