PostgreSQL কর্মক্ষমতা উন্নত করতে লিনাক্স টিউনিং। ইলিয়া কোসমোডেমিয়ানস্কি

ইলিয়া কোসমোডেমিয়ানস্কির 2015 রিপোর্টের প্রতিলিপি "পোস্টগ্রেএসকিউএল কর্মক্ষমতা উন্নত করতে লিনাক্স টিউনিং"

দাবিত্যাগ: আমি লক্ষ্য করেছি যে এই প্রতিবেদনটি নভেম্বর 2015 তারিখের - 4 বছরেরও বেশি সময় কেটে গেছে এবং অনেক সময় অতিবাহিত হয়েছে৷ প্রতিবেদনে আলোচিত সংস্করণ 9.4 আর সমর্থিত নয়। গত 4 বছরে, PostgreSQL-এর 5টি নতুন রিলিজ প্রকাশিত হয়েছে, এবং Linux কার্নেলের 15টি সংস্করণ প্রকাশ করা হয়েছে। আপনি যদি এই প্যাসেজগুলি আবার লেখেন, তাহলে আপনি একটি ভিন্ন রিপোর্ট দিয়ে শেষ করবেন। কিন্তু এখানে আমরা PostgreSQL এর জন্য মৌলিক লিনাক্স টিউনিং বিবেচনা করি, যা আজও প্রাসঙ্গিক।

আমার নাম ইলিয়া কোসমোডেমিয়ানস্কি। আমি PostgreSQL-Consulting এ কাজ করি। এবং এখন আমি সাধারণভাবে ডাটাবেস এবং বিশেষ করে PostgreSQL সম্পর্কিত লিনাক্সের সাথে কী করতে হবে সে সম্পর্কে একটু কথা বলব, কারণ নীতিগুলি বেশ একই রকম।

আমরা কি সম্পর্কে কথা বলতে হবে? আপনি যদি PostgreSQL এর সাথে যোগাযোগ করেন, তাহলে কিছু পরিমাণে আপনাকে UNIX অ্যাডমিন হতে হবে। এর মানে কী? যদি আমরা Oracle এবং PostgreSQL এর তুলনা করি, তাহলে Oracle এ আপনাকে 80% DBA ডাটাবেস অ্যাডমিন এবং 20% Linux অ্যাডমিন হতে হবে।

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

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

এবং আমি মনে করি সবাই সোলারিসের মতো এক্সোটিকগুলিতে কম আগ্রহী, তাই চলুন।

আপনি কীভাবে কার্নেল তৈরি করবেন তার উপর নির্ভর করে একটি আধুনিক লিনাক্স ডিস্ট্রিবিউশনে 1টির বেশি syctl বিকল্প রয়েছে। একই সময়ে, আমরা যদি বিভিন্ন বাদামের দিকে তাকাই, আমরা অনেক উপায়ে কিছু সমন্বয় করতে পারি। কিভাবে তাদের মাউন্ট করতে ফাইল সিস্টেম পরামিতি আছে. এটি কীভাবে শুরু করবেন সে সম্পর্কে আপনার যদি প্রশ্ন থাকে: BIOS-এ কী সক্ষম করবেন, কীভাবে হার্ডওয়্যার কনফিগার করবেন ইত্যাদি।

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

লিনাক্সে কোন প্রথাগত টিউনিং টার্গেট আছে? আমি মনে করি যেহেতু আপনি সকলেই লিনাক্স প্রশাসনের সাথে কাজ করছেন, তাই লক্ষ্যগুলি কী তা ব্যাখ্যা করার কোনও বিশেষ প্রয়োজন নেই।

আপনি টিউন করতে পারেন:

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

PostgreSQL এবং সাধারণভাবে ডাটাবেসের বৈশিষ্ট্যগুলি কী কী? সমস্যাটি হল যে আপনি কোনও পৃথক বাদামকে পরিবর্তন করতে পারবেন না এবং দেখুন যে আমাদের কর্মক্ষমতা উল্লেখযোগ্যভাবে উন্নত হয়েছে।

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

নীতিগতভাবে, কিছু পরিমাণে পরিস্থিতি PostgreSQL এর সাথে ঠিক একই রকম। পার্থক্য হল যে ডাটাবেস এখনও নিজের জন্য সমস্ত সংস্থান নিতে সক্ষম নয়, অর্থাৎ লিনাক্স স্তরের কোথাও আপনাকে এটিকে নিজেরাই সাজাতে হবে।

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

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

