अपडेट (सॉफ्टवेयर और हार्डवेयर) से भारी I / O के लिए डेटाबेस का अनुकूलन कैसे करें


20

स्थिति मैं एक postgresql 9.2 डेटाबेस है जो हर समय काफी भारी अद्यतन किया जाता है। प्रणाली इसलिए I / O बाध्य है, और मैं वर्तमान में एक और उन्नयन करने पर विचार कर रहा हूं, मुझे अभी कुछ दिशाओं की आवश्यकता है जहां सुधार शुरू करना है।

यहाँ एक तस्वीर है कि स्थिति पिछले 3 महीनों में कैसी दिख रही है:

यहां छवि विवरण दर्ज करें

जैसा कि आप देख सकते हैं, अधिकांश डिस्क उपयोग के लिए ऑपरेशन खातों को अपडेट करते हैं। यहां एक और तस्वीर है कि स्थिति अधिक विस्तृत 3 घंटे की खिड़की में कैसे दिखती है:

यहां छवि विवरण दर्ज करें

जैसा कि आप देख सकते हैं, चोटी लिखने की दर लगभग 20 एमबी / एस है

सॉफ़्टवेयर सर्वर ubuntu 12.04 और postgresql 9.2 चला रहा है। अपडेट के प्रकार आमतौर पर आईडी द्वारा पहचान की गई व्यक्तिगत पंक्तियों पर छोटे अपडेट किए जाते हैं। जैसे UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id। मैंने जितना संभव हो सके अनुक्रमणिका को हटा दिया है और अनुकूलित कर लिया है, और सर्वर कॉन्फ़िगरेशन (दोनों लिनक्स कर्नेल और पोस्ट को कॉन्फ़िगर करता है) बहुत अच्छी तरह से अनुकूलित है।

हार्डवेयर हार्डवेयर एक समर्पित सर्वर है जिसमें 32GB ECC ram, 4x 600GB 15.000 rpm SAS एक RAID 10 सरणी में है, जिसे BBU और Intel Xeon E3-1245 Quadcore प्रोसेसर के साथ LSI छाप नियंत्रक द्वारा नियंत्रित किया जाता है।

प्रशन

  • क्या इस कैलिबर की एक प्रणाली के लिए ग्राफ द्वारा देखा गया प्रदर्शन उचित है (पढ़ें / लिखते हैं)?
  • इसलिए मुझे एक हार्डवेयर अपग्रेड करने पर ध्यान केंद्रित करना चाहिए या सॉफ्टवेयर में गहराई से जांच करनी चाहिए (कर्नेल ट्विकिंग, कॉन्फ, क्वेरी इत्यादि)?
  • यदि हार्डवेयर अपग्रेड करते हैं, तो डिस्क की संख्या प्रदर्शन के लिए महत्वपूर्ण है?

------------------------------अपडेट करें------------------- ----------------

मैंने अब अपने डेटाबेस सर्वर को पुराने 15k एसएएस डिस्क के बजाय चार इंटेल 520 एसएसडी के साथ अपग्रेड किया है। मैं एक ही छापे नियंत्रक का उपयोग कर रहा हूँ। चीजों में काफी सुधार हुआ है, जैसा कि आप निम्न चोटी से देख सकते हैं I / O प्रदर्शन में लगभग 6-10 बार सुधार हुआ है - और यह बहुत अच्छा है! यहां छवि विवरण दर्ज करें हालाँकि, मैं उत्तर के अनुसार 20-50 गुना सुधार की उम्मीद कर रहा था और नए SSDs की I / O क्षमताओं के अनुसार। तो यहाँ एक और सवाल है।

नया प्रश्न क्या मेरे मौजूदा विन्यास में कुछ है, जो मेरे सिस्टम के आई / ओ प्रदर्शन (जहां अड़चन है) को सीमित कर रहा है?

मेरे विन्यास:

/etc/postgresql/9.2/main/postgresql.conf

data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p postgres@192.168.0.2:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400 

/etc/sysctl.conf

# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000

/etc/sysctl.d/30-postgresql-shm.conf

# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuning

का आउटपुट MegaCli64 -LDInfo -LAll -aAll

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 446.125 GB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 446.125 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives per span:2
Span Depth          : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Is VD Cached: No

(1)। यदि स्तंभों को अनुक्रमित नहीं किया जाता है, तो आप HOT का लाभ उठा सकते हैं (देखें git.postgresql.org/gitweb/?p=postgresql.git=a=blob=f=rc/… )। (2)। Postgresql.org/docs/9.2/static/wal-async-itmit.htmlsynchronous_commit = off पर डॉक्स पढ़ने के बाद प्रयास करें । (3)। आपका कॉन्फ़िगरेशन कैसा दिखता है? उदाहरण के लिए। इस क्वेरी के परिणाम:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');
bma

@bma मुझे इस बारे में चेतावनी देता है synchronous_commit: 'अतुल्यकालिक प्रतिबद्ध एक विकल्प है जो लेनदेन को और अधिक तेज़ी से पूरा करने की अनुमति देता है, इस कीमत पर कि हाल ही में लेन-देन खो सकता है यदि डेटाबेस क्रैश हो जाए।'
dezso

@ मेरे द्वारा बताए गए डॉक्स के अनुभाग के बारे में मुझे अधिक स्पष्ट होना चाहिए था। स्पष्टीकरण के लिए धन्यवाद। मैंने जो कारण सामने लाए, वह इसलिए था क्योंकि उच्च लोड के तहत हमारा एक सर्वर (हाइबरनेट का उपयोग कर रहा था) पीड़ित था इसलिए मैंने एसिंक्स कमिट पर स्विच करने के लिए एक सूचित निर्णय लिया और लोड का 40% लगभग गायब हो गया। अधिकांश प्रणालियों के लिए अनुशंसित नहीं है, लेकिन कुछ मामलों में यह आपको सर्वर अपग्रेड और एप्लिकेशन परिवर्तन के बीच का समय दे सकता है।
बामा

जवाबों:


10

यदि हार्डवेयर अपग्रेड करते हैं, तो डिस्क की संख्या प्रदर्शन के लिए महत्वपूर्ण है?

हां, एक कठिन डिस्क के रूप में - यहां तक ​​कि एसएएस - एक सिर है जिसे स्थानांतरित करने के लिए समय लगता है।

एक उन्नयन चाहते हैं?

एसएएस डिस्क को मारें, एसएटीए पर जाएं। SATA SSD में प्लग इन करें - एंटरप्राइज़ स्तर, जैसे सैमसंग 843T।

परिणाम? आप प्रति ड्राइव लगभग 60.000 (यानी 60 हजार) IOPS कर सकते हैं।

यही कारण है कि एसएसडी डीबी अंतरिक्ष में हत्यारे हैं और एसएएस ड्राइव की तुलना में बहुत सस्ता है। Phyiscal कताई डिस्क बस IOPS क्षमताओं की डिस्क के साथ नहीं रख सकती।

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

सॉफ्टवेयर / कर्नेल के बारे में। कोई भी सभ्य डेटाबेस बहुत सारे IOPS करेगा और बफ़र्स को फ्लश करेगा। गारंटी के लिए मूलभूत ACID शर्तों के लिए TH लॉग फ़ाइल की आवश्यकता है। केवल कर्नेल धुन जो आप कर सकते थे, वह आपकी व्यवहारिक अखंडता को अमान्य कर देगा - आंशिक रूप से आप इससे दूर हो सकते हैं। Back back लिखने में RAID कंट्रोलर ऐसा करेगा - लिखने की पुष्टि करें कि फ्लश किया हुआ है भले ही वह न हो - लेकिन यह ऐसा कर सकता है क्योंकि BBU को उस दिन को सुरक्षित करने के लिए माना जाता है जब बिजली विफल हो जाती है। आप कर्नेल में जो कुछ भी करते हैं - बेहतर जानते हैं कि आप नकारात्मक दुष्प्रभावों के साथ रह सकते हैं।

अंत में, डेटाबेस को IOPS की आवश्यकता होती है, और आप यह देखकर आश्चर्यचकित हो सकते हैं कि आपका सेटअप यहां कुछ अन्य लोगों की तुलना में कितना छोटा है। मैंने 100+ डिस्क्स के साथ डेटाबस को सिर्फ IOPS प्राप्त करने के लिए देखा है जिसकी उन्हें आवश्यकता है। लेकिन वास्तव में, आज, आप एसएसडी खरीदते हैं और उन पर आकार के लिए जाते हैं - वे IOPS क्षमताओं में बहुत बेहतर हैं, इस खेल को एसएएस ड्राइव के साथ लड़ने का कोई मतलब नहीं है।

और हाँ, आपके IOPS नंबर हार्डवेयर के लिए बुरे नहीं लगते हैं। जो मैं उम्मीद करूंगा।


6

यदि आप इसे बर्दाश्त कर सकते हैं, तो बैटरी-समर्थित रैम के साथ अपने स्वयं के नियंत्रक पर एक अलग RAID 1 ड्राइव पर pg_xlog को राइट-बैक के लिए कॉन्फ़िगर किया गया है। यह तब भी सच है जब आपको SSD पर बाकी सब कुछ pg_xlog के लिए कताई जंग का उपयोग करने की आवश्यकता होती है।

यदि आप SSD का उपयोग करते हैं, तो सुनिश्चित करें कि इसमें सुपर-कैपेसिटर या अन्य साधन हैं जो बिजली की विफलता पर सभी कैश्ड डेटा को बनाए रखने के लिए हैं।

सामान्य तौर पर, अधिक स्पिंडल का मतलब अधिक I / O बैंडविड्थ है।


दुर्भाग्य से मैं छापे नियंत्रक में केवल चार hdd स्लॉट है। यदि आप अन्य सभी डिस्क SSD के थे, तो आप pg_xlogs को एक अलग सरणी में क्यों रखेंगे?
नील्स क्रिस्टियन

2
@NielsKristian मुझे लगता है कि मैं सही हूं जब मैं कहता हूं कि अधिकांश प्रणालियों में डिस्क पर सबसे अधिक लिखित रूप में लेन-देन लॉग होता है। इसके अलावा, यह लिखना मूल रूप से डेटा लिखने के साथ समानांतर होता है। दोनों एक ही समय में एचडीडी के साथ नहीं किया जा सकता है क्योंकि सिर या तो pg_xlog पर या डेटा फ़ोल्डरों पर है। (गंभीर सरलीकरण चेतावनी!) दो कार्यों को अलग करना दो स्वतंत्र डिस्क / सरणियों पर IO बोझ को विभाजित करता है।
dezso

2
@Dezso ने जो कहा, इसके अलावा, हार्ड ड्राइव वाल के लिए समर्पित भंडारण के लिए ठीक है क्योंकि एक्सेस लगभग पूरी तरह से अनुक्रमिक है, इसलिए समय कम से कम चाहिए ..
kgrittn

1

यह मानकर कि आप लिनक्स पर चल रहे हैं, डिस्क IO शेड्यूलर सेट करना सुनिश्चित करें।

पिछले अनुभव से, नोएप पर स्विच करने से आपको काफी गति मिलेगी (विशेषकर एसएसडी के लिए)।

IO अनुसूचक को बिना किसी डाउनटाइम के साथ फ्लाई पर किया जा सकता है।

अर्थात। echo noop> / sys / block // queue / अनुसूचक

अधिक जानकारी के लिए देखें: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.