الموارد
- الموارد المشتركة زمنيًا (CPU, IO, فتحات الاستعلام) - تدير طلبات الموارد التي توضع في قائمة الانتظار عند العقد الطرفية في التسلسل الهرمي للجدولة. تُجدول الطلبات وفقًا للسياسات والقيود التي يحددها هذا التسلسل الهرمي. تُنشأ طلبات الموارد عندما يستخدم الاستعلام المورد المقابل. على سبيل المثال، عندما يقرأ استعلام بيانات من disk، أو يستخدم CPU للمعالجة، تُنشأ طلبات موارد لكل حصة زمنية من العمل المنجز أو لكل عدد من البايتات المرسلة أو المستقبلة عبر socket.
- الموارد المشتركة من حيث المساحة (الذاكرة) - تدير تخصيصات الموارد عند العقد الطرفية في التسلسل الهرمي للجدولة. يمكن أن تكون التخصيصات قيد التشغيل أو معلّقة. تُحجب التخصيصات المعلّقة إلى أن تتوفر مساحة كافية أو يُزال تخصيص آخر (يُقتل). تستند القرارات إلى الحدود والسياسات التي يحددها التسلسل الهرمي. توجد مطابقة واحد إلى واحد بين التخصيصات والاستعلامات (أو الأنشطة الخلفية). يُنشأ التخصيص عندما يبدأ الاستعلام التنفيذ، ويُحرَّر عند انتهائه. ويمكن أن يزيد حجم التخصيصات قيد التشغيل أو ينقص ديناميكيًا.
التسلسل الهرمي لأحمال العمل
max_* تكون لكل مضيف. ويقسّم عبء العمل “user” موارده بين عبئي العمل “development” و”production”، بحيث يمتلك “production” موارد تزيد 3 مرات على “development”:
SETTINGS workload = 'name'. راجع وسم عبء العمل للحصول على التفاصيل.
لتخصيص عبء العمل، يمكن استخدام الإعدادات التالية:
priority- (للمشاركة الزمنية فقط) تتم خدمة أعباء العمل الشقيقة وفقًا لقيم ثابتة (القيمة الأقل تعني أولوية أعلى). ويؤثر ذلك في الاستباق.precedence- (للمشاركة المكانية فقط) تُقبَل أعباء العمل الشقيقة وفقًا لقيم ثابتة (القيمة الأقل تعني أسبقية أعلى). ويؤثر ذلك في الإخلاء والقبول.weight- تتشارك أعباء العمل الشقيقة ذات الأولوية أو الأسبقية الثابتة نفسها الموارد وفقًا للأوزان بطريقة عادلة. ويؤثر ذلك في الاستباق والإخلاء والقبول.max_io_requests- الحد الأقصى لعدد طلبات IO المتزامنة في عبء العمل هذا.max_bytes_inflight- الحد الأقصى لإجمالي البايتات قيد المعالجة للطلبات المتزامنة في عبء العمل هذا.max_bytes_per_second- الحد الأقصى لمعدل قراءة أو كتابة البايتات في عبء العمل هذا.max_burst_bytes- الحد الأقصى لعدد البايتات التي يمكن أن يعالجها عبء العمل من دون تقييد المعدل (لكل مورد على حدة).max_concurrent_threads- الحد الأقصى لعدد خيوط التنفيذ الخاصة بالاستعلامات في عبء العمل هذا.max_concurrent_threads_ratio_to_cores- مثلmax_concurrent_threads، ولكن محسوب نسبةً إلى عدد أنوية CPU المتاحة.max_cpus- الحد الأقصى لعدد أنوية CPU المستخدمة لخدمة الاستعلامات في عبء العمل هذا.max_cpu_share- مثلmax_cpus، ولكن محسوب نسبةً إلى عدد أنوية CPU المتاحة.max_burst_cpu_seconds- الحد الأقصى لعدد ثواني CPU التي يمكن أن يستهلكها عبء العمل من دون تقييد المعدل بسببmax_cpus.max_memory- الحد الأقصى لإجمالي الذاكرة المحجوزة لعبء العمل هذا.
max_bytes_per_second = '10Mi' ستكون له سعة نطاق قدرها 10 MB/s لكل مورد قراءة ومورد كتابة على حدة. إذا كان مطلوبًا حدٌّ مشترك للقراءة والكتابة، ففكّر في استخدام المورد نفسه لوصول READ وWRITE.
لا توجد طريقة لتحديد هياكل هرمية مختلفة لأعباء العمل لموارد مختلفة. ولكن توجد طريقة لتحديد قيمة مختلفة لإعداد عبء العمل لمورد معيّن:
CREATE OR REPLACE WORKLOAD.
تُترجم إعدادات عبء العمل إلى مجموعة مناسبة من عُقَد الجدولة. ولمزيد من التفاصيل ذات المستوى الأدنى، راجع وصف أنواع عُقَد الجدولة وخياراتها.
وسم عبء العمل
workload لتمييز أعباء العمل المختلفة. وإذا لم يتم تعيين workload، فستُستخدم القيمة “default”. لاحظ أنه يمكنك أيضًا تحديد قيمة أخرى باستخدام ملفات تعريف الإعدادات. ويمكن استخدام قيود الإعداد لجعل workload ثابتًا إذا كنت تريد وسم جميع استعلامات المستخدم بقيمة ثابتة لإعداد workload.
workload لعمليات الخلفية. وتستخدم عمليات الدمج والطفرات إعدادَي الخادم merge_workload وmutation_workload على الترتيب. ويمكن أيضًا تجاوز هذه القيم لجداول محددة باستخدام إعدادَي MergeTree merge_workload وmutation_workload.
جدولة CPU
- الخيط الرئيسي — أول خيط يبدأ العمل على استعلام أو نشاط في الخلفية مثل عملية دمج أو عملية mutation.
- خيط العامل — الخيوط الإضافية التي يمكن للخيط الرئيسي إنشاؤها للعمل على المهام كثيفة الاستهلاك للمعالج.
max_threads. وعندئذٍ ينبغي أن تُحجب الاستعلامات الواردة وتنتظر توفّر فتحة CPU حتى تتمكن خيوطها الرئيسية من بدء التنفيذ. ولتجنّب ذلك، يمكن استخدام الإعداد التالي:
cpu_slot_preemption. وإذا كان مفعّلًا، يجدّد كل خيط تنفيذ فتحة CPU الخاصة به دوريًا (وفقًا لإعداد الخادم cpu_slot_quantum_ns). وقد يؤدي هذا التجديد إلى حظر التنفيذ إذا كان CPU مثقلاً. وعندما يُحظر التنفيذ لفترة طويلة (راجع إعداد الخادم cpu_slot_preemption_timeout_ms)، يُقلَّص الاستعلام وينخفض عدد خيوط التنفيذ المتزامنة العاملة ديناميكيًا. لاحظ أن عدالة وقت CPU مضمونة بين أعباء العمل، لكنها قد لا تتحقق بين الاستعلامات داخل عبء العمل نفسه في بعض الحالات الطرفية.
يؤدي تعريف مورد CPU إلى إبطال مفعول الإعدادين
concurrent_threads_soft_limit_num وconcurrent_threads_soft_limit_ratio_to_cores. وبدلاً من ذلك، يُستخدم إعداد عبء العمل max_concurrent_threads لتقييد عدد وحدات CPU المخصّصة لعبء عمل معيّن. وللحصول على السلوك السابق، أنشئ فقط مورد WORKER THREAD، واضبط max_concurrent_threads لعبء العمل all على القيمة نفسها لـ concurrent_threads_soft_limit_num، واستخدم إعداد الاستعلام workload = "all". ويتوافق هذا الضبط مع تعيين الإعداد concurrent_threads_scheduler إلى القيمة “fair_round_robin”.الخيوط مقابل وحدات CPU
- حد عدد الخيوط:
max_concurrent_threadsوmax_concurrent_threads_ratio_to_cores - خنق CPU:
max_cpusوmax_cpu_shareوmax_burst_cpu_seconds
max_threads. أما الطريقة الثانية فتقوم بخنق استهلاك CPU لعبء العمل باستخدام خوارزمية token bucket. وهي لا تؤثر مباشرةً في عدد الخيوط، لكنها تحدّ من إجمالي استهلاك CPU لجميع الخيوط في عبء العمل.
يعني خنق token bucket باستخدام max_cpus و max_burst_cpu_seconds ما يلي: خلال أي interval مقداره delta ثانية، لا يُسمح بأن يزيد إجمالي استهلاك CPU لجميع الاستعلامات في عبء العمل على max_cpus * delta + max_burst_cpu_seconds ثانية CPU. وهو يقيّد متوسط الاستهلاك عند max_cpus على المدى الطويل، لكن قد يتم تجاوز هذا الحد على المدى القصير. على سبيل المثال، إذا كانت max_burst_cpu_seconds = 60 و max_cpus=0.001، فيُسمح بتشغيل خيط واحد لمدة 60 ثانية، أو خيطين لمدة 30 ثانية، أو 60 خيطًا لمدة ثانية واحدة، من دون خنق. القيمة الافتراضية لـ max_burst_cpu_seconds هي ثانية واحدة. وقد تؤدي القيم الأقل إلى عدم الاستفادة الكاملة من الأنوية المسموح بها في max_cpus عند وجود عدد كبير من الخيوط المتزامنة.
أثناء احتفاظ خيط بفتحة CPU، يمكن أن يكون في واحدة من ثلاث حالات رئيسية:
- Running: يستهلك مورد CPU فعليًا. ويُحتسب الوقت المقضي في هذه الحالة ضمن خنق CPU.
- Ready: ينتظر حتى تصبح وحدة CPU متاحة. لا يُحتسب الوقت المقضي في هذه الحالة ضمن خنق CPU.
- Blocked: ينفّذ عمليات IO أو استدعاءات نظام حاجبة أخرى (مثل انتظار mutex). لا يُحتسب الوقت المقضي في هذه الحالة ضمن خنق CPU.
default ذي القيمة 0)، ويحصل أولًا على أي فتحة CPU عند الحاجة. وعندما لا يُشغّل Admin أي استعلامات، تُوزَّع موارد CPU بين أعباء عمل الإنتاج والتطوير. وتعتمد الحصص المضمونة من وقت CPU على الأوزان (4 إلى 1): يذهب ما لا يقل عن 80% إلى الإنتاج (عند الحاجة)، ويذهب ما لا يقل عن 20% إلى التطوير (عند الحاجة). وبينما توفّر الأوزان هذه الضمانات، يفرض تقييد CPU حدودًا: فالإنتاج غير مقيَّد ويمكنه استهلاك 100%، بينما للتطوير حدّ قدره 30%، ويُطبَّق هذا الحد حتى إذا لم تكن هناك استعلامات من أعباء عمل أخرى. وعبء عمل الإنتاج ليس عقدة طرفية، لذا تُقسَّم موارده بين التحليلات والاستيعاب وفقًا للأوزان (3 إلى 1). وهذا يعني أن التحليلات لها حصة مضمونة لا تقل عن 0.8 * 0.75 = 60%، وبالاستناد إلى max_cpu_share، فلها حد أقصى يبلغ 70% من إجمالي موارد CPU. أما الاستيعاب، فرغم أن حصته المضمونة لا تقل عن 0.8 * 0.25 = 20%، فلا يوجد له حد أعلى.
إذا كنت تريد زيادة استخدام CPU إلى أقصى حد على ClickHouse server، فتجنّب استخدام
max_cpus وmax_cpu_share لعبء العمل الجذر all. وبدلًا من ذلك، اضبط قيمة أعلى لـ max_concurrent_threads. على سبيل المثال، في نظام يحتوي على 8 وحدات CPU، اضبط max_concurrent_threads = 16. يتيح ذلك تشغيل 8 خيوط لمهام CPU، بينما يمكن لـ 8 خيوط أخرى التعامل مع عمليات I/O. وستُحدِث الخيوط الإضافية ضغطًا على CPU، ما يضمن تطبيق قواعد الجدولة. وعلى النقيض من ذلك، فإن ضبط max_cpus = 8 لن يُحدِث أبدًا ضغطًا على CPU لأن الخادم لا يمكنه تجاوز وحدات CPU الثماني المتاحة.حجوزات الذاكرة
جدولة حجوزات الذاكرة تجريبية. ولا تسري إلا عند وجود مورد
MEMORY RESERVATION، وقد تتغير صيغتها في SQL وسلوكها في الإصدارات المستقبلية. وهي غير مدعومة بعد لعمليات الدمج والطفرات، كما أن إخلاء استعلام قيد التشغيل يتم على أساس أفضل جهد: إذ يسري عند نقطة مزامنة الذاكرة التالية للاستعلام بدلًا من أن يحدث فورًا.MEMORY RESERVATION واضبط حدًا واحدًا على الأقل لإجمالي الذاكرة المحجوزة باستخدام إعدادات أعباء العمل:
reserve_memory للاستعلام أكبر من صفر، فسيُنشأ التخصيص في حالة معلّقة. ويحجز التخصيص المعلّق مقدار الذاكرة المطلوب ضمن التسلسل الهرمي لعبء العمل. وإذا لم تكن هناك ذاكرة متاحة كافية، فسيظل التخصيص معلّقًا إلى أن تتحرر ذاكرة كافية أو تُزال تخصيصات أخرى (تُقتل). وعندما يُقبَل التخصيص، يصبح قيد التشغيل. ويمكن أن يزيد التخصيص قيد التشغيل حجمه أو يقلّصه ديناميكيًا وفقًا لاستهلاك الاستعلام للذاكرة. ويمكن تمثيل دورة حياة التخصيص بمخطط الحالات التالي:
تُقبَل تخصيصات عبء العمل الطرفي المعلّقة وفق ترتيب FIFO. وعندما تكون هناك عدة أعباء عمل لديها تخصيصات معلّقة، تُقبَل وفق إعدادات الأسبقية والأوزان. وتُخدَم أعباء العمل ذات الأسبقية الأعلى أولًا. أما أعباء العمل الشقيقة ذات الأسبقية نفسها فتتقاسم الذاكرة وفق الأوزان بطريقة عادلة من نوع max-min، ما يعني أن عبء العمل ذو استخدام الذاكرة المعياري الأقل (الاستخدام الحالي مضافًا إليه الزيادة المطلوبة ثم مقسومًا على الوزن) يُخدَم أولًا. ويُطبَّق المنطق العكسي أثناء الإخلاء. وعندما يلزم تحرير الذاكرة، تُخلى أولًا أعباء العمل ذات الأسبقية الأدنى واستخدام الذاكرة المعياري الأعلى.
لاحظ أن الموارد المشتركة زمنيًا تستخدم الأولوية، بينما الموارد المشتركة من حيث السعة تستخدم الأسبقية. وهما إعدادان مستقلان ويمكن ضبطهما على قيم مختلفة. فالأولوية الأعلى تعني استباقًا غير هدّام (تأخيرًا أو تقييدًا)، بينما قد تعني الأسبقية الأعلى إخلاءً هدّامًا (إيقافًا مصحوبًا بخطأ). وقد يكون لعبء العمل أولوية عالية لجدولة CPU، مع احتفاظه بالأسبقية نفسها لحجز الذاكرة، لتجنّب إخلاء أعباء عمل أخرى وفقدان العمل الذي أُنجز فيها بالفعل.
يضمن كل عبء عمل لديه حد max_memory ألا يتجاوز إجمالي الذاكرة المخصّصة في شجرته الفرعية هذا الحد. وإذا كان تخصيص معلّق أو زيادة في تخصيص قائم سيتجاوز هذا الحد، فسيبدأ إجراء الإخلاء لتحرير الذاكرة. ويختار إجراء الإخلاء ضحيةً لإنهائها. ويمنع عبء العمل الذي يمثّل السلف المشترك الأدنى بين المتسبّب بالإخلاء والضحية عملية الإخلاء في الحالات التالية:
- لا يمكن للتخصيص المعلّق أن يُخلي تخصيصات قيد التشغيل داخل عبء العمل نفسه. (يتطابق عبءا العمل: المتسبّب بالإخلاء والضحية).
- لا يمكن مطلقًا لتخصيص معلّق ذي أسبقية أدنى أن يُنهي عبء عمل ذي أسبقية أعلى.
- لا يمكن للتخصيص المعلّق أن يُنهي تخصيصًا له الأسبقية نفسها. لاحظ أن التخصيصات قيد التشغيل ذات الأسبقية نفسها قد تُخلي بعضها بعضًا استنادًا إلى استخدام الذاكرة المعياري. وإذا مُنع الإخلاء أو لم يحرر قدرًا كافيًا من الذاكرة، فسيُحظر التخصيص الجديد حتى تتحرر ذاكرة كافية. وتسمح هذه القواعد بوضع الاستعلامات الزائدة في قائمة الانتظار استنادًا إلى ضغط الذاكرة، وتوفّر طريقة ملائمة لتجنّب أخطاء MEMORY_LIMIT_EXCEEDED.
حدود عبء العمل مستقلة عن الطرق الأخرى لتقييد استهلاك الذاكرة، مثل إعداد الاستعلام max_memory_usage. ويمكن استخدامها معًا لتحقيق تحكم أفضل في استهلاك الذاكرة. ومن الممكن تعيين حدود مستقلة للذاكرة استنادًا إلى المستخدمين (وليس أعباء العمل). وهذا أقل مرونة ولا يوفّر ميزات مثل حجز الذاكرة ووضع الاستعلامات المعلّقة في قائمة الانتظار. راجع Memory overcommit
max_waiting_queries من عدد التخصيصات المعلّقة لعبء العمل. وعند بلوغ الحد، يُرجع الخادم الخطأ SERVER_OVERLOADED. لاحظ أن max_waiting_queries لا يُورَّث إلى أعباء العمل الفرعية، ولا يكون ذا معنى إلا لأعباء العمل الطرفية.
لا تزال جدولة حجز الذاكرة غير مدعومة لعمليات الدمج والطفرات حتى الآن.
فقط الاستعلامات التي يكون فيها الإعداد reserve_memory أكبر من الصفر تكون عرضةً للحجب أثناء انتظار حجز الذاكرة. ومع ذلك، فإن الاستعلامات التي تكون فيها قيمة reserve_memory صفراً تُحتسب أيضاً ضمن البصمة الذاكرية لعبء العمل الخاص بها، ويمكن إزاحتها عند الحاجة لتحرير الذاكرة من أجل تخصيصات أخرى معلّقة أو متزايدة. أما الاستعلامات التي لا تحتوي على وسم عبء عمل مناسب، فلا تخضع لجدولة حجز الذاكرة، ولا يمكن للمجدول إزاحتها.
لتوفير حجز ذاكرة غير مرن لاستعلام ما، اضبط كلاً من إعدادَي الاستعلام reserve_memory وmax_memory_usage على القيمة نفسها. في هذه الحالة، سيحجز الاستعلام مقداراً ثابتاً من الذاكرة، ولن يكون قادراً على زيادة تخصيصه ديناميكياً. لاحظ أن حجز الذاكرة المرن يمكن زيادته فوق reserve_memory حتى max_memory_usage من دون إنهاء الاستعلام، ما لم يكن هناك ضغط على الذاكرة. لكنه لا يمكن أن ينخفض إلى ما دون reserve_memory حتى عندما يكون الاستهلاك الفعلي أقل.
لننظر إلى مثال على إعداد:
جدولة حصص الاستعلام
max_concurrent_queries من عدد الاستعلامات المتزامنة التي يمكن تشغيلها في الوقت نفسه لعبء عمل معيّن. وهو مماثل لإعداد الاستعلام max_concurrent_queries_for_all_users وإعداد الخادم max_concurrent_queries. ولا تُحتسب استعلامات async insert وبعض الاستعلامات المحددة، مثل KILL، ضمن هذا الحد.
يحدّ إعدادا عبء العمل max_queries_per_second وmax_burst_queries عدد الاستعلامات لعبء العمل باستخدام مُقيِّد من نوع token bucket. ويضمن ذلك أنه خلال أي فترة زمنية T لن يبدأ تنفيذ أكثر من max_queries_per_second * T + max_burst_queries من الاستعلامات الجديدة.
يحدّ إعداد عبء العمل max_waiting_queries من عدد الاستعلامات المنتظرة لعبء العمل. وعند بلوغ هذا الحد، يعيد الخادم الخطأ SERVER_OVERLOADED. لاحظ أن max_waiting_queries لا يُورَّث إلى أعباء العمل الفرعية ولا يكون ذا معنى إلا لأعباء العمل الطرفية.
ستنتظر الاستعلامات المحجوبة إلى أجل غير مسمّى، ولن تظهر في
SHOW PROCESSLIST حتى تُستوفى جميع القيود.تخزين أحمال العمل والموارد
CREATE WORKLOAD وCREATE RESOURCE، تخزينًا دائمًا إما على القرص في workload_path أو في ZooKeeper عند workload_zookeeper_path. ويُوصى باستخدام التخزين في ZooKeeper لتحقيق الاتساق بين العُقد. وبدلًا من ذلك، يمكن استخدام البند ON CLUSTER إلى جانب التخزين على القرص.
أحمال العمل والموارد المستندة إلى التهيئة
تنسيق التهيئة
CREATE WORKLOAD وCREATE RESOURCE. يجب أن تكون جميع الاستعلامات صحيحة.
توصيات الاستخدام
- حدِّد عبء العمل الجذري وموارد IO للشبكة في التهيئة لوضع حدود البنية التحتية
- اضبط
throw_on_unknown_workloadلفرض هذه الحدود - أنشئ
CREATE WORKLOAD default IN allلتطبيق الحدود تلقائيًا على جميع الاستعلامات (لأن القيمة الافتراضية لإعداد الاستعلامworkloadهي ‘default’) - اسمح للمستخدمين بإنشاء أعباء عمل إضافية ضمن التسلسل الهرمي المُعدّ
الوصول المقيّد إلى الموارد
throw_on_unknown_workload. إذا ضُبط على true، فسيُطلب من كل استعلام استخدام إعداد workload صالح، وإلا فسيُرفع الاستثناء RESOURCE_ACCESS_DENIED. وإذا ضُبط على false، فلن يستخدم هذا الاستعلام مجدول الموارد، أي سيحصل على وصول غير محدود إلى أي RESOURCE. يتيح إعداد الاستعلام ‘use_concurrency_control = 0’ للاستعلام تجاوز مجدول CPU والحصول على وصول غير محدود إلى CPU. ولفرض جدولة CPU، أنشئ قيدًا على الإعداد للإبقاء على ‘use_concurrency_control’ كقيمة ثابتة للقراءة فقط.
لا تضبط
throw_on_unknown_workload على true ما لم يكن CREATE WORKLOAD default قد نُفِّذ. فقد يؤدي ذلك إلى مشكلات في بدء تشغيل الخادم إذا نُفِّذ أثناء بدء التشغيل استعلام بدون إعداد workload صريح.التسلسل الهرمي لعُقد الجدولة
inflight_limit(قيد) - يمنع التنفيذ إذا تجاوز عدد الطلبات الجارية المتزامنةmax_requests، أو إذا تجاوزت تكلفتها الإجماليةmax_cost؛ ويجب أن تكون له عقدة فرعية واحدة.bandwidth_limit(قيد) - يمنع التنفيذ إذا تجاوز عرض النطاق الحاليmax_speed(0 تعني غير محدود) أو تجاوز الاندفاعmax_burst(يساويmax_speedافتراضيًا)؛ ويجب أن تكون له عقدة فرعية واحدة.fair(سياسة) - يختار الطلب التالي للخدمة من إحدى عقده الفرعية وفقًا للإنصاف الأقصى-الأدنى؛ ويمكن للعقد الفرعية تحديدweight(القيمة الافتراضية هي 1).priority(سياسة) - يختار الطلب التالي للخدمة من إحدى عقده الفرعية وفقًا للأولويات الثابتة (القيمة الأقل تعني أولوية أعلى)؛ ويجب على العقد الفرعية تحديدpriority(القيمة الافتراضية هي 0).fifo(طابور) - عقدة طرفية في التسلسل الهرمي قادرة على الاحتفاظ بالطلبات التي تتجاوز سعة الموارد.
limit- يضمن ألا يتجاوز إجمالي تخصيصات العقدة الفرعية حدًا معينًا، ويبدأ إجراء الإخلاء في شجرة فرعية عند الحاجة؛ ويجب أن تكون له عقدة فرعية واحدة.fair_allocation- يفرض الإخلاء وفقًا للإنصاف الأقصى-الأدنى؛ ولا تُخلي التخصيصات المعلّقة التخصيصات قيد التشغيل مطلقًا؛ ويمكن للعقد الفرعية تحديدweight(القيمة الافتراضية هي 1).precedence_allocation- يفرض الإخلاء وفقًا للأسبقية الثابتة (القيمة الأقل تعني أسبقية أعلى)؛ وتُخلي التخصيصات المعلّقة ذات الأسبقية الأعلى التخصيصات ذات الأسبقية الأقل؛ ويجب على العقد الفرعية تحديدprecedence(القيمة الافتراضية هي 0).queue- عقدة طرفية في التسلسل الهرمي قادرة على الاحتفاظ بالتخصيصات قيد التشغيل والمعلّقة.
تهيئة XML المهملة
storage_configuration الخاصة بالخادم:
لتمكين جدولة IO لقرص معيّن، يجب تحديد read_resource و/أو write_resource في إعدادات التخزين. يحدّد ذلك لـ ClickHouse المورد الذي يجب استخدامه لكل طلب قراءة وكتابة على القرص المحدد. ويمكن أن يشير مورد القراءة ومورد الكتابة إلى اسم المورد نفسه، وهو ما يفيد مع أقراص Local SSD أو HDD. كما يمكن أن تشير عدة أقراص مختلفة إلى المورد نفسه، وهو ما يفيد مع الأقراص البعيدة إذا كنت تريد إتاحة تقسيم عادل لعرض نطاق الشبكة بين أعباء العمل مثلًا “الإنتاج” و”التطوير”.
مثال:
راجع أيضًا
- system.scheduler
- system.workloads
- system.resources
- merge_workload إعداد MergeTree
- merge_workload إعداد عام على مستوى الخادم
- mutation_workload إعداد MergeTree
- mutation_workload إعداد عام على مستوى الخادم
- workload_path إعداد عام على مستوى الخادم
- workload_zookeeper_path إعداد عام على مستوى الخادم
- cpu_slot_preemption إعداد عام على مستوى الخادم
- cpu_slot_quantum_ns إعداد عام على مستوى الخادم
- cpu_slot_preemption_timeout_ms إعداد عام على مستوى الخادم