"20000 IOPS لكل عقدة هي أداء جيد مع وقت استجابة 5 مللي ثانية." ل OLTP - لا

كان سبب كتابة هذا المقال مراجعة جديرة للغاية بكيفية اختبار VMware vSAN ... CROC. إن المراجعة جديرة بالاهتمام ، لكنها تحتوي على عبارة كنت أواجهها منذ أكثر من عقد. يكرر مديرو التخزين والمحاولون الافتراضيون والمتكاملون مرارًا وتكرارًا: "التأخير لمدة 5 مللي ثانية يعد مؤشرًا ممتازًا". حتى الرقم 5 مللي ثانية لمدة عشر سنوات لا يتغير. سمعت هذا مباشرة من مدراء محترمين للغاية ما لا يقل عن اثنتي عشرة مرة. من الأقل احترامًا - العشرات ، وعدد المرات التي قرأت فيها على الإنترنت ... لا ، لا ، لا. بالنسبة لأحمال OLTP التي تبلغ 5 مللي ثانية ، خاصةً حيث يتم قياسها عادةً ، تكون هذه أعطال ملحمية. كان عليّ أن أشرح أسباب ذلك عدة مرات ، هذه المرة قررت جمع أفكاري في شكل قابل لإعادة الاستخدام.

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

بداية نموذجية

كل ما تم وصفه في هذه المقالة ينطبق على أنظمة إدارة قواعد البيانات (DBMS) الشائعة المستخدمة في OLTP التجارية النموذجية. الأهم من كل ذلك لدي خبرة مع MS SQL Server ، ولكن على الأقل بالنسبة لـ PostgeSQL و Oracle و Sybase ، ستظل العديد من النقاط والاستنتاجات صحيحة أيضًا.

DBMS الأداء عادة ما يكون غير سعيد مع الجميع. إذا كان هناك نظام إدارة قواعد البيانات (DBMS) في نظام كبير - وهو فجأة موجود دائمًا تقريبًا - فإن نظام إدارة قواعد البيانات (DBMS) هذا يمثل اختناقًا. حسنًا ، أو سيصبح عنق الزجاجة على الفور إذا بدأت في تحسين كل شيء آخر. وهكذا ، يأتي العميل ويقول بصوت بشري: "مساعدة! وفر! لقد دفعوا NNNNNNNN $ مقابل الخادم والتخزين ، ولكن السرعة لا تزداد! إذا كان مطورو النظام يتناسبون مع تعريف Lavrov (يمكننا الاستغناء عن عرض أسعار دقيق) ، ويعاني أخصائيو التشغيل والصيانة "من مشاكل مع إعادة تشغيل الخادم" ، فإن المشكلة غالبًا ما تكون بسيطة وبسيطة: لا توجد فهارس ، استعلامات معوجة ، أخطاء تكوين فادحة (حول الوثائق غامق) تقول "لا يمكنك أن تفعل هذا !!!" ) ، والأقفال المفرطة ، والمآزق وغيرها من الهراء البسيط والواضح. هناك العديد من هذه الحالات ، معظمها ، ولكن ليس كلها. إذا تجاوز النظام ، في التعقيد أو الحمل ، بعض الحدود غير المرئية ، فسوف يموت إما بسبب هذه المشاكل أو ينتقل إلى المستوى التالي.

على هذا المستوى ، لم يعد الخادم تحت طاولة المدير ، ولم تعد الأقراص داخل الخادم ، ولكن في نظام التخزين ، يعرف المطورون الفهارس ، ويعرف المسؤولون بالفعل PowerShell ، ويبدأ مديرو تكنولوجيا المعلومات في قول كلمات ذكية مثل SLA و RPO / RTO. ينشأ وضع مثير للاهتمام على هذا المستوى:

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

لكن لا. التمساح لا يتم اصطياده ، جوز الهند لا ينمو ، وأداء النظام هو نفسه أو أقل من الخادم القديم. أبحث في sys.dm_os_waitsats وأرى PAGEIOLATCH_SH و PAGEIOLATCH_SH و PAGEIOLATCH_EX في الأعلى ، ومتوسط ​​وقت الانتظار هو 5+ مللي ثانية. حسنًا ، نموذجي ، cho: "مرحبًا ، المشرفون و DBA ، هنا لديك نظام قرص - عنق الزجاجة" وهنا تبدأ أغنية قديمة حوالي 5 مللي ثانية:

• لدينا 5 مللي ثانية لجيش تحرير السودان
• نعم ، لدينا فوج من 20000 IOPS
• أخبرنا البائع أن جميع ملفات قاعدة البيانات يمكن أن تكون في قسم واحد
• لدينا محاكاة افتراضية وتقارب شديد ولا يمكننا تخصيص أقراص منفصلة تحت قاعدة البيانات
• وفقًا لبياناتنا ، استخدام الخادم 5٪
• تم تكوين كل شيء وفقًا للتوصيات
• قواعد البيانات الخاصة بك لا تحتاج إلى الكثير من الأداء ، ولا تفعل أكثر من 300 IOPS (ولدينا رف لـ 20000 IOPS)

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

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

على من يقع اللوم؟

لماذا قاعدة البيانات بطيئة للغاية؟ حسنًا ، يبدو أن خادمًا نموذجيًا يحتوي على 20-64 نوى بتردد 2-3 جيجاهرتز قادر على تنفيذ 50-150 مليار عملية بسيطة ، وتظهر أقصى اختبارات قاعدة البيانات (الاصطناعية) على هذه الأجهزة فقط 10000-50000 معاملة في الثانية. مرحبًا! حسنًا ، هذا من مليون إلى عشرات الملايين من المعاملات الممكنة لكل معاملة. ليس الكثير فقط ، بل الكثير من الإحساس.
مثل هذه التكاليف العامة ACID- متطلبات المعاملات.

• عدد قليل - إما اكتمال المعاملة بالكامل ، أو لم يكتمل الكل.
• الإصرار - عند دخول وخروج المعاملة ، يكون النظام في حالة ثابتة
• أنا solation - المعاملات لا ترى حالات وسيطة لبعضها البعض
• D قابلية السحب - إذا تم إكمال المعاملة (الالتزام) بنجاح ، فعندئذٍ ، بغض النظر عن الظروف ، يجب أن تظل التغييرات التي تم إجراؤها في النظام.

بالمناسبة ، حرفًا بحرف ، لا يتم استيفاء هذه المتطلبات في أي مكان تقريبًا ولا يتم أبدًا ، ولكن ببساطة في الأنظمة الموزعة (تتداخل نظرية CAP). بالنسبة لموقفنا ، من المرجح أن يكون متطلب "D" أكثر تكلفة من غيره ، ويتم توفير هذا المطلب من خلال الآلية الرئيسية لجميع قواعد بيانات OLTP DBMS الشائعة: WAL ، سجل الكتابة المسبقة (PostgeSQL) ، وهو أيضًا سجل معاملات (SQL Server) ، ويعرف أيضًا بسجل REDO (Oracle). ومن هنا - حجر على عنق الإنتاجية ، وهو أساس معاملات المتانة.

ما هو WAL؟

