সাধারণ অ্যাপ্লিকেশন ত্রুটি যা postgresql এ ব্লাট হতে পারে। আন্দ্রে সালনিকভ

আমি আন্দ্রে সালনিকভের 2016 সালের শুরুর রিপোর্টের প্রতিলিপিটি পড়ার প্রস্তাব করছি "অ্যাপ্লিকেশানগুলিতে সাধারণ ত্রুটি যা পোস্টগ্রেস্কএলে ফুলে যায়"

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

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

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

আমি আপনাকে ভয়ানক ছবি সহ তিনটি উদাহরণ দেব কিভাবে জিনিস খারাপ হয়েছে. আমি সংক্ষিপ্তভাবে সেখানে ঘটে যাওয়া প্রক্রিয়া বর্ণনা করব। এবং কিভাবে তাদের মোকাবেলা করতে হবে, তারা কখন ঘটেছে, এবং ভুল প্রতিরোধ করতে কি প্রতিরোধমূলক পদ্ধতি ব্যবহার করতে হবে। আমি আপনাকে সহায়ক সরঞ্জাম সম্পর্কে বলব এবং দরকারী লিঙ্কগুলি দেব।

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

প্লেটের প্রাথমিক তথ্য: এটি বেশ ছোট, 2 এমবি। ডাটাবেসের জন্য এবং বিশেষত প্লেটের জন্য প্রতিক্রিয়া সময়ও খুব ভাল। এবং একটি মোটামুটি ভাল লোড - প্লেটে প্রতি সেকেন্ডে 2 অপারেশন।

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

এবং এই পরিস্থিতিতে, আমরা দেখতে পাই যে আমাদের কাছে সত্যিই একটি ছোট প্লেট রয়েছে। সূচকটি 2 MB এ ছোট। এটি বাম দিকের প্রথম চার্ট।

সার্ভার জুড়ে গড় প্রতিক্রিয়া সময়ও স্থিতিশীল, ছোট। এটি উপরের ডানদিকের গ্রাফ।

নীচের বাম গ্রাফটি দীর্ঘতম লেনদেন। আমরা দেখতে পাচ্ছি লেনদেন দ্রুত সম্পন্ন হচ্ছে। এবং অটোভ্যাকুয়াম এখনও এখানে কাজ করে না, কারণ - এটি একটি স্টার্ট-টেস্ট ছিল। তাহলে এটা কাজ করবে এবং আমাদের কাজে লাগবে।

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

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

এবং এখন আমরা একটি ট্র্যাজেডি আছে. কিছু কারণে, একটি দীর্ঘ ভুলে যাওয়া লেনদেন ঘটে। কারণগুলি সাধারণত সমস্ত সাধারণ:

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

এই ধরনের জিনিস কোথায় নিয়ে যায়?

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

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

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

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

আমাদের জীবন ফিরে পেতে হবে। আমরা ইন্টারনেটে আরোহণ করি এবং খুঁজে পাই যে দীর্ঘ লেনদেনের ফলে সমস্যা হয়। আমরা এই লেনদেন খুঁজে এবং হত্যা. এবং সবকিছু আমাদের জন্য ভাল যাচ্ছে. সবকিছু যেমন উচিত কাজ করে।

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

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

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

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

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

এবং সেখানে কী ঘটছে তা বোঝার জন্য, আপনি যদি আগের প্রতিবেদনে না ছিলেন তবে এখন তত্ত্বের কিছুটা বিট। অভ্যন্তরীণ প্রক্রিয়া সম্পর্কে তত্ত্ব। কেন autovacuum এবং এটি কি করে?

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

কেন আপনি একটি autovacuum প্রয়োজন? অটোভ্যাকুয়াম কিছু সময়ে আসে, ডাটাবেসে কল করে এবং জিজ্ঞাসা করে: "অনুগ্রহ করে আমাকে সবচেয়ে পুরানো লেনদেনের আইডি দিন যা বর্তমানে ডাটাবেসে খোলা আছে।" ডাটাবেস এই আইডি প্রদান করে। এবং অটোভ্যাকুয়াম, এটির উপর নির্ভর করে, টেবিলের লাইনগুলির মধ্য দিয়ে যায়। এবং যদি তিনি দেখেন যে কিছু লাইন অনেক পুরানো লেনদেনের দ্বারা পরিবর্তিত হয়েছে, তাহলে তার কাছে সেগুলিকে লাইন হিসাবে চিহ্নিত করার অধিকার রয়েছে যা আমরা সেখানে নতুন ডেটা লিখে ভবিষ্যতে পুনরায় ব্যবহার করতে পারি। এটি একটি পটভূমি প্রক্রিয়া।

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

দুর্ঘটনার সময় কী ঘটেছিল? কিভাবে এই প্রক্রিয়া সঞ্চালিত হয়েছে?

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

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

কাজ করার জন্য আমাদের সত্যিই সবুজ লাইন দরকার। কিন্তু এই ধরনের সমস্যার সময়, দেখা যাচ্ছে যে টেবিলের পুরো ভলিউমে সবুজ লাইনের শতাংশ অত্যন্ত কম।

এবং যখন আমরা একটি ক্যোয়ারী এক্সিকিউট করি, ডাটাবেসটিকে লাল এবং সবুজ উভয় লাইনের মধ্য দিয়ে যেতে হয়, সঠিক লাইনটি খুঁজে বের করতে। এবং অকেজো ডেটা দিয়ে টেবিলটি স্ফীত করার প্রভাবকে "ব্লোট" বলা হয়, যা আমাদের ডিস্কের স্থানও খেয়ে ফেলে। মনে রাখবেন, আগে 2 এমবি, এখন 300 এমবি? এখন মেগাবাইটকে গিগাবাইটে পরিবর্তন করুন এবং আপনি খুব দ্রুত আপনার সমস্ত ডিস্ক সংস্থান হারাবেন।

আমাদের জন্য প্রভাব কি?

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

এ জন্য একটি নির্দিষ্ট চক্রের কাজ চলছে।

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

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

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

আমরা সবকিছু সংশোধন করার পরে, সবকিছু ঠিক আছে কিনা তা নিশ্চিত করার পরে, ভবিষ্যতে এই পরিস্থিতি কীভাবে প্রতিরোধ করা যায় তা আমাদের জানা উচিত:

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

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

টেবিলের আকার অবিলম্বে কয়েক মেগাবাইটের স্বাভাবিক কাজের অবস্থায় ফিরে আসে। এটি সার্ভার জুড়ে গড় প্রতিক্রিয়া সময়কে ব্যাপকভাবে প্রভাবিত করেনি।

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

এখানেই প্রথম গল্পের সমাপ্তি। তিনি সবচেয়ে সাধারণ. এবং এটি প্রত্যেকের সাথেই ঘটে, ক্লায়েন্টের অভিজ্ঞতা নির্বিশেষে, সেখানে কতটা যোগ্যতাসম্পন্ন প্রোগ্রামার রয়েছে। শীঘ্রই বা পরে এটি ঘটে।

দ্বিতীয় গল্প, যেখানে আমরা লোড বিতরণ করি এবং সার্ভার সংস্থান অপ্টিমাইজ করি

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

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

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

বিশেষ করে, টেস্ট ট্যাবলেট অনুযায়ী, আমরা সেখানে অ্যাকাউন্টে ব্যালেন্স আপডেট করতে থাকি। এবং আমাদের অনুরোধে একটি স্থিতিশীল প্রতিক্রিয়া সময়, স্থিতিশীল সম্পদ খরচ রয়েছে। আমাদের সাথে সবকিছু ঠিক আছে।

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

আমরা অনলাইনে যাই এবং কেন এটি ঘটছে তা পড়তে শুরু করি। এবং আমরা একটি সমাধান খুঁজে.

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

আমরা চাই সবকিছু নিখুঁত হোক। আরো এগিয়ে যাক. এবং আমরা ইন্টারনেটে একটি দুর্দান্ত সেটিং খুঁজে পাই - hot_standby_feedback৷ আমরা এটি চালু করি। Hot_standby_feedback আমাদেরকে মাস্টারে চলমান অটোভ্যাকুয়াম ধরে রাখতে দেয়। এইভাবে, আমরা সম্পূর্ণরূপে প্রতিলিপি দ্বন্দ্ব পরিত্রাণ পেতে. এবং আমরা সবাই রিপোর্টের সাথে ভাল কাজ করি।

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

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

আমি আগে কি কথা বলছিলাম তা যদি আমরা না জানি তবে এটি কেমন হবে?

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

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

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

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

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

আমরা সবকিছু ঠিকঠাক করেছি বলে মনে হচ্ছে। লোড বিতরণ করুন। যন্ত্রপাতি নিষ্ক্রিয় নয়। মনের মতে, তারা অনুরোধ ভেঙ্গেছে, কিন্তু তবুও সবকিছু খারাপভাবে পরিণত হয়েছে।

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

আমরা একইভাবে ফলাফলগুলি দূর করি:

