অ্যাপাচি স্পার্ক: করের সংখ্যা বনাম নির্বাহকের সংখ্যা

Question

আমি ইয়ার্নে স্পার্ক কাজ চালানোর সময় করের সংখ্যা এবং নির্বাহকের সংখ্যার সম্পর্ক বোঝার চেষ্টা করছি।

পরীক্ষার পরিবেশটি নিম্নরূপ:

• ডেটা নোডের সংখ্যা: 3
• ডেটা নোড মেশিন বিশেষ:
  • সিপিইউ: কোর আই -4--47৯০ (করের #: 4, # থ্রেডের মধ্যে: 8)
  • র‌্যাম: 32 জিবি (8 জিবি এক্স 4)
  • এইচডিডি: 8 টিবি (2 টিবি এক্স 4)

• নেটওয়ার্ক: 1 জিবি

• স্পার্ক সংস্করণ: 1.0.0

• হ্যাডোপ সংস্করণ: ২.৪.০ (হর্টন ওয়ার্কস এইচডিপি ২.১)

• চাকরি প্রবাহ স্পার্ক করুন: sc.textFile -> ফিল্টার -> মানচিত্র -> ফিল্টার -> মানচিত্রটিপেইয়ার -> হ্রাসবাইক -> মানচিত্র -> saveAsTextFile

• তথ্য অন্তর্ভুক্তী

  • প্রকার: একক পাঠ্য ফাইল
  • আকার: 165 জিবি
  • লাইনের সংখ্যা: 454,568,833

• আউটপুট

  • দ্বিতীয় ফিল্টারের পরে রেখার সংখ্যা: 310,640,717
  • ফলাফল ফাইলের লাইন সংখ্যা: 99,848,268
  • ফলাফল ফাইলের আকার: 41 জিবি

কাজটি নিম্নলিখিত কনফিগারেশনের মাধ্যমে পরিচালিত হয়েছিল:

1. --master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3 (প্রতিটি ডেটা নোডের এক্সিকিউটাররা, কোর হিসাবে ব্যবহার করুন)

2. --master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3 (# টি কোর কমেছে)

3. --master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12 (কম কোর, আরও নির্বাহক)

বিগত সময়:

1. 50 মিনিট 15 সেকেন্ড

2. 55 মিনিট 48 সেকেন্ড

3. 31 মিনিট 23 সেকেন্ড

আমার অবাক করার বিষয়, (3) অনেক দ্রুত ছিল।
আমি ভেবেছিলাম যে (1) দ্রুততর হবে, যেহেতু এলোমেলো করার সময় আন্ত-নির্বাহী যোগাযোগ কম হবে।
যদিও (১) এর কোরগুলির (#) কম (3) এর চেয়ে কম, তবে # কফ 2 (যেহেতু মূল কারণ নয়) ভাল অভিনয় করেছে perform

(পাইলট জলের উত্তর পরে অনুসরণ করা হয়েছে।)

তথ্যের জন্য, পারফরম্যান্স মনিটর স্ক্রিন ক্যাপচারটি নিম্নরূপ:

• (1) - এর জন্য গাংলিয়া ডেটা নোডের সংক্ষিপ্তসার - 04:37 এ কাজ শুরু হয়েছিল।

• (3) - এর জন্য গ্যাংলিয়া ডেটা নোডের সংক্ষিপ্তসার 19:47 এ কাজ শুরু হয়েছিল। সময়ের আগে গ্রাফ উপেক্ষা করুন।

গ্রাফটি মোটামুটি 2 বিভাগে বিভক্ত:

• প্রথম: বাইকি থেকে শুরু থেকে হ্রাস পর্যন্ত: সিপিইউ নিবিড়, কোনও নেটওয়ার্ক ক্রিয়াকলাপ নয়
• দ্বিতীয়: কমান্ডবাইয়ের পরে: সিপিইউ হ্রাস করে, নেটওয়ার্ক আই / ও করা হয়।

গ্রাফটি যেমন দেখায়, (1) যতটা সিপিইউ শক্তি দেওয়া হয়েছিল তা ব্যবহার করতে পারে। সুতরাং, এটি থ্রেড সংখ্যার সমস্যা নাও হতে পারে।

এই ফলাফলটি কীভাবে ব্যাখ্যা করবেন?

Comments

এখন আমি জিসিকে সন্দেহ করছি ... আসলে স্পার্ক ইউআইতে জিসির জন্য মোট সময় ব্যয় করা ছিল ২ এর চেয়ে বেশি)))।