دعونا ننسى للحظة حول SSDs الحديثة ، حول أنظمة التخزين الرائعة. لنفترض أن لدينا خادمًا ، يحتوي على قرص واحد أو أكثر.
أي صفقة ، حتى إدخال سجل واحد ، هي على الأقل محتملة ، ولكن في الواقع دائمًا تقريبًا وواقعيًا إجراء غير ذري. نحتاج دائمًا تقريبًا إلى تغيير ليس فقط الصفحة التي يوجد فيها السجل ، ولكن أيضًا تغيير صفحات الفهرس ، وربما صفحات الخدمة. علاوة على ذلك ، في نفس المعاملة يمكن أن تتغير الصفحة نفسها عدة مرات. بالإضافة إلى ذلك ، يمكن إجراء المعاملات الأخرى بالتوازي معنا. علاوة على ذلك - المعاملات المجاورة في الوقت المناسب باستمرار "تسحب" نفس الصفحات. إذا انتظرنا حتى تتم كتابة كل صفحة على القرص قبل المتابعة ، وهو ما تتطلبه المتانة بشكل أساسي ، فسيتعين علينا كتابة المزيد من المرات وانتظار اكتمال كل تسجيل على وسائط غير متقلبة. لا توجد مخابئ ، ولا إعادة ترتيب للعمليات في قائمة الانتظار ، وإلا فلن يكون هناك تكامل! علاوة على ذلك ، نحتاج بطريقة ما إلى ملاحظة البيانات الموجودة بالفعل في المعاملات الثابتة وأيها لم يتم بعد (وأي البيانات كانت من قبل). من أجل الفهم - سيعطي القرص الصلب الفردي النموذجي (HDD) في هذا الوضع 50-100 IOPS وكان هذا ثابتًا لمدة 20 عامًا. سوف تتطلب عملية صغيرة واحدة 5-10 عمليات الكتابة. آه ، نعم ، من أجل معرفة ما يجب تسجيله ، يجب عليك قراءته. حتى أنظمة OLTP القابلة للكتابة بشكل كبير جدًا تقرأ 3 مرات أكثر مما تكتب. وبالتالي ، تكلف معاملتنا 20-40 IO ، مما يعني 0.2-0.8 ثانية لكل قرص.
معاملات في الثانية. لا يكفي؟ دعونا نحاول تشتيت الأقراص؟ أوه ، لكننا ما زلنا بحاجة إلى الانتظار حتى يتم تسجيل السابق وليس هناك توازٍ في النهاية. كيف تكون ودعونا نبدأ ملف سجل نسجل فيه جميع عمليات الكتابة بشكل متسلسل في قاعدة البيانات وعلامات المعاملات! الإيجابيات:

• يمكن أن تكون المعلومات حول العملية أكثر إحكاما من تسجيل الصفحة بأكملها (حجم الصفحة النموذجي هو 8 كيلوبايت ، المعلومات المكتوبة على السجل غالبًا ما تكون 0.5-1 كيلوبايت).
• بدلاً من الكتابة حول ما إذا كانت المعاملة مسجلة أم لا مباشرة على الصفحة ، فهناك ما يكفي من التسميات حول بداية وإصلاح المعاملة في السجل.
• لا يمكن كتابة الصفحات بعد كل معاملة - أقل عدة مرات. عملية قراءة / كتابة البيانات "غير مرتبطة" بالكامل من السجل.
• الشيء الرئيسي. إذا وضعنا يومياتنا على قرص منفصل وكتبنا السجلات بالتسلسل ، فبسبب أنك لست بحاجة إلى إعادة وضع رؤوس الأقراص باستمرار ، حتى القرص الصلب المنزلي في هذا الوضع يضغط حتى 1000 IOPS ، نظرًا لأن المعاملات الصغيرة "التكلفة" 2-4 إدخالات دفتر اليومية ، ثم يمكنك ضغط 200-400 TPS
• في حالة الفشل ، يمكن استعادة حالة ملف البيانات من مثل هذا السجل ، وإذا تم إلغاء المعاملة ، يمكن إرجاعها

يسمى هذا السجل سجل الكتابة / سجل المعاملات / سجل REDO.

مرحى! عظيم! كانت هناك صفقتان في الثانية ، وأصبحت 300 - تحسنت 150 مرة. وبأي تكلفة؟ كما اتضح ، فإن السعر مهم:

• في جميع DBMSs الشائعة ، يكون التسجيل متسقًا تمامًا. خيط واحد مسؤول عن الكتابة إلى السجل. هل لديك 100 معالج؟ رائع. وسيظل السجل يكتب خيط واحد. عمق قائمة الانتظار هو بالضبط واحد.
• لا يزال - لا توجد ذاكرة تخزين مؤقت لنظام التشغيل ، ولا تبديل في العمليات. بقيت متطلبات المتانة. عمليات الكتابة: حتى أجاب القرص "كتبت ، كتبته مباشرة على السطح ، وليس على ذاكرة التخزين المؤقت ، بالتأكيد" لا يستمر DBMS في العمل.
• إذا وضعت ملف السجل على قرص البيانات ، فستفقد جميع مزايا التسجيل التسلسلي تقريبًا. علاوة على ذلك - للخير ، إذا كان هناك العديد من قواعد البيانات على الخادم ، ثم عدة أقراص للمجلات.
• التراجع عن المعاملة (على الأقل في MS SQL Server) - اقرأ السجل واستعد الحالة منه. هذا هو عدد عمليات الكتابة أو حتى أكثر من عمليات الكتابة في المعاملة. الاسترجاع مكلف!

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

