تحليل أداء الاستعلام في ClickHouse. تقرير ياندكس

ماذا لو كان استعلام قاعدة البيانات لا يعمل بسرعة كافية؟ كيف يمكنك معرفة ما إذا كان الاستعلام يستخدم موارد الحوسبة على النحو الأمثل أم يمكن تسريعها؟ في آخر مؤتمر HighLoad ++ في موسكو ، تحدثت عن التأمل في أداء الاستعلام - سواء الذي توفره ClickHouse DBMS وميزات نظام التشغيل التي يجب على الجميع معرفتها.



في كل مرة أقوم بتقديم طلب ، أنا مهتم ليس فقط بالنتيجة ، ولكن أيضًا بما يفعله هذا الطلب. على سبيل المثال ، يعمل لمدة ثانية واحدة. هل هو كثير أم قليلا؟ أعتقد دائما: لماذا لا نصف ثانية؟ ثم أقوم بتحسين شيء ما ، وتسريعه ، ويعمل لمدة 10 مللي ثانية. أنا عادة راض. لكن مع ذلك ، في هذه الحالة أحاول التعبير عن تعبير وجهي مستاء وأسأل: "لماذا لا 5 مللي ثانية؟" كيف يمكنني معرفة الوقت الذي يقضيه في معالجة الطلب؟ هل يمكن تسريعها من حيث المبدأ؟

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

فكر في الحقائق التافهة حول الأجهزة والموارد الموجودة في خوادمنا.



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

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

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

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

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



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

دعونا نلقي نظرة فاحصة على هذا.



المورد الأسهل والأكثر ملاءمة هو المعالج. نظرتم إلى الأعلى ، تقول أن المعالج 100٪. ولكن ينبغي أن يؤخذ في الاعتبار أن هذا ليس معالج 100 ٪. البرنامج العلوي لا يعرف ما يفعله المعالج هناك. إنها تبدو من منظور مخطط OS. هذا هو ، الآن نوع من مؤشر ترابط البرنامج يعمل على المعالج. يقوم المعالج بشيء ما ، ثم سيتم عرض 100٪ إذا كان متوسطه بمرور الوقت. في الوقت نفسه ، يقوم المعالج بعمل شيء ما ، وليس من الواضح مدى فعاليته. يمكنه تنفيذ عدد مختلف من التعليمات لكل دورة. إذا كانت هناك بعض الإرشادات ، فيمكن للمعالج نفسه انتظار شيء ما ، على سبيل المثال ، تحميل البيانات من الذاكرة. في الوقت نفسه ، سيتم عرض نفس الشيء في الأعلى - 100 ٪. نحن في انتظار المعالج لاتباع تعليماتنا. وما يفعله في الداخل غير واضح.

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

إذا كنت مهتمًا بعدد مرات فقدان ذاكرة التخزين المؤقت بالداخل ، فكم عدد الإرشادات التي يتم تنفيذها في كل دورة ، استخدم سجل الأداء. سجل بعض عينات البرنامج. علاوة على ذلك ، سيكون من الممكن النظر إليه باستخدام تقرير الأداء أو تقرير الأداء.



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

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

بشكل افتراضي ، يستخدم ClickHouse فقط مراكز المعالج الفعلية ، باستثناء خيوط المعالجة المتعددة. إذا كنت تعرف أن طلبك يمكن أن يستفيد من الترابط المفرط ، ما عليك سوى مضاعفة عدد مؤشرات الترابط: SET max Threads = 32 ، وسيكون طلبك أسرع.

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



دعونا نلقي نظرة فاحصة ، خيار معقد بعض الشيء. هناك استعلام مع تعبير في الاستعلام الفرعي. داخل الاستفسار الفرعي ، لدينا 100 مليون رقم عشوائي. ونحن فقط تصفية على هذه النتيجة.

نرى مثل هذه الصورة. بالمناسبة ، من سيقول بأي أداة أستطيع أن أرى هذه الصورة الرائعة؟ صحيح تماما - perf. أنا سعيد جدًا لأنك تعرف هذا.

فتحت الكمال ، وأعتقد أنني الآن أفهم كل شيء. أنا فتح قائمة المجمع. هناك كتبت عدد مرات تنفيذ البرنامج بناءً على تعليمات معينة ، أي عدد مرات وجود مؤشر تعليمات. الأرقام هنا هي في المئة ، ومكتوب أن ما يقرب من 90 ٪ من الوقت قد تم تنفيذ اختبار٪ edx ،٪ edx ، أي فحص أربعة بايت للصفر.