ডিস্ক এই সিস্টেমের অধীনে বাস করে। আমি ডিস্ক হিসাবে এটি আঁকা. আসলে, একটি RAID কন্ট্রোলার, ইত্যাদি থাকতে পারে।

এবং এই ইনপুট-আউটপুট একটি উপায় বা অন্য এই ব্যাপার মাধ্যমে ঘটে.

PostgreSQL একটি ক্লাসিক ডাটাবেস। ভিতরে একটি পাতা আছে. এবং সমস্ত ইনপুট এবং আউটপুট পেজ ব্যবহার করে ঘটে। আমরা পৃষ্ঠাগুলির সাথে মেমরিতে ব্লকগুলিকে উত্থাপন করছি। এবং যদি কিছু না ঘটে তবে আমরা কেবল সেগুলি পড়ি, তারপর ধীরে ধীরে সেগুলি এই ক্যাশে থেকে, ভাগ করা বাফারগুলি থেকে অদৃশ্য হয়ে যায় এবং ডিস্কে ফিরে আসে।

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

কেন এটা করা হচ্ছে? আমরা যদি ভোল্টেজ হারিয়ে ফেলি, তবে আমরা এমন পরিস্থিতি পাইনি যে সমস্ত ডেটা হারিয়ে গেছে। অবিরাম মেমরি, যার সম্পর্কে সবাই আমাদের বলেছে, ডাটাবেস তত্ত্বে এখন পর্যন্ত রয়েছে - এটি একটি উজ্জ্বল ভবিষ্যত, যার জন্য আমরা অবশ্যই চেষ্টা করি এবং আমরা এটি পছন্দ করি, তবে আপাতত তারা বিয়োগ 20 বছর বেঁচে থাকে। এবং, অবশ্যই, এই সব নিরীক্ষণ করা প্রয়োজন।

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

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

এবং এর এই পয়েন্ট প্রতিটি মাধ্যমে যান.

এই পৃষ্ঠাগুলিকে আরও দ্রুত ভ্রমণ করতে, আপনাকে নিম্নলিখিতগুলি অর্জন করতে হবে:

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

যদি আপনার সার্ভারে 512 জিবি র‍্যাম থাকে এবং এর সমস্ত কিছুই কোনো ক্যাশে ছাড়াই একটি SATA হার্ড ড্রাইভে শেষ হয়, তাহলে পুরো ডাটাবেস সার্ভারটি কেবল একটি কুমড়া নয়, একটি SATA ইন্টারফেস সহ একটি কুমড়াতে পরিণত হবে৷ আপনি সরাসরি এটিতে ছুটে যাবেন। এবং কিছুই আপনাকে রক্ষা করবে না।

স্মৃতির সাথে প্রথম পয়েন্ট সম্পর্কে, তিনটি জিনিস রয়েছে যা জীবনকে খুব কঠিন করে তুলতে পারে।

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

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

আসলে কি হচ্ছে? NUMA মানে নন-ইউনিফর্ম মেমরি অ্যাক্সেস। আলোচ্য বিষয়টি কি? আপনার একটি সিপিইউ আছে, এটির পাশে এটির স্থানীয় মেমরি রয়েছে। এবং এই মেমরি ইন্টারকানেক্ট অন্যান্য সিপিইউ থেকে মেমরি টানতে পারে।

চালালে numactl --hardware, তাহলে আপনি এত বড় শীট পাবেন। অন্যান্য জিনিসের মধ্যে, একটি দূরত্বের ক্ষেত্র থাকবে। সংখ্যা থাকবে - 10-20, এরকম কিছু। এই সংখ্যাগুলি এই দূরবর্তী মেমরি বাছাই এবং স্থানীয়ভাবে ব্যবহার করার জন্য হপের সংখ্যা ছাড়া আর কিছুই নয়। নীতিগতভাবে, একটি ভাল ধারণা। এটি বিভিন্ন কাজের চাপের অধীনে পারফরম্যান্সের গতি বাড়ায়।

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

অতএব, ডাটাবেসের জন্য একটি আরও সঠিক বিকল্প হল লিনাক্স অপারেটিং সিস্টেমের জন্য সেখানে কী ঘটছে তা না জানার জন্য। যাতে এটি মেমরি অ্যাক্সেস করে যেমন এটি করে।

কেন এমন হল? মনে হচ্ছে এটা উল্টো হওয়া উচিত। এটি একটি সাধারণ কারণে ঘটে: আমাদের পৃষ্ঠা ক্যাশের জন্য প্রচুর মেমরির প্রয়োজন - দশ, শত শত গিগাবাইট।

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