يجب أن يكون موضوع تسجيل الدخول المسبق في قاعدة البيانات على الأقل معروفًا لأي شخص يقوم بطريقة ما بإدارة DBMS أو البنية التحتية DBMS أو تطوير قواعد البيانات.

WAL و SHD

يواجه مصنعو التخزين "منذ الولادة" نظام DBMS. بالنسبة لقواعد البيانات ، فإن الأعمال التجارية تشتري هذه المجمعات باهظة الثمن: من متاجر أسعار الشوارع في Dell-EMC و HP و Hitachi و NetApp ، عند فرض الميزانية ، تملأ العيون الدموع لمعظم كبار المديرين ، ما لم يحصلوا بالطبع على نسبة من هذا السعر. ولكن هناك صراع هندسي وتسويقي. سأشرح ذلك باستخدام Dell-EMC كمثال ، ولكن فقط لأنني أتذكر مكان وجود الوثائق.

لذا:

1. مجلة واحدة مترابطة
2. سجل الكتابة ، أي زمن الانتقال ، "أبدي" مقارنة بأداء وحدة المعالجة المركزية
3. تعد حمولات OLTP الكثير من المعاملات الصغيرة نسبيًا ،
4. معظم تحميلات DBMS الأخرى متوازية بطريقة أو بأخرى.

يخبرنا قانون Amdahl بلا رحمة أن الحمل المنخفض الأداء ذي الخيوط الفردية سيجعل إضافة المعالجات عديمة الفائدة ، وسيتم تحديد الأداء من خلال السجل. علاوة على ذلك ، في هذه اللحظة لن نهتم بأداء التخزين في IOPS ، وسيصبح الكمون فقط هو المهم.
ولكن لا تستبعد عمليات القرص الأخرى - القراءة والكتابة إلى ملفات البيانات و tempdb . القراءة هي أيضًا عملية "انتظار". حتى يمكن قراءة صفحة البيانات من القرص إلى الذاكرة ، لا يمكن للمعالج معالجتها. ولكن بالنسبة لهذه العمليات ، تكون قوائم الانتظار الكبيرة وتبديل العمليات في قائمة الانتظار هذه ممكنة: يعرف نظام إدارة قواعد البيانات (DBMS) غالبًا الصفحات التي سيتم تحميلها في الذاكرة ، وأي الصفحات يتم تفريغها ويضع الكثير من قوائم الانتظار للقراءة في وقت واحد. نظرًا لأنه في هذا السيناريو ، من المهم عندما تنتهي العملية الأخيرة من الحزمة ، في هذا الحمل ، على العكس من ذلك ، فإن IOPS أكثر أهمية بالنسبة لنا من الكمون لعملية واحدة. لفهم النطاق: عمليات القراءة في نظام OLTP النموذجي هي 85٪ -95٪. نعم ، نعم ، نعم ، عمليات الكتابة أقل حجمًا.

