أداء SVN بعد العديد من المراجعات

Question

يستخدم مشروعي حاليًا مستودع svn الذي يحصل على عدة مئات من المراجعات الجديدة يوميًا.يوجد المستودع على خادم Win2k3 ويتم تقديمه من خلال Apache/mod_dav_svn.

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

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

هل هذا يعني أنه من أجل التحقق من المراجعة 10 للملف foo.baz، سيأخذ svn المراجعة 1 ثم يطبق الدلتا 2-10؟

Answer 1

ما هو نوع الريبو لديك؟FSFS أو BDB؟

(لنفترض أن FSFS في الوقت الحالي، لأن هذا هو الإعداد الافتراضي.)

في حالة FSFS، يتم تخزين كل مراجعة على أنها فرق مقارنة بالسابقة.لذا، قد تعتقد أنه بعد العديد من المراجعات، سيكون الأمر بطيئًا للغاية.

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

(لذا، إذا كنت تستخدم FSFS repo، فإن إجابة براد ويلسون خاطئة.)

في حالة BDB repo، تكون مراجعة HEAD (الأحدث) نصًا كاملاً، ولكن المراجعات السابقة مبنية على شكل سلسلة من الاختلافات مقابل الرأس.وهذا يعني أنه يجب إعادة حساب الدورات السابقة بعد كل التزام.

لمزيد من المعلومات: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

ملاحظة.يبلغ حجم الريبو الخاص بنا حوالي 20 جيجابايت، مع حوالي 35000 مراجعة، ولم نلاحظ أي تدهور في الأداء.

Answer 2

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

Answer 3

أنا شخصياً لم أتعامل مع مستودعات Subversion التي تحتوي على قواعد تعليمات برمجية أكبر من 80 ألف LOC للمشروع الفعلي.كان أكبر مستودع لدي بالفعل حوالي 1.2 جيجا، ولكن هذا يشمل جميع المكتبات والأدوات المساعدة التي يستخدمها المشروع.

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

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

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

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

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

Answer 4

نحن نقوم بتشغيل خادم تخريبي يحتوي على أكواد برمجية وثنائيات بقيمة غيغابايت، ويصل الأمر إلى أكثر من عشرين ألف مراجعة.لا يوجد تباطؤ حتى الآن.

Answer 5

يقوم Subversion فقط بتخزين الدلتا (الاختلافات)، بين مراجعتين، لذلك يساعد هذا في توفير مساحة كبيرة، خاصة إذا كنت تلتزم فقط بالكود (النص) وليس الثنائيات (الصور والمستندات).

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

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

أوه، لقد عملت على مستودعات CVS بسعة 2 جيجا بايت + من العناصر (الكود، الصور، المستندات) ولم أواجه أي مشكلة في الأداء مطلقًا.نظرًا لأن svn يعد تحسينًا كبيرًا في السيرة الذاتية، فلا أعتقد أنه يجب عليك القلق بشأنه.

نأمل أن يساعد على تخفيف عقلك قليلا ؛)

Answer 6

لا أعتقد أن تخريبنا تباطأ بسبب الشيخوخة.لدينا حاليًا عدة تيرابايت من البيانات، معظمها ثنائية.نقوم بالخروج/ الالتزام يوميًا بما يصل إلى 50 جيجابايت من البيانات.في المجموع لدينا حاليًا 50000 مراجعة.نحن نستخدم FSFS كنوع تخزين ونتواصل إما مباشرة مع SVN:(خادم Windows) أو عبر Apache mod_dav_svn (Gentoo Linux Server).

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

ومع ذلك، يجب أن أقول إن عملية التخريب لدينا بطيئة بشكل غير عادي ومن الواضح أنها عملية تخريبية بحد ذاتها كما حاولنا مع نظام كمبيوتر آخر.

لبعض الأسباب غير المعروفة، يبدو أن التخريب محدود تمامًا بوحدة المعالجة المركزية للخادم.تقتصر معدلات الخروج/الالتزام لدينا على ما بين 15-30 ميجابايت/ثانية لكل عميل لأنه يتم استهلاك نواة وحدة المعالجة المركزية للخادم بالكامل.وهذا هو نفسه بالنسبة للمستودع الفارغ تقريبًا (1 جيجا بايت، 5 مراجعات) كما هو الحال بالنسبة لخادمنا الكامل (~5 تيرابايت، 50000 مراجعة).ضبط مثل ضبط الضغط على 0 = إيقاف لم يحسن هذا.

النطاق الترددي العالي الخاص بنا (يوفر ~ 1 جيجا بايت / ثانية) من خمول FC-Array، والنوى الأخرى في وضع الخمول والشبكة (حاليًا 1 جيجا بايت / ثانية للعملاء، و 10 جيجا بايت / ثانية للخادم) في وضع الخمول أيضًا.حسنًا، ليس في وضع الخمول حقًا ولكن إذا تم استخدام 2-3٪ فقط من السعة المتاحة فإنني أسميها في وضع الخمول.

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

ومع ذلك، فأنا أحاول فقط إيجاد طريقة لضبط التخريب.إذا لم يكن ذلك ممكنًا، فقد نحتاج إلى التبديل إلى نظام آخر.

لذلك:إجابة:لا يوجد SVN لا يتدهور في الأداء فهو بطيء في البداية.

بالطبع إذا لم تكن بحاجة إلى أداء (عالٍ) فلن تواجه مشكلة.بالمناسبة.كل ما سبق ينطبق على Subversion 1.7 أحدث إصدار مستقر

Answer 7

العمليات الوحيدة التي من المحتمل أن تتباطأ هي الأشياء التي تقرأ المعلومات من مراجعات متعددة (على سبيل المثال.لوم SVN).

Answer 8

لست متأكدا.....أنا أستخدم SVN مع Apache على Centos 5.2.يعمل بشكل جيد.رقم المراجعة كان 8230 شيء من هذا القبيل ...وعلى جميع الأجهزة العميلة، كان الالتزام بطيئًا للغاية لدرجة أنه كان علينا الانتظار لمدة دقيقتين على الأقل للحصول على ملف يبلغ حجمه 1 كيلو بايت.أنا أتحدث عن ملف واحد ليس له حجم كبير.

ثم قمت بإنشاء مستودع جديد.بدأت من القس.1.الآن يعمل بشكل جيد.سريع.يستخدم svnadmin إنشاء xxxxxx.لم يتم التحقق مما إذا كان FSFS أو BDB .....

Answer 9

ربما يجب عليك أن تفكر في تحسين سير عملك.

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

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

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