অতএব, এই মুহুর্তে এখানে দুটি পন্থা রয়েছে, যতক্ষণ না উজ্জ্বল ভবিষ্যত আসে, এবং ডাটাবেস নিজেই বুঝতে পারে না যে এটি কোন CPU-তে চলছে এবং কোথা থেকে কিছু টানতে হবে।

অতএব, সঠিক পদ্ধতি হল NUMA সম্পূর্ণরূপে নিষ্ক্রিয় করা, উদাহরণস্বরূপ, রিবুট করার সময়। বেশিরভাগ ক্ষেত্রে, জয়গুলি এমন মাত্রার আদেশের হয় যে কোনটি ভাল তা নিয়ে প্রশ্ন ওঠে না।

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

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

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

জরুরী পরিস্থিতিতে, যখন সবকিছু খুব খারাপ, আপনার ফোন ক্রমাগত বাজছে এবং আপনার বস একটি বড় লাঠি নিয়ে ছুটে আসছেন, আপনার চেক করার কথা ভাবার সময় থাকবে না। এবং ফলাফল বেশ বিপর্যয়কর হতে পারে।

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

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

কেন এমন হল? তো কেমন যাচ্ছে? অপারেটিং সিস্টেম ছোট টুকরা মেমরি বরাদ্দ. এটা খুবই সুবিধাজনক, এটা ঐতিহাসিকভাবে কিভাবে ঘটেছে। এবং যদি আমরা বিস্তারিতভাবে যাই, ওএসকে অবশ্যই ভার্চুয়াল ঠিকানাগুলিকে প্রকৃত ঠিকানায় অনুবাদ করতে হবে। এবং এই প্রক্রিয়াটি সবচেয়ে সহজ নয়, তাই ওএস এই অপারেশনের ফলাফল ট্রান্সলেশন লুকসাইড বাফার (TLB) এ ক্যাশে করে।

এবং যেহেতু TLB একটি ক্যাশে, এই পরিস্থিতিতে একটি ক্যাশে অন্তর্নিহিত সমস্ত সমস্যা দেখা দেয়। প্রথমত, যদি আপনার প্রচুর RAM থাকে এবং এটি সমস্ত ছোট অংশে বরাদ্দ করা হয়, তাহলে এই বাফারটি অনেক বড় হয়ে যায়। এবং যদি ক্যাশে বড় হয়, তাহলে এটির মাধ্যমে অনুসন্ধান ধীর হয়। ওভারহেড স্বাস্থ্যকর এবং এটি নিজেই জায়গা নেয়, অর্থাত্ RAM কিছু ভুল দ্বারা গ্রাস করা হচ্ছে। এইবার.

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

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

এবং কিভাবে এটি PostgreSQL এর সাথে বন্ধুত্ব করা যায়? প্রথমত, লিনাক্স কার্নেলে বিশাল পৃষ্ঠাগুলি সক্রিয় করা আবশ্যক।

দ্বিতীয়ত, তাদের অবশ্যই sysctl প্যারামিটার দ্বারা স্পষ্টভাবে উল্লেখ করতে হবে - কতগুলি আছে৷ এখানে নম্বরগুলি কিছু পুরানো সার্ভার থেকে এসেছে। আপনি কতগুলি ভাগ করা বাফার আছে তা গণনা করতে পারেন যাতে বিশাল পৃষ্ঠাগুলি সেখানে ফিট করতে পারে।

এবং যদি আপনার সম্পূর্ণ সার্ভার PostgreSQL-এ উত্সর্গীকৃত হয়, তাহলে একটি ভাল সূচনা পয়েন্ট হল RAM এর 25% ভাগ করা বাফারগুলিতে বরাদ্দ করা, অথবা 75% যদি আপনি নিশ্চিত হন যে আপনার ডাটাবেস অবশ্যই এই 75% এর মধ্যে ফিট হবে। শুরু বিন্দু এক. এবং বিবেচনা করুন, আপনার যদি 256 গিগাবাইট র‍্যাম থাকে, তবে সেই অনুযায়ী, আপনার কাছে 64 জিবি বড় বাফার থাকবে। কিছু মার্জিন দিয়ে আনুমানিক গণনা করুন - এই চিত্রটি কী সেট করা উচিত।

