সার্ভার সমাপ্তির পরে অবজেক্টগুলিকে সঠিকভাবে নিষ্পত্তি করা


9

আমি একটি বড় সি ++ প্রকল্পে কাজ করছি। এটি এমন একটি সার্ভারে অন্তর্ভুক্ত যা একটি REST API উন্মুক্ত করে, অন্য অনেকগুলি সার্ভারের সমন্বয়ে খুব বিস্তৃত সিস্টেমের জন্য একটি সহজ এবং ব্যবহারকারী-বান্ধব ইন্টারফেস সরবরাহ করে। কোডবেসটি বেশ বড় এবং জটিল এবং যথাযথ ডিজাইনের সামনে না রেখে সময়ের সাথে বিকশিত হয়েছে। আমার কাজটি হ'ল নতুন বৈশিষ্ট্যগুলি প্রয়োগ করা এবং এটিকে আরও স্থিতিশীল এবং নির্ভরযোগ্য করার জন্য পুরানো কোডটি রিফ্যাক্টর / ঠিক করা।

এই মুহুর্তে, সার্ভারটি প্রচুর দীর্ঘজীবী অবজেক্ট তৈরি করে যা প্রক্রিয়াটি শেষ হয়ে গেলে কখনও শেষ হয় না বা নিষ্পত্তি হয় না। এটি ভালগ্রিন্ডকে ফাঁস সনাক্তকরণের জন্য প্রায় অকেজো করে তোলে, কারণ "বিপজ্জনক" থেকে হাজার হাজার (প্রশ্নোত্তর) বৈধ লিকের মধ্যে পার্থক্য করা অসম্ভব।

আমার ধারণা হ'ল সমাপ্তির আগে সমস্ত বস্তু নিষ্পত্তি করা হয়েছে তা নিশ্চিত করা, কিন্তু যখন আমি এই প্রস্তাবটি তৈরি করি তখন আমার সহকর্মীরা এবং আমার বস আমাকে বিরোধিতা করে বলেছিলেন যে ওএস যেভাবেই সেই স্মৃতি মুক্ত করতে চলেছে (যা সবার কাছে স্পষ্ট) এবং অবজেক্টগুলি নিষ্পত্তি করে দিচ্ছে সার্ভারের শাটডাউনটি ধীর করবে (যা এই মুহূর্তে মূলত একটি কল std::exit) আমি জবাব দিয়েছি যে "ক্লিন" শাটডাউন পদ্ধতি থাকার কারণে এটি অবশ্যই ব্যবহার করা উচিত নয়। আমরা অধৈর্য বোধ করলে আমরা সবসময় কল করতে পারি std::quick_exitবা কেবল kill -9প্রক্রিয়াটি করতে পারি।

তারা জবাব দিয়েছিল "বেশিরভাগ লিনাক্স ডিমন এবং প্রক্রিয়াগুলি শাটডাউনে মেমরি মুক্ত করতে বিরত হয় না"। আমি এটি দেখতে পাচ্ছি, এটি সত্য যে আমাদের প্রকল্পের সঠিক মেমরি ডিবাগিংয়ের দরকার নেই, কারণ আমি ইতিমধ্যে মেমরির দুর্নীতি, ডাবল ফ্রি এবং অবিচ্ছিন্ন ভেরিয়েবলগুলি পেয়েছি।

আপনার চিন্তা কি? আমি কি অর্থহীন প্রচেষ্টা অনুসরণ করছি? যদি তা না হয় তবে আমি কীভাবে আমার সহকর্মীদের এবং আমার মনিবকে বোঝাতে পারি? যদি তা হয় তবে কেন এবং এর পরিবর্তে আমার কী করা উচিত?


পারফরম্যান্স যুক্তি (যা যুক্তিসঙ্গত!) ছাড়াও দীর্ঘস্থায়ী বস্তুগুলি বিচ্ছিন্ন করার জন্য এবং তাদের জন্য ক্লিন-আপ কোড যুক্ত করার জন্য কি অনেক চেষ্টা করা হচ্ছে?
ডক ব্রাউন

উত্তর:


7

সার্ভার প্রক্রিয়াতে একটি স্যুইচ যুক্ত করুন যা ভ্যালগ্রাইন্ড পরিমাপের সময় ব্যবহার করা যেতে পারে যা সমস্ত স্মৃতি ছেড়ে দেয়। আপনি এই সুইচটি পরীক্ষার জন্য ব্যবহার করতে পারেন। প্রভাব স্বাভাবিক ক্রিয়াকলাপের সময় সর্বনিম্ন হবে।

