كيف تحدد مثالية حجم المخزن المؤقت عند استخدام فيلينبوتستريام?

Question

لدي الأسلوب الذي يخلق MessageDigest (تجزئة) من ملف و أريد أن أفعل هذا الكثير من الملفات (>= 100,000).كيف كبيرة يجب أن تجعل العازلة المستخدمة في قراءة من الملفات إلى تحقيق أقصى قدر من الأداء ؟

معظم الناس على دراية التعليمات البرمجية الأساسية (التي سوف أكرر هنا فقط في حالة):

MessageDigest md = MessageDigest.getInstance( "SHA" );
FileInputStream ios = new FileInputStream( "myfile.bmp" );
byte[] buffer = new byte[4 * 1024]; // what should this value be?
int read = 0;
while( ( read = ios.read( buffer ) ) > 0 )
    md.update( buffer, 0, read );
ios.close();
md.digest();

ما هو الحجم المثالي العازلة لتحقيق أقصى قدر من الإنتاجية?أنا أعلم أن هذا النظام يعتمد وأنا متأكد OS, الملفات ، و الأقراص الصلبة التي تعتمد على, وربما هناك غيرها من الأجهزة/البرمجيات في هذا المزيج.

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

تحرير: أنا لا أعرف في وقت مبكر أنواع أنظمة سيتم استخدام هذا لذا لا أستطيع تحمل الكثير.(أنا باستخدام جافا لهذا السبب.)

تحرير: رمز أعلاه مفقود أشياء مثل محاولة..القبض على جعل منصب أصغر

Answer 1

الأمثل حجم المخزن المؤقت هو ذات الصلة إلى عدد من الأمور:نظام الملفات حجم كتلة وحدة المعالجة المركزية وحجم ذاكرة التخزين المؤقت ذاكرة التخزين المؤقت الكمون.

معظم أنظمة الملفات تم تكوينها لاستخدام أحجام كتلة من 4096 أو 8192.في نظرية, إذا كان يمكنك تكوين حجم المخزن المؤقت إذا كنت تقرأ بضع بايت أكثر من القرص كتلة العمليات مع نظام الملفات يمكن أن تكون فعالة للغاية (أيإذا قمت بتكوين إعدادات المخزن المؤقت إلى قراءة 4100 بايت في كل مرة قراءة يتطلب 2 بلوك يقرأ من قبل نظام الملفات).إذا كانت كتل بالفعل في ذاكرة التخزين المؤقت ، ثم الرياح تدفع الثمن من ذاكرة الوصول العشوائي -- > L3/L2 ذاكرة التخزين المؤقت الكمون.إذا كنت سيئ الحظ و الكتل ليست في ذاكرة التخزين المؤقت بعد ، يمكنك دفع سعر القرص->ذاكرة الوصول العشوائي الكمون كذلك.

هذا هو السبب في أن ترى معظم مخازن بحجم قوة 2 ، عموما أكبر من (أو مساوية) القرص حجم الكتلة.هذا يعني أن واحدا من تيار يقرأ يمكن أن يؤدي متعددة القرص كتلة يقرأ - ولكن تلك يقرأ دائما استخدام كامل كتلة لا يضيع يقرأ.

الآن, هذا هو إزاحة قليلا جدا في نموذجي تدفق السيناريو لأن الكتلة التي يتم قراءتها من القرص سوف تكون لا تزال في الذاكرة عندما تضغط على التالي قراءة (نحن نفعل متتابعة يقرأ هنا بعد كل شيء) - إذا كنت تصل الرياح دفع RAM -> L3/L2 ذاكرة التخزين المؤقت الكمون السعر التالية على قراءة ، ولكن ليس القرص->ذاكرة الوصول العشوائي الكمون.حيث أمر من حجم القرص->ذاكرة الوصول العشوائي الكمون بطيئة الى حد كبير المستنقعات أي الكمون قد يكون التعامل مع.

لذا أعتقد أنه إذا قمت بتشغيل اختبار مع مختلف أحجام ذاكرة التخزين المؤقت (لم فعلت هذا بنفسي), سوف تجد على الأرجح تأثير كبير من حجم ذاكرة التخزين تصل إلى حجم نظام الملفات كتلة.فوق ذلك, وأظن أن الأمور قد مستوى جيد.

وهناك طن من الشروط والاستثناءات هنا - تعقيدات النظام فعلا مذهل تماما (فقط الحصول على مقبض على L3 -> L2 ذاكرة التخزين المؤقت التحويلات هو العقل bogglingly تعقيدا, فهو يتغير مع كل نوع وحدة المعالجة المركزية).

هذا يؤدي إلى "العالم الحقيقي" الجواب:إذا كان التطبيق الخاص بك هو مثل 99% هناك تعيين حجم ذاكرة التخزين المؤقت إلى 8192 والانتقال (حتى أفضل, اختيار التغليف على الأداء واستخدام BufferedInputStream إلى إخفاء تفاصيل).إذا كنت في 1% من التطبيقات التي تعتمد اعتمادا كبيرا على سرعة نقل القرص الحرفية التطبيق الخاص بك بحيث يمكنك مبادلة مختلفة القرص استراتيجيات التفاعل وتقديم المقابض والأوجه أن تسمح للمستخدمين لاختبار وتحسين (أو الخروج مع بعض الذاتي وتحسين النظام).

Answer 2

نعم, ربما تعتمد على أشياء مختلفة - ولكن أشك في أنها سوف تجعل الكثير جدا من الفرق.أنا أميل إلى اختيار 16K أو 32K كما توازن جيد بين استخدام الذاكرة والأداء.

لاحظ أنه يجب أن يكون محاولة/أخيرا كتلة في التعليمات البرمجية للتأكد من تيار مغلقة حتى لو تم طرح استثناء.

Answer 3

في معظم الحالات, لا يهم كثيرا.مجرد اختيار حجم جيد مثل 4K أو 16K و العصا معه.إذا كنت إيجابية هذا هو عنق الزجاجة في التطبيق الخاص بك, ثم يجب أن تبدأ التنميط للعثور على أفضل حجم المخزن المؤقت.إذا اخترت حجم صغير جدا, سوف تضيع الوقت في القيام إضافية عمليات الإدخال/الإخراج إضافية المكالمات وظيفة.إذا اخترت حجم كبير جدا, سوف تبدأ في رؤية الكثير من ذاكرة التخزين المؤقت يفتقد التي سوف حقا كنت بطيئا.لا استخدام المخزن مؤقت أكبر من حجم ذاكرة التخزين المؤقت L2.

Answer 4

في الحالة المثالية يجب أن يكون لديك ذاكرة كافية لقراءة الملف في عملية القراءة.سيكون هذا أفضل أداء لأننا السماح نظام إدارة نظام الملفات وتخصيص الوحدات و HDD في الإرادة.في الواقع كنت محظوظا لمعرفة أحجام الملفات في وقت مبكر ، فقط استخدام متوسط حجم الملف تقريب تصل إلى 4K (الافتراضي تخصيص وحدة على NTFS).وأفضل للجميع :إنشاء المؤشر لاختبار خيارات متعددة.

Answer 5

هل يمكن استخدام BufferedStreams/القراء ومن ثم استخدام المخزن المؤقت الأحجام.

وأعتقد أن BufferedXStreams تستخدم 8192 مثل حجم المخزن المؤقت ، ولكن مثل أوفيديو قال: ربما يجب عليك تشغيل اختبار على مجموعة كاملة من الخيارات.حقا سوف تعتمد على نظام الملفات على القرص تكوينات ما أفضل الأحجام.

Answer 6

قراءة الملفات باستخدام جافا NIO هو FileChannel و MappedByteBuffer من المرجح أن يؤدي الحل الذي سوف يكون أسرع بكثير من أي حل تنطوي فيلينبوتستريام.في الأساس, الذاكرة-خريطة الملفات الكبيرة ، واستخدام المباشر المخازن الصغيرة منها.

Answer 7

في BufferedInputStream المصدر سوف تجد:خاصة ثابتة الباحث DEFAULT_BUFFER_SIZE = 8192;
حتى انها على ما يرام بالنسبة لك أن استخدام القيمة الافتراضية.
ولكن إذا كان يمكنك معرفة المزيد من المعلومات سوف تحصل على أكثر ثمينة إجابات.
على سبيل المثال, adsl الخاص بك ربما preffer العازلة من 1454 بايت, هذا لأن TCP/IP الحمولة.على الأقراص يمكنك استخدام قيمة المباراة القرص الخاص بك هو حجم الكتلة.

Answer 8

كما سبق ذكره في إجابات أخرى ، استخدم BufferedInputStreams.

بعد أن اعتقد حجم المخزن المؤقت لا يهم حقا.أما برنامج I/O bound, وتزايد حجم المخزن المؤقت على مكررا default, لا تجعل أي تأثير كبير على الأداء.

أو برنامج CPU ملزمة داخل MessageDigest.تحديث () ، و معظم الوقت لا تنفق في رمز التطبيق ، لذلك التغيير والتبديل انها لن تساعد.

(هم...مع متعددة النوى ، المواضيع قد تساعد.)

Answer 9

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

هذا يتوقف على عدد من العوامل بما في ذلك نظام الملفات كتلة حجم وحدة المعالجة المركزية الأجهزة.

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

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