সংস্করণ 9.2 এর আগে (যদি আমি ভুল না করি, সংস্করণ 8.2 থেকে), তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করে বিশাল পৃষ্ঠাগুলির সাথে PostgreSQL সংযোগ করা সম্ভব ছিল। এবং এটি সর্বদা করা উচিত। প্রথমত, সঠিকভাবে বিশাল পৃষ্ঠাগুলি বরাদ্দ করতে সক্ষম হওয়ার জন্য আপনার কার্নেল প্রয়োজন। এবং, দ্বিতীয়ত, যাতে তাদের সাথে কাজ করে এমন অ্যাপ্লিকেশন তাদের ব্যবহার করতে পারে। এটা শুধু যে ভাবে ব্যবহার করা হবে না. যেহেতু PostgreSQL সিস্টেম 5 স্টাইলে মেমরি বরাদ্দ করেছে, তাই এটি libhugetlbfs ব্যবহার করে করা যেতে পারে - এটি লাইব্রেরির পুরো নাম।

9.3-এ, মেমরির সাথে কাজ করার সময় PostgreSQL কর্মক্ষমতা উন্নত করা হয়েছিল এবং সিস্টেম 5 মেমরি বরাদ্দকরণ পদ্ধতি পরিত্যাগ করা হয়েছিল। সবাই খুব খুশি ছিল, কারণ অন্যথায় আপনি একটি মেশিনে দুটি PostgreSQL দৃষ্টান্ত চালানোর চেষ্টা করেন এবং তিনি বলেন যে আমার কাছে পর্যাপ্ত ভাগ করা মেমরি নেই। এবং তিনি বলেছেন যে sysctl সংশোধন করা প্রয়োজন। এবং এমন একটি sysctl আছে যা আপনাকে এখনও রিবুট করতে হবে ইত্যাদি। সাধারণভাবে, সবাই খুশি ছিল। কিন্তু mmap মেমরি বরাদ্দ বিশাল পেজ ব্যবহার ভেঙ্গে. আমাদের বেশিরভাগ ক্লায়েন্ট বড় ভাগ করা বাফার ব্যবহার করে। এবং আমরা দৃঢ়ভাবে 9.3-এ স্যুইচ না করার পরামর্শ দিই, কারণ ওভারহেড ভাল শতাংশে গণনা করা শুরু হয়েছিল।

কিন্তু সম্প্রদায় এই সমস্যার দিকে মনোযোগ দিয়েছে এবং 9.4-এ তারা এই ইভেন্টটি খুব ভালভাবে পুনরায় কাজ করেছে। এবং 9.4-এ postgresql.conf-এ একটি প্যারামিটার উপস্থিত হয়েছে যেখানে আপনি চালু বা বন্ধ করার চেষ্টা করতে পারবেন।

চেষ্টা নিরাপদ বিকল্প. যখন PostgreSQL শুরু হয়, যখন এটি ভাগ করা মেমরি বরাদ্দ করে, এটি বিশাল পৃষ্ঠাগুলি থেকে এই মেমরিটি দখল করার চেষ্টা করে। এবং যদি এটি কাজ না করে, তাহলে এটি স্বাভাবিক নির্বাচনে ফিরে আসে। এবং যদি আপনার ফ্রিবিএসডি বা সোলারিস থাকে তবে আপনি চেষ্টা করতে পারেন, এটি সর্বদা নিরাপদ।

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

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

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

এবং এটি বিভিন্ন উপায়ে খুব অপ্রীতিকর হবে। এবং প্রধান সমস্যা হল যে আধুনিক কার্নেলগুলি পুরানো লিনাক্স কার্নেল থেকে কিছুটা আলাদা আচরণ করে। এবং এই জিনিসটি পদক্ষেপ নেওয়া বেশ অপ্রীতিকর, কারণ যখন আমরা অদলবদল নিয়ে কিছু কাজ করার কথা বলি, তখন এটি OOM-হত্যাকারীর অকাল আগমনের সাথে শেষ হয়। এবং OOM-হত্যাকারী, যেটি সময়মতো পৌঁছায়নি এবং PostgreSQL ফেলে দিয়েছে, এটি অপ্রীতিকর। সবাই এই সম্পর্কে জানবে, অর্থাৎ শেষ ব্যবহারকারী পর্যন্ত।

কি হচ্ছে? আপনার সেখানে প্রচুর পরিমাণে RAM রয়েছে, সবকিছুই ঠিকঠাক কাজ করে। কিন্তু কিছু কারণে সার্ভার অদলবদল হ্যাং হয়ে যায় এবং এর কারণে গতি কমে যায়। মনে হবে অনেক স্মৃতি আছে, কিন্তু এটা ঘটে।

