লিনাক্সে O_DIRECT এর ব্যবহার


24

এই প্রশ্নটি যদি খুব প্রোগ্রামার ভিত্তিক হয় তবে আমাকে জানান। আমি অবাক হয়েছি যদি লিনাক্স ২.6-তে ওপেন () সিস্টেম কলের জন্য ও_ডিআরইসিটি পতাকাটির সাথে পরিচিত লোকেরা থাকে? লিনাস এর ব্যবহারকে ব্যর্থ করে, তবে উচ্চ সম্পাদনকারী ফাইল রাইটিং এর ব্যবহারকে ইঙ্গিত করে বলে মনে হয়। আমি কোনও বাস্তব বিশ্বের অভিজ্ঞতা এবং সুপারিশ সম্পর্কে জানতে চাই।

আরও তথ্য: আমি যে অ্যাপ্লিকেশনটি ব্যবহার করছি তা তার নিজস্ব ক্যাশে বজায় রাখে এবং এর ফলে গড়ে 5x বা তার বেশি গতি অর্জন করে। ফাইল লিখতে গিয়ে ক্যাশের বিষয়বস্তু অবশ্যই ফাইল সিস্টেম ক্যাশে লিখতে হবে, যা অনর্থক এবং কার্য সম্পাদনের উদ্বেগ বলে মনে হচ্ছে।

উত্তর:


17

ঠিক আছে, আপনি অভিজ্ঞতার জন্য জিজ্ঞাসা করুন, এটি প্রশ্নটিকে কিছুটা সাবজেক্টিভ এবং যুক্তিযুক্ত করে তোলে তবে উত্তীর্ণযোগ্য।

লিনাস বলেছিলেন যে লোকেরা সাধারণত ও_ডিআরইসিটির সাথে লোকেরা যে ব্যবহারগুলি উল্লেখ করে এবং সেই ব্যবহারগুলির জন্য আইএমও লিনাস বেশিরভাগ ক্ষেত্রেই সঠিক। এমনকি যদি আপনি সরাসরি আই / ও করেন, আপনি সরাসরি আপনার প্রোগ্রামের স্টেটমেন্টগুলিতে ডিভাইসগুলিতে / থেকে ডেটা স্থানান্তর করতে পারবেন না, আপনার একটি বাফার দরকার যা ভরাট হয় (প্রোগ্রাম বা ডিভাইস দ্বারা) এবং অন্যদিকে সিস্টেম কলের মাধ্যমে স্থানান্তরিত হয়। এছাড়াও, এটিকে দক্ষ করে তোলার জন্য, আপনার যদি আবার এটির প্রয়োজন হয় তবে আপনি সবেমাত্র ইতিমধ্যে পড়া কিছু পুনরায় পড়তে চাইবেন না। সুতরাং আপনার কিছু ধরণের ক্যাশে দরকার ... এবং এটি হ'ল কার্নেল O_DIRECT ছাড়াই সরবরাহ করে, একটি পৃষ্ঠায় ক্যাশে! কেন ব্যবহার করবেন না? এটি আরও সুবিধাগুলি নিয়ে আসে যদি আরও প্রক্রিয়াগুলি একই ফাইল একই সাথে অ্যাক্সেস করতে চায় তবে এটি O_DIRECT দ্বারা বিপর্যয় হবে।

এটি বলার পরে, O_DIRECT এর ব্যবহার রয়েছে: যদি কোনও কারণে আপনার সরাসরি ব্লক ডিভাইস থেকে ডেটা নেওয়া দরকার। পারফরম্যান্সের সাথে এর কোনও যোগসূত্র নেই।

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

আমি আমার মেশিনে মেমরির ত্রুটি খুঁজে পেতে বিড়ালের একটি সহজ প্রয়োগের জন্য O_DIRECT ব্যবহার করেছি। এটি O_DIRECT এর জন্য একটি বৈধ ব্যবহার। পারফরম্যান্সের সাথে এর কোনও যোগসূত্র ছিল না।


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

4
ও_ডাইরেক্ট এমন সিস্টেমে কার্যকর হতে পারে যেখানে বিকাশকারী অ্যাপ্লিকেশন স্তরে ক্যাচিং ব্যবস্থা সরবরাহ করতে চান (ডাটাবেসগুলি ভাবেন)।
Jmoney38

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

14

আসলে, O_DIRECT এর যে কোন একটি এড়াতে প্রয়োজন

  • ক্যাশে দূষণ - কখনও কখনও আপনি জানেন যে ক্যাচিংয়ের সাথে ওভারহেডের কোনও ধারণা নেই, উদাহরণস্বরূপ সত্যিকারের বড় ফাইলগুলির সাথে লেনদেন করার সময়, মাত্র 2 গিগাবাইট র‌্যাম রয়েছে যখন G৪ জিবি বলুন। 32 জিআইবির টরেন্ট ফাইল যা কোনও ব্যবহারকারী যাচাই করার সিদ্ধান্ত নিয়েছে তা ক্যাশে যাওয়ার পক্ষে ভাল প্রার্থী বলে মনে হচ্ছে না। এটি কেবল নিজের ওভারহেড দিয়ে অতিরিক্ত ক্রিয়াকলাপ। এবং এটি ক্যাশে থেকে কিছু সত্য উপকারী ডেটা ছাঁটাই করতে পারে।
  • ডাবল ক্যাচিং - যেমন কিছু আরডিবিএমএস (উল্লেখ করার জন্য মাইএসকিউএল) এর নিজস্ব ক্যাশে সংজ্ঞায়িত করার অনুমতি দেয় allows ডেটাবেসগুলি কর্ণেলের ভার্চুয়াল মেমোরি যা এসকিউএল পরিকল্পনা সম্পর্কিত কিছুই জানতে পারে না তার চেয়ে কীভাবে ক্যাশে যায় এবং কী কী তা ভালভাবে জানে।

- যা কোনও ভাল নয়, যেমনটি মনে হয়। এবং O_DIRECTদ্রুত হওয়া মানে না, প্রায়শই তা হয় না


10
posix_fadviseক্যাশে দূষণ সমস্যার যত্ন নিতে পারে।
psusi

আমি মনে করি না যে ভার্চুয়াল মেমরির সাথে এর কোনও সম্পর্ক আছে এটি কেবল মেমরির ঠিকানা মানচিত্র করে। বাফার ক্যাশে / পৃষ্ঠা ক্যাশে বলতে যা বোঝায় তাই।
আরেকবুলস্কি 26:51

ক্যাশে / ক্যাশিং ইউএনআইএক্স-এর ভিএম সাবসিস্টেমের অংশ, যতদূর আমি বলতে পারি, এই কারণে আমি এই শব্দটি ব্যবহার করেছি। সম্পাদনার জন্য ধন্যবাদ। :)
কবুতর

6

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


1
বাগ রিপোর্টটি আসলে জার্নাল = ডেটা বিকল্পের সাথে ফাইল সিস্টেমের ব্যবহারের বিষয়ে আলোচনা করে। এই বিকল্পটি O_DIRECT পতাকার সাথে সরাসরি বিপরীত। বেশিরভাগ ext3 এবং ext4 ফাইল সিস্টেমে এই পতাকা সেট থাকে না এবং যদি তা করে, এটি বন্ধ করে রাখলে O_DIRECT দিয়ে ফাইলটি খোলার অনুমতি দেওয়া হবে।
নৈমিত্তিকের

3

পারফরম্যান্সের সাথে এর অনেক কিছুই রয়েছে।

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

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

তবে এটি মনে রাখা জরুরী যে O_DIRECT সম্পদ বরাদ্দে ন্যায্যতা ভঙ্গ করে। আপনার অ্যাপ্লিকেশনটির গতি বাড়ানোর একটি কারণ হ'ল এটি অন্যান্য জিনিসগুলি ধীর করে দিচ্ছে।


আপনি বলছেন এর পারফরম্যান্সের সাথে অনেক কিছু করার আছে, তবুও, আপনি একটি উদাহরণ সরবরাহ করেন যেখানে এটি ক্ষীণতা বা অর্ডার লেখার হ্রাস করতে ব্যবহৃত হয়। তবে আমি সম্মত হই না যে এটি কার্য সম্পাদনকে প্রভাবিত করে। ন্যায্যতা সম্পর্কে ফর্সা পয়েন্ট।
আরেকবুলস্কি

যখন আপনি অন্যায় হন তখন কি আপনি আরও রেফারেন্স সরবরাহ করতে পারেন?
এসাইক্লিক

3

@ জুলিয়ানো ইতিমধ্যে যা বলেছে তার সাথে সম্পর্কিত।

চেকআউট posix_fadviseযদি বাস্তব সমস্যা ফাইলসিস্টেম ক্যাশে আলগোরিদিম অন্তর্নিহিত এর অশোভন আচরণ চলে এলে, আপনি উপদেশ দিতে, আপনি কিভাবে ফাইল সিস্টেম ব্যবহার করতে যাচ্ছি চেষ্টা করতে পারেন। সুন্দরভাবে প্রয়োগ করা fs এর জন্য, এটির কার্য সম্পাদন বাড়ানো উচিত। (অনুরূপ বিবেচনার সাথে স্পর্শ করা অন্য বিষয়ের লিঙ্কটি এখানে /programming//a/3755818/544721 )


1
দেখে মনে হচ্ছে পিক্স_ফ্যাডভিস কার্নেলের দ্বারা ব্যবহৃত রিডহেড অ্যালগরিদমগুলিকে পরিবর্তন করে। প্রশ্নের কোড সহ সমালোচনামূলক কারণটি হল রাইটিং পারফরম্যান্স। সমস্যাটি হ'ল বাফারটি লেখার ফলে লিনাক্সের ক্যাশেগুলি প্রথমে পূর্ণ হয় যা মেমরির বাইরে চলে যাওয়ার পরে কার্নেলটি ডাম্প করতে হয়। এটি প্রচেষ্টার অপচয়, এই ক্ষেত্রে আউটপুটটি ডিস্কে যাওয়ার পথে ন্যূনতমভাবে বাফার করা উচিত।
নৈমিত্তিক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.