— zeodtr

আপনি 3 জি 19 জি দিয়ে কেন চেষ্টা করলেন না? এটি কি এমন হতে পারে যে 4 জি-তে শ্রমিককে আবদ্ধ রাখার ফলে কিছু পিপিএল স্পটযুক্ত NUMA প্রভাবকে হ্রাস করতে পারে? অর্থাত্ আপনার 4G আপনার কর্মপ্রবাহে বরাদ্দকৃত 2 টির একটিতে অবস্থিত এবং এইভাবে কম i / o মন্দা রয়েছে, যা সামগ্রিকভাবে আরও ভাল পারফরম্যান্সের দিকে পরিচালিত করে। অন্যথায় আমি মনে করি একটি প্রধান প্রশ্ন হ'ল: একজন শ্রমিকের জন্য একক নির্বাহককে কয়টি কোর / থ্রেড ব্যবহার করতে পারে? (একজন কেবলমাত্র শ্রমিকের জন্য মোট কোরের সংখ্যা নির্দিষ্ট করতে পারবেন, নির্বাহকের গ্রানুলারিটিতে নয়)

— বেকন

বিটিডব্লিউ আমি কেবল কোডটি মূল / এসসিআর / মেইন / স্কেলা / অর্গ / অ্যাপাচি / স্পার্ক / মোতায়েন / কর্মী / এক্সিকিউটারআরনার.স্কালায় পরীক্ষা করে দেখেছি যে এটি 1 নির্বাহক = 1 কর্মীর থ্রেড।

— বেকন

কিছুটা দেরি হলেও এখানে এই বিষয় নিয়ে ক্লৌডের একটি পোস্ট রয়েছে: blog.cloudera.com/blog/2015/03/…

— ওরেলাস

যাইহোক, আমি একটি cloudera স্লাইড ডেক এই তথ্য পাওয়া slideshare.net/cloudera/... , যে নির্বাহক, কোর মধ্যে decission তৈরীর এবং মেমরি সম্পর্কে একটু ব্যাখ্যা করে

— মনীশ Sahni

Answer 1

আশাবাদী এগুলি আরও কিছুটা কংক্রিট করার জন্য, ক্লাস্টারের যতটা সম্ভব ব্যবহার করার জন্য স্পার্ক অ্যাপটি কনফিগার করার একটি কাজের উদাহরণ এখানে: নোডম্যানেজারগুলি চালিত ছয়টি নোডযুক্ত একটি ক্লাস্টারের কল্পনা করুন , প্রতিটি 16 টি কোর এবং GB৪ জিবি মেমরির সজ্জিত । নোডম্যানেজারের ক্ষমতা, yarn.nodemanager.resource.memory-mb এবং yarn.nodemanager.resource.cpu-vcores সম্ভবত যথাক্রমে 63 * 1024 = 64512 (মেগাবাইট) এবং 15 সেট করা উচিত। আমরা YARN পাত্রে 100% সংস্থানগুলি বরাদ্দ এড়াতে পারি কারণ নোডের ওএস এবং হ্যাডোপ ডেমনগুলি চালনার জন্য কিছু সংস্থান প্রয়োজন। এই ক্ষেত্রে, আমরা এই সিস্টেম প্রক্রিয়াগুলির জন্য একটি গিগাবাইট এবং একটি কোর ছেড়ে চলেছি। ক্লৌডের ম্যানেজার এগুলির জন্য অ্যাকাউন্টিং এবং এই YARN বৈশিষ্ট্যগুলি স্বয়ংক্রিয়ভাবে কনফিগার করে সহায়তা করে।

সম্ভবত প্রথম প্রেরণা হ'ল --num- এক্সিকিউটার 6 - এক্সেকিউটার-কোর 15 - এক্সিকিউটর-মেমরি 63 জি ব্যবহার করা । তবে এটি ভুল পদ্ধতির কারণ:

নোডম্যানেজারগুলির GB৩ গিগাবাইটের ক্ষমতার মধ্যে GB৩ জিবি + এক্সিকিউটার মেমরি ওভারহেড ফিট হবে না। অ্যাপ্লিকেশন মাস্টার নোডগুলির মধ্যে একটিতে একটি কোর গ্রহণ করবে, যার অর্থ that নোডে 15-কোর নির্বাহকের জন্য জায়গা থাকবে না। এক্সিকিউটারের জন্য 15 টি কোরে খারাপ এইচডিএফএস আই / ও থ্রুপুট হতে পারে।