পূর্বে, আমরা vm.swappiness শূন্যে সেট করার পরামর্শ দিয়েছিলাম, অর্থাৎ অদলবদল নিষ্ক্রিয় করা। পূর্বে, মনে হয়েছিল যে 32 গিগাবাইট RAM এবং সংশ্লিষ্ট ভাগ করা বাফারগুলি একটি বিশাল পরিমাণ ছিল। অদলবদলের মূল উদ্দেশ্য হল আমরা পড়ে গেলে ভূত্বক নিক্ষেপ করার জন্য একটি জায়গা থাকা। এবং এটি আর বিশেষভাবে পূর্ণ হয়নি। এবং তারপর আপনি এই ভূত্বক সঙ্গে কি করতে যাচ্ছেন? এটি এমন একটি কাজ যেখানে কেন অদলবদল প্রয়োজন তা খুব স্পষ্ট নয়, বিশেষ করে এই ধরনের আকারের।

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

অতএব, এখন ডিফল্ট, যতদূর আমার মনে আছে, বেশিরভাগ ডিস্ট্রিবিউশন 6 এর কাছাকাছি, অর্থাৎ কতটা মেমরি বাকি আছে তার উপর নির্ভর করে আপনি কোন সময়ে সোয়াপ ব্যবহার শুরু করবেন। আমরা এখন vm.swappiness = 1 সেট করার পরামর্শ দিই, কারণ এটি কার্যত এটিকে বন্ধ করে দেয়, কিন্তু OOM-কিলারের মতো একই প্রভাব দেয় না যা অপ্রত্যাশিতভাবে এসে পুরো জিনিসটিকে হত্যা করে।

এরপর কি? যখন আমরা ডাটাবেসের কর্মক্ষমতা সম্পর্কে কথা বলি এবং ধীরে ধীরে ডিস্কের দিকে চলে যাই, তখন সবাই তাদের মাথা ধরতে শুরু করে। কারণ ডিস্ক ধীরগতির এবং স্মৃতিশক্তি দ্রুত এই সত্যটি ছোটবেলা থেকেই সবার কাছে পরিচিত। এবং সবাই জানে যে ডাটাবেসে ডিস্কের কর্মক্ষমতা সমস্যা থাকবে।

চেকপয়েন্ট স্পাইকের সাথে যুক্ত প্রধান PostgreSQL কর্মক্ষমতা সমস্যাটি ঘটে না কারণ ডিস্কটি ধীর। এটি সম্ভবত মেমরি এবং ডিস্ক ব্যান্ডউইথ ভারসাম্যপূর্ণ না হওয়ার কারণে। যাইহোক, তারা বিভিন্ন জায়গায় ভারসাম্য নাও হতে পারে। PostgreSQL কনফিগার করা নেই, OS কনফিগার করা নেই, হার্ডওয়্যার কনফিগার করা নেই এবং হার্ডওয়্যারটি ভুল। এবং এই সমস্যাটি তখনই ঘটে না যখন সবকিছু যেমন হওয়া উচিত তেমন ঘটে, যেমন হয় কোনও লোড নেই, বা সেটিংস এবং হার্ডওয়্যারগুলি ভালভাবে নির্বাচন করা হয়েছে।

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

এখানে আমার দুটি ছবি আছে। আমি এখন ব্যাখ্যা করব এটা কি। এগুলি দুটি সময়-সম্পর্কিত গ্রাফ। প্রথম গ্রাফটি ডিস্ক ব্যবহার। এই সময়ে এটি প্রায় 90% এ পৌঁছেছে। আপনার যদি ফিজিক্যাল ডিস্কের সাথে একটি ডাটাবেস ব্যর্থতা থাকে, 90% এ RAID কন্ট্রোলার ব্যবহার করে, তাহলে এটি খারাপ খবর। এর মানে হল একটু বেশি এবং এটি 100 এ পৌঁছাবে এবং I/O বন্ধ হয়ে যাবে।

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

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

এই সমস্যা কাটিয়ে ওঠার জন্য কী করা দরকার? আপনি যদি ডাটাবেসের অধীনে IO বন্ধ করে থাকেন, তাহলে এর মানে হল যে সমস্ত ব্যবহারকারীরা তাদের অনুরোধ পূরণ করতে এসেছেন তারা অপেক্ষা করবেন।

আপনি যদি লিনাক্সের দৃষ্টিকোণ থেকে দেখেন, আপনি যদি ভাল হার্ডওয়্যার নেন, সঠিকভাবে কনফিগার করেন, PostgreSQL সাধারণভাবে কনফিগার করেন যাতে এটি এই চেকপয়েন্টগুলিকে কম ঘন ঘন করে তোলে, একে অপরের মধ্যে সময়ের সাথে ছড়িয়ে দেয়, তাহলে আপনি ডিফল্ট ডেবিয়ান প্যারামিটারে চলে যান। বেশিরভাগ লিনাক্স ডিস্ট্রিবিউশনের জন্য, এটি হল ছবি: vm.dirty_ratio=20, vm.dirty_background_ratio=10।

এর মানে কী? কার্নেল 2.6 থেকে একটি ফ্লাশিং ডেমন আবির্ভূত হয়েছে৷ Pdglush, কে কোনটি ব্যবহার করছে তার উপর নির্ভর করে, যেটি কার্নেল বাফার থেকে নোংরা পৃষ্ঠাগুলিকে ব্যাকগ্রাউন্ডে বাতিল করার কাজে নিযুক্ত রয়েছে এবং যখন নোংরা পৃষ্ঠাগুলি বাতিল করার প্রয়োজন হয় তখন বাতিল করা হয়, যাই হোক না কেন, যখন ব্যাকগ্রাউন্ড বাতিল করা সাহায্য করে না।

ব্যাকগ্রাউন্ড কখন আসে? যখন সার্ভারে উপলব্ধ মোট RAM এর 10% কার্নেল বাফারে নোংরা পৃষ্ঠা দ্বারা দখল করা হয়, তখন পটভূমিতে একটি বিশেষ রাইট-অফ ফাংশন বলা হয়। কেন এটা ব্যাকগ্রাউন্ড? একটি পরামিতি হিসাবে, এটি কত পৃষ্ঠাগুলি লিখতে হবে তা বিবেচনা করে। এবং, ধরা যাক, তিনি N পৃষ্ঠাগুলি লিখে ফেলেন। আর কিছুক্ষণের জন্য এই জিনিস ঘুমিয়ে পড়ে। এবং তারপর সে আবার আসে এবং আরও কিছু পৃষ্ঠা কপি করে।

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

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

কৌশল কি? কৌশলটি হল যে আধুনিক বিশ্বে এই প্যারামিটারগুলি মেশিনে থাকা মোট RAM এর 20 এবং 10%, এগুলি আপনার যে কোনও ডিস্ক সিস্টেমের থ্রুপুট পরিপ্রেক্ষিতে একেবারে দানবীয়।

কল্পনা করুন আপনার 128 GB RAM আছে। 12,8 GB আপনার ডিস্ক সিস্টেমে আসে। এবং আপনার সেখানে কোন ক্যাশে থাকুক না কেন, আপনার সেখানে যে অ্যারেই থাকুক না কেন, সেগুলি বেশিক্ষণ স্থায়ী হবে না।

অতএব, আমরা সুপারিশ করি যে আপনি অবিলম্বে আপনার RAID কন্ট্রোলারের ক্ষমতার উপর ভিত্তি করে এই সংখ্যাগুলি সামঞ্জস্য করুন৷ আমি অবিলম্বে 512 এমবি ক্যাশে আছে এমন একটি নিয়ামকের জন্য এখানে একটি সুপারিশ করেছি।

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

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

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

জীবনকে আর কি কঠিন করে তুলতে পারে? এই দুটি পরামিতি. তারা তুলনামূলকভাবে নতুন। ডিফল্টরূপে, তারা বিভিন্ন অ্যাপ্লিকেশন অন্তর্ভুক্ত করা যেতে পারে. এবং যদি তারা ভুলভাবে চালু করা হয় তবে তারা জীবনকে কঠিন করে তুলতে পারে।

দুটি তুলনামূলকভাবে নতুন জিনিস আছে। তারা ইতিমধ্যে তৃতীয় কোরে হাজির হয়েছে। এটি ন্যানোসেকেন্ডে sched_migration_cost এবং sched_autogroup_enabled, যা ডিফল্টভাবে একটি।

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

এই সময়সূচী জন্য মানে কি হবে? এটি বিবেচনা করা হবে যে এই সময়ের মধ্যে প্রক্রিয়াটি এখনও গরম। অর্থাৎ, আপনার যদি একটি দীর্ঘ-চলমান লেনদেন থাকে যা দীর্ঘদিন ধরে কিছু করে চলেছে, তবে শিডিউলকারী এটি বুঝতে পারবে। তিনি অনুমান করবেন যে এই সময়সীমাটি না হওয়া পর্যন্ত, এই প্রক্রিয়াটি কোথাও স্থানান্তরিত করার প্রয়োজন নেই। যদি একই সময়ে প্রক্রিয়াটি কিছু করে, তবে এটি কোথাও স্থানান্তরিত হবে না, এটি নিঃশব্দে এটির জন্য বরাদ্দ করা CPU-তে কাজ করবে। এবং ফলাফল চমৎকার।

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

আমার সহকর্মী অ্যালেক্সি লেসোভস্কি একটি সাধারণ পিজিবেঞ্চের মাধ্যমে পরীক্ষা করেছিলেন, যেখানে তিনি একটি ক্রম অনুসারে মাইগ্রেশন_কস্ট বাড়িয়েছিলেন এবং অটোগ্রুপ বন্ধ করে দিয়েছিলেন। খারাপ হার্ডওয়্যারের পার্থক্য ছিল প্রায় 10%. পোস্টগ্রেস মেলিং লিস্টে একটি আলোচনা রয়েছে যেখানে লোকেরা অনুসন্ধানের গতিতে একই রকম পরিবর্তনের ফলাফল দেয় প্রভাবিত 50%. এরকম অনেক গল্প আছে।

এবং পরিশেষে, শক্তি সঞ্চয় নীতি সম্পর্কে। ভালো কথা হলো লিনাক্স এখন ল্যাপটপে ব্যবহার করা যায়। এবং এটি অনুমিতভাবে ব্যাটারি ভালভাবে ব্যবহার করবে। কিন্তু হঠাৎ দেখা যাচ্ছে যে এটি সার্ভারেও ঘটতে পারে।

অধিকন্তু, আপনি যদি কিছু হোস্টার থেকে সার্ভার ভাড়া নেন, তাহলে "ভাল" হোস্টরা আপনার ভাল পারফরম্যান্সের কথা চিন্তা করে না। তাদের কাজ হল তাদের লোহা যতটা সম্ভব দক্ষতার সাথে ব্যবহার করা হয় তা নিশ্চিত করা। অতএব, ডিফল্টরূপে তারা অপারেটিং সিস্টেমে ল্যাপটপ পাওয়ার সেভিং মোড সক্ষম করতে পারে।

আপনি যদি ভারী লোডের মধ্যে একটি ডাটাবেস সহ সার্ভারে এই জিনিসটি ব্যবহার করেন, তাহলে আপনার পছন্দ হল acpi_cpufreq + permormance। এমনকি অনডিমান্ড নিয়েও সমস্যা হবে।

Intel_pstate একটি সামান্য ভিন্ন ড্রাইভার। এবং এখন এটিকে অগ্রাধিকার দেওয়া হয়, কারণ এটি পরে এবং আরও ভাল কাজ করে।

এবং, সেই অনুযায়ী, গভর্নর শুধুমাত্র কর্মক্ষমতা. ওন্ডেমান্ড, পাওয়ার সেভ এবং অন্য সবকিছু আপনার সম্পর্কে নয়।

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

এই আইটেমগুলি ডিফল্টরূপে অন্তর্ভুক্ত হতে পারে. তারা ডিফল্টরূপে এটি চালু করেছে কিনা তা দেখতে সাবধানে দেখুন। এটি একটি সত্যিই বড় সমস্যা হতে পারে.

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

প্রশ্ন:

ধন্যবাদ! উদাহরণস্বরূপ, যদি একটি কোম্পানি অর্থ সঞ্চয় করতে চায় এবং একটি সার্ভারে ডাটাবেস এবং অ্যাপ্লিকেশন লজিক রাখতে চায়, অথবা যদি কোম্পানিটি মাইক্রোসার্ভিস আর্কিটেকচারের ফ্যাশনেবল প্রবণতা অনুসরণ করে, যেখানে PostgreSQL একটি পাত্রে চলে। কৌশল কি? Sysctl বিশ্বব্যাপী সমগ্র কার্নেলকে প্রভাবিত করবে। আমি sysctls একরকম ভার্চুয়ালাইজড হওয়ার কথা শুনিনি যাতে তারা একটি কন্টেইনারে আলাদাভাবে কাজ করে। শুধুমাত্র একটি cgroup আছে এবং সেখানে শুধুমাত্র নিয়ন্ত্রণের অংশ আছে। আপনি কিভাবে এই সঙ্গে বসবাস করতে পারেন? অথবা আপনি যদি কর্মক্ষমতা চান, তাহলে একটি পৃথক হার্ডওয়্যার সার্ভারে PostgreSQL চালান এবং এটি টিউন করবেন?

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

সমস্যাটা কি? যদি এটি একটি ভার্চুয়াল মেশিন হয়, তবে সম্ভবত আপনার অনেক সমস্যা হবে, উদাহরণস্বরূপ, বেশিরভাগ ভার্চুয়াল মেশিনে ডিস্কের লেটেন্সি বেশ বেমানান। এমনকি যদি ডিস্ক থ্রুপুট ভাল হয়, তবে একটি ব্যর্থ I/O লেনদেন যা চেকপয়েন্টের সময় বা WAL-তে লেখার সময় ঘটেছিল এমন গড় থ্রুপুটকে ব্যাপকভাবে প্রভাবিত করে না, তাহলে ডাটাবেস এটি থেকে ব্যাপকভাবে ক্ষতিগ্রস্ত হবে। এবং আপনি এই সমস্যাগুলি চালানোর আগে এটি লক্ষ্য করবেন।

আপনার যদি একই সার্ভারে NGINX থাকে তবে আপনারও একই সমস্যা হবে। তিনি ভাগ করা স্মৃতির জন্য লড়াই করবেন। এবং আপনি এখানে বর্ণিত সমস্যাগুলি পাবেন না।

কিন্তু অন্যদিকে, এই পরামিতিগুলির মধ্যে কিছু এখনও আপনার জন্য প্রাসঙ্গিক হবে। উদাহরণস্বরূপ, sysctl দিয়ে dirty_ratio সেট করুন যাতে এটি এতটা পাগল না হয় - যে কোনও ক্ষেত্রে, এটি সাহায্য করবে। একটি উপায় বা অন্য, আপনি ডিস্ক সঙ্গে মিথস্ক্রিয়া হবে. এবং এটি ভুল প্যাটার্ন অনুযায়ী হবে। এটি সাধারণত আমি দেখানো পরামিতিগুলির জন্য একটি ডিফল্ট। এবং যে কোনও ক্ষেত্রে তাদের পরিবর্তন করা ভাল।

কিন্তু NUMA এর সাথে সমস্যা হতে পারে। VmWare, উদাহরণস্বরূপ, ঠিক বিপরীত সেটিংস সহ NUMA এর সাথে ভাল কাজ করে। এবং এখানে আপনাকে বেছে নিতে হবে - একটি লোহা সার্ভার বা একটি অ-লোহা সার্ভার।

আমার Amazon AWS সম্পর্কিত একটি প্রশ্ন আছে। তাদের পূর্বে কনফিগার করা ছবি আছে। তাদের মধ্যে একটিকে বলা হয় অ্যামাজন আরডিএস। তাদের অপারেটিং সিস্টেমের জন্য কোন কাস্টম সেটিংস আছে?

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

বিশাল TLB এর তুলনায় স্বচ্ছ বিশাল পৃষ্ঠাগুলির কোন প্রভাব নেই কেন?

দিও না. এটি অনেক উপায়ে ব্যাখ্যা করা যেতে পারে। কিন্তু বাস্তবে তারা তা দেয় না। PostgreSQL এর ইতিহাস কি? স্টার্টআপে, এটি শেয়ার করা মেমরির একটি বড় অংশ বরাদ্দ করে। তারা স্বচ্ছ কিনা তা সম্পূর্ণ অপ্রাসঙ্গিক। তারা যে শুরুতে দাঁড়িয়েছে তা সবকিছু ব্যাখ্যা করে। এবং যদি প্রচুর মেমরি থাকে এবং আপনাকে শেয়ার্ড_মেমরি সেগমেন্টটি পুনর্নির্মাণ করতে হবে, তাহলে স্বচ্ছ বিশাল পৃষ্ঠাগুলি প্রাসঙ্গিক হবে। PostgreSQL-এ, এটি কেবল শুরুতে একটি বিশাল অংশে বরাদ্দ করা হয়েছে এবং এটিই, এবং তারপরে সেখানে বিশেষ কিছু ঘটে না। আপনি, অবশ্যই, এটি ব্যবহার করতে পারেন, কিন্তু শেয়ার্ড_মেমোরির একটি দুর্নীতি পাওয়ার সম্ভাবনা আছে যখন এটি কিছু পুনরায় বরাদ্দ করে। PostgreSQL এই সম্পর্কে জানে না।

উত্স: www.habr.com