والسؤال هو: لماذا يمكن للمعالج أن يستغرق وقتًا طويلاً لمجرد مقارنة أربع بايتات بصفر؟ (إجابات من الجمهور ...) لا يوجد ما تبقى من التقسيم. هناك تحولات بت ، ثم هناك تعليمات crc32q ، ولكن كما لو أن مؤشر التعليمات لا يحدث على الإطلاق. وتوليد عدد عشوائي ليس في هذه القائمة. كانت هناك وظيفة منفصلة ، وهي مُحسّنة بشكل جيد للغاية ، ولا تبطئ. هناك شيء آخر يتباطأ هنا. يتوقف تنفيذ التعليمات البرمجية عند هذه التعليمات وينفق كثيرًا من الوقت. حلقة الخمول؟ لا. لماذا يجب علي إدراج حلقات فارغة؟ وأيضًا ، إذا أدخلت حلقة الخمول ، فسيكون ذلك مرئيًا أيضًا. لا يوجد تقسيم على الصفر ، هناك ببساطة مقارنة مع الصفر.

يحتوي المعالج على خط أنابيب ، يمكنه تنفيذ العديد من التعليمات بالتوازي. وعندما يكون مؤشر التعليمات في مكان ما ، فإن هذا لا يعني على الإطلاق أنه ينفذ هذه التعليمات. ربما كان ينتظر بعض التعليمات الأخرى.

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



الآن المورد التالي ، وأكثر تعقيدا قليلا - محركات الأقراص. تسمى محركات الأقراص الصلبة أحيانًا محركات الأقراص ، على الرغم من أن هذا غير صحيح تمامًا. سيتم أيضًا تضمين محركات أقراص الحالة الصلبة في هذا المثال.

نفتح ، على سبيل المثال ، iostat ، فإنه يدل على استخدام 100 ٪.

في المؤتمرات ، يحدث غالبًا أن يتم تشغيل السماعة على خشبة المسرح ويقول مع باثوس: "قواعد البيانات تتاخم القرص دائمًا. لذلك ، قدمنا ​​قاعدة بيانات في الذاكرة. إنها لن تبطئ ". إذا اتصل بك شخص وقال لك ذلك ، يمكنك إرساله بأمان. ستكون هناك بعض المشاكل - كما قلت ، لقد قمت بحلها. :)

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

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

على سبيل المثال ، لديك مجموعة RAID والعديد من الأجهزة - على سبيل المثال ، 8 أقراص. وأنت تقرأ بالتتابع دون قراءة للأمام ، مع حجم مخزن مؤقت يبلغ 1 ميغابايت ، وحجم القطعة في الشريط الخاص بك في RAID هو أيضًا 1 ميغابايت. ثم كل قراءة سيكون لديك من جهاز واحد. أو ، إن لم تكن محاذاة ، من جهازين. سيذهب نصف ميغابايت إلى مكان ما ، ونصف آخر ميغابايت في مكان ما ، وهكذا - سيتم استخدام الأقراص بدورها: واحد ، ثم الآخر ، ثم الثلث.

يجب أن تقرأ إلى الأمام. أو إذا كان لديك O_DIRECT ، قم بزيادة حجم المخزن المؤقت. بمعنى ، القاعدة هي: 8 أقراص ، حجم قطعة 1 ميغابايت ، تعيين حجم المخزن المؤقت إلى 8 ميغابايت على الأقل. ولكن هذا لن يعمل على النحو الأمثل إلا إذا تم محاذاة القراءة. وإذا لم تتم محاذاتها ، فستكون هناك أولاً قطع إضافية ، وستحتاج إلى وضع المزيد ، بضرب عدد قليل.

أو ، على سبيل المثال ، لديك RAID 10. بأي سرعة يمكنك أن تقرأ من RAID 10 - على سبيل المثال ، من 8 أقراص؟ ماذا ستكون الميزة؟ أربعة أضعاف ، لأن هناك مرآة ، أو ثمانية أضعاف؟ في الواقع ، يعتمد ذلك على كيفية إنشاء RAID ، مع ترتيب القطع في الخطوط.

إذا كنت تستخدم mdadm على Linux ، فيمكنك تحديد التنسيق القريب والتخطيط البعيد هناك ، مع كونه أفضل للكتابة ، بعيد القراءة.

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

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

أشعل النار الرهيب الآخر هو RAID 5 أو RAID 6. كل شيء يتحرك جيدًا من خلال القراءة والكتابة المتسلسلة. في RAID 5 ، التعدد هو "عدد الأجهزة ناقص واحد." هذا المقياس جيدًا حتى مع القراءات العشوائية ، لكنه لا يتناسب بشكل جيد مع القراءات العشوائية. قم بعمل سجل في أي مكان ، وتحتاج إلى قراءة البيانات من جميع الأقراص الأخرى ، poksorit لهم (XOR - تقريبا. إد.) والكتابة إلى مكان آخر. لهذا ، يتم استخدام ذاكرة التخزين المؤقت معينة من شرائط ، وأشعل النار رهيب. في نظام Linux ، يتم إنشاء RAID 5 افتراضيًا وسيتباطأ من أجلك. وستعتقد أن RAID 5 يبطئ دائمًا ، لأن هذا أمر مفهوم. ولكن في الواقع ، والسبب هو الإعداد الخاطئ.

مثال آخر أنت تقرأ من SSD ، واشتريت لنفسك SSD جيدًا ، تقول 300 ألف قراءة عشوائية في الثانية في المواصفات. ولسبب ما لا يمكنك القيام بذلك. وتعتقد - نعم كلها تقع في مواصفاتها ، لا يوجد شيء من هذا القبيل. لكن كل هذه القراءات يجب أن تتم بالتوازي ، مع أقصى درجة من التوازي. الطريقة الوحيدة للقيام بذلك على النحو الأمثل هي استخدام I / O غير المتزامن ، والذي يتم تنفيذه باستخدام مكالمات النظام io_submit ، io_getevents ، io_setup ، إلخ.

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

- ClickHouse يضغط البيانات. أراه تقع على المعالج. لدي محركات أقراص الحالة الصلبة NVMe سريعة جدًا ، ولديها سرعة قراءة تبلغ عدة غيغابايت في الثانية. هل من الممكن تعطيل الضغط بطريقة ما في ClickHouse؟
"لا ، لا ،" أقول. - تحتاج إلى الحفاظ على ضغط البيانات.
- دعنا نتوقف عن ذلك ، سيكون هناك خوارزمية ضغط أخرى لا تفعل شيئًا.
- سهل. أدخل هذه الحروف في سطر التعليمات البرمجية هذا.
"في الواقع ، كل شيء بسيط للغاية" ، أجاب بعد يوم واحد. - لقد فعلت.
- كم تغير الأداء؟
"فشل في اختبار" ، وكتب في وقت لاحق يوم آخر. - هناك الكثير من البيانات. لم تعد صالحة على SSDs.

دعونا الآن نرى كيف تبدو القراءة من القرص. نبدأ dstat ، فإنه يدل على سرعة القراءة.


هنا عمود القراءة - 300 ميجابايت / ثانية. نقرأ من الأقراص. إنه كثير أو قليل - لا أعرف.

الآن أركض iostat للتحقق من ذلك. هنا يمكنك أن ترى انهيار حسب الجهاز. لدي RAID ، MD2 ، وثمانية محركات أقراص صلبة. كل منهم يظهر إعادة التدوير ، لا يصل حتى 100 ٪ (50-60 ٪). ولكن الشيء الأكثر أهمية هو أنني قرأت من كل قرص فقط بسرعة 20-30 ميغا بايت / ثانية. ومنذ الطفولة تذكرت القاعدة التي يمكنك قراءتها في مكان ما من 100 ميجابايت / ثانية من القرص الصلب. لسبب ما ، لم يتغير هذا كثيرًا.


هنا مثال آخر. القراءة هي الأمثل. أقوم بتشغيل dstat ولدي سرعة قراءة تبلغ 1 جيجابايت / ثانية من RAID 5 من أصل ثمانية محركات أقراص. ماذا تظهر iostat؟ نعم ، حوالي 1 جيجابايت / ثانية.

الآن يتم الآن تحميل محركات الأقراص بنسبة 100 ٪. صحيح ، لسببين ، هما 100 ٪ ، والباقي 95 ٪. ربما ، فهي لا تزال مختلفة بعض الشيء. ولكن مع كل واحد منهم قرأت 150 ميغا بايت / ثانية ، حتى أكثر برودة مما يمكن أن يكون. ما هو الفرق؟ في الحالة الأولى ، قرأت مع حجم المخزن المؤقت غير كافية في القطع غير كافية. انها بسيطة ، وأنا أقول لك الحقائق المشتركة.