• আমরা ফোলা টেবিল খুঁজে.
• এবং আমরা সবচেয়ে সুবিধাজনক টুল দিয়ে সংকুচিত করি যা আমাদের জন্য উপযুক্ত।

দ্বিতীয় গল্প এখানেই শেষ। তৃতীয় গল্পে যাওয়া যাক।

এছাড়াও আমাদের জন্য বেশ সাধারণ, যেখানে আমরা মাইগ্রেশন করি।

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

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

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

আমরা মাইগ্রেট করেছি এবং আবার সমস্যা পেয়েছি।

মাইগ্রেশন সফল হয়েছে, কিন্তু:

• পুরোনো কার্যকারিতা আরও দীর্ঘ হতে শুরু করে।
• টেবিল আবার আকারে বড় হয়েছে।
• সার্ভারে আবার লোড আগের চেয়ে বেড়েছে।
• এবং, অবশ্যই, আমরা এখনও সেই কার্যকারিতা নিয়ে ঝাঁকুনি দিচ্ছি যা ভাল কাজ করেছে, আমরা এটিকে কিছুটা উন্নত করেছি।

এবং এটি আবার ফোলা, যা আবার আমাদের জীবন নষ্ট করে।

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

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

এবং এখানে মূল জিনিসটি হ'ল কীভাবে এই জাতীয় মাইগ্রেশনগুলি সঠিকভাবে করা যায় তা বোঝা। এবং তারা করা প্রয়োজন. আমরা এই স্থানান্তরগুলি বেশ নিয়মিত করি।

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

এবং একই সময়ে, আমরা ফুলে উঠব না এবং পারফরম্যান্সে দমে যাব না।

এই তৃতীয় গল্পের সমাপ্তি।

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

এবং এখন আমি প্রথম গল্পে যে সরঞ্জামগুলি উল্লেখ করেছি সেগুলি সম্পর্কে আরও কিছুটা।

ব্লোট খোঁজার আগে, আপনাকে অবশ্যই এক্সটেনশনটি ইনস্টল করতে হবে pgstattuple.

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

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

আমরা বুঝতে পেরেছি যে কীভাবে আমাদের সাথে ফুলে থাকা টেবিলগুলিকে শনাক্ত করা যায়, উপরন্তু, যখন সেগুলি অকেজো ডেটা দিয়ে ফুলে যায়।

এখন কিভাবে ব্লাট ঠিক করবেন সে সম্পর্কে:

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

সরঞ্জাম সহ সবকিছু।

আপনি যদি ব্লোট বিষয়টিকে আরও ভিতরের দিকে খননের ক্ষেত্রে আকর্ষণীয় মনে করেন, তাহলে এখানে আপনার জন্য কিছু দরকারী লিঙ্ক রয়েছে:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres আমার সহকর্মীর রিপোর্ট। পোস্টগ্রেস এর কাজ এবং জীবনের সময় কোথায় যায় সে সম্পর্কে এটি সাধারণ। এবং ব্লোট সম্পর্কে ডিবিএর জন্য একটি খুব বড় এবং বিশদ প্রযুক্তিগত অংশ রয়েছে।
• https://github.com/dataegret/pg-utils এটি আমাদের সংগ্রহস্থলের একটি লিঙ্ক, যেখানে আমরা ডাটাবেসের স্থিতি পরীক্ষা করার জন্য একগুচ্ছ দরকারী স্ক্রিপ্ট সংরক্ষণ করি। সেখানে আপনি ব্লোট সার্চ স্ক্রিপ্টগুলি খুঁজে পেতে পারেন।
• তৃতীয় и চতুর্থ সরঞ্জামগুলির লিঙ্ক যা আপনাকে প্লেটগুলিকে সংকুচিত করতে সহায়তা করবে।
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html এটা আমার সহকর্মী থেকে একটি পোস্ট. সেখানে তিনি বেশ গুরুত্ব সহকারে এবং প্রযুক্তিগতভাবে প্রশাসকদের কাছাকাছি স্তরে ইতিমধ্যেই বিশদভাবে ব্লোট বিশ্লেষণ করেছেন।

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

প্রশ্ন

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

এই ক্ষেত্রে, এটি আপনার কোম্পানির প্রশাসকদের জন্য একটি কাজ, DBA-এর জন্য অপরিহার্য নয়।

আমি একজন প্রশাসক।

PostgreSQL এর pg_stat_activity নামে একটি ভিউ আছে যা মুলতুবি থাকা প্রশ্নগুলি দেখায়। এবং আপনি দেখতে পারেন এটি সেখানে কতক্ষণ ঝুলে থাকে।

আমাকে প্রতি ৫ মিনিট পর পর এসে দেখতে হবে?

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

এটা কেন ঘটছে তা কি স্পষ্ট কারণ আছে?

আমি কিছু তালিকাভুক্ত করেছি। অন্যান্য আরও জটিল উদাহরণ। এবং একটি দীর্ঘ কথোপকথন হতে পারে.

প্রতিবেদনের জন্য ধন্যবাদ! আমি pg_repack ইউটিলিটি সম্পর্কে স্পষ্ট করতে চেয়েছিলাম। যদি এটি একটি এক্সক্লুসিভ লক না নেয়, তাহলে...

তিনি একটি একচেটিয়া তালা তোলে.

... তাহলে আমি সম্ভাব্য ডেটা হারাতে পারি। আমার অ্যাপ এই সময়ে কিছু রেকর্ড করা উচিত নয়?

না, এটি টেবিলের সাথে শান্তভাবে কাজ করে, যেমন pg_repack প্রথমে সেখানে থাকা সমস্ত লাইভ লাইন স্থানান্তর করে। স্বাভাবিকভাবেই, টেবিলে একরকম রেকর্ড চলছে। সে শুধু এই পনিটেল ছুড়ে ফেলে।

অর্থাৎ শেষ পর্যন্ত কি তিনি তা করেন?

শেষ পর্যন্ত, এই ফাইলগুলি অদলবদল করার জন্য এটি একটি একচেটিয়া লক লাগে।

এটা কি ভ্যাকুয়াম ফুলের চেয়ে দ্রুত হবে?

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

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

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

আমি বুঝেছি. কিন্তু প্রশ্ন সেটা নিয়ে নয়। আমি রাজি হইনি। ধরা যাক আমাদের একটি টেবিল আছে। এটি পরিবর্তনশীল আকার ক্ষেত্র আছে. এবং যদি আমি নতুন কিছু ঢোকানোর চেষ্টা করি, তবে এটি পুরানো কক্ষে মাপসই নাও হতে পারে।

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

প্রতিবেদনের জন্য ধন্যবাদ! সময়সীমা সীমিত করতে বিবৃতি টাইমআউট অনুরোধগুলি ব্যবহার করা কতটা গ্রহণযোগ্য?

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

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

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

অর্থাৎ আপডেটের পরপরই বন্ধ হয়ে যায়?

এটি সেটিংসের উপর নির্ভর করে। আমি একটি সেটিং এর নাম দিয়েছি। এটি অটো কমিট অন। সে বেশ সাধারণ। যদি এটি সক্রিয় করা হয়, তাহলে লেনদেন খোলা এবং বন্ধ ছিল। যদি না আপনি স্পষ্টভাবে বলেন "লেনদেন শুরু করুন" এবং "লেনদেন শেষ করুন", কিন্তু কেবল সেশনে একটি অনুরোধ চালু করেন।

হ্যালো! প্রতিবেদনের জন্য ধন্যবাদ! কল্পনা করুন যে আমাদের একটি ডাটাবেস আছে যা ফুলে যায় এবং ফুলে যায় এবং তারপরে সার্ভারের স্থান ফুরিয়ে যায়। এই পরিস্থিতি ঠিক করার জন্য কোন সরঞ্জাম আছে?

সার্ভারে জায়গাটি ভালোভাবে পর্যবেক্ষণ করা দরকার।

উদাহরণস্বরূপ, ডিবিএ চা খেতে গিয়েছিল, একটি রিসোর্টে ছিল ইত্যাদি।

যখন একটি ফাইল সিস্টেম তৈরি করা হয়, তখন অন্তত কিছু রিজার্ভ স্পেস তৈরি হয় যেখানে ডেটা লেখা হয় না।

এটা সম্পূর্ণ শূন্য হলে কি হবে?

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

অন্য কোন টুল আছে?

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

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

সেগুলোও প্যাক করে।

কিন্তু শূন্যতা সূচকে প্রভাব ফেলে না?

কিছু একটি সূচক সঙ্গে কাজ. যেমন pg_rapack, pgcompacttable. ভ্যাকুয়াম সূচকগুলি পুনরায় তৈরি করে, তাদের প্রভাবিত করে। VACUUM FULL-এ সবকিছু ওভাররাইট করার সারমর্ম রয়েছে, অর্থাৎ এটি সবার সাথে কাজ করে।

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

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

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

এটি একটি পরিষেবা ওকমিটার.

এটি একটি বাণিজ্যিক পণ্য?

হ্যাঁ. এটি একটি বাণিজ্যিক পণ্য।

উত্স: www.habr.com