Skip to main content
يبدأ تشخيص الاستعلام البطيء بالرجوع إلى سجل الاستعلامات الخاص به. يوضح هذا الدليل كيفية استخدام system.query_log للعثور على أنماط متكررة للاستعلامات البطيئة، واختيار تنفيذ ممثل، ومراجعة استخدامه للموارد. بعد ذلك، ستستخدم EXPLAIN لفحص خطة تنفيذ الاستعلام وصياغة فرضية بشأن عنق الزجاجة قبل تعديل الاستعلام أو مخطط البيانات.

قبل البدء

تستخدم الأمثلة الواردة في هذا الدليل جدول nyc_taxi.trips_small_inferred. لتنفيذها كما هي، أنشئ الجدول وحمّله إذا لم تكن قد فعلت ذلك مسبقًا:
يبلغ حجم ملف Parquet المصدر نحو 5.8 GB. قد يستغرق تحميله عدة دقائق، حسب الشبكة والموارد المتاحة.
لإعادة إنتاج نتائج سجل الاستعلامات في هذا الدليل، نفّذ استعلامات حمل العمل النموذجية الثلاثة جميعها مرتين على الأقل بعد تحميل مجموعة البيانات. ثم أفرغ سجل الاستعلامات لتصبح عمليات التنفيذ المكتملة متاحة للأمثلة أدناه:
إذا لم تتمكن من تنفيذ SYSTEM FLUSH LOGS، فانتظر حتى يُفرَّغ سجل الاستعلامات تلقائيًا، ثم أعد محاولة البحث الأول. عند تشخيص حمل العمل لديك، تأكد من أن system.query_log يحتوي على عمليات تنفيذ مكتملة ضمن النطاق الزمني الذي تنوي فحصه.

آلية العمل

افتراضيًا، يسجّل ClickHouse معلومات عن الاستعلامات المكتملة في جدول system.query_log. وقد يتضمن كل سجل مدة الاستعلام، وعدد الصفوف المقروءة، واستخدام CPU والذاكرة، ونشاط ذاكرة التخزين المؤقت لنظام الملفات. تساعدك هذه القياسات على تحديد أنماط الاستعلامات البطيئة وفهم كيفية استخدام هذه الاستعلامات للموارد. بعد اختيار تنفيذ ممثل، يمكنك فحص خطة تنفيذ الاستعلام للتحقق من المواضع التي قد يستغرق فيها الاستعلام وقتًا. في عنقود، تظل بيانات سجل الاستعلامات محلية على كل عقدة. تستخدم الأمثلة في هذا الدليل clusterAllReplicas للاستعلام من كل نسخة متماثلة، وmerge لتضمين جدول system.query_log الحالي وأي جداول query_log_N مُرقّمة بالإصدار ومحتفَظ بها بعد تغييرات مخطط جداول النظام. يتضمن كل مثال لسجل الاستعلامات علامات تبويب لعمليات النشر على عنقود وعلى عقدة واحدة. يوفر ClickHouse Cloud عنقود default المستخدم في أمثلة العنقود. في عملية نشر ذاتية الإدارة، استبدل default بعنقود مدرج في system.clusters.
تضبط الأمثلة skip_unavailable_shards بحيث لا تتسبب نسخة متماثلة غير متاحة مؤقتًا في فشل استعلام التشخيص. ويكون ذلك مفيدًا بشكل خاص أثناء التحجيم التلقائي. لا تُضمَّن السجلات من النسخة المتماثلة التي تم تخطيها، لذا قد تكون النتائج غير مكتملة.

تشخيص استعلام بطيء

بعد اكتمال عمليات التنفيذ في سجل الاستعلامات، اتبع هذه الخطوات الثلاث بالترتيب. ستحدّد نمطًا متكررًا لاستعلام بطيء، وتختار عملية تنفيذ ممثّلة، وتفحص خطة تنفيذ الاستعلام.
1

تحديد الاستعلامات المُرشَّحة

ابدأ بتجميع الاستعلامات الأولية المكتملة حسب normalized_query_hash. يميّز ذلك أنماط الاستعلامات المتكررة عن عمليات التنفيذ البطيئة المنفردة. ويرتّب الاستعلام التالي الأنماط وفقًا للوسيط لمدتها، مع تضمين استعلام كمثال لكل نمط:
استخدم executions للتمييز بين الحِمل (workload) المتكرر والاستعلامات المنفردة. فالنمط (pattern) ذو وسيط المدة (Duration) المرتفع، أو التنفيذات المتكررة، أو الاستهلاك المرتفع للموارد، يُعد مرشحًا (candidate) للتقصّي (investigation) أقوى من عملية تنفيذ بطيئة واحدة.كجردٍ سريع، يسرد الاستعلام التالي أبطأ عملية تنفيذ مكتملة لما يصل إلى خمسة أنماط استعلام مختلفة على NYC Taxi dataset. وهو يستثني عبارات تحميل مجموعة البيانات وعمليات التنفيذ المتكررة للنمط نفسه. وفي الخطوة التالية، ستحصر سجل الاستعلامات في عمليات التنفيذ التي تحمل قيمة normalized_query_hash التي اخترتها أعلاه.
يحتوي الحقل query_duration_ms على مدة تنفيذ الاستعلام بالمللي ثانية. وفي هذه النتائج، استغرق الاستعلام الأطول تنفيذًا 2,967 مللي ثانية.يمكنك أيضًا تحديد الاستعلامات المرشحة استنادًا إلى استهلاك الموارد بدلًا من مدة الاستعلام:
يصنّف هذا الاستعلام الاستعلامات الأخيرة حسب استخدام الذاكرة، ويعرض استخدام وحدة المعالجة المركزية (CPU) لكلٍّ منها. تختلف النتائج بحسب عبء العمل وطريقة النشر:
2

اختر تشغيلًا ممثلًا للاستعلام

قد يكون التشغيل البطيء الوحيد حالةً شاذةً ناتجة عن استعلام مخصص أو حمل مؤقت على النظام. قبل فحص خطة الاستعلام، راجع عدة عمليات تشغيل مكتملة لها normalized_query_hash نفسه، إذ يكون متطابقًا للاستعلامات التي لا تختلف إلا في القيم الحرفية. اختر عملية تشغيل تمثل المدة المعتادة للنمط واستخدام الموارد فيه.استبدل القيمة المعيّنة لـ selected_hash بـ normalized_query_hash للنمط الذي تريد التحقيق فيه:
  1. ابحث عن عمليات تشغيل ذات قيم read_rows وread_bytes متشابهة.
  2. قارن query_duration_ms وmemory_usage لعمليات التشغيل تلك.
  3. اختر query_id الذي تكون قيمة query_duration_ms له الأقرب إلى الوسيط.
قد تختلف نتائج سجل الاستعلامات التاريخية بحسب حالة ذاكرة التخزين المؤقت وحمل النظام، لذا استخدمها لاختيار استعلام للتحقيق فيه، لا لمقارنة تغييرات التحسين. إذا لم يحتوِ سجل الاستعلامات على عدد كافٍ من عمليات التشغيل المكتملة، فشغّل الاستعلام عدة مرات في ظروف متشابهة. يشرح الدليل التالي، عزل اختناقات الاستعلام، كيفية جمع قياسات مضبوطة لمقارنة التغييرات.
تُظهر نتائج سجل الاستعلامات في المثال أن كل مرشح قرأ نحو 329.04 مليون صف. وللتأكد من ذلك، تحقق من عدد الصفوف في جدول المثال:
يحتوي الجدول على 329.04 مليون صف، وهو عدد يقترب مما أُبلِغ عنه في read_rows لكل مرشح. يشير ذلك إلى أن الاستعلامات فحصت معظم الجدول أو الجدول بأكمله، لكنه لا يوضح سبب قراءة هذه الصفوف أو ما إذا كان هذا العدد مناسبًا للاستعلام. افحص خطة الاستعلام بعد ذلك لمعرفة كيفية اختيار ClickHouse للبيانات ومعالجتها.
3

افحص خطة التنفيذ

بعد اختيار تنفيذٍ ممثّل، استخدم EXPLAIN لفحص كيفية تخطيط ClickHouse للاستعلام دون تنفيذه. يوضّح الإخراج العمليات التي يتوقع ClickHouse تنفيذها وكيفية انتقال البيانات بينها، مما يوفر سياقًا إضافيًا للقياسات في سجل الاستعلامات.للاطلاع على مقدمة تفصيلية عن تنسيقات الإخراج المتاحة، راجع فهم تنفيذ الاستعلام باستخدام المحلل. في هذا المثال، يوضح EXPLAIN كيف يخطط ClickHouse لقراءة البيانات وتصفيتها، وما إذا كان بإمكانه تجاوز أي جزء منها.الإخراج عبارة عن شجرة عمليات توضّح كيف يتوقع ClickHouse قراءة البيانات وتصفيتها ومعالجتها. تظهر العمليات الفرعية أسفل عملياتها الأصلية. ابدأ بأعمق عملية قراءة، ثم اتبع الخطة صعودًا لمعرفة كيف يحوّل ClickHouse البيانات إلى النتيجة النهائية.في هذا المثال، افحص استعلام السرعة المحسوبة من نتائج سجل الاستعلامات:
يتضمن الناتج العمليات التالية. وتعتمد تفاصيل، مثل عدد الأجزاء والحبيبات، على كيفية تخزين البيانات:
من الأسفل إلى الأعلى، تتطابق الخطة مع الاستعلام على النحو التالي:
  1. يقرأ ReadFromMergeTree من nyc_taxi.trips_small_inferred. يشير غياب قسم Indexes، إلى جانب تطابق read_rows مع عدد صفوف الجدول، إلى أن ClickHouse يقرأ الجدول بالكامل.
  2. يعرض Filter التعبير الموسّع لـ speed_mph > 30. لكل صف يُقرأ، يحسب ClickHouse مدة الرحلة وسرعتها، ثم لا يحتفظ إلا بالصفوف التي تزيد سرعتها على 30 ميلاً في الساعة.
  3. يحسب Aggregating القيم الكمية من قيم trip_distance المُرشَّحة.
تحدد هذه الخطة ثلاثة جوانب من العمل ينبغي اختبارها: قراءة كل صف، وحساب speed_mph أثناء التصفية، وحساب القيم الكمية.

الخطوات التالية

بعد ذلك، استخدم عزل اختناقات الاستعلامات للتعرّف على كيفية اختبار مصادر الحمل المشتبه بها في ظروف مضبوطة. يقارن هذا الدليل بين أشكال استعلامات تزداد بساطةً تدريجيًا لتحديد العمليات التي تستدعي مزيدًا من التحليل.
آخر تعديل في ٢٨ أغسطس ٢٠٢٦