"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > إتقان MySQL: مقاييس الأداء الرئيسية التي يجب على كل مطور مراقبتها

إتقان MySQL: مقاييس الأداء الرئيسية التي يجب على كل مطور مراقبتها

تم النشر بتاريخ 2024-11-06
تصفح:321

ليس من الضروري أن تكون مراقبة مقاييس أداء MySQL وإدارة قاعدة بياناتك أمرًا صعبًا. نعم، لقد سمعت هذا الحق. ومع وجود استراتيجيات وأدوات المراقبة المناسبة المتاحة لك، يمكنك أخيرًا الجلوس في المقعد الخلفي. إن طريقة RED، المقترنة بقدرات المراقبة القوية لـ Releem وتوصيات التكوين سهلة التطبيق، تقوم بالمهمة الثقيلة نيابةً عنك.

مقدمة إلى الطريقة الحمراء

تُستخدم طريقة RED تقليديًا لمراقبة أداء تطبيقات وخدمات الويب ولكن يمكن تطبيقها أيضًا على مراقبة أداء MySQL. وقد وجدت Relem أن إطار العمل له نفس القدر من القيمة في مراقبة مقاييس أداء MySQL لأن التحديات التي تواجهها قواعد البيانات، من حيث الأداء والموثوقية، تعكس تلك التي تواجهها تطبيقات الويب.

عند تطبيقها على قواعد بيانات MySQL، تنقسم طريقة RED إلى ثلاثة مجالات مهمة مهمة، يوفر كل منها رؤى حول السلامة التشغيلية لقاعدة البيانات الخاصة بك:

  • معدل الاستعلام (المعدل) – يقوم هذا بتقييم حجم الاستعلامات أو الأوامر التي يتم تنفيذها في الثانية، مما يوفر قياسًا مباشرًا لعبء عمل الخادم. إنها مفيدة في تقييم قدرة قاعدة البيانات على التعامل مع العمليات المتزامنة واستجابتها لمتطلبات المستخدم.

  • معدل الخطأ (الأخطاء) - يلقي تتبع تكرار الأخطاء في الاستعلامات الضوء على مشكلات الموثوقية المحتملة داخل قاعدة البيانات. قد يشير معدل الخطأ المرتفع إلى مشاكل أساسية في بناء جملة الاستعلام أو مخطط قاعدة البيانات أو قيود النظام التي تؤثر على تكامل قاعدة البيانات بشكل عام. مقياس MySQL الأساسي لمعدل المراقبة هو Aborted_clients.

  • مدة تنفيذ الاستعلام (المدة) - مقياس المدة هو مقياس للوقت الذي يستغرقه إكمال الاستعلامات، من البداية إلى التنفيذ. يقوم مؤشر الأداء هذا بتقييم كفاءة عمليات استرجاع البيانات ومعالجتها والتي لها تأثيرات مباشرة على تجربة المستخدم وإنتاجية النظام.

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

8 مقاييس أداء MySQL أساسية لطريقة RED

لتطبيق طريقة RED بشكل فعال لمراقبة أداء MySQL، قم بإعادة التركيز على ثمانية جوانب مهمة لقاعدة البيانات الخاصة بك. يرتبط كل منها بالمعدل أو الأخطاء أو المدة بطريقة أو بأخرى:

1. زمن وصول MySQL

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

يقيس زمن الوصول الوقت الذي يستغرقه تنفيذ الاستعلام - من لحظة إرسال الاستعلام إلى قاعدة البيانات حتى تستجيب قاعدة البيانات. يؤثر زمن الوصول بشكل مباشر على كيفية إدراك المستخدمين لتطبيقك.

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

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

لمعرفة المزيد عن زمن استجابة MySQL

2. الإنتاجية

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

تقيس الإنتاجية، والتي يتم قياسها كمياً بالاستعلامات في الثانية (QPS)، كفاءة قاعدة البيانات الخاصة بك وقدرتها على إدارة أعباء العمل. تشير الإنتاجية العالية إلى نظام قاعدة بيانات محسّن جيدًا يمكنه التعامل مع كميات كبيرة من الاستعلامات بكفاءة. قد تشير الإنتاجية المنخفضة إلى اختناقات في الأداء أو قيود على الموارد.

يتضمن تحقيق إنتاجية عالية عادةً مجموعة من استعلامات SQL المحسنة، وموارد الأجهزة المناسبة (وحدة المعالجة المركزية، والذاكرة، وأنظمة الإدخال والإخراج السريعة)، وتكوينات قاعدة البيانات المضبوطة بدقة.

لمزيد من المعلومات حول الإنتاجية

3. عدد الاستعلامات البطيء

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

الاستعلامات البطيئة هي في الأساس طلبات قاعدة بيانات تنتهك حد وقت التنفيذ المحدد مسبقًا. يمكنك ضبط هذا الحد ليناسب أهداف الأداء المحددة أو المعايير التشغيلية. إن تتبع عدد الاستعلامات البطيئة هو كيفية تحديد الاستعلامات التي تحتاج إلى التحسين.

يتم تحديد وتسجيل هذه الاستعلامات البطيئة في Slow_query_log، وهو ملف مخصص تم إنشاؤه لتخزين تفاصيل حول الاستعلامات التي تفشل في تلبية معايير الأداء المحددة.

لمزيد من المعلومات حول عدد الاستعلامات البطيئة

4. العملاء المجهضون

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

يحسب هذا المقياس عدد الاتصالات التي تم إحباطها لأن العميل لم يقم بإغلاق الاتصال بشكل صحيح. يمكن أن تشير الأعداد الكبيرة من العملاء الذين تم إحباطهم إلى مجموعة من الأسباب:

    تأخر وصول الشبكة وعدم استقرارها مما يتسبب في انتهاء المهلة
  • حدود سعة الخادم تؤدي إلى رفض الاتصال
  • التنافس على الموارد بين الاستعلامات
  • أوجه القصور من الاستعلامات طويلة الأمد
  • التكوينات الخاطئة في إعدادات MySQL
  • أخطاء التطبيق تؤدي إلى قطع الاتصال المبكر

لمزيد من المعلومات عن العملاء المجهضين

5. استخدام وحدة المعالجة المركزية

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

وحدة المعالجة المركزية هي عقل الخادم الخاص بك. يقوم بتنفيذ الأوامر وإجراء العمليات الحسابية التي تسمح لقاعدة البيانات الخاصة بك بتخزين البيانات واسترجاعها وتعديلها وحذفها. تساعد مراقبة استخدام وحدة المعالجة المركزية (CPU) عن كثب على التأكد من أن الخادم لديه قوة معالجة كافية للتعامل مع عبء العمل الخاص به. يمكن أن يكون الاستخدام العالي لوحدة المعالجة المركزية علامة واضحة على وجود خادم مثقل بالأعباء يكافح من أجل مواكبة المتطلبات المفروضة عليه.

إليك بعض الإرشادات العامة التي يجب مراعاتها لاستخدام وحدة المعالجة المركزية:

  • 50-70٪ مستدامة – في هذا المستوى، تتعامل وحدة المعالجة المركزية لديك مع أعباء العمل المتوسطة إلى الثقيلة بفعالية، ولكن لا يزال هناك بعض المساحة لأحمال الذروة. إنه نطاق صحي للخوادم في ظل التشغيل العادي.

  • 70-90٪ مستدامة - عندما يقع استخدام وحدة المعالجة المركزية باستمرار ضمن هذا النطاق، فهذا يشير إلى عبء عمل مرتفع يترك مساحة محدودة للتعامل مع متطلبات الذروة. يجب عليك مراقبة الخادم عن كثب.

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

ملاحظة: قد لا تشير الارتفاعات العرضية فوق هذه الحدود بالضرورة إلى وجود مشكلة، حيث أن قواعد البيانات مصممة للتعامل مع الأحمال المتغيرة. الكلمة الأساسية مستدامة. يعد الاستخدام المستمر العالي علامة على أن الخادم الخاص بك يتعرض لضغط كبير.

6. استخدام ذاكرة الوصول العشوائي

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

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

إليك بعض الإرشادات العامة التي يجب مراعاتها لاستخدام ذاكرة الوصول العشوائي:

  • – يعتبر هذا النطاق آمنًا بشكل عام ويشير إلى وجود ذاكرة كافية متاحة لكل من عمليات قاعدة البيانات الحالية وتزايد عبء العمل الإضافي.

  • استخدام 70-85% - عندما يقع استخدام ذاكرة الوصول العشوائي باستمرار ضمن هذا النطاق، فهذا يشير إلى أن قاعدة البيانات تستخدم الذاكرة المتوفرة بشكل جيد ولكنها بدأت في الوصول إلى الحد الأدنى للمراقبة الدقيقة . إن البقاء في هذا النطاق خلال أوقات الذروة قد يحد من الاحتياطي اللازم للتعامل مع الزيادات المفاجئة في الطلب.

  • استخدام 85-90% – في هذا النطاق، يقترب الخادم من سعة الذاكرة الخاصة به. يمكن أن يؤدي الاستخدام العالي للذاكرة إلى زيادة عمليات الإدخال/الإخراج للقرص عندما يبدأ النظام في تبديل البيانات من القرص وإليه. اعتبر هذه علامة تحذير بأن عبء العمل يحتاج إلى تحسين أو أن الذاكرة الفعلية للخادم تحتاج إلى توسيع.

  • >استخدام بنسبة 95% - يعد التشغيل بنسبة 95% من استخدام ذاكرة الوصول العشوائي أو أكثر أمرًا بالغ الأهمية ومن المحتمل أن يسبب مشكلات في الأداء. في هذا المستوى، قد يلجأ الخادم بشكل متكرر إلى التبديل، مما يؤدي إلى حدوث تباطؤ شديد وربما يتسبب في انتهاء المهلات لتطبيقات العميل. مطلوب اتخاذ إجراء فوري من جانبك.

7. استخدام المبادلة

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

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

من الناحية المثالية، يجب أن يُظهر خادم MySQL استخدامًا منخفضًا إلى الحد الأدنى من استخدام SWAP. يشير هذا إلى أن قاعدة البيانات تعمل ضمن ذاكرة الوصول العشوائي (RAM) المتوفرة بها.

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

8. عمليات الإدخال/الإخراج في الثانية (IOPS)

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

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

تشمل بعض العوامل الرئيسية التي تؤثر على IOPS ما يلي:

    نوع وسائط التخزين، حيث تتفوق محركات أقراص SSD عادةً على محركات الأقراص الثابتة في السرعة
  • تكوينات RAID، والتي يمكنها تحسين عمليات القراءة أو الكتابة
  • المتطلبات المحددة لعبء عمل قاعدة البيانات، سواء كانت كثيفة القراءة أو كثيفة الكتابة
  • مستوى التزامن وفعالية استراتيجيات التخزين المؤقت
استراتيجية ريليم الشاملة لإدارة قواعد البيانات

Mastering MySQL: Key Performance Metrics Every Developer Should Monitor

إن أسلوب Releme في مراقبة أداء MySQL يدور حول مراقبة التفاصيل المهمة. تتضمن هذه الإستراتيجية التتبع الدقيق للمقاييس الثمانية المذكورة - زمن استجابة MySQL، والإنتاجية، والاستعلامات البطيئة، والعملاء المجهضين، ووحدة المعالجة المركزية، وذاكرة الوصول العشوائي، واستخدام SWAP، وIOPS - كل ذلك في إطار طريقة RED. من خلال دمج هذه المراقبة كجزء من الفحوصات الصحية التي تتم مرتين يوميًا (19 مقياسًا!)، تساعد Relem قاعدة بياناتك على تحقيق مستويات عالية من الأداء والموثوقية وقابلية التوسع والحفاظ عليها.

أبعد من مجرد مراقبة أداء MySQL، تخطو Relemem خطوة أبعد من خلال تقديم اقتراحات تكوين مخصصة تهدف إلى إصلاح أي عقبات تم اكتشافها أثناء المراقبة. نحن نسمي هذه الميزة Autopilot لـ MySQL. على سبيل المثال، إذا كنت تواجه مشكلات تتعلق بزمن الاستجابة المرتفع، فسوف توفر لك Relem رؤى قابلة للتنفيذ لإعادة أرقام زمن الاستجابة الخاصة بك إلى المسار الصحيح. هدفنا النهائي هو إزالة الحاجة إلى الإشراف اليدوي من خلال برامج قوية وبديهية تتعامل مع جميع تعقيدات إدارة قاعدة البيانات التي لا تفضل القلق بشأنها.

يتمتع Releem بتوافق واسع النطاق، لذا سواء كنت تستخدم Percona أو MySQL أو MariaDB لنظام إدارة قاعدة البيانات الخاص بك - يمكن أن يساعدك Relem. تحقق من القائمة الرسمية للأنظمة المدعومة هنا.

للحصول على استكشاف متعمق لكل مقياس وأفضل الممارسات لمراقبة قاعدة بيانات MySQL وتحسينها، فكر في زيارة موقع Relemem.com.

بيان الافراج تم إعادة نشر هذه المقالة على: https://dev.to/drupaladmin/mastering-mysql-key-performance-metrics-every-developer-should-track-18g8?1 إذا كان هناك أي انتهاك، يرجى الاتصال بـ [email protected] لحذفه
أحدث البرنامج التعليمي أكثر>

تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.

Copyright© 2022 湘ICP备2022001581号-3