পোস্টগ্রেস 9.2 এ ওয়ার্ক_মেম এবং ভাগ করা_বফারগুলি ক্রমবর্ধমান প্রশ্নগুলি ধীর করে দেয়

আমার একটি পোস্টগ্রিএসকিউএল 9.2 উদাহরণ রয়েছে যা 16 গিগাবাইট র‌্যাম সহ আরএইচইল 6.3, 8-কোর মেশিনে চলছে। সার্ভারটি এই ডাটাবেসে উত্সর্গীকৃত। প্রদত্ত যে ডিফল্ট postgresql.conf মেমরি সেটিংস সম্পর্কিত যথেষ্ট রক্ষণশীল, আমি ভেবেছিলাম পোস্টগ্রিসকে আরও মেমরি ব্যবহার করার অনুমতি দেওয়া ভাল ধারণা হতে পারে। আমার অবাক করার বিষয়, wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server- র পরামর্শ অনুসরণ করে আমি চালিত প্রতিটি ক্যোয়ারী উল্লেখযোগ্যভাবে কমিয়ে দিয়েছি তবে আরও জটিল প্রশ্নগুলির ক্ষেত্রে এটি স্পষ্টতই বেশি লক্ষণীয়।

আমি প্যাগটিউন চালানোর চেষ্টা করেছি যা আরও বেশি পরামিতিগুলির সাথে সুরক্ষার সাথে নিম্নলিখিত প্রস্তাবটি দিয়েছিল, তবে এতে কোনও পরিবর্তন হয়নি। এটি র‌্যাম আকারের 1/4 ভাগের ভাগযুক্ত_বাফারদের পরামর্শ দেয় যা অন্য কোথাও পরামর্শের সাথে সঙ্গতিপূর্ণ বলে মনে হয় (এবং বিশেষত পিজি উইকিতে)।

default_statistics_target = 50
maintenance_work_mem = 960MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 11GB
work_mem = 96MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 3840MB
max_connections = 80

আমি সেটিংস পরিবর্তন করে (ব্যবহার করে reindex database) পুরো ডাটাবেসটিকে পুনরায় সূচি দেওয়ার চেষ্টা করেছি , তবে এটি কোনওরকমই কাজে লাগেনি । আমি ভাগ করে নেওয়া_বাফারস এবং ওয়ার্ক_মেমের সাথে প্রায় খেলেছি। খুব রক্ষণশীল ডিফল্ট মানগুলি (128 কে / 1 এমবি) থেকে ধীরে ধীরে এগুলি পরিবর্তন করা ক্রমান্বয়ে কর্মক্ষমতা হ্রাস পেয়েছে।

আমি EXPLAIN (ANALYZE,BUFFERS)কয়েকটি অনুসন্ধানে ছুটে এসেছি এবং অপরাধী মনে হচ্ছে হ্যাশ জোড় উল্লেখযোগ্যভাবে ধীর। কেন তা আমার কাছে পরিষ্কার নয়।

কিছু সুনির্দিষ্ট উদাহরণ দেওয়ার জন্য আমার নীচের প্রশ্নটি রয়েছে। এটি ডিফল্ট কনফিগারেশনে 2100 মিলিয়ন ডলার এবং বর্ধিত আকারের বৃদ্ধি সহ কনফিগারেশনে 00 3300ms এ চলে:

select count(*) from contest c
left outer join contestparticipant cp on c.id=cp.contestId
left outer join teammember tm on tm.contestparticipantid=cp.id
left outer join staffmember sm on cp.id=sm.contestparticipantid
left outer join person p on p.id=cp.personid
left outer join personinfo pi on pi.id=cp.personinfoid
where pi.lastname like '%b%' or pi.firstname like '%a%';

EXPLAIN (ANALYZE,BUFFERS) উপরের প্রশ্নের জন্য:

ডিফল্ট বাফারস: http://explain.depesz.com/s/xaHJ
বড় বাফার: http://explain.depesz.com/s/Plk

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

সম্পাদনা: আমি সবেমাত্র একটি আকর্ষণীয় তথ্য পেয়েছি: আমি যখন ২০১০-এর মাঝামাঝি আইম্যাক (ওএসএক্স 10.7.5) তে পোস্টগ্রিস 9.2.1 এবং 16 জিবি র‌্যামের সাথেও একই পরীক্ষা করি তখন আমি ধীর গতি অনুভব করি না। বিশেষ করে:

set work_mem='1MB';
select ...; // running time is ~1800 ms
set work_mem='96MB';
select ...' // running time is ~1500 ms

আমি যখন সার্ভারে ঠিক একই ডেটা দিয়ে ঠিক একই প্রশ্নের (উপরের একটিটি) করি তখন আমি work_mem = 1MB সহ 2100 এমএস এবং 96 এমবি সহ 3200 এমএস পাই।

ম্যাকের এসএসডি রয়েছে তাই এটি বোধগম্যভাবে দ্রুত, তবে এটি এমন একটি আচরণ প্রদর্শন করে যা আমি প্রত্যাশা করব।

আরও দেখুন pgsql-কর্মক্ষমতার উপর ফলো-আপ আলোচনা ।

postgresql query-performance

— পেট্র প্রুস
সূত্র

মনে হচ্ছে ধীরের ক্ষেত্রে প্রতিটি পদক্ষেপটি ধারাবাহিকভাবে ধীর। অন্যান্য সেটিংস কি একই রকম ছিল?

— dezso

এটি জেনেরিকের চেয়ে আরও বিশেষীকৃত ফোরামে এটি জিজ্ঞাসা করা আপনার পক্ষে উপযুক্ত। এই ক্ষেত্রে আমি pgsql জেনারেল মেইলিং লিস্ট সুপারিশ archives.postgresql.org/pgsql-general

— কলিন 'টি হার্ট

ওহ, এবং ফেরত রিপোর্ট করুন এবং উত্তরটি খুঁজে পেলে দয়া করে আপনার নিজের প্রশ্নের উত্তর দিন! (এটি অনুমোদিত, এমনকি উত্সাহিত)।

— কলিন 'হার্ট

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

— কলিন টি হার্ট

প্রশ্নটি এখন pgsql- পারফরম্যান্সে পোস্ট করা হয়েছে: সংরক্ষণাগারগুলি.পোস্টগ্রেসকল.আর

— 2012-11/msg00004.php

উত্তর:

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

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

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

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

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

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

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

— ক্রিস ট্র্যাভারস
সূত্র

আপাতদৃষ্টিতে প্যারাডোক্সিকাল প্রভাব যে ক্রমবর্ধমান work_memকর্মক্ষমতা হ্রাস করে তা ছাড়া ( @ ক্রিসের একটি ব্যাখ্যা থাকতে পারে), আপনি কমপক্ষে দুটি উপায়ে আপনার কার্যকারিতা উন্নত করতে পারেন।

দুটি নকল LEFT JOINএর সাথে আবার লিখুন JOIN। এটি ক্যোয়ারির পরিকল্পনাকারীকে বিভ্রান্ত করতে পারে এবং নিকৃষ্ট পরিকল্পনার দিকে নিয়ে যেতে পারে।

SELECT count(*) AS ct
FROM   contest            c
JOIN   contestparticipant cp ON cp.contestId = c.id
JOIN   personinfo         pi ON pi.id = cp.personinfoid
LEFT   JOIN teammember    tm ON tm.contestparticipantid = cp.id
LEFT   JOIN staffmember   sm ON sm.contestparticipantid = cp.id
LEFT   JOIN person        p  ON p.id = cp.personid
WHERE (pi.firstname LIKE '%a%'
OR     pi.lastname  LIKE '%b%')

আপনার প্রকৃত অনুসন্ধান নিদর্শনগুলি আরও নির্বাচনী বলে ধরে নিচ্ছেন, অ-অ্যাঙ্করড অনুসন্ধানগুলিকে সমর্থন করতে pi.firstnameএবং ট্রাইগ্রাম সূচকগুলি ব্যবহার করুন । (এর মতো ছোট আকারের নিদর্শনগুলিও সমর্থিত তবে কোনও সূচকটি অ-নির্বাচনী ভবিষ্যদ্বাণীগুলির পক্ষে সহায়তা করবে না not):pi.lastnameLIKE'%a%'

CREATE INDEX personinfo_firstname_gin_idx ON personinfo USING gin (firstname gin_trgm_ops);
CREATE INDEX personinfo_lastname_gin_idx  ON personinfo USING gin (lastname gin_trgm_ops);

অথবা একটি মাল্টিকালম ইনডেক্স:

CREATE INDEX personinfo_name_gin_idx ON personinfo USING gin (firstname gin_trgm_ops, lastname gin_trgm_ops);

আপনার ক্যোয়ারীটি কিছুটা দ্রুত করা উচিত। এর জন্য আপনাকে অতিরিক্ত মডিউল pg_trgm ইনস্টল করতে হবে । এই সম্পর্কিত প্রশ্নের অধীনে বিশদ:

এছাড়াও, আপনি কি work_mem স্থানীয়ভাবে সেট করার চেষ্টা করেছেন - কেবলমাত্র বর্তমান লেনদেনের জন্য ?

SET LOCAL work_mem = '96MB';

এটি আরও র‌্যাম খাওয়া, সম্ভবত একে অপরকে অনাহারে থেকে একযোগে লেনদেনগুলি রাখে।

— এরউইন ব্র্যান্ডস্টেটার
সূত্র

আমি এরউইনের স্থানীয় ওয়ার্ক মেমের পরামর্শটি দ্বিতীয় করতে চাই। যেহেতু work_mem বিভিন্ন ধরণের ক্যোয়ারী দ্রুতগতিতে পরিবর্তন করে তাই আপনার কিছু প্রশ্নের জন্য এটি পরিবর্তন করতে হবে। অর্থাত্ কম কর্ম_মেম স্তরগুলি কোয়ালিটির জন্য সবচেয়ে ভাল যা জটিল পদ্ধতিতে ছোট সংখ্যক রেকর্ডকে क्रमবদ্ধ করে (যেমন প্রচুর যোগ দেয়) যখন হাই ওয়ার্ক_মীম স্তরগুলি বেশ কয়েকটি ধরণের থাকে তবে যা বাছাই করে বা এক সাথে সংখ্যক সারিগুলিতে একসাথে যোগদান করে ।

— ক্রিস ট্র্যাভারগুলি

আমি এর মধ্যে কোয়েরিটির উন্নতি করেছি (প্রশ্নটি গত বছরের অক্টোবর থেকে) তবে ধন্যবাদ :) বিশেষ প্রশ্নের তুলনায় অপ্রত্যাশিত প্রভাব সম্পর্কে এই প্রশ্নটি আরও বেশি। কোয়েরিটি প্রধানত প্রভাবটি প্রদর্শন করে। সূচকে টিপ দেওয়ার জন্য ধন্যবাদ, আমি চেষ্টা করব!

— পেটর প্রাস 20