أقترح قراءة نص تقرير بداية عام 2016 بواسطة Andrey Salnikov "الأخطاء النموذجية في التطبيقات التي تؤدي إلى الانتفاخ في postgresql"
في هذا التقرير ، سوف أقوم بتحليل الأخطاء الرئيسية في التطبيقات التي تحدث في مرحلة تصميم وكتابة كود التطبيق. وسأقبل فقط تلك الأخطاء التي تؤدي إلى الانتفاخ في Postgresql. كقاعدة عامة ، هذه هي بداية نهاية أداء نظامك ككل ، على الرغم من عدم وجود متطلبات مسبقة لذلك في البداية.
سعيد للترحيب بالجميع! هذا التقرير ليس تقنيًا مثل التقرير السابق من زميلي. يستهدف هذا التقرير مطوري الأنظمة الخلفية بشكل أساسي لأن لدينا عددًا كبيرًا من العملاء. وجميعهم يرتكبون نفس الأخطاء. سأخبرك عنهم. سأشرح ما تؤدي إليه هذه الأخطاء القاتلة والسيئة.
لماذا ترتكب الاخطاء؟ يتم إجراؤها لسببين: عشوائيًا ، ربما ستعمل بسبب الجهل ببعض الآليات التي تحدث على المستوى بين القاعدة والتطبيق ، وكذلك في القاعدة نفسها.
سأعطيكم ثلاثة أمثلة بصور مروعة عن كيف ساءت الأمور. سوف أصف بإيجاز الآلية التي تحدث هناك. وكيفية التعامل معها ، ومتى حدثت ، وما هي الأساليب الوقائية التي يجب اتباعها لمنع الأخطاء. سأخبرك عن الأدوات المساعدة وأعطيك روابط مفيدة.
لقد استخدمت قاعدة بيانات اختبار حيث كان لدي جدولين. لوحة بها حسابات العملاء ، والأخرى بها عمليات على هذه الحسابات. ومع بعض التواتر ، نقوم بتحديث الأرصدة في هذه الحسابات.
البيانات الأولية للوحة: صغيرة جدا ، 2 ميغا بايت. كما أن وقت الاستجابة لقاعدة البيانات وتحديدًا للوحة جيدة جدًا. وحمل جيد إلى حد ما - 2 عملية في الثانية على اللوحة.
ومن خلال هذا التقرير ، سأعرض عليكم الرسوم البيانية بحيث يتضح ما يحدث. سيكون هناك دائمًا شريحتان بهما رسوم بيانية. الشريحة الأولى هي ما يحدث بشكل عام على الخادم.
وفي هذه الحالة ، نرى أن لدينا بالفعل طبقًا صغيرًا. الفهرس صغير بحجم 2 ميغا بايت. هذا هو الرسم البياني الأول على اليسار.
متوسط وقت الاستجابة عبر الخادم أيضًا مستقر وصغير. هذا هو أعلى الرسم البياني الأيمن.
الرسم البياني السفلي الأيسر هو أطول المعاملات. يمكننا أن نرى أن المعاملات يتم الانتهاء منها بسرعة. والفراغ التلقائي لا يعمل هنا بعد ، لأنه - كان اختبارًا للبدء. ثم ستعمل وتكون مفيدة لنا.
ستخصص الشريحة الثانية دائمًا للوحة الاختبار. في هذه الحالة ، نقوم بتحديث أرصدة حساب العميل باستمرار. ونلاحظ أن متوسط وقت الاستجابة لعملية التحديث جيد جدًا ، أقل من ملي ثانية. نرى أن موارد المعالج (هذا هو الرسم البياني الأيمن العلوي) يتم استهلاكها أيضًا بشكل متساوٍ وصغير جدًا.
يوضح الرسم البياني السفلي الأيمن مقدار ذاكرة التشغيل والقرص التي نمر بها بحثًا عن الخط المطلوب قبل تحديثه. وعدد العمليات على اللوح 2 عملية في الثانية كما قلت في البداية.
والآن لدينا مأساة. لسبب ما ، تحدث صفقة منسية منذ فترة طويلة. عادة ما تكون الأسباب كلها عادية:
- أحد أكثرها شيوعًا هو أننا بدأنا في الوصول إلى خدمة خارجية في كود التطبيق. وهذه الخدمة لا ترد علينا. أي أننا فتحنا معاملة ، وأجرينا تغييرًا في قاعدة البيانات وانتقلنا من التطبيق لقراءة البريد أو إلى خدمة أخرى داخل بنيتنا التحتية ، ولسبب ما لم يرد علينا. وجلستنا معلقة في حالة - لا يعرف متى سيتم حلها.
- الموقف الثاني هو عندما حدث استثناء في الكود الخاص بنا لسبب ما. ولم نقم بمعالجة إغلاق الصفقة في الاستثناء. وحصلنا على جلسة معلقة بصفقة مفتوحة.
- والأخير شائع جدًا أيضًا. هذا هو رمز جودة رديئة. بعض الأطر تفتح صفقة. إنه معلق ، وقد لا تعرف في التطبيق أنه لديك معلق.
إلى أين تقود مثل هذه الأشياء؟
إلى حقيقة أن جداولنا وفهارسنا بدأت تتضخم بشكل كبير. هذا هو بالضبط نفس تأثير الانتفاخ. بالنسبة لقاعدة البيانات ، سيتم التعبير عن ذلك في حقيقة أنه سيكون لدينا زيادة حادة جدًا في وقت استجابة قاعدة البيانات ، وسيزداد الحمل على خادم قاعدة البيانات. ونتيجة لذلك ، سيعاني تطبيقنا. لأنه إذا قضيت 10 مللي ثانية في التعليمات البرمجية الخاصة بك على طلب إلى قاعدة البيانات ، و 10 مللي ثانية على منطقك ، فإن وظيفتك عملت على 20 مللي ثانية. والآن سيكون وضعك محزنًا جدًا.
ودعونا نرى ما سيحدث. يوضح الرسم البياني الأيسر السفلي أن لدينا صفقة شراء طويلة. وإذا نظرنا إلى الرسم البياني الأيسر العلوي ، نلاحظ أن حجم الجدول قفز من 300 ميغا بايت إلى XNUMX ميغا بايت. في الوقت نفسه ، لم يتغير حجم البيانات في الجدول ، أي أن هناك كمية كبيرة إلى حد ما من القمامة.
الوضع العام من حيث متوسط وقت استجابة الخادم قد تغير أيضًا بعدة أوامر من حيث الحجم. أي أن جميع الطلبات الموجودة على الخادم بدأت في الترهل تمامًا. وفي الوقت نفسه ، تم إطلاق عمليات Postgres الداخلية في مواجهة الفراغ التلقائي ، والتي تحاول القيام بشيء ما واستهلاك الموارد.
ماذا يحدث لطبقنا؟ نفس الشيء. قفز متوسط وقت الاستجابة على الجهاز اللوحي عدة مرات من حيث الحجم. إذا كان على وجه التحديد من حيث الموارد المستهلكة ، فإننا نرى أن الحمل على المعالج قد زاد بشكل كبير. هذا هو أعلى الرسم البياني الأيمن. وقد زاد لأن المعالج يجب أن يمر عبر مجموعة من الخطوط غير المجدية بحثًا عن الخط الذي تحتاجه. هذا هو الرسم البياني الأيمن السفلي. ونتيجة لذلك ، بدأ عدد المكالمات في الثانية في الانخفاض كثيرًا ، لأن قاعدة البيانات لا تملك الوقت لمعالجة نفس العدد من الطلبات.
نحن بحاجة للعودة إلى الحياة. نتسلق الإنترنت ونكتشف أن المعاملات الطويلة تؤدي إلى مشكلة. نجد هذه الصفقة ونقتلها. وكل شيء يسير على ما يرام بالنسبة لنا. كل شيء يعمل على مايرام.
هدأنا ، لكن بعد فترة بدأنا نلاحظ أن التطبيق لا يعمل كما كان قبل الطوارئ. تتم معالجة الطلبات بشكل أبطأ وببطء أكثر. أبطأ مرة ونصف إلى مرتين على وجه التحديد في المثال الخاص بي. كما أن الحمل على الخادم أعلى مما كان عليه قبل وقوع الحادث.
والسؤال: "ماذا يحدث للقاعدة في هذه اللحظة؟". ومع وجود أساس هناك الحالة التالية. في مخطط المعاملة ، يمكنك أن ترى أنه قد توقف ولا توجد بالفعل معاملات طويلة الأجل. لكن أبعاد اللوحة أثناء الحادث نمت بشكل مميت. ولم ينخفض منذ ذلك الحين. استقر متوسط الوقت على القاعدة. ويبدو أن الإجابات تسير بشكل مناسب وبسرعة مقبولة بالنسبة لنا. أصبح الفراغ التلقائي أكثر نشاطًا وبدأ في عمل شيء ما مع الجهاز اللوحي ، لأنه يحتاج إلى تجريف المزيد من البيانات.
على وجه التحديد ، في لوحة نتائج الاختبار ، حيث نقوم بتغيير الأرصدة: يبدو أن وقت الاستجابة للطلب قد عاد إلى طبيعته. لكنها في الواقع أعلى مرة ونصف.
ومن خلال الحمل على المعالج ، نرى أن الحمل على المعالج لم يعد إلى القيمة المطلوبة قبل الانهيار. وتكمن أسباب ذلك في الرسم البياني الأيمن السفلي. يمكن ملاحظة أن هناك بحثًا عن قدر من الذاكرة. أي للبحث عن السطر المطلوب ، ننفق موارد خادم قاعدة البيانات عند الفرز من خلال البيانات غير المفيدة. استقر عدد المعاملات في الثانية.
بشكل عام جيد لكن الوضع أسوأ مما كان عليه. تدهور صريح لقاعدة البيانات كنتيجة لتطبيقنا الذي يعمل مع قاعدة البيانات هذه.
ومن أجل فهم ما يحدث هناك ، إذا لم تكن في التقرير السابق ، فلدينا الآن القليل من النظرية. نظرية العملية الداخلية. لماذا الفراغ الذاتي وماذا يفعل؟
حرفيا باختصار لفهم. في وقت ما لدينا طاولة. لدينا صفوف في الجدول. يمكن أن تكون هذه الخطوط نشطة ، حية ، نحتاجها الآن. تم تمييزها باللون الأخضر في الصورة. وهناك مواعيد نهائية تم العمل عليها بالفعل ، وتم تحديثها ، وظهرت إدخالات جديدة عليها. ويتم تمييزهم بأنهم لم يعودوا مهتمين بقاعدة البيانات. لكنهم يرقدون على الطاولة بسبب خصائص Postgres.
لماذا تحتاج إلى مكنسة كهربائية؟ يأتي Autovacuum في مرحلة ما ، ويستدعي قاعدة البيانات ويسألها: "من فضلك أعطني معرف أقدم معاملة مفتوحة حاليًا في قاعدة البيانات." تقوم قاعدة البيانات بإرجاع هذا المعرف. والفراغ التلقائي ، بالاعتماد عليه ، يمر عبر الخطوط الموجودة في الجدول. وإذا رأى أن بعض السطور قد تم تغييرها من خلال معاملات قديمة ، فيحق له وضع علامة عليها كخطوط يمكننا إعادة استخدامها في المستقبل عن طريق كتابة بيانات جديدة هناك. هذه عملية خلفية.
في هذا الوقت ، نواصل العمل مع قاعدة البيانات ، ونستمر في إجراء بعض التغييرات في الجدول. وعلى هذه السطور ، التي يمكننا إعادة استخدامها ، نكتب بيانات جديدة. وبهذه الطريقة نحصل على دورة ، أي أن بعض الأسطر القديمة الميتة تظهر هناك طوال الوقت ، بدلاً من كتابة الأسطر الجديدة التي نحتاجها. وهذه هي الحالة الطبيعية لعمل PostgreSQL.
ماذا حدث خلال الحادث؟ كيف تمت هذه العملية؟
كان لدينا طبق في حالة ما ، وبعضها حي ، وبعض المواعيد الميتة. لقد وصل الفراغ التلقائي. سأل قاعدة البيانات عن أقدم معاملة لدينا ، وما هو معرفها. حصلت على هذا المعرف ، الذي يمكن أن يكون عمره عدة ساعات ، وربما عشر دقائق. يعتمد ذلك على مدى ثقل الحمل على قاعدة البيانات. وذهب للبحث عن الخطوط التي يمكنه تمييزها على أنها معاد استخدامها. ولم أجد مثل هذه الخطوط في طاولتنا.
لكن في هذا الوقت نواصل العمل مع الطاولة. نحن نفعل شيئًا فيه ، ونحدّثه ، ونغيّر البيانات. ما الذي يجب أن تفعله قاعدة البيانات في هذا الوقت؟ ليس لديها خيار سوى إضافة سطور جديدة إلى نهاية الجدول الحالي. وهكذا عندنا يبدأ حجم الطاولة بالتضخم.
نحتاج حقًا إلى خطوط خضراء للعمل. ولكن خلال هذه المشكلة ، اتضح أن نسبة الخطوط الخضراء منخفضة للغاية في الحجم الكلي للجدول.
وعندما ننفذ استعلامًا ، يجب أن تمر قاعدة البيانات عبر جميع الأسطر ، باللونين الأحمر والأخضر ، للعثور على السطر الصحيح. ويطلق على تأثير تضخيم الجدول ببيانات غير مفيدة اسم "bloat" ، والذي يستهلك أيضًا مساحة القرص لدينا. تذكر ، كان 2 ميغا ، والآن 300 ميغا؟ الآن قم بتغيير الميغابايت إلى جيجابايت وستفقد جميع موارد القرص بسرعة كبيرة.
ما هي الآثار المترتبة علينا؟
- في المثال الخاص بي ، نما الجدول والفهرس 150 مرة. تعرض بعض عملائنا لحالات أكثر خطورة عندما بدأت مساحة القرص في النفاد.
- لن تتقلص الجداول من تلقاء نفسها. يمكن أن يؤدي الفراغ التلقائي في بعض الحالات إلى قطع ذيل الطاولة إذا كان هناك خطوط ميتة فقط. ولكن نظرًا لوجود دوران مستمر ، فقد يتدلى خط أخضر واحد في النهاية ولا يتم تحديثه ، وسيتم تسجيل جميع الباقي في مكان ما في بداية اللوحة. لكن هذا حدث غير مرجح لدرجة أن طاولتك نفسها ستنخفض في الحجم ، لذلك لا يجب أن تأمل في ذلك.
- تحتاج قاعدة البيانات إلى الفرز عبر كومة الخطوط عديمة الفائدة بأكملها. ونحن نهدر موارد القرص ، ونهدر موارد المعالج والكهرباء.
- وهذا يؤثر بشكل مباشر على تطبيقنا ، لأنه إذا قضينا في البداية 10 مللي ثانية على طلب ، 10 مللي ثانية على الكود الخاص بنا ، ثم أثناء الانهيار ، بدأنا في قضاء ثانية على طلب و 10 مللي ثانية على الكود ، أي أمر انخفض حجم أداء التطبيق. وعندما تم حل الحادث ، بدأنا في إنفاق 20 مللي ثانية لكل طلب ، أي 10 مللي ثانية لكل كود. هذا يعني أننا ما زلنا نغرق مرة ونصف من حيث الأداء. وهذا كله بسبب صفقة واحدة معلقة ، وربما بسبب خطأنا.
- والسؤال: "كيف يمكنني استعادة كل شيء؟" حتى يكون كل شيء على ما يرام معنا ، وتعمل الطلبات بأسرع ما كانت قبل وقوع الحادث.
لهذا ، هناك دورة عمل معينة يتم تنفيذها.
نحتاج أولاً إلى إيجاد الجداول الإشكالية التي تضخمت. نحن نتفهم أن بعض الجداول تسجل بشكل أكثر نشاطًا ، وبعضها الآخر أقل نشاطًا. ولهذا نستخدم الامتداد . عن طريق تثبيت هذا الامتداد ، يمكنك كتابة استعلامات لمساعدتك في العثور على الجداول المتضخمة بدرجة كافية.
بمجرد العثور على هذه الجداول ، يجب ضغطها. توجد بالفعل أدوات لهذا الغرض. في شركتنا ، نستخدم ثلاث أدوات. الأول هو المدمج في فراغ كامل. إنه قاسٍ وقاسٍ ولا يرحم ، لكنه أحيانًا يكون مفيدًا جدًا. и هي أدوات مساعدة خارجية لضغط الجداول. وهم أكثر حرصًا بشأن قاعدة البيانات.
يتم استخدامها اعتمادًا على ما هو أكثر ملاءمة لك. لكنني سأتحدث عن هذا في النهاية. الشيء الرئيسي هو أن هناك ثلاث أدوات. هناك الكثير للاختيار من بينها.
بعد تصحيح كل شيء ، والتأكد من أن كل شيء على ما يرام ، يجب أن نعرف كيفية منع هذا الموقف في المستقبل:
- من السهل منعه إلى حد ما. تحتاج إلى مراقبة مدة الجلسات على الخادم الرئيسي. جلسات خطرة بشكل خاص في حالة الخمول في حالة المعاملة. هؤلاء هم أولئك الذين فتحوا للتو معاملة ، أو فعلوا شيئًا وتركوا ، أو ببساطة علقوا ، فقدوا في الكود.
- وبالنسبة لك ، كمطورين ، من المهم اختبار الكود في الوقت الذي تظهر فيه هذه المواقف. ليس من الصعب القيام به. سيكون هذا فحصًا مفيدًا. سوف تتجنب الكثير من المشاكل "الطفولية" المرتبطة بالمعاملات الطويلة.
في هذه الرسوم البيانية ، أردت أن أوضح لك كيف تغير الجدول وسلوك قاعدة البيانات بعد اجتياز VACUUM FULL على الجدول في هذه الحالة. هذا ليس إنتاجي.
عاد حجم الجدول على الفور إلى حالة العمل الطبيعية التي تبلغ بضعة ميغا بايت. لم يؤثر ذلك بشكل كبير على متوسط وقت الاستجابة عبر الخادم.
ولكن على وجه التحديد في جدول الاختبار الخاص بنا ، حيث قمنا بتحديث أرصدة الحسابات ، نرى أن متوسط وقت الاستجابة لطلب تحديث البيانات في الجهاز اللوحي قد انخفض إلى مستويات ما قبل الانهيار. كما انخفضت الموارد التي استهلكها المعالج لتنفيذ هذا الطلب إلى مستويات ما قبل الانهيار. ويوضح الرسم البياني السفلي الأيمن أننا وجدنا الآن الخط الذي نحتاجه بالضبط على الفور ، دون المرور عبر كومة الخطوط الميتة التي كانت قبل ضغط الجدول. وظل متوسط وقت الاستعلام عند نفس المستوى تقريبًا. لكن لدي هنا ، بدلاً من ذلك ، خطأ في أجهزتي.
هذا هو المكان الذي تنتهي فيه القصة الأولى. هي الأكثر شيوعًا. ويحدث للجميع ، بغض النظر عن خبرة العميل ، مدى تأهيل المبرمجين هناك. عاجلا أم آجلا يحدث ذلك.
القصة الثانية ، حيث نقوم بتوزيع الحمل وتحسين موارد الخادم
- لقد كبرنا وأصبحنا رجالا جادين. ونحن نفهم أن لدينا نسخة طبق الأصل وسيكون من الجيد لنا موازنة الحمل: اكتب إلى السيد ، واقرأ من النسخة المتماثلة. وعادة ما ينشأ هذا الموقف عندما نريد إعداد نوع من التقارير أو ETL. والعمل سعيد للغاية حيال ذلك. إنه يريد حقًا مجموعة متنوعة من التقارير مع مجموعة من التحليلات المعقدة.
- تستمر التقارير لعدة ساعات ، لأنه لا يمكن حساب التحليلات المعقدة بالمللي ثانية. نحن ، مثل الرجال الشجعان ، نكتب الكود. نقوم في تطبيق الإدراج الذي نسجله على Master ، بعمل تقارير على النسخة المتماثلة.
- نوزع الحمولة.
- كل شيء يعمل على أكمل وجه. نحن رائعون.
وكيف تبدو هذه الحالة؟ على وجه التحديد ، في هذه المخططات ، أضفت أيضًا مدة المعاملات من النسخة المتماثلة طوال مدة المعاملة. تشير جميع الرسوم البيانية الأخرى إلى الخادم الرئيسي فقط.
بحلول هذا الوقت ، نمت لوحة تقريري. هناك المزيد منهم. يمكننا أن نرى أن متوسط وقت استجابة الخادم مستقر. يمكننا أن نرى أن لدينا معاملة طويلة الأمد على النسخة المتماثلة والتي تعمل لمدة ساعتين. نرى العمل الهادئ للفراغ الذاتي ، الذي يعالج المواعيد النهائية. وكلنا بخير.
على وجه التحديد ، وفقًا للكمبيوتر اللوحي التجريبي ، نواصل تحديث الأرصدة في الحسابات هناك. ولدينا أيضًا وقت استجابة ثابتًا عند الطلب ، واستهلاكًا مستقرًا للموارد. كل شيء على ما يرام معنا.
كل شيء على ما يرام حتى اللحظة التي تبدأ فيها هذه التقارير بإطلاق النار علينا بشأن تعارض مع النسخ المتماثل. ويقومون بإطلاق النار على فترات منتظمة.
نتصل بالإنترنت ونبدأ في قراءة سبب حدوث ذلك. ونجد حلا.
الحل الأول هو زيادة زمن انتقال النسخ المتماثل. نعلم أن تقريرنا يستمر لمدة 3 ساعات. اضبط تأخير النسخ المتماثل على 3 ساعات. نبدأ كل شيء ، لكننا ما زلنا نواجه مشاكل مع حقيقة أن التقارير يتم ردها في بعض الأحيان.
نريد أن يكون كل شيء مثاليًا. لنذهب أبعد من ذلك. ونجد إعدادًا رائعًا على الإنترنت - hot_standby_feedback. نقوم بتشغيله. يتيح لنا Hot_standby_feedback الاحتفاظ بالفراغ التلقائي الذي يعمل على الماستر. وبالتالي ، نتخلص تمامًا من تعارضات النسخ المتماثل. وكلنا نعمل بشكل جيد مع التقارير.
وماذا يحدث للسيرفر الماستر في هذا الوقت؟ ومع الخادم الرئيسي ، لدينا كارثة كاملة. نشاهد الآن مخططات مع تشغيل كلا الإعدادين. ونرى أن الجلسة على النسخة المتماثلة بدأت بطريقة ما في التأثير على الوضع على الخادم الرئيسي. إنه يحدث تأثيرًا لأنه يعلق الفراغ التلقائي الذي ينظف الخطوط الميتة. ارتفع حجم طاولتنا مرة أخرى. كما ارتفع متوسط وقت تنفيذ الاستعلام عبر قاعدة البيانات بأكملها. تم إحكام الأوتوفاكيو قليلاً.
على وجه التحديد ، في لوحة لدينا ، نرى أن تحديث البيانات الموجود عليها قفز أيضًا إلى السماء. وبالمثل ، زاد استهلاك موارد المعالج بشكل كبير. نكرر مرة أخرى على عدد كبير من الخطوط غير المجدية الميتة. ووقت الاستجابة على هذا الجهاز اللوحي ، انخفض عدد المعاملات.
كيف سيبدو الأمر إذا كنا لا نعرف ما الذي كنت أتحدث عنه من قبل؟
- نبدأ في البحث عن المشاكل. إذا واجهنا مشاكل في الجزء الأول ، فإننا نعلم أن هذا قد يكون سبب صفقة طويلة ونحن نتسلق على السيد. المشكلة مع السيد. النقانق له. إنه يقوم بالإحماء ، متوسط حمله أقل من مائة.
- الطلبات تتباطأ هناك ، لكننا لا نرى أي معاملات طويلة الأجل هناك. ولا نفهم ما يحدث. لا نعرف أين ننظر.
- فحص أجهزة الخادم. ربما انهارت غارتنا. ربما أحرقنا شريط الذاكرة. نعم ، يمكن أن يكون أي شيء. لكن لا ، الخوادم جديدة ، كل شيء يعمل بشكل جيد.
- الجميع يدير: الإداريين والمطورين والمدير. لا شيء يساعد.
- وفي مرحلة ما ، يبدأ كل شيء فجأة في تصحيح نفسه.
في النسخة المتماثلة ، في ذلك الوقت ، نجح الطلب وغادر. لقد تلقينا بلاغًا. العمل لا يزال سعيدا. كما ترى ، نمت طاولتنا مرة أخرى ولن تنخفض. على الرسم البياني مع الجلسات ، تركت جزءًا من هذه المعاملة الطويلة من النسخة المتماثلة ، بحيث يمكنك تقييم المدة التي تستغرقها حتى يستقر الموقف.
انتهت الجلسة. وفقط بعد مرور بعض الوقت ، يأتي الخادم بترتيب أكثر أو أقل. ويعود متوسط وقت الاستجابة للطلبات على الخادم الرئيسي إلى طبيعته. لأنه ، أخيرًا ، حصل الفراغ التلقائي على فرصة للتنظيف ، ووضع علامة على هذه الخطوط الميتة. وبدأ في أداء وظيفته. وبأي سرعة يفعل ذلك ، بسرعة سنكون في وضع جيد.
في جدول الاختبار ، حيث نقوم بتحديث أرصدة الحسابات ، نرى نفس الصورة تمامًا. يتم أيضًا تطبيع متوسط وقت تحديث الحساب بشكل تدريجي. يتم أيضًا تقليل الموارد التي يستهلكها المعالج. وعاد عدد المعاملات في الثانية إلى طبيعته. لكن مرة أخرى ، عد إلى طبيعته ، ليس كما كان قبل وقوع الحادث.
على أي حال ، نحصل على تراجع في الأداء ، كما في الحالة الأولى ، مرة ونصف إلى مرتين ، وأحيانًا أكثر.
يبدو أننا فعلنا كل شيء بشكل صحيح. توزيع الحمولة. الجهاز ليس خاملا. وفقًا للعقل ، لقد كسروا الطلبات ، لكن كل شيء لا يزال سيئًا.
- لا تمكّن hot_standby_feedback؟ نعم ، لا يوصى بتشغيله بدون أسباب قوية بشكل خاص. لأن هذا التواء يؤثر بشكل مباشر على الخادم الرئيسي ويوقف عمل الفراغ التلقائي هناك. من خلال تشغيله على بعض النسخ المتماثلة ونسيانها ، يمكنك قتل Master وواجه مشكلات كبيرة مع التطبيق.
- زيادة max_standby_streaming_delay؟ نعم ، بالنسبة للتقارير هو كذلك. إذا كان لديك تقرير مدته ثلاث ساعات ولا تريد أن يتعطل بسبب تعارضات النسخ المتماثل ، فقم ببساطة بزيادة التأخير. لا يتطلب التقرير المطول أبدًا البيانات التي تم إدخالها إلى قاعدة البيانات الآن. إذا كان لديك لمدة ثلاث ساعات ، فأنت تقوم بتشغيله لبعض فترة البيانات القديمة. وأنت ، تلك الثلاث ساعات من التأخير ، تلك الست ساعات من التأخير - لن تلعب أي دور ، لكنك ستتلقى تقارير باستمرار ولا تعرف مشاكل سقوطها.
- بطبيعة الحال ، تحتاج إلى التحكم في الجلسات الطويلة على النسخ المتماثلة ، خاصة إذا قررت تمكين hot_standby_feedback على نسخة متماثلة. لأنه يمكن أن يكون أي شيء. قدمنا هذه الملاحظة للمطور حتى يختبر الطلبات. كتب طلب مجنون. بدأ وذهب لشرب الشاي ، وحصلنا على المعلم الراسخ. أو أطلقنا التطبيق الخاطئ هناك. المواقف متنوعة. يجب التحكم في الجلسات على النسخ المتماثلة بدقة كما هو الحال في الماستر.
- وإذا كانت لديك استفسارات سريعة وطويلة عن النسخ المتماثلة ، فمن الأفضل في هذه الحالة تقسيمها لتوزيع الحمل. هذا رابط لـ streaming_delay. لسرعة الحصول على نسخة متماثلة واحدة مع تأخير نسخ صغير. بالنسبة لطلبات إعداد التقارير طويلة المدى ، يجب أن يكون لديك نسخة متماثلة يمكن أن تتأخر لمدة 6 ساعات في اليوم. هذا هو الوضع الطبيعي تماما.
نقوم بإزالة العواقب بنفس الطريقة:
- نجد طاولات منتفخة.
- ونقوم بالضغط باستخدام الأداة الأكثر ملاءمة التي تناسبنا.
القصة الثانية تنتهي هنا. دعنا ننتقل إلى القصة الثالثة.
أيضًا شائع جدًا بالنسبة لنا ، حيث نقوم بالهجرة.
- أي منتج برمجي ينمو. المتطلبات تتغير. على أي حال ، نريد أن نتطور. ويحدث أننا بحاجة إلى تحديث البيانات الواردة في الجدول ، أي تشغيل التحديث من حيث الترحيل إلى الوظائف الجديدة التي نقوم بتنفيذها كجزء من تطويرنا.
- تنسيق البيانات القديم لا يناسب. لنفترض أننا ننتقل الآن إلى الجدول الثاني ، حيث لدي عمليات على هذه الحسابات. ولنفترض أنهم كانوا بالروبل ، وقررنا زيادة الدقة والقيام بذلك بالكوبيكس. ولهذا نحتاج إلى إجراء تحديث: اضرب الحقل بكمية العملية في مائة.
- في عالم اليوم ، نستخدم أدوات إصدارات قواعد البيانات المؤتمتة. دعنا نقول . نسجل هجرتنا هناك. نقوم باختباره على قاعدة الاختبار الخاصة بنا. كل شيء على ما يرام. التحديث قيد التشغيل. تعمل الكتل لبعض الوقت ، لكننا نحصل على بيانات محدثة. ويمكننا إطلاق وظائف جديدة في هذا الشأن. تم اختبارها وفحصها جميعًا. كل تأكيد.
- نفذت الأعمال المخطط لها ، نفذت الهجرة.
إليك الترحيل مع التحديث المقدم أمامك. نظرًا لأن لديّ عمليات على الحسابات ، كانت اللوحة 15 جيجا بايت. ونظرًا لأننا نقوم بتحديث كل سطر ، فقد ضاعفنا حجم الجدول لأننا قمنا بالكتابة فوق كل سطر.
أثناء الترحيل ، لم نتمكن من القيام بأي شيء بهذه التسمية ، لأن جميع الطلبات الخاصة بها كانت في قائمة الانتظار وانتظار انتهاء هذا التحديث. لكن هنا أود أن ألفت انتباهكم إلى الأرقام الموجودة على المحور الرأسي. بمعنى ، لدينا متوسط وقت طلب قبل الترحيل في منطقة 5 مللي ثانية وحمل على المعالج ، وعدد عمليات الكتلة لقراءة ذاكرة القرص أقل من 7,5.
هاجرنا وواجهنا مشاكل مرة أخرى.
كانت الهجرة ناجحة ، ولكن:
- بدأت الوظائف القديمة في العمل لفترة أطول.
- نما الجدول في الحجم مرة أخرى.
- أصبح الحمل على الخادم مرة أخرى أكثر مما كان عليه.
- وبالطبع ، ما زلنا نعبث بالوظائف التي عملت بشكل جيد ، وقمنا بتحسينها قليلاً.
وهذا مرة أخرى سخام ، والذي يفسد حياتنا مرة أخرى.
هنا أوضح أن الجدول ، مثل الحالتين السابقتين ، لن يعود إلى الأحجام السابقة. يبدو أن متوسط الحمل على الخادم كافٍ.
وإذا انتقلنا إلى جدول الحسابات ، فسنرى أن متوسط وقت الطلب قد تضاعف لهذا الجدول. قفز الحمل على المعالج وعدد الأسطر المراد تصنيفها في الذاكرة فوق 7,5 ، لكنه كان أقل. وقفز في حالة المعالجات مرتين ، في حالة عمليات البلوك بمقدار 2 مرة ، أي حصلنا على تدهور في أداء الخادم. ونتيجة لذلك - تدهور أداء تطبيقنا. في نفس الوقت ، ظل عدد المكالمات على نفس المستوى تقريبًا.
وهنا الشيء الرئيسي هو فهم كيفية القيام بمثل هذه الهجرات بشكل صحيح. وهم بحاجة إلى القيام به. نقوم بهذه الهجرات بانتظام.
- لا تتم عمليات الترحيل الكبيرة هذه تلقائيًا. يجب دائمًا التحكم فيها.
- يحتاج إلى إشراف من أهل العلم. إذا كان لديك DBA في الفريق ، فدع DBA يفعل ذلك. إنها وظيفته. إذا لم يكن الأمر كذلك ، فدع الشخص الأكثر خبرة يفعل ذلك ، والذي يعرف كيفية التعامل مع قواعد البيانات.
- مخطط قاعدة البيانات الجديد ، حتى إذا قمنا بتحديث عمود واحد ، فإننا نستعد دائمًا على مراحل ، أي مقدمًا قبل طرح الإصدار الجديد من التطبيق:
- تتم إضافة حقول جديدة نكتب فيها البيانات المحدثة فقط.
- نقوم بنقل البيانات من الحقل القديم إلى الحقل الجديد في أجزاء صغيرة. لماذا نفعل ذلك؟ أولاً ، نحن نتحكم دائمًا في عملية هذه العملية. نحن نعلم أننا قمنا بالفعل بتحويل العديد من الدفعات وبقي لدينا الكثير.
- والتأثير الإيجابي الثاني هو أنه بين كل دفعة نقوم بإغلاق معاملة ، وفتح واحدة جديدة ، وهذا يجعل من الممكن للفراغ التلقائي العمل وفقًا للوحة ، لتحديد المواعيد النهائية لإعادة الاستخدام.
- بالنسبة للأسطر التي ستظهر أثناء تشغيل التطبيق (لا يزال لدينا التطبيق القديم) ، نضيف مشغلًا يكتب قيمًا جديدة في الحقول الجديدة. في حالتنا هذه ، هذه عملية ضرب بمئة من القيمة القديمة.
- إذا كنا عنيدين تمامًا ونريد نفس الحقل ، فعند الانتهاء من جميع عمليات الترحيل وقبل طرح الإصدار الجديد من التطبيق ، نقوم ببساطة بإعادة تسمية الحقول. تم اختراع الأسماء القديمة في بعض الأسماء ، وقمنا بإعادة تسمية الحقول الجديدة إلى الحقول القديمة.
- وفقط بعد ذلك نطلق نسخة جديدة من التطبيق.
وفي الوقت نفسه ، لن نشعر بالانتفاخ ولن نتراجع في الأداء.
هذه نهاية القصة الثالثة.
والآن المزيد عن الأدوات التي ذكرتها في القصة الأولى.
قبل البحث عن bloat ، يجب عليك تثبيت الامتداد .
لكي لا تخترع الطلبات ، قمنا بالفعل بكتابة هذه الطلبات في عملنا. يمكنك استخدامها. هناك طلبان هنا.
- يستغرق الأمر الأول وقتًا طويلاً ، لكنه سيُظهر لك القيم الدقيقة للانتفاخ وفقًا للجدول.
- الطريقة الثانية تعمل بشكل أسرع وتكون فعالة للغاية عندما تحتاج إلى تقييم سريع لما إذا كان هناك انتفاخ في الجدول أم لا. ويجب أن تفهم أيضًا أن هناك دائمًا سخامًا في جدول Postgres. هذه سمة من سمات نموذج MVCC الخاص به.
- و 20٪ سخام جيد للطاولات في معظم الحالات. وهذا يعني أنه لا داعي للقلق وضغط هذا الجدول.
لقد توصلنا إلى كيفية تحديد الجداول المتضخمة معنا ، علاوة على ذلك ، عندما تكون مليئة بالبيانات غير المفيدة.
الآن حول كيفية إصلاح سخام:
- إذا كان لدينا لوحة صغيرة وأقراص جيدة ، أي على لوحة يصل حجمها إلى جيجابايت ، فمن الممكن تمامًا استخدام VACUUM FULL. سيأخذ منك قفلًا حصريًا لبضع ثوانٍ ، حسنًا ، لكنه سيفعل كل شيء بسرعة وبقسوة. ماذا تفعل VACUUM FULL؟ يأخذ قفلًا حصريًا على الطاولة ويعيد كتابة الصفوف الحية من الجداول القديمة إلى الجدول الجديد. وفي النهاية يستبدلهم. حذف الملفات القديمة واستبدال القديمة بالملفات الجديدة. ولكن طوال مدة عملها ، فإنها تأخذ قفلًا حصريًا على الطاولة. هذا يعني أنه لا يمكنك فعل أي شيء مع هذا الجدول: لا تكتب إليه ولا تقرأ فيه ولا تعدله. ويتطلب VACUUM FULL مساحة قرص إضافية لكتابة البيانات.
- الأداة التالية . من حيث المبدأ ، فهو مشابه جدًا لـ VACUUM FULL ، لأنه يقوم أيضًا بالكتابة فوق البيانات من الملفات القديمة إلى الجديدة واستبدالها في الجدول. لكن في الوقت نفسه ، لا يأخذ قفلًا حصريًا على الطاولة في بداية عمله ، ولكنه يأخذها فقط في الوقت الذي يكون فيه لديه بيانات جاهزة لاستبدال الملفات. له نفس متطلبات موارد القرص مثل VACUUM FULL. أنت بحاجة إلى مساحة قرص إضافية ، وهذا أمر بالغ الأهمية في بعض الأحيان إذا كان لديك جداول تيرابايت. وهو شره للغاية فيما يتعلق بالمعالج ، لأنه يعمل بنشاط مع I / O.
- الأداة الثالثة هي . إنه أكثر حرصًا بشأن الموارد ، لأنه يعمل على مبادئ مختلفة قليلاً. الجوهر الرئيسي لـ pgcompacttable هو أنه ينقل جميع الصفوف الحية إلى بداية الجدول مع التحديثات في الجدول. ثم يبدأ الفراغ على هذه الطاولة ، لأننا نعلم أن لدينا صفوفًا حية في البداية وصفوفًا ميتة في النهاية. والفراغ نفسه يقطع هذا الذيل ، أي أنه لا يتطلب مساحة إضافية على القرص. وفي الوقت نفسه ، لا يزال من الممكن تقليصها من خلال الموارد.
كل شيء بالأدوات.
إذا وجدت موضوع سخام مثيرًا للاهتمام من حيث التعمق أكثر في الداخل ، فإليك بعض الروابط المفيدة لك:
- هو تقرير زميلي. إنه عام حول المكان الذي تذهب إليه Postgres في سياق عملها وحياتها. وهناك قطعة فنية كبيرة جدًا ومفصلة لمسؤولي قواعد البيانات حول سخام.
- هو رابط إلى مستودعنا ، حيث نقوم بتخزين مجموعة من البرامج النصية المفيدة للتحقق من حالة قاعدة البيانات. هناك يمكنك أن تجد نصوص بحث سخام.
- и روابط إلى الأدوات التي ستساعدك على ضغط اللوحات.
- هذا منشور من زميلي. هناك يحلل بشكل جاد وتقنيًا سخامًا بالتفصيل بالفعل على مستوى قريب من المسؤولين.
حاولت هنا عرض قصة مرعبة للمطورين ، لأنهم عملاء مباشرون لقواعد البيانات ويجب أن يفهموا ما الذي تؤدي إليه وما هي الإجراءات. أتمنى أن أكون قد نجحت. شكرًا لكم على اهتمامكم!
الأسئلة
شكرا على التقرير! لقد تحدثت عن كيفية تحديد المشاكل. كيف يمكن تحذيرهم؟ أي ، كان لدي موقف حيث تم تعليق الطلبات ليس فقط لأنها تحولت إلى بعض الخدمات الخارجية. كانت مجرد بعض الصلات البرية. كانت هناك بعض الطلبات الصغيرة غير المؤذية التي ظلت معلقة لمدة يوم ، ثم بدأت في فعل نوع من الهراء. أي أنه مشابه جدًا لما تصفه. كيف تتعقبه؟ اجلس وشاهد باستمرار ، أي طلب عالق؟ كيف يمكن لهذا أن يمنع؟
في هذه الحالة ، هذه مهمة لمسؤولي شركتك ، وليس بالضرورة لمسؤول قاعدة البيانات.
أنا مسؤول.
لدى PostgreSQL طريقة عرض تسمى pg_stat_activity تُظهر الاستعلامات المعلقة. ويمكنك أن ترى كم من الوقت معلقة هناك.
لا بد لي من الحضور كل 5 دقائق والنظر؟
قم بإعداد كرون وتحقق. إذا كان لديك طلب طويل ، اكتب رسالة وهذا كل شيء. أي أنك لست بحاجة إلى النظر بعينيك ، يمكن أن يكون هذا آليًا. سوف تتلقى رسالة ، ترد عليها. أو يمكنك التصوير تلقائيًا.
هل هناك أسباب واضحة لحدوث ذلك؟
لقد أدرجت بعض. أمثلة أخرى أكثر تعقيدًا. ويمكن أن يكون هناك محادثة طويلة.
شكرا على التقرير! أردت أن أوضح حول الأداة المساعدة pg_repack. إذا لم يأخذ قفلًا خاصًا ، إذن ...
إنها تصنع قفلًا حصريًا.
... ثم من المحتمل أن أفقد البيانات. ألا يجب أن يسجل تطبيقي أي شيء في هذا الوقت؟
لا ، إنه يعمل بهدوء مع الجدول ، أي أن pg_repack ينقل أولاً جميع الخطوط الحية الموجودة هناك. بطبيعة الحال ، هناك نوع من التسجيلات الجارية في الجدول. هو فقط يرمي ذيل الحصان هذا.
هذا هو ، هل ما زال يفعل ذلك في النهاية؟
في النهاية ، يتطلب الأمر قفلًا حصريًا عند تبديل هذه الملفات.
هل سيكون أسرع من الفراغ ممتلئ؟
VACUUM FULL ، عندما بدأ ، أخذ على الفور قفلًا حصريًا. وحتى يفعل كل شيء ، لن يتركها تذهب. ويأخذ pg_repack قفلًا حصريًا فقط في وقت استبدال الملفات. في هذه المرحلة ، لا تكتب هناك ، لكن البيانات لن تضيع ، كل شيء سيكون على ما يرام.
مرحبًا! لقد تحدثت عن عمل الفراغ الذاتي. كان هناك رسم بياني بخلايا حمراء وصفراء وخضراء للسجل. أي الأصفر - وضع علامة عليها على أنها محذوفة. ونتيجة لذلك ، يمكنك كتابة شيء جديد فيها؟
نعم. لا يزيل Postgres الصفوف. لديه مثل هذه الخصوصية. إذا قمنا بتحديث السطر ، فسنضع علامة على السطر القديم على أنه محذوف. يظهر معرّف المعاملة الذي غيّر هذا السطر هناك ، ونكتب سطرًا جديدًا. ولدينا جلسات يمكن أن تقرأها. في مرحلة ما ، يصبحون كبار السن. وجوهر الفراغ التلقائي هو أنه يمر عبر هذه الخطوط ويميزها على أنها غير ضرورية. وهناك يمكنك الكتابة فوق البيانات.
أفهم. لكن السؤال لا يتعلق بذلك. لم أوافق. لنفترض أن لدينا طاولة. لديها حقول متغيرة الحجم. وإذا حاولت إدخال شيء جديد ، فقد لا يتناسب ببساطة مع الخلية القديمة.
لا ، على أي حال يتم تحديث الخط بالكامل. يحتوي Postgres على نموذجين للتخزين. يختار من نوع البيانات. هناك بيانات مخزنة مباشرة في الجدول ، وهناك أيضًا بيانات tos. هذه كميات كبيرة من البيانات: text ، json. يتم تخزينها في أقراص منفصلة. ووفقًا لهذه الأجهزة اللوحية ، تحدث نفس القصة مع النفاخ ، أي أن كل شيء متماثل. تم سردها فقط بشكل منفصل.
شكرا على التقرير! ما مدى قبول استخدام طلبات مهلة كشف الحساب لتحديد المدة؟
مقبول جدا. نحن نستخدمه في كل مكان. وبما أننا لا نملك خدماتنا الخاصة ، فنحن نقدم الدعم عن بعد ، وهناك مجموعة متنوعة من العملاء. والجميع راضون تمامًا عن هذا. هذا هو ، لدينا وظائف في كرون التي تحقق. كل ما في الأمر أن مدة الجلسات يتم التفاوض عليها مع العميل ، قبل ذلك لم نتوقف. قد تكون دقيقة أو 10 دقائق. يعتمد ذلك على الحمل على القاعدة والغرض منه. لكننا جميعًا نستخدم pg_stat_activity.
شكرا على التقرير! أحاول أن أحاول تقريرك لتطبيقاتي. ويبدو أننا نبدأ معاملة في كل مكان ، ونكملها صراحة في كل مكان. في حالة وجود بعض الاستثناءات ، يحدث كل نفس التراجع. ثم فكرت. بعد كل شيء ، لا يمكن أن تبدأ الصفقة بشكل صريح. أعتقد أن هذا تلميح للفتاة. إذا قمت للتو بتحديث سجل ، فهل ستبدأ المعاملة في PostgreSQL وتنتهي فقط عند قطع الاتصال؟
إذا كنت تتحدث الآن عن مستوى التطبيق ، فهذا يعتمد على برنامج التشغيل الذي تستخدمه ، على ORM الذي يتم استخدامه. هناك الكثير من الإعدادات هناك. إذا تم تمكين الالتزام التلقائي ، فستبدأ المعاملة هناك وتغلق على الفور.
أي أنه يغلق مباشرة بعد التحديث؟
ذلك يعتمد على الإعدادات. سميت مكانًا واحدًا. هذا هو الالتزام التلقائي. إنها شائعة جدًا. إذا تم تمكينه ، فسيتم فتح المعاملة وإغلاقها. ما لم تقل صراحةً "بدء المعاملة" و "إنهاء المعاملة" ، ولكنك ببساطة أطلقت طلبًا في الجلسة.
مرحبًا! شكرا على التقرير! تخيل أن لدينا قاعدة بيانات تتضخم وتتضخم ثم تنفد مساحة الخادم. هل توجد أي أدوات لإصلاح هذا الموقف؟
المكان على الخادم بطريقة جيدة يحتاج إلى المراقبة.
على سبيل المثال ، ذهب DBA لشرب الشاي ، وكان في منتجع ، وما إلى ذلك.
عند إنشاء نظام ملفات ، يتم إنشاء بعض المساحة الاحتياطية على الأقل حيث لا تتم كتابة البيانات.
ماذا لو كانت صفرًا تمامًا؟
هناك تسمى المساحة المحجوزة ، أي يمكن تحريرها ، واعتمادًا على حجم إنشائها ، لديك مساحة خالية. بشكل افتراضي ، لا أعرف كم هناك. وفي حالة أخرى ، قم بتوصيل الأقراص بحيث يكون لديك مكان لإجراء عملية الاسترداد. يمكنك حذف بعض الجداول التي تضمن أنك لن تحتاج إليها.
ألا توجد أدوات أخرى؟
إنها مصنوعة يدويًا دائمًا. وفي المكان ، يتم الكشف عن ما هو الأفضل القيام به هناك ، نظرًا لوجود بيانات مهمة ، وهناك بيانات غير حرجة. ولكل قاعدة بيانات وتطبيق يعمل معها ، يعتمد ذلك على العمل. يتم تحديده دائمًا على الفور.
شكرا على التقرير! لدي سؤالان. أولاً ، قمت بعرض الشرائح حيث تم توضيح أنه في حالة المعاملات المعلقة ، يزداد حجم مساحة الجدول وحجم المؤشر. علاوة على ذلك في التقرير ، كانت هناك مجموعة من الأدوات المساعدة التي تحزم الجهاز اللوحي. وماذا عن المؤشر؟
يحزمونها أيضًا.
لكن الفراغ لا يؤثر على المؤشر؟
يعمل البعض مع فهرس. على سبيل المثال pg_rapack و pgcompacttable. يعيد الفراغ تكوين الفهارس ، ويؤثر عليها. يمتلك VACUUM FULL جوهر الكتابة فوق كل شيء ، أي أنه يعمل مع الجميع.
والسؤال الثاني. لم أفهم لماذا تعتمد التقارير المتعلقة بالنسخ المتماثلة كثيرًا على النسخ المتماثل نفسه. بدا لي أن التقارير تقرأ ، والنسخ هو الكتابة.
ما الذي يسبب تعارض النسخ المتماثل؟ لدينا ماجستير في العمليات التي تتم. لدينا فراغ تلقائي. الفراغ الذاتي في الواقع ، ماذا يفعل؟ يقطع بعض الخطوط القديمة. إذا كان لدينا في هذا الوقت طلبًا على النسخة المتماثلة التي تقرأ هذه السطور القديمة ، وفي حالة المعلم ، كان هناك موقف قام فيه الفراغ التلقائي بتمييز هذه السطور قدر الإمكان لإعادة كتابتها ، ثم قمنا بالكتابة فوقها. وتلقينا حزمة بيانات ، عندما يتعين علينا إعادة كتابة الأسطر التي يحتاجها الطلب في النسخة المتماثلة ، فستنتظر عملية النسخ المهلة التي قمت بتكوينها. وبعد ذلك ستقرر PostgreSQL ما هو أكثر أهمية بالنسبة لها. والنسخ أكثر أهمية بالنسبة له من الطلب ، وسيقوم بتصوير الطلب لإجراء هذه التغييرات على النسخة المتماثلة.
أندرو ، لدي سؤال. هذه الرسومات الرائعة التي أظهرتها أثناء العرض ، هل هذه نتيجة لبعض الأعمال التي تفيدك؟ كيف تم عمل المخططات؟
هذه خدمة .
هل هذا منتج تجاري؟
نعم. هذا منتج تجاري.
المصدر: www.habr.com