আমাদের একটি দীর্ঘ চলমান প্রক্রিয়া ছিল যা 1000 এর অবজেক্ট প্রকাশ করতে কয়েক মিনিট সময় নেয়। এটি কেবল প্রস্থান এবং তাদের মরতে দেওয়া অনেক বেশি দক্ষ ছিল। দুর্ভাগ্যক্রমে, আপনি যেমনটি ইঙ্গিত করেছেন, এটি ভ্যালগ্র্রিন্ড বা অন্য কোনও সরঞ্জাম দিয়ে সত্যিকারের মেমরি ফাঁস সনাক্ত করতে অসুবিধাজনক হয়েছে।

এটি আমাদের পরীক্ষার জন্য একটি ভাল সমঝোতা ছিল যখন সাধারণ পারফরম্যান্সকে প্রভাবিত করে না।


1
+1 বাস্তববাদ এফটিডাব্লু। পরিমাপের মান রয়েছে তবে দ্রুত শাটডাউনের মানও রয়েছে।
রস প্যাটারসন

2
কমান্ড লাইন সুইচের বিকল্প হিসাবে আপনি একটি # আইফডিএফ ডিইবিইউজি ব্লকের অভ্যন্তরে স্থায়ী অবজেক্টগুলি মুছে ফেলার বিষয়টি প্রয়োগ করতেও বিবেচনা করতে পারেন।
জুলাই

3

এখানে মূল কীটি হ'ল:

আমি এটি দেখতে পাচ্ছি, এটি সত্য যে আমাদের প্রকল্পের সঠিক মেমরি ডিবাগিংয়ের দরকার নেই, কারণ আমি ইতিমধ্যে মেমরির দুর্নীতি, ডাবল ফ্রি এবং অবিচ্ছিন্ন ভেরিয়েবলগুলি পেয়েছি।

এটি বেশিরভাগই সরাসরি বোঝায় যে আপনার কোডবেস আশা এবং স্ট্রিং ছাড়া আর কিছুই থেকে একসাথে আবদ্ধ। সক্ষম সি ++ প্রোগ্রামারদের ডাবল ফ্রি নেই।

আপনি একেবারে একটি নিরর্থক প্রচেষ্টা অনুসরণ করছেন- হিসাবে আপনি প্রকৃত সমস্যার একটি ক্ষুদ্র লক্ষণটি সম্বোধন করছেন, যা আপনার কোড অ্যাপোলো 13 পরিষেবা মডিউল হিসাবে প্রায় নির্ভরযোগ্য reliable

আপনি যদি সার্ভারকে সঠিকভাবে আরআইআইআই এর সাথে প্রোগ্রাম করেন তবে এই সমস্যাগুলি দেখা দেবে না এবং আপনার প্রশ্নের সমস্যাটি দূর হয়ে যাবে। এছাড়াও, আপনার কোড সময়ে সময়ে সঠিকভাবে কার্যকর হতে পারে। সুতরাং, এটি স্পষ্টভাবে সেরা বিকল্প।


অবশ্যই সমস্যাটি বৃহত্তর ছবিতে রয়েছে। তবে এটি খুব বিরল যে কেউ কোনও প্রকল্পকে আরও ভাল আকারের জন্য রিফ্যাক্টর / পুনর্লিখনের জন্য সংস্থান এবং অনুমতি পেতে পারে।
চেঞ্জিজ

@ সেনজিজকান: আপনি যদি বাগগুলি ঠিক করতে চান তবে আপনাকে রিফ্যাক্টর লাগবে। এটি কিভাবে এটি কাজ করে।
ডেডএমজি

2

একটি ভাল পদ্ধতির শ্রেণিবিন্যাসের মাধ্যমে আপনার সহকর্মীদের সাথে আলোচনা সংকীর্ণ করা হবে। একটি বৃহত কোড বেস দেওয়া, অবশ্যই দীর্ঘ জীবিত অবজেক্টের একক কারণ নয় বরং একাধিক, (শনাক্তযোগ্য) কারণ রয়েছে।

উদাহরণ:

  • দীর্ঘ জীবন্ত বস্তু যা কারও দ্বারা রেফারেন্স করা হয় না (আসল ফাঁস)। এটি একটি প্রোগ্রামিং লজিক ত্রুটি। নিম্ন অগ্রাধিকার ব্যতীত যাদের এটি স্থির করুন তারা আপনার মেমরির পদক্ষেপের জন্য সময়ের সাথে সাথে বৃদ্ধির জন্য দায়ী (এবং আপনার অ্যাপ্লিকেশনগুলির মানের অবনতি ঘটায়)। যদি তারা সময়ের সাথে আপনার মেমরির পদচিহ্নগুলি বাড়িয়ে তোলে তবে তাদের উচ্চ অগ্রাধিকারের সাথে ঠিক করুন।

  • দীর্ঘ জীবন্ত অবজেক্টগুলি, যা এখনও রেফারেন্সযুক্ত তবে আর ব্যবহার করা হয়নি (প্রোগ্রাম লজিকের কারণে), তবে এটি আপনার স্মৃতি পদক্ষেপকে বাড়ায় না। কোড পর্যালোচনা করুন এবং অন্যান্য বাগগুলি যা সেটিকে সন্ধান করার চেষ্টা করুন। কোড বেজে মন্তব্য যুক্ত করুন যদি এটি উদ্দেশ্যমূলক (পারফরম্যান্স) অপ্টিমাইজেশন হয়।

  • "নকশার দ্বারা" দীর্ঘ জীবন্ত বস্তু। উদাহরণস্বরূপ একক প্যাটার্ন। এগুলি থেকে মুক্তি পাওয়া সত্যিই কঠিন, বিশেষত যদি এটি বহু-থ্রেডযুক্ত অ্যাপ্লিকেশন হয়।

  • পুনর্ব্যবহারযোগ্য বস্তু। দীর্ঘজীবী জিনিসগুলি সর্বদা খারাপ হওয়া উচিত নয়। তারা উপকারী হতে পারে। উচ্চ ফ্রিকোয়েন্সি মেমরি বরাদ্দ / ডিএলোকেশনের পরিবর্তে, যখন এই ধরণের মেমরি ব্লকের আবার প্রয়োজন হয় তখন থেকে একটি কন্টেইনারটিতে অব্যবহৃত অবজেক্টগুলি যুক্ত করা কোনও অ্যাপ্লিকেশনকে গতি বাড়িয়ে তুলতে এবং হিপ বিভাজন এড়াতে সহায়তা করে। শাটডাউন সময়ে এগুলি ফ্রি করা সহজ হওয়া উচিত, সম্ভবত কোনও বিশেষ "উপকরণ / পরীক্ষিত" বিল্ডে।

  • "অংশীদারি অবজেক্টস" - একাধিক অন্যান্য বস্তুর দ্বারা ব্যবহৃত (রেফারেন্স করা) অবজেক্ট এবং এগুলি মুক্ত করার জন্য কখন সংরক্ষণ করা হয় তা কেউ জানে না। এগুলি রেফারেন্স গণনা করা বস্তুগুলিতে রূপান্তর করার বিষয়ে বিবেচনা করুন।

একবার আপনি এই অদম্য বস্তুর প্রকৃত কারণগুলি শ্রেণিবদ্ধ করে ফেললে কেস আলোচনার মাধ্যমে কেস প্রবেশ করা এবং সমাধান পাওয়া খুব সহজ।


0

আইএমএইচও, যখন সিস্টেমটি বন্ধ হয়ে যায় তখন এই সামগ্রীর জীবনকাল কখনই ঠিক তৈরি করা উচিত এবং মারা যাওয়া উচিত নয়। গ্লোবাল ভেরিয়েবলগুলির এই রেকস, যা আমরা সবাই জানি খারাপ খারাপ খারাপ খারাপ। বিশেষত স্মার্ট পয়েন্টার যুগে, অলসতা ছাড়া এটি করার কোনও কারণ নেই। তবে আরও গুরুত্বপূর্ণ বিষয়, এটি আপনার সিস্টেমে এমন এক স্তর প্রযুক্তিগত debtণ যুক্ত করে যে কাউকে কিছুদিনের জন্য ডিল করতে হতে পারে।

"প্রযুক্তিগত debtণ" এর ধারণাটি হ'ল আপনি যখন এই জাতীয় শর্টকাট গ্রহণ করেন, যখন কেউ ভবিষ্যতে কোড পরিবর্তন করতে চায় (বলতে দিন, আমি ক্লায়েন্টকে "অফলাইন মোড" বা "স্লিপ মোডে যেতে সক্ষম করতে চাই) ", বা আমি প্রক্রিয়াটি পুনরায় আরম্ভ না করেই সার্ভারগুলি স্যুইচ করতে সক্ষম হতে চাই) আপনি যা করছেন তা এড়াতে তাদের চেষ্টা করতে হবে effort তবে তারা আপনার কোড বজায় রাখবে, সুতরাং তারা আপনার মতো করে প্রায় ততটা জানতে পারবে না, সুতরাং এটি তাদের আরও বেশি সময় নেবে (আমি 20% দীর্ঘ কথা বলছি না, আমি 20x দীর্ঘ কথা বলছি!)। এমনকি যদি এটি আপনি হয় তবে আপনি সপ্তাহে বা মাস ধরে এই নির্দিষ্ট কোডটিতে কাজ করেন নি এবং এটিকে সঠিকভাবে প্রয়োগ করতে কোব্বসটিকে ধুয়ে ফেলতে অনেক বেশি সময় লাগবে।

এই ক্ষেত্রে, এটি প্রদর্শিত হচ্ছে যে আপনি সার্ভার অবজেক্ট এবং "দীর্ঘজীবী" অবজেক্টগুলির মধ্যে খুব শক্ত সংযোগ স্থাপন করেছেন ... এমন সময় আসে যখন কোনও রেকর্ড সার্ভারের সাথে সংযোগকে আউটলাইভ করতে পারে (এবং হওয়া উচিত)। সার্ভারে কোনও সামগ্রীতে প্রতি একক পরিবর্তন বজায় রাখা ব্যয়বহুল হতে পারে, তাই সাধারণত এটি ভাল যে প্রকৃতপক্ষে সার্ভারটি পরিবর্তন করে সেভ এবং আপডেট কলগুলি দিয়ে স্প্যানযুক্ত বস্তুগুলি সত্যই সার্ভার অবজেক্টে হ্যান্ডেল করা হয়। একে সাধারণত সক্রিয় রেকর্ড প্যাটার্ন বলা হয়। দেখা:

http://en.wikipedia.org/wiki/Active_record_pattern

সি ++ এ, আমার প্রতিটি সক্রিয় রেকর্ডটিতে সার্ভারে একটি দুর্বল_পিটার থাকতে হবে, যা সার্ভারের সংযোগটি অন্ধকার হয়ে গেলে জিনিসগুলি বুদ্ধি করে ফেলতে পারে। এই ক্লাসগুলি আপনার প্রয়োজনের উপর নির্ভর করে অলস বা ব্যাচ জনবহুল হতে পারে তবে objects অবজেক্টগুলির আজীবন কেবলমাত্র যেখানে সেগুলি ব্যবহৃত হবে।

আরো দেখুন:

কোনও প্রক্রিয়া থেকে বেরিয়ে আসার আগে কী কী সম্পদ মুক্ত করতে সময় নষ্ট করা উচিত?

অন্যটি


This reeks of global variables"তাদের হাজার হাজার বস্তু মুক্ত করতে হবে" "তারা অবশ্যই বিশ্বব্যাপী হতে হবে" থেকে আপনি কীভাবে যাবেন? এটাই বেশ যুক্তি।
ডোভাল

0

যদি আপনি সহজেই সনাক্ত করতে পারেন যে অনির্দিষ্টকালের জন্য বেঁচে থাকা অবজেক্টগুলি বরাদ্দ করা হয় তবে একবার বিকল্প বরাদ্দ প্রক্রিয়া ব্যবহার করে তাদের বরাদ্দ দেওয়া সম্ভব হয় যাতে তারা কোনও ভ্যালগ্রিন্ড ফাঁস রিপোর্টে প্রদর্শিত না হয় বা কেবল একটি একক বরাদ্দ হিসাবে উপস্থিত হয় না।

আপনি যদি ধারণার সাথে পরিচিত না হন তবে সি ++ তে কীভাবে কাস্টম মেমরি বরাদ্দ রাখতে হবে সে সম্পর্কে একটি নিবন্ধ এখানে দেওয়া হয়েছে , তবে নোট করুন যে আপনার সমাধানটি নিবন্ধের উদাহরণগুলির চেয়ে সহজতর হতে পারে কারণ আপনাকে মুছে ফেলার কোনও প্রয়োজন নেই all !

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.