PostgreSQL টিউন করার জন্য একটি শিল্প পদ্ধতি: ডাটাবেস নিয়ে পরীক্ষা।" নিকোলাই সামোখভালভ

আমি আপনাকে নিকোলাই সামোখভালভের রিপোর্টের প্রতিলিপি পড়ার পরামর্শ দিচ্ছি "পোস্টগ্রেএসকিউএল টিউনিং করার জন্য শিল্প পদ্ধতি: ডেটাবেসের উপর পরীক্ষাগুলি"

শেয়ার্ড_বাফার = 25% - এটা কি অনেক বা সামান্য? নাকি ঠিক? আপনি কীভাবে জানবেন যে এটি - বরং পুরানো - আপনার নির্দিষ্ট ক্ষেত্রে সুপারিশ উপযুক্ত?

এটি postgresql.conf প্যারামিটার নির্বাচন করার সমস্যাটি "একজন প্রাপ্তবয়স্কের মতো" করার সময় এসেছে। অন্ধ "অটো টিউনার" বা নিবন্ধ এবং ব্লগের পুরানো পরামর্শের সাহায্যে নয়, তবে এর উপর ভিত্তি করে:

1. ডাটাবেসগুলিতে কঠোরভাবে যাচাই করা পরীক্ষাগুলি, স্বয়ংক্রিয়ভাবে সম্পাদিত, প্রচুর পরিমাণে এবং যতটা সম্ভব "লড়াই" করার শর্তে,
2. ডিবিএমএস এবং ওএস এর বৈশিষ্ট্যগুলির গভীর উপলব্ধি।

ন্যান্সি সিএলআই ব্যবহার করে (https://gitlab.com/postgres.ai/nancy), আমরা একটি নির্দিষ্ট উদাহরণ দেখব - কুখ্যাত শেয়ার্ড_বাফারগুলি - বিভিন্ন পরিস্থিতিতে, বিভিন্ন প্রকল্পে এবং কীভাবে আমাদের অবকাঠামো, ডাটাবেস এবং লোডের জন্য সর্বোত্তম সেটিং বেছে নেওয়া যায় তা বের করার চেষ্টা করব।

আমরা ডাটাবেস নিয়ে পরীক্ষা-নিরীক্ষার কথা বলব। এটি একটি গল্প যা ছয় মাস ধরে চলে।

অল্প কিছু আমার সম্পর্কে. পোস্টগ্রেসের সাথে 14 বছরেরও বেশি সময় ধরে অভিজ্ঞতা। বেশ কয়েকটি সামাজিক নেটওয়ার্কিং কোম্পানি প্রতিষ্ঠা করেছে। Postgres ছিল এবং সর্বত্র ব্যবহৃত হয়.

এছাড়াও মিটআপে RuPostgres গ্রুপ, বিশ্বের ২য় স্থান। আমরা ধীরে ধীরে 2 লোকের কাছে যাচ্ছি। RuPostgres.org.

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

এবং গত কয়েক বছরে, আমি এখান থেকে আমার পোস্টগ্রেস পরামর্শ অনুশীলন 11টি সময় অঞ্চল পুনরায় শুরু করেছি।

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

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

এই প্রতিবেদনটি অন্তর্ভুক্ত করবে না:

• "সিলভার বুলেট" এবং বিবৃতি যেমন - 8 GB বা 25% শেয়ার্ড_বাফার সেট করুন এবং আপনি ঠিক হয়ে যাবেন। ভাগ করা_বাফার সম্পর্কে অনেক কিছু থাকবে না।
• হার্ডকোর "ইননার্ডস"।

আর কি হবে?

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

কিভাবে এই সব উন্নয়নশীল?

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

এখন এটি এই মত সেট আপ করা হয়েছে. আমরা পর্যবেক্ষণের দিকে তাকাই, আমরা কিছু দেখি, কিন্তু আমরা কিছু বিবরণ মিস করছি। আমরা আরও সাবধানে খনন করতে শুরু করি, সাধারণত আমাদের হাত দিয়ে, এবং বুঝতে পারি এটির সাথে এক বা অন্য উপায়ে কী করতে হবে।

এবং দুটি পন্থা আছে. Pg_stat_statements হল ধীরগতির প্রশ্ন শনাক্ত করার জন্য ডিফল্ট সমাধান। এবং pgBadger ব্যবহার করে পোস্টগ্রেস লগের বিশ্লেষণ।

প্রতিটি পদ্ধতির গুরুতর ত্রুটি রয়েছে। প্রথম পদ্ধতিতে, আমরা সমস্ত পরামিতি ফেলে দিয়েছি। এবং যদি আমরা গ্রুপগুলি দেখি SELECT * FROM টেবিল যেখানে কলাম "?" এর সমান। বা পোস্টগ্রেস 10 থেকে "$"। আমরা জানি না এটি একটি সূচক স্ক্যান নাকি একটি seq স্ক্যান। এটি পরামিতি উপর অনেক নির্ভর করে। আপনি যদি সেখানে খুব কমই সম্মুখীন হওয়া মান প্রতিস্থাপন করেন, তাহলে এটি একটি সূচক স্ক্যান হবে। যদি আপনি একটি মান প্রতিস্থাপন করেন যা সেখানে টেবিলের 90% দখল করে, seq স্ক্যানটি সুস্পষ্ট হবে, কারণ Postgres পরিসংখ্যান জানে। এবং এটি pg_stat_statements এর একটি বড় অপূর্ণতা, যদিও কিছু কাজ চলছে।

লগ বিশ্লেষণের সবচেয়ে বড় অসুবিধা হল যে আপনি একটি নিয়ম হিসাবে "log_min_duration_statement = 0" বহন করতে পারবেন না। এবং আমরা এই বিষয়েও কথা বলব। সেই অনুযায়ী, আপনি পুরো ছবি দেখতে পাবেন না। এবং কিছু ক্যোয়ারী, যা খুব দ্রুত, প্রচুর পরিমাণে সম্পদ ব্যবহার করতে পারে, কিন্তু আপনি এটি দেখতে পাবেন না কারণ এটি আপনার থ্রেশহোল্ডের নীচে।

কিভাবে DBAs তাদের খুঁজে পাওয়া সমস্যা সমাধান করে?

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

• টিউন কনফিগারেশন।
• সূচী সেট অপ্টিমাইজ করুন.
• এসকিউএল ক্যোয়ারী নিজেই পরিবর্তন করুন (এটি সবচেয়ে কঠিন উপায়)।
• ক্ষমতা যোগ করুন (বেশিরভাগ ক্ষেত্রে সবচেয়ে সহজ উপায়)।

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

আর আমি এই কালো জাদুর বিরুদ্ধে যোদ্ধা। আমি সবকিছু করতে চাই যাতে প্রযুক্তি থাকে এবং এই সবের মধ্যে কোনও অন্তর্দৃষ্টি নেই।

জীবনের উদাহরণ

আমি আমার নিজের সহ অন্তত দুটি প্রকল্পে এটি পর্যবেক্ষণ করেছি। আরেকটি ব্লগ পোস্ট আমাদের বলে যে ডিফল্ট_স্ট্যাটিস্টিক_টার্গেটের জন্য 1 এর মান ভাল। ঠিক আছে, এর উৎপাদন চেষ্টা করা যাক.

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

এবং এর জন্য আমাদের একটি পরীক্ষা তৈরি করতে হবে। এটি চারটি অংশ নিয়ে গঠিত।

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

আমরা একটি পরীক্ষা শুরু করছি। এখানে pg_stat_statements আছে। বাম দিকে যা ঘটেছে. ডানদিকে - কি হয়েছে.

বামদিকে ডিফল্ট_পরিসংখ্যান_টার্গেট = 100, ডানদিকে = 1। আমরা দেখতে পাচ্ছি যে এটি আমাদের সাহায্য করেছে। সামগ্রিকভাবে, সবকিছু 000% দ্বারা ভাল হয়েছে।

কিন্তু যদি আমরা নিচে স্ক্রোল করি, তাহলে pgBadger বা pg_stat_statements থেকে অনুরোধের গ্রুপ থাকবে। দুটি বিকল্প আছে। আমরা দেখব যে কিছু অনুরোধ 88% কমে গেছে। এবং এখানে প্রকৌশল পদ্ধতি আসে। আমরা আরও ভিতরে খনন করতে পারি কারণ আমরা ভাবছি কেন এটি ডুবে গেছে। পরিসংখ্যান দিয়ে কী ঘটেছে তা বুঝতে হবে। পরিসংখ্যানে বেশি বালতি কেন খারাপ ফলাফলের দিকে নিয়ে যায়।

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

অন্যান্য এলাকা থেকে উদাহরণ একটি দম্পতি. বহু বছর ধরে পরীক্ষায় সিআই পরীক্ষা রয়েছে। এবং তার সঠিক মনের কোনও প্রকল্প স্বয়ংক্রিয় পরীক্ষা ছাড়া বাঁচবে না।

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

আমরা অন্যান্য শিল্পের পর্যবেক্ষণ থেকে সিদ্ধান্ত নিতে পারি।

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

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

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

ন্যান্সি সিএলআই - "ডাটাবেস পরীক্ষাগার" এর ভিত্তি

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

ন্যান্সি - এটি ওপেন সোর্সে, গিটল্যাবে। আপনি এটা বলতে পারেন, আপনি এটি চেষ্টা করতে পারেন. আমি স্লাইডে একটি লিঙ্ক প্রদান করেছি। আপনি এটিতে ক্লিক করতে পারেন এবং এটি সেখানে থাকবে সাহায্য সর্বথা.

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

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

এবং EC2 ইন্সট্যান্সে, দাগগুলিতে অ্যামাজনে দূরবর্তীভাবে চালানোর সুযোগও রয়েছে। এবং এটি একটি খুব দুর্দান্ত সুযোগ। উদাহরণস্বরূপ, গতকাল আমরা i500 দৃষ্টান্তে 3 টিরও বেশি পরীক্ষা চালিয়েছি, সবচেয়ে ছোট থেকে শুরু করে এবং i3-16-xlarge দিয়ে শেষ হয়েছে৷ এবং 500 পরীক্ষার জন্য আমাদের $64 খরচ হয়। প্রতিটি 15 মিনিট স্থায়ী হয়েছিল। যে কারণে যে দাগ সেখানে ব্যবহার করা হয়, এটা খুব সস্তা - একটি 70% ডিসকাউন্ট, Amazon এর প্রতি সেকেন্ড বিলিং. আপনি অনেক কিছু করতে পারেন. আপনি বাস্তব গবেষণা করতে পারেন.

এবং Postgres এর তিনটি প্রধান সংস্করণ সমর্থিত। কিছু পুরানো এবং নতুন 12 তম সংস্করণটিও শেষ করা এতটা কঠিন নয়।

আমরা একটি বস্তুকে তিনটি উপায়ে সংজ্ঞায়িত করতে পারি। এই:

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

এবং লোড:

• আমরা একটি SQL থ্রেডে লোড নির্বাহ করতে পারি। এটি সবচেয়ে আদিম উপায়।
• এবং আমরা লোড অনুকরণ করতে পারেন. এবং আমরা এটিকে প্রথমে নিম্নলিখিত উপায়ে অনুকরণ করতে পারি। আমাদের সমস্ত লগ সংগ্রহ করতে হবে। এবং এটা বেদনাদায়ক। আমি কেন দেখাব. এবং pgreplay ব্যবহার করে আমরা খেলি, যা ন্যান্সিতে নির্মিত।
• অথবা অন্য বিকল্প। তথাকথিত নৈপুণ্য লোড, যা আমরা একটি নির্দিষ্ট পরিমাণ প্রচেষ্টার সাথে করি। যুদ্ধ ব্যবস্থায় আমাদের বর্তমান লোড বিশ্লেষণ করে, আমরা অনুরোধের শীর্ষ গ্রুপগুলি বের করি। এবং pgbench ব্যবহার করে আমরা পরীক্ষাগারে এই লোডটি অনুকরণ করতে পারি।

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

• একটি ডিরেক্টরি পিজি স্ন্যাপশট থেকে শুরু করে বিভিন্ন ফাইলের গুচ্ছ নিয়ে আসেরাষ্ট্র*** এবং সবচেয়ে আকর্ষণীয় জিনিস হল pg_stat_statements, pg_stat_kcacke। এই দুটি এক্সটেনশন যা অনুরোধ বিশ্লেষণ করে। এবং pg_stat_bgwriter শুধুমাত্র pgwriter পরিসংখ্যানই ধারণ করে না, বরং চেকপয়েন্টে এবং কীভাবে ব্যাকএন্ডগুলি নিজেরাই নোংরা বাফারগুলিকে স্থানচ্যুত করে। এবং এটা সব দেখতে আকর্ষণীয়. উদাহরণস্বরূপ, যখন আমরা শেয়ার্ড_বাফার সেট আপ করি, তখন সবাই কতটা প্রতিস্থাপিত হয় তা দেখা খুবই আকর্ষণীয়।
• পোস্টগ্রেস লগও আসছে। দুটি লগ - একটি প্রস্তুতি লগ এবং একটি লোড প্লেব্যাক লগ।
• একটি অপেক্ষাকৃত নতুন বৈশিষ্ট্য হল FlameGraphs।
• এছাড়াও, আপনি যদি লোড চালানোর জন্য pgreplay বা pgbench বিকল্পগুলি ব্যবহার করেন, তাহলে তাদের আউটপুট নেটিভ হবে। এবং আপনি লেটেন্সি এবং টিপিএস দেখতে পাবেন। তারা কীভাবে দেখেছে তা বোঝা সম্ভব হবে।
• পদ্ধতিগত তথ্য.
• বেসিক CPU এবং IO চেক। এটি অ্যামাজনে EC2 উদাহরণের জন্য বেশি, যখন আপনি একটি থ্রেডে 100টি অভিন্ন দৃষ্টান্ত চালু করতে চান এবং সেখানে 100টি ভিন্ন রান চালাতে চান, তখন আপনার 10টি পরীক্ষা-নিরীক্ষা হবে। এবং আপনাকে নিশ্চিত করতে হবে যে আপনি এমন কোনও ত্রুটিপূর্ণ উদাহরণের মুখোমুখি না হন যা ইতিমধ্যেই কারও দ্বারা নিপীড়িত হচ্ছে। অন্যরা হার্ডওয়্যারের এই অংশে সক্রিয় এবং আপনার কাছে সামান্য সম্পদ অবশিষ্ট আছে। এই ধরনের ফলাফল বর্জন করা ভাল। এবং আলেক্সি কপিটোভের সিসবেঞ্চের সাহায্যে, আমরা বেশ কয়েকটি সংক্ষিপ্ত চেক করি যা আসবে এবং অন্যদের সাথে তুলনা করা যেতে পারে, অর্থাৎ আপনি বুঝতে পারবেন কিভাবে CPU আচরণ করে এবং IO কীভাবে আচরণ করে।

বিভিন্ন কোম্পানির উদাহরণের ভিত্তিতে প্রযুক্তিগত অসুবিধা কি?

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

সময়কাল এবং টাইমস্ট্যাম্প নিয়ে কিছু জটিলতা রয়েছে। আমরা এই পুরো রান্নাঘর খালি করব। প্রধান প্রশ্ন আপনি এটা সামর্থ্য কি না?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

সমস্যা হল এটি উপলব্ধ নাও হতে পারে। প্রথমত, আপনাকে অবশ্যই বুঝতে হবে যে লগটিতে কী স্ট্রিম লেখা হবে। আপনার যদি pg_stat_statements থাকে, আপনি প্রতি সেকেন্ডে আনুমানিক কত বাইট লেখা হবে তা বোঝার জন্য আপনি এই ক্যোয়ারীটি ব্যবহার করতে পারেন (লিঙ্কটি স্লাইডে উপলব্ধ হবে)।

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

আমরা দেখতে পাচ্ছি যে প্রতি সেকেন্ডে 802 বার এই অনুরোধটি কার্যকর করা হয়েছে। এবং আমরা দেখছি যে বাইট_পার সেকেন্ড - 300 kB/s লেখা হবে প্লাস বা মাইনাস। এবং, একটি নিয়ম হিসাবে, আমরা যেমন একটি প্রবাহ সামর্থ্য করতে পারেন।

কিন্তু! সত্য যে বিভিন্ন লগিং সিস্টেম আছে. এবং মানুষের ডিফল্ট সাধারণত "syslog" হয়।

এবং যদি আপনার syslog থাকে, তাহলে আপনার কাছে এরকম একটি ছবি থাকতে পারে। আমরা pgbench নেব, ক্যোয়ারী লগিং সক্ষম করব এবং দেখুন কি হয়।

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

এবং CentOS 7-এ, যেটিতে জার্নাল্ডও অংশগ্রহণ করে, সহজ অনুসন্ধানের জন্য লগগুলিকে একটি বাইনারি বিন্যাসে পরিণত করে, ইত্যাদি, তখন এটি একটি দুঃস্বপ্ন, আমরা TPS-এ 44 বার ড্রপ করি।

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

• IOPS মূল্যায়ন করুন এবং প্রবাহ লিখুন।
• আপনার লগিং সিস্টেম পরীক্ষা করুন.
• প্রক্ষিপ্ত লোড অত্যধিক বড় হলে, নমুনা বিবেচনা করুন.

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

এটা অনেকটা "-f" বোঝে। এবং আপনি "@" এর সাহায্যে শেষ পর্যন্ত বলতে পারেন প্রতিটি ফাইলে কী কী ভাগ থাকা উচিত। অর্থাৎ, আমরা বলতে পারি যে 10% ক্ষেত্রে এটি করুন এবং 20% ক্ষেত্রে এটি করুন। এবং এটি আমাদের উৎপাদনে যা দেখি তার কাছাকাছি নিয়ে আসবে।

আমরা কীভাবে বুঝব যে আমাদের উত্পাদনে কী আছে? কি ভাগ এবং কিভাবে? এটি একটি সরাইয়া একটি বিট. আমাদের আরও একটি পণ্য আছে পোস্টগ্রেস-চেকআপ. এছাড়াও ওপেন সোর্সে একটি বেস। এবং আমরা এখন সক্রিয়ভাবে এটি বিকাশ করছি।

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

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

সমস্যা হল যখন আপনি একটি বড় কোম্পানিকে সাহায্য করেন, তারা দ্রুত কিছু বাস্তবায়ন করতে পারে না। তারা দ্রুত ওকেমিটার কিনতে পারে না। হয়তো তারা ছয় মাসের মধ্যে এটি কিনবে। তারা দ্রুত কিছু প্যাকেজ সরবরাহ করতে পারে না।

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

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

এবং আমরা যেমন একটি টুল আছে. এটি প্রায় তিন মাস আগে সক্রিয়ভাবে উত্থিত হতে শুরু করে। তিনি এখনও তরুণ, কিন্তু সেখানে অনেক আছে.

প্রশ্নের সবচেয়ে "প্রভাবশালী" গোষ্ঠী সংগ্রহ করা - পোস্টগ্রেস-চেকআপে K003 রিপোর্ট করুন

এবং রিপোর্টের একটি গ্রুপ আছে. এখন পর্যন্ত তিনটি রিপোর্ট. এবং যেমন একটি রিপোর্ট K003 আছে. pg_stat_statements থেকে শীর্ষ আছে, মোট_সময় অনুসারে সাজানো।

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

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

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

এই টেবিলে কি ঘটেছে? আমরা দুটি স্ন্যাপশট নিলাম। Postgres_checkup আপনাকে প্রতিটি মেট্রিকের জন্য একটি ডেল্টা দেবে: মোট-সময়, কল, সারি, শেয়ার্ড_ব্লক্স_রিড, ইত্যাদি। তাই, ডেল্টা গণনা করা হয়েছে। pg_stat_statements এর সাথে বড় সমস্যা হল যে এটি কখন রিসেট করা হয়েছিল তা মনে থাকে না। যদি pg_stat_database মনে থাকে, তাহলে pg_stat_statements মনে থাকে না। আপনি দেখতে পাচ্ছেন যে 1 সংখ্যা আছে, কিন্তু আমরা জানি না আমরা কোথা থেকে গণনা করেছি।

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

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

এটা আমাদের জানার বিষয়, আমি কোথাও এরকম কিছু দেখিনি। দয়া করে নোট করুন - এটি একটি খুব সাধারণ জিনিস - সেকেন্ড প্রতি সেকেন্ড। কখনও কখনও, যখন আপনার সিপিইউ 100% হয়, তখন প্রতি সেকেন্ডে আধা ঘন্টা, অর্থাৎ, আপনি এই অনুরোধগুলি করতে আধা ঘন্টা ব্যয় করেন।

এরপর আমরা প্রতি সেকেন্ডে সারি দেখতে পাই। আমরা জানি প্রতি সেকেন্ডে কত সারি এটি ফিরে এসেছে।

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

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

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

এবং প্রতিটি লাইনের চতুর্থ সাবস্ট্রিং হল মোট কত শতাংশ। আমরা কল আছে. ধরা যাক 1 এবং আমরা বুঝতে পারি এই গ্রুপটি কী অবদান রাখে। আমরা দেখতে পাই যে এই ক্ষেত্রে প্রথম গ্রুপটি 000% এর কম অবদান রাখে। অর্থাৎ এটি এতই ধীর যে আমরা সামগ্রিক ছবিতে দেখতে পাই না। এবং দ্বিতীয় গ্রুপ কলে 000%। অর্থাৎ, সমস্ত কলের 0,01% দ্বিতীয় গ্রুপ।

মোট_সময়ও আকর্ষণীয়। আমরা অনুরোধের প্রথম গ্রুপে আমাদের মোট কাজের সময়ের 14% ব্যয় করেছি। এবং দ্বিতীয় জন্য - 11%, ইত্যাদি।

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

তারপরে আমরা আমাদের প্রসঙ্গে ফিরে আসি। আমাদের কাজের চাপ তৈরি করতে হবে। আমরা এটিকে উপরে থেকে নীচে নিয়ে যাই এবং যতক্ষণ না আমরা 80% বা 90% পৌঁছাই। সাধারণত এই 10-20 গ্রুপ হয়। এবং আমরা পিজিবেঞ্চের জন্য ফাইল তৈরি করি। আমরা সেখানে র্যান্ডম ব্যবহার করি। কখনও কখনও এটি, দুর্ভাগ্যবশত, কাজ করে না। এবং Postgres 12-এ এই পদ্ধতি ব্যবহার করার আরও সুযোগ থাকবে।

এবং তারপরে আমরা এইভাবে মোট_সময়ে 80-90% লাভ করি। “@” এর পরে আমার কী রাখা উচিত? আমরা কলগুলি দেখি, কতটা আগ্রহ আছে তা দেখি এবং বুঝতে পারি যে আমাদের এখানে এত আগ্রহ রয়েছে। এই শতাংশ থেকে আমরা বুঝতে পারি কিভাবে প্রতিটি ফাইলের ভারসাম্য বজায় রাখা যায়। এর পরে আমরা পিজিবেঞ্চ ব্যবহার করি এবং কাজে যাই।

আমাদের কাছে K001 এবং K002ও রয়েছে।

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

K002 কে আমি কোয়েরি ক্লাস বলি, যেমন SELECT, INSERT, UPDATE, DELETE। এবং আলাদাভাবে আপডেটের জন্য নির্বাচন করুন, কারণ এটি একটি লক।

এবং এখানে আমরা উপসংহারে আসতে পারি যে SELECT হল সাধারণ পাঠক - সমস্ত কলের 82%, কিন্তু একই সময়ে - 74% মোট_সময়ে। যে, তারা অনেক বলা হয়, কিন্তু কম সম্পদ খরচ।

এবং আমরা প্রশ্নে ফিরে আসি: "আমরা কীভাবে সঠিক ভাগ করা_বাফারগুলি বেছে নিতে পারি?" আমি লক্ষ্য করি যে বেশিরভাগ বেঞ্চমার্ক ধারণার উপর ভিত্তি করে - আসুন দেখি থ্রুপুট কী হবে, অর্থাৎ থ্রুপুট কী হবে। এটি সাধারণত TPS বা QPS এ পরিমাপ করা হয়।

এবং আমরা টিউনিং প্যারামিটার ব্যবহার করে গাড়ি থেকে প্রতি সেকেন্ডে যতটা সম্ভব লেনদেন করার চেষ্টা করি। এখানে নির্বাচনের জন্য প্রতি সেকেন্ডে ঠিক 311।

কিন্তু কেউই কর্মস্থলে গাড়ি চালিয়ে ফুল স্পিডে বাড়ি ফেরে না। এটা বোকামি. ডাটাবেস সঙ্গে একই. আমাদের পূর্ণ গতিতে গাড়ি চালাতে হবে না, এবং কেউ করেও না। কেউ উৎপাদনে থাকে না, যার 100% CPU আছে। যদিও, হয়তো কেউ বেঁচে থাকে, তবে এটি ভাল নয়।

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

এবং অবশেষে, সুপারিশ:

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

প্রশ্ন

অনেক ধন্যবাদ! একটি খুব আকর্ষণীয় জিনিস.

দুই টুকরা.

হ্যাঁ, দুই টুকরা। শুধু আমি ঠিক বুঝতে পারিনি। যখন ন্যান্সি এবং আমি কাজ করি, আমরা কি শুধুমাত্র একটি প্যারামিটার বা পুরো গোষ্ঠীকে পরিবর্তন করতে পারি?

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

হ্যাঁ. কেন জিজ্ঞেস করলাম? কারণ আপনার কাছে শুধুমাত্র একটি প্যারামিটার থাকলে পরীক্ষা-নিরীক্ষা করা কঠিন। আপনি এটি শক্ত করুন, দেখুন এটি কীভাবে কাজ করে। আমি তাকে বের করে দিলাম। তারপর আপনি পরেরটি শুরু করুন।

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

এবং আরো একটি প্রশ্ন আছে. প্রকল্পটি তরুণ এবং উন্নয়নশীল। ডকুমেন্টেশন ইতিমধ্যে প্রস্তুত, একটি বিস্তারিত বিবরণ আছে?

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

একবার আমরা ল্যাবরেটরি তৈরি করলে, হয়তো মতামত পাওয়া যাবে। দেখা যাক. ধন্যবাদ!

হ্যালো! প্রতিবেদনের জন্য ধন্যবাদ! দেখলাম আমাজন সাপোর্ট আছে। জিএসপি সমর্থন করার কোন পরিকল্পনা আছে কি?

ভাল প্রশ্ন. আমরা এটা করতে শুরু করেছি। এবং আমরা আপাতত এটি হিমায়িত করেছি কারণ আমরা অর্থ সঞ্চয় করতে চাই। অর্থাৎ, লোকালহোস্টে রান ব্যবহার করে সমর্থন রয়েছে। আপনি নিজে একটি উদাহরণ তৈরি করতে পারেন এবং স্থানীয়ভাবে কাজ করতে পারেন। উপায় দ্বারা, যে আমরা কি. আমি এটা গেটল্যাবে করি, সেখানে জিএসপিতে। কিন্তু আমরা এখনও এই ধরনের অর্কেস্ট্রেশন করার বিন্দু দেখতে পাচ্ছি না, কারণ গুগলের কাছে সস্তা দাগ নেই। এখানে ??? উদাহরণ, কিন্তু তাদের সীমাবদ্ধতা আছে। প্রথমত, তাদের সবসময় শুধুমাত্র 70% ডিসকাউন্ট থাকে এবং আপনি সেখানে দাম নিয়ে খেলতে পারবেন না। স্পটে, আপনাকে লাথি মারার সম্ভাবনা কমাতে আমরা দাম 5-10% বাড়িয়ে দিই। অর্থাৎ, আপনি দাগগুলি সংরক্ষণ করেন, তবে সেগুলি যে কোনও সময় আপনার কাছ থেকে কেড়ে নেওয়া যেতে পারে। আপনি যদি অন্যদের চেয়ে একটু বেশি বিড করেন তবে আপনাকে পরে মেরে ফেলা হবে। গুগল সম্পূর্ণ ভিন্ন স্পেসিফিকেশন আছে. এবং আরেকটি খুব খারাপ সীমাবদ্ধতা আছে - তারা শুধুমাত্র 24 ঘন্টা বেঁচে থাকে। এবং কখনও কখনও আমরা 5 দিনের জন্য একটি পরীক্ষা চালাতে চাই। কিন্তু আপনি দাগে এটি করতে পারেন; দাগ কখনও কখনও কয়েক মাস ধরে থাকে।

হ্যালো! প্রতিবেদনের জন্য ধন্যবাদ! আপনি চেকআপের কথা বলেছেন। আপনি কিভাবে stat_statements ত্রুটি গণনা করবেন?

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

আপনি কি ভয় পাচ্ছেন না যে স্ন্যাপশটগুলির মধ্যে সময়কালে এটি সেখানে দুই বা তিনবার ঘুরবে?

অর্থাৎ তারা কি আবার নিবন্ধন করেছে বা কি?

উদাহরণস্বরূপ, এই অনুরোধটি ইতিমধ্যেই একবার প্রিমম্প করা হয়েছে, তারপরে এটি এসেছে এবং আবার প্রিমম্প করা হয়েছে, তারপর এটি আবার এসেছে এবং আবার প্রিমম্প করা হয়েছে। এবং আপনি এখানে কিছু গণনা, এবং এটি সব কোথায়?

ভাল প্রশ্ন, আমরা দেখতে হবে.

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

হ্যা হ্যা.

কিন্তু আমি বুঝতে পারছি না কীভাবে এটি নির্ভরযোগ্যভাবে করা যায়।

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

না, তাকে স্ন্যাপশটের মধ্যে বেশ কয়েকবার জোর করে বের করে দেওয়া যেতে পারে এবং আবার আসতে পারে।

একই আইডি দিয়ে?

হ্যাঁ।

আমরা এই অধ্যয়ন করব. ভাল প্রশ্ন. আমরা এটা অধ্যয়ন করা প্রয়োজন. কিন্তু আপাতত, আমরা যা দেখছি তা হয় 0 লেখা...

এটি অবশ্যই একটি বিরল ঘটনা, কিন্তু আমি যখন জানতে পারলাম যে stat_statemetns সেখানে স্থানচ্যুত হতে পারে তখন আমি হতবাক হয়ে গিয়েছিলাম।

Pg_stat_statements-এ অনেক কিছু থাকতে পারে। আমরা জানতে পেরেছি যে আপনার যদি track_utility = চালু থাকে, তাহলে আপনার সেটগুলিও ট্র্যাক করা হয়।

অবশ্যই হ্যাঁ।

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

হ্যাঁ, তবে আপনাকে কতটা জানতে হবে। এবং কোন না কোনভাবে আমাদের তার উপর নজর রাখা প্রয়োজন। এটা যা আমি করি. অর্থাৎ, আমার কাছে pg_stat_statements.max আছে। এবং আমি দেখতে পাচ্ছি যে স্ন্যাপশটের সময় আমি 70% এ পৌঁছাইনি। ঠিক আছে, তাই আমরা কিছু হারাইনি. এর রিসেট করা যাক. এবং আমরা আবার সংরক্ষণ করি। যদি পরবর্তী স্ন্যাপশটটি 70-এর কম হয়, তাহলে সম্ভবত আপনি আর কিছু হারাননি।

হ্যাঁ. ডিফল্ট এখন 5। এবং এটি অনেক লোকের জন্য যথেষ্ট।

সাধারণত হ্যাঁ।

ভিডিও:

PS আমার নিজের পক্ষ থেকে, আমি যোগ করব যে যদি Postgres-এ গোপনীয় তথ্য থাকে এবং এটি পরীক্ষার পরিবেশে অন্তর্ভুক্ত করা না যায়, তাহলে আপনি ব্যবহার করতে পারেন PostgreSQL বেনামী. স্কিমটি প্রায় নিম্নরূপ:

উত্স: www.habr.com