يعمل مهندسو تخزين البائعين عن كثب مع موردي DBMS ، وهم على دراية تامة بكل الفروق الفنية في كيفية عمل نظام DBMS مع نظام فرعي للقرص. التخطيط السليم وتقسيم وتخصيص موارد القرص لنظام DBMS هو اختصاص معقد ومهم لمدير نظام التخزين . يحتوي نفس Dell-EMC على ورق أبيض أساسي H14621 و H12341 لتقسيم التوصيات الخاصة بـ SQL Server - أكثر من مائة صفحة. مرحبًا! هذه ليست رصيف مفصل ، هذا هو الكتاب الأبيض الأكثر شيوعًا! لا يزال هناك مجموعة محددة ( h15142 ، h16389 ... هناك ظلام هناك). "المتجاورون" من VMware - تصميم Microsoft SQL Server على VMware vSphere ليسوا متخلفين كثيرا. يرجى ملاحظة أن هذه المستندات ليست فقط وليس DBAs كثيرًا مثل مسؤولي البنية التحتية والتخزين.
وألاحظ أيضًا أنه في كل هذه المستندات ، يتم قطع LUNs منفصلة للبيانات والسجلات و tempdb . نعم ، في مكان ما في أحدث الوثائق ، يقولون بدقة أنه بالنسبة لحلول All-Flash ، لا معنى لفصل السجلات إلى وسائط منفصلة فعليًا ، ولكن لا تزال LUNs تعرض قطعها بشكل منفصل. إذا قمت بتفريغ البيانات وتسجيل الدخول إلى LUN واحد ، فستكون قائمة انتظار إدخال / إخراج واحدة من وجهة نظر نظام التشغيل. وستكون هناك مشكلة. عمليات الكمون سيكون لها حجم أكبر على الفور. وبسبب حقيقة أن عمليات السجل غير القابلة للنقل ستظهر في قائمة الانتظار ، فإن IOPS سوف تنزلق على ملفات البيانات و tempdb . هذه ليست "اكتشاف القرن" ، إنها حقيقة أولية للعمل مع قاعدة البيانات. لم يتم إبطالها أو إلغاؤها مع ظهور All-Flash. نعم ، التأخيرات في العمليات مع محركات الأقراص ذات الحالة الصلبة أسرع من حيث الحجم مقارنة بالعمليات مع محركات الأقراص الصلبة ، ولكن لا يزال هناك ضعف في حجم الطلبات مقارنة بالعمليات مع الذاكرة. IO لا يزال عنق الزجاجة لنظام DBMS.
وتؤكد المستندات الفنية بشكل صحيح أنه في سجلات المعاملات ، فإن عدد IOPS ليس مهمًا ، ولكن من المهم أن يكون زمن الوصول ضئيلًا (في العصر الحديث مكتوب بأقل من 1 مللي ثانية).

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

5 مللي ثانية

إما أنك سمعت كثيرًا من قراءة المسوقين ، أو من الكسل ، أو بسبب نوع من الصراصير ، ولكن لسبب ما غالبًا ما يقوم مسؤولو التخزين بعمل شيء من هذا القبيل. نأخذ رفًا كبيرًا ، ونجمعها جميعًا في شيء مسطح ، ونقطعها إلى وحدات LUN صغيرة الحجم ونوزعها بواسطة LUN على الخادم. أو اثنين ، لأن "قسم النظام مكرر البيانات بشكل جيد." وعندما أرى ذلك مع النظام الفرعي للقرص من جانب SQL hell-hell-hell ، تبدأ الأغنية نفسها بأن "5 مللي ثانية هو مؤشر ممتاز" ، أن "100000 IOPS" ، "حمل التخزين الخاص بك أقل من 5٪"

لا .

• بالنسبة لأنظمة OLTP على قسم به سجلات WAL / المعاملات تبلغ 5 مللي ثانية ، يعد هذا مؤشرًا غير صالح. على قطعة الحديد "شبه سلعة" بسعر 1000 (في الكلمات: ألف) أرخص ، سيكون المؤشر العادي الآن 0.1-0.3 مللي ثانية. وغداً - 0.01 مللي ثانية. السرعة ، مثل محرك الأقراص الصلبة لعام 2008 ، بسعر المدخل الكامل للشقق في موسكو ، ليست ضرورية. لا يستحق "الخدمة" يستحق ذلك.
• هل يكتب البائع أن سجلات المعاملات لا تتطلب على IOPS وهل يمكن وضعها على محرك الأقراص الثابتة؟ نعم إنه كذلك. ولكن لهذا فمن الضروري ألا يكون أي من هذه الأقراص عدوى بالإضافة إلى كتابة السجلات ، لم يلمس DBMS المهمة. وحتى يستجيب نظام التخزين للخادم الذي تمت كتابة البيانات عليه ، فور دخول البيانات في ذاكرة غير متقلبة (هذا في وقت أبكر بكثير مما ستتم كتابته)
• الأقراص الرقيقة لقواعد بيانات OLTP الحقيقية شريرة.
• بالنسبة إلى WAL ، من غير المثير للاهتمام على الإطلاق مقدار IOPS الذي يمكن عصره هناك على عمق قائمة الانتظار من 10 أو 20. لا يوجد عمق هناك.
• بالنسبة إلى WAL ، ليس مؤشراً على الإطلاق أن قائمة انتظار الإدخال / الإخراج في نظام التشغيل "حوالي 1 فقط". لن تكون بعد الآن.
• لا ، مطوري DBA و DB ليسوا "نقار الخشب المنحرفين الذين لا يمكنهم التكوين بشكل صحيح للكتابة إلى موازاة WAL" (رأي حقيقي للمسؤول)
• منطق المعجبين للنظر في إعادة التدوير "نظرًا لأن نظامك الذي قمنا بتكوينه بشكل مخادع في قسم واحد لا يقوم بـ 10000 IOPS ، فيجب نقله من صفيف متطور إلى متوسط ​​المدى" - هذا منطق غير صحيح.
• إذا كان خادم 40-core يحتوي على تحميل معالج 2.5 في المائة ، فهذا لا يعني أنه ليس لديه ما يفعله ، ولكن على الأرجح ، يعني أن هناك نوعًا من المهام التي تمنع أي شخص آخر.

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

