2009-06-01 16 views
10

मेरे पास 25 एम पंक्तियों, ~ 3K प्रत्येक (यानी ~ 75 जीबी) के साथ एक डीबी तालिका है, जो कि मैं एकाधिक इंडेक्स का उपयोग करता हूं (एक अतिरिक्त 15-20 जीबी) पूरी तरह से स्मृति में फिट (मशीन पर 64 जीबी)। एक सामान्य क्वेरी इंडेक्स के माध्यम से 300 पंक्तियों को रेखांकित करती है, वैकल्पिक रूप से उन्हें अन्य इंडेक्स का उपयोग करके ~ 50-300 पंक्तियों तक फ़िल्टर करती है, अंत में मिलान पंक्तियों को लाती है। ठंड डीबी पर 20 सेकंड के बीच गर्म डीबी पर प्रतिक्रिया समय 20 सेकंड के बीच भिन्न होता है। मेरे पास दो संबंधित प्रश्न हैं:पोस्टग्रेस्क्ल कैश (मेमोरी) प्रदर्शन + कैश को गर्म करने के लिए कैसे करें

  1. किसी भी समय मैं कैसे जांच सकता हूं कि विशिष्ट तालिकाओं और इंडेक्स का कौन सा हिस्सा (%) स्मृति में कैश किया गया है?

  2. प्रश्नों के लिए डीबी खोलने से पहले कैश को गर्म करने का सबसे अच्छा तरीका क्या है? जैसे "चयन करें *" अनुक्रमिक स्कैन को बल देता है (~ ठंडा डीबी पर ~ 15 मिनट) लेकिन इसके बाद प्रतिक्रिया समय अभी भी खराब हैं। वहाँ एक अंतर्निहित तरीका बजाय यह करने के लिए प्रश्नों के माध्यम से है एक

धन्यवाद, ईमेल द्वारा भी बेझिझक उत्तर ([email protected]])

- शाऊल

उत्तर

1

विज्ञापन। 1 - मेरे पास बिल्कुल कोई विचारधारा नहीं है।

विज्ञापन। 2 - आप केवल कुछ प्रश्नों को यादृच्छिक रूप से क्यों नहीं चुनते हैं जिन्हें आप जानते हैं कि महत्वपूर्ण हैं, और उन्हें ठंडे सर्वर पर चलाएं? जितना अधिक प्रश्न आप चलाएंगे, बेहतर होगा गर्मजोशी की प्रक्रिया होगी।

2

2) मैं आमतौर पर एक लाइव सिस्टम से प्रश्नों का लॉग और उन्हें पुनः चलाने के द्वारा हल करता हूं। यह डेटा के विशिष्ट हिस्सों को उजागर करता है, न कि उन हिस्सों को जिन्हें अक्सर उपयोग नहीं किया जाता है (जो अन्यथा राम को बर्बाद कर देगा)।

+0

समस्या यह है कि मैं उपयोगकर्ता के प्रश्नों का अनुमान नहीं लगा सकता, "अमेज़ॅन" सोचता हूं - अगले 10000 प्रश्न क्या होंगे? इसलिए मुझे ऐसा कुछ चलाने के लिए पसंद आया जो कैश में विशिष्ट टेबल और इंडेक्स खींचता हो। –

+0

अनुमान मत लगाओ। पिछले 5 मिनट, या पिछले 10'000 प्रश्नों से वास्तविक लॉग लें। मैंने "एक अग्रणी खोज इंजन प्रदाता" पर काम किया है और यह बहुत अच्छा काम करता है। या यदि आपके पास सर्वर हैं जो चल रहे हैं और चल रहे हैं और आप एक नया गर्म करना चाहते हैं तो आप उन सर्वरों को क्वेरी मिरर कर सकते हैं जिन्हें गर्म किया जाना है। – Thomas

3

आपके पहले बिंदु के बारे में, contrib मॉड्यूल "pg_buffercache" आपको बफर कैश की सामग्री का निरीक्षण करने की अनुमति देता है। मैं इस परिभाषित करना चाहते:

create or replace view util.buffercache_hogs as 
select case 
     when pg_buffercache.reldatabase = 0 
      then '- global' 
     when pg_buffercache.reldatabase <> (select pg_database.oid from pg_database where pg_database.datname = current_database()) 
      then '- database ' || quote_literal(pg_database.datname) 
     when pg_namespace.nspname = 'pg_catalog' 
      then '- system catalogues' 
     when pg_class.oid is null and pg_buffercache.relfilenode > 0 
      then '- unknown file ' || pg_buffercache.relfilenode 
     when pg_namespace.nspname = 'pg_toast' and pg_class.relname ~ '^pg_toast_[0-9]+$' 
      then (substring(pg_class.relname, 10)::oid)::regclass || ' TOAST'::text 
     when pg_namespace.nspname = 'pg_toast' and pg_class.relname ~ '^pg_toast_[0-9]+_index$' 
      then ((rtrim(substring(pg_class.relname, 10), '_index'))::oid)::regclass || ' TOAST index' 
     else pg_class.oid::regclass::text 
     end as key, 
     count(*) as buffers, sum(case when pg_buffercache.isdirty then 1 else 0 end) as dirty_buffers, 
     round(count(*)/(SELECT pg_settings.setting FROM pg_settings WHERE pg_settings.name = 'shared_buffers')::numeric, 4) as hog_factor 
from pg_buffercache 
    left join pg_database on pg_database.oid = pg_buffercache.reldatabase 
    left join pg_class on pg_class.relfilenode = pg_buffercache.relfilenode 
    left join pg_namespace on pg_namespace.oid = pg_class.relnamespace 
group by 1 
order by 2 desc; 

इसके अतिरिक्त, "pageinspect" योगदान मॉड्यूल आप एक संबंध से एक विशेष पृष्ठ का उपयोग करने की अनुमति देता है, तो मैं आप बस एक संबंध में सभी पृष्ठों के माध्यम से लूप उन्हें हथियाने सकता है लगता है?

select count(get_raw_page('information_schema.sql_features', n)) 
from generate_series(0, 
     (select relpages-1 from pg_class where relname = 'sql_features')) n; 

यह कैश में information_schema.sql_features सभी लोड करेगा।

0

मेमोरी को गर्म करने की कोशिश न करें, यह पोस्टग्रेस्क्ल और ओएस काम है। विभाजन में टेबल (और अनुक्रमणिका) को विभाजित करें और छोटे डेटा सेट के साथ काम करने का प्रयास करें। यदि आप एक अच्छी विभाजन योजना स्थापित करने के लिए पूरा करते हैं तो विशाल सूचकांक या तालिकाओं में कोई समस्या नहीं है। यदि आप अभी भी टेबल और इंडेक्स को गर्म करना चाहते हैं तो शायद रैम में पूरी तरह से कैश किया जा सकता है क्योंकि पहले से छोटे होते हैं।

+0

मुझे लगता है कि कैश वार्मिंग और विभाजन दो अलग-अलग मुद्दे हैं। विभाजन प्रारंभिक "ठंडा कैश" मुद्दा हल नहीं करता है। यह एक आई/ओ मुद्दा है। – Jan

संबंधित मुद्दे