আরও ভাল বিকল্প হ'ল --num- এক্সিকিউটার 17 - এক্সিকিউটর-কোর 5 - এক্সিকিউটর-মেমরি 19 জি ব্যবহার করা । কেন?

এই কনফিগারেশনের ফলাফল এএম সহ একটি ছাড়া অন্য সমস্ত নোডে তিনজন এক্সিকিউটারের হয়ে থাকে, যার দু'জন এক্সিকিউটার থাকবে। --executor- মেমোরিটি প্রাপ্ত হয়েছিল (নোডের প্রতি 63/3 এক্সিকিউটার) = 21. 21 * 0.07 = 1.47। 21 - 1.47 ~ 19।

ক্লাউডেরার ব্লগের একটি নিবন্ধে ব্যাখ্যাটি দেওয়া হয়েছিল, কীভাবে: আপনার অ্যাপাচি স্পার্ক জবসকে (পার্ট 2) টিউন করুন ।

Comments

"এই কনফিগারেশনের ফলস্বরূপ এএম এর সাথে একটি বাদে সমস্ত নোডে তিনজন নির্বাহকের ফলাফল রয়েছে, যার দুটি এক্সিকিউটার থাকবে" " "--Executor-cores 5" এর সাথে সম্পর্কিতটির অর্থ কী?

— ডেরেক

এর অর্থ প্রতিটি নির্বাহক 5 টি কোর ব্যবহার করে। প্রতিটি নোডে 3 জন এক্সিকিউটার রয়েছে সুতরাং 15 টি কোর ব্যবহার করে, নোডগুলির মধ্যে একটি ছাড়াও এই কাজের জন্য অ্যাপ্লিকেশন মাস্টার চালিত হবে, সুতরাং কেবলমাত্র 2 এক্সিকিউটিউটর অর্থাৎ এক্সিকিউটর হিসাবে 10 কোরের ব্যবহার করতে পারবেন।

— দাভোস

সুন্দরভাবে ব্যাখ্যা করা হয়েছে - দয়া করে নোট করুন যে এটি yarn.scheduler.capacity.resource-calculatorঅক্ষমদের ক্ষেত্রে প্রযোজ্য , যা ডিফল্ট। এটি ডিফল্টরূপে এটি মেমরির দ্বারা নির্ধারিত হয় এবং সিপিইউ দ্বারা নয়।

— YoYo

আরও নির্বাহকরা খারাপ এইচডিএফএস আই / ও থ্রুপুট নিয়ে যেতে পারে। সুতরাং আমি যদি এইচডিএফএস মোটেও ব্যবহার করছি না, সেক্ষেত্রে আমি আরও একবার নির্বাহকের জন্য পাঁচটি কোর ব্যবহার করতে পারি?

— দর্শনা

আমি যদিও অ্যাপ্লিকেশন মাস্টার প্রতিটি নোডে চলমান। উপরের প্রতি, যার অর্থ চাকরিটি চালানোর জন্য কেবলমাত্র 1 টি আবেদন মাস্টার থাকবে। এটা কি ঠিক?

— রওশন ফার্নান্দো

Answer 2

স্যান্ডি রিজা অনুসারে আপনি যখন আপনার স্পার্ক অ্যাপটি এইচডিএফএসের শীর্ষে চালাচ্ছেন

আমি লক্ষ করেছি যে এইচডিএফএস ক্লায়েন্টটি প্রচুর পরিমাণে সামঞ্জস্যের থ্রেড নিয়ে সমস্যায় পড়েছে। মোটামুটি অনুমান যে নির্বাহক প্রতি সর্বাধিক পাঁচটি কাজ সম্পূর্ণ রাইটিং থ্রুপুট অর্জন করতে পারে, সুতরাং নির্বাহক প্রতি কোর সংখ্যার নীচে রাখা ভাল।

সুতরাং আমি বিশ্বাস করি যে আপনার প্রথম কনফিগারেশনটি তৃতীয়টির চেয়ে ধীরতর কারণ খারাপ এইচডিএফএস আই / ও থ্রুপুট

Answer 3

আমি নিজে এই সেটিংগুলির সাথে খেলিনি তাই এটি কেবল জল্পনা ulation তবে আমরা যদি বিতরণ সিস্টেমে এই সমস্যাটিকে সাধারণ কোর এবং থ্রেড হিসাবে মনে করি তবে আপনার ক্লাস্টারে আপনি 12 টি কোর (4 * 3 মেশিন) এবং 24 টি থ্রেড ব্যবহার করতে পারেন (8 * 3 মেশিন)। আপনার প্রথম দুটি উদাহরণে আপনি আপনার কাজটি ন্যায্য সংখ্যক কোর (সম্ভাব্য গণনার স্থান) দিচ্ছেন কিন্তু সেই সমস্ত কোরগুলিতে চালিত থ্রেড (কাজ) এর সংখ্যা এতটাই সীমাবদ্ধ যে আপনি বরাদ্দকৃত প্রসেসিং পাওয়ারের অনেকাংশ ব্যবহার করতে সক্ষম নন এবং এইভাবে আরও গণনা সংস্থান বরাদ্দ করা সত্ত্বেও কাজটি ধীর গতিতে রয়েছে।

আপনি উল্লেখ করেছেন যে আপনার উদ্বেগটি বদলানো পদক্ষেপে ছিল - যদিও এলোমেলো পদক্ষেপে ওভারহেড সীমাবদ্ধ করে রাখা ভাল তবে ক্লাস্টারের সমান্তরালতাটি ব্যবহার করা সাধারণত অনেক বেশি গুরুত্বপূর্ণ। চূড়ান্ত কেস সম্পর্কে চিন্তা করুন - শূন্য শফল সহ একক থ্রেডেড প্রোগ্রাম।

Comments

আপনার উত্তরের জন্য ধন্যবাদ। তবে আমার সন্দেহ যে থ্রেডের সংখ্যাটি মূল সমস্যা নয়। আমি মনিটরিং স্ক্রিন ক্যাপচার যুক্ত করেছি। গ্রাফটি যেমন দেখায়, 1) যতটা সিপিইউ শক্তি দেওয়া হয়েছিল তা ব্যবহার করতে পারে।

— Zedodtr

@zeodtr pwilmot সঠিক - আপনার কোরগুলির সম্পূর্ণ সম্ভাব্যতাটি ব্যবহার করার জন্য আপনার 2-6 টি কার্য ন্যূনতম প্রয়োজন। এটি এটি রেখে দিন - আমি সাধারণত আমার 80 টি ক্লাস্টারের জন্য কমপক্ষে 1000 পার্টিশন ব্যবহার করি।

— সামতিবেস্ট

@ সাম্বেটিবেস্ট আমি যা জানতে চাই তা হল 1) এবং 3 এর মধ্যে পারফরম্যান্স পার্থক্যের কারণ। আমি যখন স্পার্ক ইউআই দেখি, উভয়ই বিভাগ 2 এর সমান্তরালভাবে 21 টি কার্য চালায় (কেন 3 এর ক্ষেত্রে 24 এর পরিবর্তে 21) আপাতত অজানা) তবে, 3 এর জন্য কার্যগুলি কেবল দ্রুত চলে।

— জেডডটর

Answer 4

সংক্ষিপ্ত উত্তর : আমার মনে হয় tgbaggio সঠিক। আপনি আপনার নির্বাহকদের উপর এইচডিএফএস থ্রুপুট সীমাবদ্ধ করেছেন।

আমি মনে করি যে এখানে দেওয়া কিছু সুপারিশের চেয়ে উত্তরটি এখানে কিছুটা সহজ হতে পারে।

আমার জন্য ক্লুটি ক্লাস্টার নেটওয়ার্ক গ্রাফে রয়েছে। রান 1 এর জন্য ব্যবহারটি 50 ডলার বাইট / সেকেন্ডে স্থির থাকে। 3 রান করার জন্য অবিচ্ছিন্ন ব্যবহার দ্বিগুণ করা হয়, প্রায় 100 এম বাইট / গুলি।

থেকে cloudera ব্লগ পোস্ট দ্বারা ভাগ করা DzOrd , আপনি এই গুরুত্বপূর্ণ উদ্ধৃতি দেখতে পারেন:

আমি লক্ষ করেছি যে এইচডিএফএস ক্লায়েন্টটি প্রচুর পরিমাণে সামঞ্জস্যের থ্রেড নিয়ে সমস্যায় পড়েছে। মোটামুটি অনুমান যে নির্বাহক প্রতি সর্বাধিক পাঁচটি কাজ সম্পূর্ণ রাইটিং থ্রুপুট অর্জন করতে পারে, সুতরাং নির্বাহক প্রতি কোরের সংখ্যাটি সেই সংখ্যার নীচে রাখা ভাল।

সুতরাং, আসুন কয়েকটি গণনা করা যাক আমরা যদি পারফরম্যান্স আশা করি তবে এটি সত্য হয়।

---

1: 19 গিগাবাইট, 7 টি কোর, 3 এক্সিকিউটার চালান

• 3 এক্সিকিউটার এক্স 7 থ্রেড = 21 থ্রেড
• এক্সিকিউটারের জন্য c টি কোর সহ, আমরা এইচডিএফএসের মধ্যে সীমাবদ্ধ আইও আশা করি (সর্বোচ্চ c 5 কোরের চেয়ে বেশি)
• কার্যকর থ্রুপুট 3 = 3 এক্সিকিউটার এক্স 5 থ্রেড = 15 থ্রেড

3: 4 জিবি, 2 কোর, 12 নির্বাহক চালান

• 2 এক্সিকিউটার x 12 থ্রেড = 24 থ্রেড
• এক্সিকিউটারের জন্য 2 টি কোর, তাই এইচডিএফএস থ্রুপুট ঠিক আছে
• কার্যকর থ্রুপুট 12 = 12 এক্সিকিউটার x 2 থ্রেড = 24 থ্রেড

---

যদি কাজটি 100% সীমাবদ্ধ থাকে (সম্মিলিত থ্রেড) by আমরা আশা করব রানটাইম পুরোপুরি বিপরীতভাবে থ্রেডের সংখ্যার সাথে সম্পর্কিত হবে।

ratio_num_threads = nthread_job1 / nthread_job3 = 15/24 = 0.625
inv_ratio_runtime = 1/(duration_job1 / duration_job3) = 1/(50/31) = 31/50 = 0.62

সুতরাং ratio_num_threads ~= inv_ratio_runtime, এবং দেখে মনে হচ্ছে আমরা নেটওয়ার্ক সীমাবদ্ধ।

এই একই প্রভাবটি রান 1 এবং রান 2 এর মধ্যে পার্থক্য ব্যাখ্যা করে।

---

2: 19 গিগাবাইট, 4 টি কোর, 3 এক্সিকিউটার চালান

• 3 এক্সিকিউটার এক্স 4 থ্রেড = 12 থ্রেড
• এক্সিকিউটারের জন্য 4 টি কোর সহ, ঠিক আছে আইও থেকে এইচডিএফএসে
• কার্যকর থ্রুপুট ~ = 3 এক্সিকিউটার x 4 থ্রেড = 12 থ্রেড

---

কার্যকর থ্রেড এবং রানটাইমের সংখ্যা তুলনা:

ratio_num_threads = nthread_job2 / nthread_job1 = 12/15 = 0.8
inv_ratio_runtime = 1/(duration_job2 / duration_job1) = 1/(55/50) = 50/55 = 0.91

এটি শেষ তুলনার মতো নিখুঁত নয়, তবে থ্রেডগুলি হারাতে পারলে আমরা পারফরম্যান্সে একই রকম ড্রপ দেখতে পাই see

এখন শেষ বিটের জন্য: কেন এটি এমন হয় যে আমরা আরও থ্রেড সহ আরও ভাল পারফরম্যান্স পাই, esp। সিপিইউ সংখ্যার চেয়ে বেশি থ্রেড?

সমান্তরালতা (একাধিক সিপিইউতে ডেটা বিভক্ত করার মাধ্যমে আমরা কী পাই) এবং সম্মতি (যে কোনও একক সিপিইউতে কাজ করার জন্য আমরা একাধিক থ্রেড ব্যবহার করি তখন আমরা কী পাই) এর মধ্যে পার্থক্যের একটি ভাল ব্যাখ্যা রব পাইকের এই দুর্দান্ত পোস্টটিতে সরবরাহ করা হয়েছে: সংহত সমান্তরালতা নয় ।

সংক্ষিপ্ত ব্যাখ্যাটি হ'ল যদি স্পার্কের কাজটি কোনও ফাইল সিস্টেম বা নেটওয়ার্কের সাথে ইন্টারঅ্যাক্ট করে তবে সিপিইউ সেই ইন্টারফেসগুলির সাথে যোগাযোগের জন্য অপেক্ষা করতে অনেক সময় ব্যয় করে এবং আসলে "কাজ করে" time এই সিপিইউগুলিকে একসাথে 1 টির বেশি কাজ করার জন্য, তারা অপেক্ষা করতে কম সময় এবং আরও বেশি সময় ব্যয় করছে এবং আপনি আরও ভাল পারফরম্যান্স দেখতে পাচ্ছেন।

Comments

আকর্ষণীয় এবং দৃinc় ব্যাখ্যা, আমি অবাক হয়েছি আপনি কীভাবে অনুমান করলেন যে নির্বাহকের সর্বাধিক মাধ্যমে আউটপুট অর্জনের জন্য 5 টি কাজের সীমা রয়েছে।

— ডেটা

সুতরাং 5 নম্বরটি এমন কিছু নয় যা আমি সামনে এলাম: আমি কেবল আইও বাধা দেওয়ার লক্ষণগুলি লক্ষ্য করেছি এবং সেই বাধা কোথায় থেকে আসতে পারে তার সন্ধানে গিয়েছিলাম।

— টার্টলমনভ

Answer 5

আরস্টুডিওর স্পার্ক্ল্লায়ার প্যাকেজ পৃষ্ঠায় পাওয়া দুর্দান্ত উত্স থেকে :

স্পার্ক সংজ্ঞা :

স্পার্ক নামকরণের জন্য কিছু সাধারণ সংজ্ঞা প্রদান করা কার্যকর হতে পারে:

নোড : একটি সার্ভার

কর্মী নোড : একটি সার্ভার যা ক্লাস্টারের অংশ এবং স্পার্ক কাজ চালানোর জন্য উপলব্ধ

মাস্টার নোড : সার্ভার যা কর্মী নোডগুলিকে সমন্বয় করে।

এক্সিকিউটার : নোডের ভিতরে এক ধরণের ভার্চুয়াল মেশিন। একটি নোডে একাধিক এক্সিকিউটার থাকতে পারে।

ড্রাইভার নোড : সেই নোড যা স্পার্ক সেশন শুরু করে। সাধারণত, এটি সার্ভার যেখানে স্পার্ক্ল্লায়ার অবস্থিত।

ড্রাইভার (এক্সিকিউটার) : ড্রাইভার নোড এক্সিকিউটারের তালিকায়ও প্রদর্শিত হবে।

Answer 6

স্পার্ক ডায়নামিক বরাদ্দ নমনীয়তা দেয় এবং গতিশীলভাবে সংস্থানগুলি বরাদ্দ করে। এই সংখ্যায় ন্যূনতম এবং সর্বাধিক নির্বাহক দেওয়া যেতে পারে। এছাড়াও অ্যাপ্লিকেশন শুরুর সময় যে পরিমাণ নির্বাহী চালু করতে হবে তাও দেওয়া যেতে পারে।

নীচে একই পড়ুন:

http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation

Answer 7

আমার মনে হয় প্রথম দুটি কনফিগারেশনে একটি ছোট সমস্যা রয়েছে। থ্রেড এবং কোরগুলির ধারণাগুলি নীচে। থ্রেডিংয়ের ধারণাটি যদি कोरগুলি আদর্শ হয় তবে ডেটা প্রক্রিয়া করার জন্য সেই কোরটি ব্যবহার করুন। সুতরাং স্মৃতি প্রথম দুটি ক্ষেত্রে সম্পূর্ণরূপে ব্যবহার হয় না। আপনি যদি এই উদাহরণটি চিহ্নিত করতে চান তবে প্রতিটি মেশিনে 10 টিরও বেশি কোরের মেশিনগুলি চয়ন করুন । তারপরে বেঞ্চ চিহ্নটি করুন।

তবে এক্সিকিউটারের জন্য 5 টিরও বেশি কোর দেবেন না I / o পারফরম্যান্সে বোতল গলা থাকবে।

সুতরাং এই বেঞ্চটি চিহ্নিত করার জন্য সেরা মেশিনগুলি এমন ডেটা নোড হতে পারে যার মধ্যে 10 টি কর থাকে।

ডেটা নোড মেশিনের স্পেস: সিপিইউ: কোর আই 7-4790 (কোরগুলির #: 10, # থ্রেডগুলির মধ্যে: 20) র‌্যাম: 32 জিবি (8 জিবি এক্স 4) এইচডিডি: 8 টিবি (2 টিবি এক্স 4)

Answer 8

আমি মনে করি একটি বড় কারণ হ'ল লোকালয়। আপনার ইনপুট ফাইলের আকার 165G, ফাইলের সম্পর্কিত ব্লকগুলি অবশ্যই একাধিক ডেটানোডগুলিতে বিতরণ করা হয়েছে, আরও এক্সিকিউটিউটর নেটওয়ার্ক অনুলিপি এড়াতে পারবেন।

নির্বাহকের সংখ্যা সমান ব্লক গণনা সেট করার চেষ্টা করুন, আমি মনে করি দ্রুততর হতে পারে।