ماذا تفعل

نصائح المشرف و DBAs

بالنسبة إلى OLTP ، توقف عن عد "إعادة التدوير" و IOPS. بشكل منفصل ، ألاحظ - لا تنظر إلى IOPS بعمق قائمة انتظار كبير على الإطلاق: حتى في أقسام البيانات ، عادةً ما يكون لقوائم الانتظار الكبيرة اندفاع قصير أو شيء لا يؤثر على الأداء الفعلي لـ OLTP.

مشاركة مساحة القرص بواسطة LUN ليست نزوة DBA. تحتوي قاعدة البيانات على العديد من ملفات تعريف تحميل النظام الفرعي للقرص المختلفة. على الأقل ، يمكن تمييز ما يلي:

• العمل مع ملفات البيانات. عادة ما تكون هذه القراءة والكتابة مع كتل عشوائية من 8/64 KiB. قراءات 80-95٪. تنشأ قوائم الانتظار: خلال فترات الخدمة ، وخلال فترات التحميل السائب ، والطلبات غير الفعالة أو الجماعية ، وأثناء نقطة التفتيش. يتأثر الأداء بالاستجابة للقراءة. من المهم أن تتم محاذاة كتل 8/64 KiB "عبر" عبر نظام التخزين بالكامل.
• العمل مع tempdb هو نفسه العمل مع ملفات البيانات ، ولكن القراءات عادة ما تكون 40-75٪ ويمكن أن تكون استجابة الكتابة مهمة. في أنظمة MS SQL الحديثة ، يمكن تحميل قاعدة البيانات هذه عدة مرات أقوى من قواعد بيانات البيانات. في تكوين DBMS غير متفاوت ، يجب استبعاد هذا القسم من أي نسخ متماثل للتخزين. محتوياته بعد إعادة تشغيل الخدمة لا تزال مدمرة.
• العمل مع البيانات المؤرشفة / DWH. قراءات قريبة من 100 ٪. عادة ما يكون حجم كتلة قراءة واحدة 64 كيلوبايت. تتم قراءة الطلبات كثيرًا وعلى التوالي ، بحيث يمكن لقائمة الانتظار أن تقفز إلى 1000 أو أكثر.
• العمل مع سجلات المعاملات. القراءة للصيانة فقط (النسخ الاحتياطي ، النسخ المتماثل ، إلخ) ، يتأثر أداء التطبيق بالكتابة فقط. التسجيل في كتل 0.5-64 كيلوبايت. بدون طابور ، في موضوع واحد. التأخير أمر بالغ الأهمية للتطبيقات.
• النسخ الاحتياطي والاستعادة. من وجهة نظر قاعدة البيانات ، يتم القراءة في كتل كبيرة (غالبًا 1 MiB). من المهم أن يعتمد هذا الحمل على القنوات / الحافلات (FC و Ethernet) وأداء معالجات التخزين في بعض الحالات. يمكن أن يؤثر النسخ الاحتياطي لخادم واحد على أداء خوادم أخرى لنفس SAN / SHD.
• العمل مع ملفات التطبيق: وهي السجلات والتتبع الافتراضي والملفات الثنائية وما إلى ذلك. هذا الحمل نادرًا ما يكون مهمًا وهو مهم فقط في بداية النظام.

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

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . هذا صحيح. . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

هذا كل شيء. . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .