প্রথমে সর্বদা PostgreSQL এর সর্বশেষতম সংস্করণ ব্যবহার করুন। পারফরম্যান্স উন্নতি সবসময়ই আসছে, তাই আপনি যদি কোনও পুরানো সংস্করণ টিউন করেন তবে আপনি সম্ভবত আপনার সময় নষ্ট করছেন। উদাহরণস্বরূপ, পোস্টগ্রিসকিউএল 9.2 তাত্পর্যপূর্ণ গতির উন্নতি করেTRUNCATE এবং অবশ্যই সূচি-শুধুমাত্র স্ক্যানগুলি যুক্ত করে। এমনকি ছোটখাট প্রকাশগুলি সর্বদা অনুসরণ করা উচিত; দেখতে সংস্করণ নীতি ।
কী করা উচিত না
না না একটি ramdisk বা অন্যান্য অ-টেকসই সঞ্চয়ের একটি tablespace- র করা ।
আপনি যদি কোনও টেবিল স্পেস হারিয়ে ফেলেন তবে পুরো ডেটাবেস ক্ষতিগ্রস্থ হতে পারে এবং উল্লেখযোগ্য কাজ ছাড়াই ব্যবহার করা শক্ত। কেবল UNLOGGEDটেবিলগুলি ব্যবহার করা এবং যে কোনও উপায়ে ক্যাশের জন্য প্রচুর র্যাম থাকার তুলনায় এর খুব সামান্য সুবিধা রয়েছে ।
আপনি যদি সত্যই র্যামডিস্ক ভিত্তিক সিস্টেম চান, র্যামডিস্কে initdbসম্পূর্ণ নতুন ক্লাস্টারটি initdbর্যামডিস্কে একটি নতুন পোস্টগ্রাইএসকিউএল ইনস্ট্যান্স করে, যাতে আপনার একটি সম্পূর্ণ নিষ্পত্তিযোগ্য পোস্টগ্রাইএসকিউএল উদাহরণ থাকে।
PostgreSQL সার্ভার কনফিগারেশন
পরীক্ষা করার সময়, আপনি অ-টেকসই তবে দ্রুত অপারেশনের জন্য আপনার সার্ভারটি কনফিগার করতে পারেন ।
fsync=offপোস্টগ্র্রেএসকিউএল- এ সেটিংসের জন্য এটি একমাত্র গ্রহণযোগ্য ব্যবহার । এই সেটিংটি পোস্টগ্র্রেএসকিউএলকে অর্ডারযুক্ত লেখাগুলি বা অন্য কোনও দুষ্টু ডেটা-অখণ্ডতা-সুরক্ষা এবং ক্র্যাশ-সুরক্ষা স্টাফ নিয়ে বিরক্ত না হওয়ার জন্য বলে দেয়, যদি আপনি শক্তি হারিয়ে ফেলেন বা কোনও ওএস ক্রাশ হয়ে থাকে তবে আপনার ডেটা পুরোপুরি ট্র্যাশ করার অনুমতি দেয় giving
বলা বাহুল্য, আপনি কখনই fsync=offউত্পাদনে সক্ষম হবেন না যদি আপনি অন্য কোথাও থেকে পুনরায় উত্পন্ন করতে পারেন এমন ডেটার জন্য অস্থায়ী ডাটাবেস হিসাবে পিজিকে ব্যবহার করছেন না। যদি আপনি কেবল ফাইএনসিচ বন্ধ করতে থাকেন তবে তা বন্ধও করতে পারে full_page_writes, কারণ এটি আর কোনও ভাল করে না। সাবধান থাকুন fsync=offএবং ক্লাস্টার স্তরে full_page_writesপ্রয়োগ করুন , যাতে তারা আপনার পোস্টগ্র্যাস এসকিউএল উদাহরণে সমস্ত ডাটাবেসকে প্রভাবিত করে।
উত্পাদন ব্যবহারের জন্য আপনি সম্ভবত ব্যবহার করতে পারেন synchronous_commit=offএবং সেট করতে পারেন commit_delay, যেহেতু আপনি fsync=offদৈত্য তথ্য দুর্নীতির ঝুঁকি ছাড়াই অনেকগুলি একই সুবিধা পাবেন । আপনি যদি অ্যাসিঙ্ক কমিট সক্ষম করে থাকেন তবে সাম্প্রতিক ডেটা হারাতে আপনার একটি ছোট উইন্ডো রয়েছে - তবে এটি it
আপনার যদি UNLOGGEDডিডিএলকে কিছুটা পরিবর্তন করার বিকল্প থাকে তবে আপনি ডাব্লুএল লগিং সম্পূর্ণরূপে এড়াতে Pg 9.1+ এ সারণীগুলিও ব্যবহার করতে পারেন এবং সার্ভারটি ক্র্যাশ হয়ে গেলে টেবিলগুলি মোছার ব্যয়ে একটি সত্য গতির উত্সাহ অর্জন করতে পারেন। সমস্ত টেবিলকে অবরোধবিহীন করার জন্য কোনও কনফিগারেশন বিকল্প নেই, এটি অবশ্যই সেট করা উচিত CREATE TABLE। এটি টেস্টিংয়ের পক্ষে ভাল হওয়ার পাশাপাশি যদি আপনার কাছে কোনও ডাটাবেজে উত্পন্ন বা গুরুত্বহীন ডেটা পূর্ণ টেবিল থাকে তবে অন্যথায় আপনার নিরাপদ থাকা দরকার।
আপনার লগগুলি পরীক্ষা করুন এবং দেখুন যে আপনি অনেকগুলি চেকপয়েন্ট সম্পর্কে সতর্কতা পেয়ে যাচ্ছেন। আপনি যদি হন তবে আপনার চেকপয়েন্ট_সেজমেন্টগুলি বাড়ানো উচিত । মসৃণ লেখার জন্য আপনি আপনার চেকপয়েন্ট_কম্পলশন_তার সাথে টিউন করতেও পারেন।
shared_buffersআপনার কাজের চাপ ফিট করার জন্য টিউন করুন । এটি ওএস-নির্ভর, আপনার মেশিনের সাথে আর কি চলছে তার উপর নির্ভর করে এবং এর জন্য কিছু পরীক্ষা এবং ত্রুটি দরকার requires ডিফল্টগুলি অত্যন্ত রক্ষণশীল। আপনি shared_buffersপোস্টগ্র্রেএসকিউএল 9.2 এবং নীচে বৃদ্ধি পেলে আপনাকে ওএসের সর্বাধিক শেয়ার করা মেমরি সীমা বাড়ানোর প্রয়োজন হতে পারে ; 9.3 এবং উপরে পরিবর্তিত তারা কীভাবে এড়াতে ভাগ করে নেওয়া মেমরি ব্যবহার করে।
আপনি যদি একটি মাত্র কানেকশন কাজের প্রচুর কাজ দুয়েক ব্যবহার করেন, তাহলে বৃদ্ধি work_memতাদের র্যাম প্রকারের ইত্যাদি খুব বেশী সাবধান যে জন্য সাথে খেলতে দিতে একটি work_memসেটিং সমস্যার আউট-অফ-মেমরি সৃষ্টি করতে পারে, কারণ এটি সাজানোর প্রতি নয় প্রতি সংযোগ যাতে একটি ক্যোয়ারিতে অনেক নেস্টেড প্রকার থাকতে পারে। আপনি শুধুমাত্র সত্যিই বাড়াতে হবে work_memআপনি ডিস্কে কেন্দ্রে সংঘাত ছড়িয়ে পরেছে প্রকারের দেখতে পারেন যদি EXPLAINবা লগ log_temp_filesসেটিং (প্রস্তাবিত), কিন্তু একটি উচ্চ মান এছাড়াও পিজি দক্ষতা সহকারে পরিকল্পনা বাছাই করতে দিতে পারে।
এখানে অন্য পোস্টার হিসাবে বলা হয়েছে, সম্ভব হলে এক্সলগ এবং প্রধান সারণী / সূচকগুলি পৃথক এইচডিডি তে রাখাই বুদ্ধিমানের কাজ। পৃথক পার্টিশনগুলি বেশ অর্থহীন, আপনি সত্যিই পৃথক ড্রাইভ চান। আপনি fsync=offযদি UNLOGGEDটেবিল ব্যবহার করে থাকেন তবে এই বিচ্ছেদটির খুব কম সুবিধা রয়েছে almost
অবশেষে, আপনার প্রশ্নের টিউন করুন। আপনার সিস্টেমের পারফরম্যান্সটি আপনার random_page_costএবং seq_page_costপ্রতিফলিত হয়, আপনার effective_cache_sizeসঠিক কিনা তা নিশ্চিত করুন ইত্যাদি নিশ্চিত করুন EXPLAIN (BUFFERS, ANALYZE)পৃথক ক্যোয়ারী পরিকল্পনাগুলি পরীক্ষা করতে, এবং auto_explainসমস্ত ধীর অনুসন্ধানগুলি রিপোর্ট করার জন্য মডিউলটি চালু করুন । আপনি প্রায়শই একটি উপযুক্ত সূচি তৈরি করে বা ব্যয় পরামিতিগুলি টুইট করে কোয়েরি পারফরম্যান্স নাটকীয়ভাবে উন্নত করতে পারেন।
আফাইক হিসাবে পুরো ডাটাবেস বা ক্লাস্টার সেট করার উপায় নেই UNLOGGED। এটি করতে সক্ষম হওয়া আকর্ষণীয় হবে। PostgreSQL মেলিং তালিকায় জিজ্ঞাসা করার বিষয়ে বিবেচনা করুন।
হোস্ট ওএস টিউনিং
অপারেটিং সিস্টেমের স্তরেও আপনি কিছু করতে পারেন tun আপনি যে প্রধান জিনিসটি করতে চাইতে পারেন তা হ'ল আক্রমণাত্মকভাবে ডিস্কে লেখার জন্য অপারেটিং সিস্টেমকে বোঝানো নয়, যেহেতু আপনি / যখন তারা ডিস্কে এটি তৈরি করেন তখন আপনার সত্যিই যত্ন নেই।
লিনাক্স-এ আপনার সাথে এই নিয়ন্ত্রণ করতে পারেন ভার্চুয়াল মেমরি সাব-সিস্টেম এর dirty_*মত সেটিংস, dirty_writeback_centisecs।
টিউনিং রাইডব্যাক সেটিংসটি খুব শিথিল হওয়ার একমাত্র সমস্যাটি হ'ল অন্য কোনও প্রোগ্রামের মাধ্যমে ফ্লাশের ফলে পোস্টগ্র্রেএসকিউএল এর সঞ্চিত বাফারগুলিকেও খুব বেশি ফ্লাশ করা হতে পারে এবং বড় আকারের স্টল সৃষ্টি করতে পারে যখন সমস্ত কিছু লেখালেখিতে অবরুদ্ধ থাকে। আপনি আলাদা ফাইল সিস্টেমে পোস্টগ্রেএসকিউএল চালিয়ে এটিকে লাঘব করতে সক্ষম হতে পারেন তবে কিছু ফ্লাশ ডিভাইস-স্তরের বা পুরো-হোস্ট-স্তরের ফাইল সিস্টেম-স্তরের নয়, তাই আপনি এটির উপর নির্ভর করতে পারবেন না।
আপনার কাজের চাপের জন্য কী সেরা কাজ করে তা দেখার জন্য এই টিউনিংয়ের জন্য সত্যই সেটিংসের চারপাশে খেলা প্রয়োজন।
নতুন কার্নেলগুলিতে, আপনি vm.zone_reclaim_modeএটি শূন্যতে সেট করা আছে তা নিশ্চিত করতে চাইতে পারেন, কারণ পোস্টগ্র্রেএসকিউএল পরিচালিত হয় তার সাথে মিথস্ক্রিয়তার কারণে এটি NUMA সিস্টেমের (বেশিরভাগ সিস্টেমে) মারাত্মক পারফরম্যান্স সমস্যার কারণ হতে পারে shared_buffers।
ক্যোয়ারী এবং কাজের চাপ টিউনিং
এগুলি এমন কি যা কোড পরিবর্তন দরকার; তারা আপনার উপযুক্ত নাও হতে পারে। কিছু কিছু এমন জিনিস যা আপনি প্রয়োগ করতে সক্ষম হতে পারেন।
আপনি যদি বৃহত্তর লেনদেনের জন্য কাজটিকে ব্যাচ করছেন না তবে শুরু করুন। প্রচুর ছোট ছোট লেনদেন ব্যয়বহুল, সুতরাং যখনই এটি করা সম্ভব হয় এবং ব্যবহারিক হয় তখন আপনার স্টাফ ব্যাচ করা উচিত। আপনি যদি অ্যাসিঙ্ক কমিট ব্যবহার করছেন তবে এটি কম গুরুত্বপূর্ণ তবে তবুও উচ্চ প্রস্তাবিত।
যখনই সম্ভব অস্থায়ী সারণী ব্যবহার করুন। তারা ওয়াল ট্র্যাফিক জেনারেট করে না, তাই সন্নিবেশ এবং আপডেটের জন্য এগুলি অনেক দ্রুত। কখনও কখনও এটি কোনও টেম্প টেবিলের মধ্যে একগুচ্ছ ডেটা স্লাপিং করার উপযুক্ত, এটি আপনাকে চালিত করে তবে INSERT INTO ... SELECT ...চূড়ান্ত টেবিলের অনুলিপি করার জন্য এটি করা। নোট করুন যে অস্থায়ী টেবিলগুলি প্রতি সেশনে রয়েছে; যদি আপনার সেশনটি শেষ হয় বা আপনি আপনার সংযোগটি হারিয়ে ফেলেন তবে টেম্প টেবিলটি চলে যায় এবং অন্য কোনও সংযোগ কোনও সেশনের টেম্প টেবিলের সামগ্রী দেখতে পাবে না।
আপনি যদি PostgreSQL 9.1 বা নতুন ব্যবহার UNLOGGEDকরে থাকেন তবে সেশন স্টেটের মতো আপনি যে ডেটা হারাতে পারবেন তা সারণী ব্যবহার করতে পারেন। এগুলি বিভিন্ন সেশনে দৃশ্যমান এবং সংযোগের মধ্যে সংরক্ষণ করা হয়। সার্ভারটি অকার্যকরভাবে বন্ধ হয়ে গেলে তারা কেটে ফেলা হয় যাতে আপনার পুনরায় তৈরি করতে না পারে এমন কোনও কিছুর জন্য সেগুলি ব্যবহার করা যায় না, তবে তারা ক্যাশে, বস্তুগত দৃষ্টিভঙ্গি, রাষ্ট্রীয় টেবিল ইত্যাদির জন্য দুর্দান্ত're
সাধারণভাবে, না DELETE FROM blah;। TRUNCATE TABLE blah;পরিবর্তে ব্যবহার করুন; আপনি যখন একটি টেবিলের মধ্যে সমস্ত সারি ডাম্প করছেন তখন এটি খুব দ্রুত হয়। TRUNCATEআপনি যদি পারেন তবে এক কলে অনেকগুলি টেবিল কেটে ফেলুন । যদিও আপনি বার বার প্রচুর TRUNCATESছোট টেবিলগুলি করছেন তবে একটি সতর্কতা রয়েছে ; দেখুন: পোস্টগ্র্যাস্কল কেটে যাওয়ার গতি
আপনার যদি বিদেশী কীগুলিতে সূচি না থাকে DELETEতবে সেই বিদেশী কীগুলির দ্বারা উল্লেখ করা প্রাথমিক কীগুলি জড়িতগুলি মারাত্মকভাবে ধীর হবে। আপনি যদি কখনও DELETEরেফারেন্স সারণী (গুলি) থেকে আশা করেন তবে এই জাতীয় সূচী তৈরির বিষয়টি নিশ্চিত করুন । সূচকের জন্য প্রয়োজন হয় না TRUNCATE।
আপনার প্রয়োজন নেই এমন সূচী তৈরি করবেন না। প্রতিটি সূচকের রক্ষণাবেক্ষণের ব্যয় থাকে। সূচকের ন্যূনতম সেট ব্যবহার করার চেষ্টা করুন এবং বিটম্যাপ সূচক স্ক্যানগুলি অনেক বিশাল, ব্যয়বহুল মাল্টি-কলাম-ইনডেক্সগুলি বজায় রাখার পরিবর্তে সেগুলি একত্রিত করতে দিন। যেখানে সূচকের প্রয়োজন হয়, প্রথমে টেবিলটি জনপ্রিয় করার চেষ্টা করুন, তারপরে শেষে সূচি তৈরি করুন।
হার্ডওয়্যারের
পুরো ডাটাবেসটি ধারণ করতে পর্যাপ্ত র্যাম থাকা যদি আপনি এটি পরিচালনা করতে পারেন তবে এটি একটি বিশাল জয়।
আপনার যদি পর্যাপ্ত র্যাম না থাকে তবে দ্রুত সঞ্চয়স্থান আপনি আরও ভাল করতে পারবেন। এমনকি একটি সস্তা এসএসডি স্পিনিং মরিচা থেকে একটি বিশাল পার্থক্য তোলে। উত্পাদনের জন্য সস্তা এসএসডিগুলিতে বিশ্বাস করবেন না, যদিও তারা প্রায়শই ক্র্যাশসফ হয়ে থাকে না এবং আপনার ডেটা খেতে পারে।
শিক্ষা
গ্রেগ স্মিথের বই পোস্টগ্রিসকিউএল 9.0 উচ্চ কার্যকারিতা কিছুটা পুরানো সংস্করণ উল্লেখ করেও প্রাসঙ্গিক রয়েছে। এটি একটি দরকারী রেফারেন্স হওয়া উচিত।
PostgreSQL সাধারণ মেলিং তালিকায় যোগ দিন এবং এটি অনুসরণ করুন।
পাঠ: