سؤال

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

لا يتعلق الأمر بزيادة في الأداء بنسبة 0.0x% ولكن ربما، ربما هناك أشياء بسيطة من شأنها تحسين الأداء بشكل كبير أو أشياء تبدو بسيطة ولكنها معروفة بأنها كارثية في البيئات الافتراضية.على سبيل المثال، تمكين CONFIG_PARAVIRT في بناء kernel يتم بسهولة ويمكن أن يعزز الأداء كثيرًا.الآن أبحث عن أشياء مماثلة للتطبيقات، إن وجدت.

في حالتي، سيكون رمز C++ وربما VMWare ولكني أريد أن أبقي السؤال غير محدد للغة/المنتج قدر الإمكان.أتساءل عما إذا كانت هناك مثل هذه الاستراتيجيات أم أن هذا سيكون مضيعة للوقت - فبعد كل شيء، مفهوم المحاكاة الافتراضية هو أنه لا يتعين عليك الاهتمام بها كثيرًا.

هل كانت مفيدة؟

المحلول

النصيحة الوحيدة التي يمكنني تقديمها لك هي الاستخدام الدقيق لـ mlock() / mlockall() ..أثناء البحث عن سائقي البالونات التي تجرها الدواب.

على سبيل المثال، إذا تم تمهيد ضيف Xen بسعة 1 جيجابايت، ثم تضخمت إلى 512 ميجابايت، فمن المعتاد جدًا أن المجال المميز لم ينظر إلى مقدار الذاكرة التي وعدت بها النواة شبه الافتراضية للعمليات (على سبيل المثال.ملتزم_AS).في الواقع، مع Xen، ما لم يتم وضع هذه القيمة على Xenbus، فإن المضيف المميز ليس لديه أي فكرة عما سيفعله هذا البالون.أعتقد أن هذا يتزامن أيضًا مع KVM، اعتمادًا على كيفية تكوين النواة ..لكن سؤالك يفترض أننا لا نعرف شيئًا عن مثل هذه الأشياء :)

لذا، قم بحماية الأشياء (كن حذرًا، ولكن حذرًا) التي لا يمكن ترحيلها ببساطة، واحتسب دائمًا سيناريو "السماء تتساقط".

وبالمثل، فإن استخدام posix_fadvise() / posix_madvise() لإخبار النواة الكهروضوئية عن مقدار ما تحتاج إليه أو لا تحتاج إلى تخزين مؤقت هو دائمًا فكرة جيدة.

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

لا أستخدم KVM كثيرًا (حتى الآن)، على الرغم من أنني أخطط لاستكشافه أكثر في المستقبل.ومع ذلك، فإن 90% من الأشياء التي كنت أكتبها مؤخرًا مصممة خصيصًا للتشغيل على ضيوف Xen شبه الافتراضيين.آسف لكوني متمحورًا حول Xen / C قليلاً، ولكن هذا هو المكان الذي توجد فيه تجربتي وpv_ops في الخط الرئيسي (قريبًا أيضًا xen-0 ops) :)

سؤال جيد ، راجع للشغل :)

يحرر:

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

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

آسف على الغموض.أفضل عبارة يمكن أن أتوصل إليها هي "حذر، ولكن حكيم".

نصائح أخرى

ولقد وجدت أن يكون كل شيء عن I / O.

ونظام رصد السفن عادة مص بشكل لا يصدق سيئة في IO. هذا يجعل الأمور مختلفة أسوأ بكثير مما لو كانت على القصدير الحقيقي.

ومبادلة هو خصوصا قاتل سيئة - هو حطام تماما الأداء VM، حتى قليلا، كما IO بطيء جدا.

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

وحتى استخدام ramdisc للملفات المؤقتة إذا كنت تستطيع، ولكن لا يؤدي إلى تبديل، لأن ذلك من شأنه أن يكون أسوأ من ذلك.

ونصيحتي الوحيدة هي إبقاء الذاكرة الخاصة بك وIO استخدام منخفضة إذا أمكن ذلك.

وIO في VM بطيء جدا بالمقارنة مع الأجهزة الفعلية. إذا كان يمكنك تجنب القيام بذلك ثم تجنب ذلك.

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

وخصوصا تجنب أي شيء يتطلب I / O مع العالم خارج بيئة افتراضية. Depeding على كيفية وضع الامور، وهذا يشمل الرسم على الشاشة، مبادلة، والقرص وشبكة I / O. هذا هو تقريبا في ترتيب تقليل من أهمية.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top