بالمناسبة ، إذا كنت تعتقد أن البيانات ما زالت لا تحتاج إلى ضغط لقاعدة البيانات التحليلية ، أي تقرير من مؤتمر HighLoad ++ Siberia ( habrastaty يستند إلى التقرير - تقريبًا ). قرر المنظمون إعداد التقارير الأكثر تشددًا في نوفوسيبيرسك.



المثال التالي هو الذاكرة. استمرار الحقائق المشتركة. أولاً ، على نظام Linux ، لا ترى أبدًا ما هي العروض المجانية. بالنسبة لأولئك الذين يشاهدون ، أنشأوا خصيصا موقع linuxatemyram.com. تعال ، سيكون هناك تفسير. لا تحتاج إلى إلقاء نظرة على مقدار الذاكرة الظاهرية أيضًا ، لأنه ما الفرق ، كم مساحة العنوان المخصصة للبرنامج؟ انظر إلى مقدار الذاكرة الفعلية المستخدمة.

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

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



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

أو تخيل - أنت تقوم بنقل ملف ، ولديك كمون كبير على شبكتك وفقدان حزم جيد. إذن ، ليس واضحًا على الإطلاق ما إذا كان من الصحيح استخدام TCP لنقل الملفات. أعتقد أن هذا خطأ ، لأن TCP يضمن الاتساق. من ناحية أخرى ، يمكنك نقل نصف الملف والآخر في نفس الوقت. TCP- TCP . , , , TCP . .

100- , . 10 -, , , . . .



? — . , , , 10 . , .



: « - » — . iotop, , , iops.

, . .


top -, , clickHouse-server - , - . , , Shift+H, . , ClickHouse . ParalInputsProc, . BackgrProcPool — merges . , .

? ClickHouse, , . BackgroundProcessingPool. 15 . 16 1, 1 — . 16? , Linux — , : «16 . ». :)

clickhouse-benchmark. clickhouse-client. , clickhouse-client, . - . .


. clickhouse-benchmark, , , , , . peft top. peft top, . , - -, uniq: UniquesHashSet. . , . , .

, , . — -. , , XOR - . -. - -. , -.

, , crc32q. , , - , - .

, ClickHouse. , , . ClickHouse.



. , — , SHOW PROCESSLIST. . , SELECT * FROM system processes. : , , . ClickHouse top.

ClickHouse ? background-. Background- — merges. , merges , SELECT * FROM system.merges.


, . -. . — ClickHouse. . , , . , . - traf_testing. ? , , . ClickHouse .



. , . , , , , . query_log. — , - , SELECT , - . query_log , . - . — , . : .

, , — merge, inserts, . part_log. , .



query_log clickhouse-benchmark. select , , stdin clickhouse-benchmark.

query_log - , .



, , . . SET send_logs_level = 'trace', , .


, . , 98%. , . انها بسيطة جدا. SET send_logs_level = 'trace', , . - : merging aggregated data, . 1% . , .

, , query_log.

. SELECT * FROM system.query_log . . , , , query_log. . — , , , . .



ClickHouse . — system.events, system.metrics system.asynchronous_metrics. Events — , , . 100 . — 10 . system.metrics — . , 10 , 10 .

system.asynchronous_metrics , . . — . , system.asynchronous_metrics — , - . , .

, . SHOW PROCESSLIST . query_log, .



, . , . , . , , . , Linux, . Linux . , . , . .

, OSReadChars OSReadBytes. ? , , , . , . , , , . , - , .


, . - . , 40 , 6,7 . . , , . , , .

, 1,3 , 5 . لماذا؟ , — page cache. ?


. . , , . . : 3,2 , — 2,5 . , , , . لماذا؟ -, : read ahead. , — ? -, — 4 , , 512 KB. . , . , - read ahead.



. . , . , , ReadBytes — , . 3 , 3 . , , .

— IOWait. 87 . 7 , IOWait — 87. ? — . . , , 87 . , - .

— CPUWait. , , , . - — , . CPU. CPU. - , . — , , user space. , - . حسنا حسنا.

— , Linux. - , . , , .


, : query_thread_log. , .

, query_id « , user space». . 16 . 800 . 16 , 0,25 . , .

HighLoad++: