🧑🏻 😛 🔗 1000+ उपयोगकर्ताओं के साथ 691 जीबी के डेटाबेस के लिए ट्यूनिंग फायरबर्ड और लिनक्स 👩🏼‍🤝‍👨🏾 🎰 ⛑️

फायरबर्ड रूस में एक बहुत लोकप्रिय ओपन डीबीएमएस है, और शोर विपणन अभियानों की अनुपस्थिति के बावजूद, इसका उपयोग बड़ी संख्या में महत्वपूर्ण प्रणालियों में किया जाता है, खासकर चिकित्सा और राज्य स्वचालन प्रणालियों में।

डेटाबेस का आकार और ऐसी प्रणालियों में सक्रिय उपयोगकर्ताओं की संख्या आमतौर पर काफी बड़ी होती है, इसलिए इस लेख में मैं BeZdorov ( Ingosstrakh ), AlfaZdrav पर बड़े Firebird डेटाबेस के विशिष्ट उदाहरणों के आधार पर Firebird और Linux सेटिंग्स को अनुकूलित करने के अनुभव के बारे में बात करूंगा , और मैं अन्य अनुकूलन कंपनियों के अनुभव को छूऊंगा फायरबर्ड + लिनक्स।

आइए अनुकूलन के विषय पर करीब से नज़र डालें - Firebird 3.0.5 DBMS (HQbird एक्सटेंशन के साथ), 1000-1100 दैनिक उपयोगकर्ताओं के साथ 691GB डेटाबेस (वर्तमान में) परोसता है, Linux CentOS 7 पर चलता है, सर्वर HP DL380 लोहे का उपयोग करता है। बैकअप सर्वर के लिए प्रतिकृति डेटाबेस के लिए कॉन्फ़िगर किया गया है (प्रतिकृति का प्रश्न इस लेख के दायरे से बाहर है)।

DBMS चिकित्सा सूचना प्रणाली Infoklinika (रूसी कंपनी स्मार्ट डेल्टा सिस्टम्स द्वारा निर्मित) में कार्य करता है, जो रूस में सबसे लोकप्रिय चिकित्सा सूचना प्रणालियों में से एक है।

आइए इस डेटाबेस के संचालन के विवरण (स्क्रीनशॉट बाद में HQbird से लिए गए हैं) पर एक नज़र डालें:

डेटा को तीव्रता से डेटाबेस में डाला जाता है - दैनिक लाभ लगभग 0.4 - 0.5 जीबी

1000-1100 कनेक्शन सामान्य दैनिक लोड है:

गहन विकास और सक्रिय कार्य के बावजूद, डेटाबेस में रिकॉर्ड के कचरा संस्करणों की कोई महत्वपूर्ण मात्रा शामिल नहीं है - दोनों बहु-संस्करण वास्तुकला के अच्छे ज्ञान के साथ लिखे गए अनुप्रयोगों के लिए धन्यवाद, और ठीक से कॉन्फ़िगर किए गए कचरा संग्रह के कारण:

ग्रीन ज़ोन में लेनदेन मार्कर:

वैसे, ध्यान दें कि डेटाबेस में डेटा स्ट्रिंग है, बूँदें मौजूद हैं, लेकिन उनमें से कुछ हैं - कुल आकार के 690 जीबी में से केवल 10 जीबी।

डेटाबेस लोड की प्रकृति मिश्रित है, 75% रीड ऑपरेशन और 25% लेखन:

लोहा

सर्वर जो इस प्रणाली का कार्य करता है वह खराब नहीं है, लेकिन शीर्ष-छोर से बहुत दूर है:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards

डिस्क सबसिस्टम में दो भाग होते हैं: एक स्थानीय 745 जीबी डिस्क और सैन के लिए एक दोहरी 2 फाइबर-चैनल कनेक्शन, 1.8 टीबी विभाजन के साथ।

ऑपरेटिंग सिस्टम

CentOS 7, कर्नेल संस्करण का उपयोग करना:

 Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019

तार्किक प्रश्न के लिए, सबसे आधुनिक कर्नेल और सेंटोस 8 का उपयोग क्यों नहीं किया जाता है, इसका उत्तर भी तर्कसंगत है - महत्वपूर्ण प्रणालियों का प्रवास कई मामूली रिलीज और कठोर परीक्षण के बाद ही होता है - यह उन मामलों में से एक है जब एक ज्ञात बग दो अज्ञात से बेहतर है।

हालांकि, यह ध्यान दिया जाना चाहिए कि 2017 तक सिस्टम ने CentOS 6.x पर काम किया, और प्रवास के बाद, प्रदर्शन संकेतकों में एक महत्वपूर्ण सुधार नोट किया गया था।

लिनक्स सेटअप

फायरबर्ड के लिए एक बिल्कुल आवश्यक लिनक्स अनुकूलन

सभी लिनक्स सर्वरों पर 2 मापदंडों को बढ़ाया जाना चाहिए जहां फायरबर्ड चलता है - वर्चुअल मेमोरी क्षेत्रों (वीएमए) की संख्या और फायरबर्ड प्रक्रिया के लिए खुली फाइलों की संख्या।

1. वीएमए

डिफ़ॉल्ट VMA संख्या 64K है, इसे 4 बार बढ़ाया जाना चाहिए, इसके लिए, sysctl.conf में लाइन जोड़ें

 vm.max_map_count=262144

वर्तमान मूल्य की जांच करने के लिए, कमांड का उपयोग करें

 sysctl vm.max_map_count

2. मैक्स ओपन फाइल्स

फ़ायरबर्ड डेटाबेस के प्रत्येक कनेक्शन के लिए 20 डिस्क्रिप्टर (फ़ाइल हैंडल) तक खोलता है (इस तथ्य पर विचार करते हुए कि लिनक्स में सभी संसाधन फ़ाइलों की तरह दिखते हैं), इसलिए डिफ़ॉल्ट रूप से खुली फ़ाइलों की अधिकतम संख्या (आमतौर पर 4096) बहुत जल्दी समाप्त हो सकती है।

फायरबर्ड के लिए उपलब्ध फ़ाइलों की संख्या की जांच करने के लिए, फायरबर्ड निष्पादन योग्य फ़ाइल की सीमाओं को देखना सबसे अच्छा है:

 cat /proc/$(pgrep firebird)/limits

जहां मैक्स ओपन फाइलों के लिए मूल्य की जांच करें और यदि आवश्यक हो तो उन्हें बढ़ाएं।

फायरबर्ड के लिए मैक्स ओपन फाइल्स पैरामीटर को बढ़ाने के लिए, हमने [सर्विस] सेक्शन में फायरबर्ड-सुपरसर्वर.स्वर फ़ाइल में लाइन जोड़ी:

 LimitNOFILE=49999

वैकल्पिक लिनक्स सेटअप

इस सर्वर पर, हमने निम्नलिखित सेटिंग्स भी कीं

1. स्वपनदोष कम होना

चूंकि सर्वर विशेष रूप से फायरबर्ड DBMSs के लिए समर्पित है, और हम DBMS कैश और ऑपरेटिंग सिस्टम फ़ाइल कैश के तहत कुशलतापूर्वक RAM का उपयोग करना चाहते हैं, हम स्वेप्टीनेस को डिफ़ॉल्ट 60% से 10% तक कम करते हैं, इसके लिए हमने sysctl.conf को जोड़ा।

 vm.swappiness=10

2. विशेष ओएस प्रक्रियाओं के लिए न्यूनतम आरक्षित स्मृति आकार में वृद्धि

 vm.min_free_kbytes=1048576

यानी 1GB मेमोरी। यह सेटिंग अप्रत्यक्ष रूप से मेमोरी डीफ़्रैग्मेन्टेशन को प्रभावित करती है।

कृपया ध्यान दें कि यह सेटिंग व्यक्तिगत है - यह देखते हुए कि हमारे पास 320GB RAM है, 1GB इतना नहीं है, लेकिन थोड़ी मात्रा में मेमोरी (उदाहरण के लिए, 32GB) के मामले में, 1GB बहुत अधिक हो सकती है।

3. कम रखनेवाला

फायरबर्ड कनेक्शन की स्थिति की जांच करने के लिए रखवाले अंतराल पर निर्भर करता है, और रखवाले का डिफ़ॉल्ट मूल्य बहुत बड़ा हो सकता है। इसे 300 सेकंड तक सीमित करते हुए, हमें हैंगिंग कनेक्शन से छुटकारा मिलता है

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15

अधिक लिनक्स ट्यूनिंग

हम इतनी कम संख्या में लिनक्स सेटिंग्स तक सीमित क्यों हैं?

सबसे पहले, हम लिनक्स के साथ ट्यूनिंग सर्वर के लिए एक रूढ़िवादी दृष्टिकोण लेते हैं (जो प्रत्येक नए संस्करण के साथ बेहतर और बेहतर हो रहा है), और दूसरी बात, यह फायरबर्ड डेटाबेस न तो बहुत बड़ा है और न ही सबसे भरा हुआ है, और लिनक्स निर्दिष्ट सेटिंग्स के साथ मुकाबला करता है। अपने कार्यों के साथ।

बेशक, कई और सेटिंग्स हैं जिनका उपयोग लिनक्स पर फायरबर्ड को अनुकूलित करने के लिए किया जा सकता है - उदाहरण के लिए, संघीय बेलीफ सेवा में 3 टीबी फायरबर्ड डेटाबेस (रेडबजा) के बारे में प्रस्तुति में कई दिलचस्प चीजें प्रस्तुत की गईं।

फायरबर्ड को कॉन्फ़िगर करें

Firebirdsql.org के साथ Firebird समुदाय की कॉन्फ़िगरेशन फ़ाइलें बहुत ही रूढ़िवादी रूप से कॉन्फ़िगर की गई हैं, और अधिक या कम शक्तिशाली सर्वर पर आपको कॉन्फ़िगरेशन फ़ाइलों को बदलने और सावधानीपूर्वक उपयोग की गई आर्किटेक्चर का चयन करने की आवश्यकता है (Firebird 3.0 में 2 प्रकार के कनेक्शन हैं - एंबेडेड और नेटवर्क सेवर, और 3 प्रकार के आर्किटेक्चर: SuperServer , सुपरक्लासिक, क्लासिक)।
इसके अलावा, आपको प्रत्येक डेटाबेस के लिए सेटिंग्स का उपयोग करना होगा - अर्थात किसी विशिष्ट डेटाबेस के संदर्भ में, डेटाबेस में महत्वपूर्ण सेटिंग्स रखें।

हमारे मामले में, हमने संस्करण 3.0 में सबसे लोकप्रिय सुपरसर्वर वास्तुकला को चुना, क्योंकि यह कुशलतापूर्वक मल्टी-कोर प्रोसेसर का उपयोग करता है और सभी कनेक्शनों के लिए एक कैश साझा किया जाता है (लेकिन प्रत्येक डेटाबेस के लिए अलग)।

विन्यास फाइल निम्नलिखित हैं (केवल प्रदर्शन से संबंधित मूल्य):

firebird.conf - सर्वर पर सभी डेटाबेस के लिए कॉन्फ़िगरेशन फ़ाइल

 DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries

प्रदर्शन के संदर्भ में, यहां प्रमुख पैरामीटर हैं:

1. DefaultDbCachePages = 50K # इसे पृष्ठों में, DB पर, पृष्ठ 16K = 0.8G में मापा जाता है

DefaultDbCachePages पेज कैश का आकार firebird.conf में विशेष रूप से डिफ़ॉल्ट रूप से 800Mb पर सेट किया गया है ताकि सर्वर पर गलती से परीक्षण किया गया डेटाबेस बड़ी मात्रा में रैम लेने की कोशिश न करे।

2. FileSystemCacheThreshold = 300K # पृष्ठ

OS फ़ाइल कैश का उपयोग सक्षम करने के लिए इस पैरामीटर को DefaultDBCachePages से अधिक मूल्य पर सेट करना महत्वपूर्ण है।

3. TempCacheLimit = 20480M # बाइट्स

यह पैरामीटर क्वेरीज़ (और कुछ अन्य ऑपरेशंस) के साथ मेमोरी साइज़ सेट करता है, और प्रत्येक सिस्टम के लिए अलग-अलग होता है।
प्रकार के आकार की निगरानी के परिणामस्वरूप, हमने पाया कि 20GB इस डेटाबेस के लिए इष्टतम है।

4. LockMemSize और LockHashSlots - लॉक टेबल के पैरामीटर

ये पैरामीटर हैश फ़ंक्शन की गणना के लिए लॉक टेबल के प्रारंभिक आकार और स्लॉट की संख्या निर्धारित करते हैं।

5. वायरकॉमप्रेशन = सच

क्लाइंट और सर्वर के बीच यातायात को संपीड़ित करता है, यह विशेष रूप से एक्सटेंसिव स्टेटमेंट ऑन एक्सटर्नल के साथ उपयोगी है, जो क्लाइंट एप्लिकेशन को चलाता है।

शेष पैरामीटर फायरबर्ड.कॉन्फ और फायरबर्ड और मुख्यालयबर्ड के संबंधित प्रलेखन में वर्णित हैं।

हमने डेटाबेस में सबसे महत्वपूर्ण सेटिंग की है। सटीक डेटाबेस के साथ ।conf

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M }

जैसा कि आप अनुमान लगा सकते हैं, इस मामले में मुख्य कठिनाई यह है कि हमारे बड़े डेटाबेस द्वारा आवंटित स्मृति के आकार की सही गणना कैसे करें।

SuperServer आर्किटेक्चर के साथ Firebird 3.0 के लिए, दो दृष्टिकोण हैं - रूढ़िवादी, जिसका उपयोग सर्वर पर RAM की थोड़ी मात्रा (32GB तक समावेशी) के साथ किया जाता है, जिसमें पेज कैश के लिए 25% से अधिक RAM आवंटित करने में शामिल नहीं है, और बाकी फ़ाइल ऑपरेटिंग सिस्टम पर निर्भर करते हैं सिस्टम, और ठीक-ट्यूनिंग, जब हम ठीक प्रकार के लिए इष्टतम आकार निर्धारित करते हैं, तो ओएस कर्नेल के लिए एक निश्चित मेमोरी आकार आवंटित करते हैं, बड़े पैमाने पर फ़ाइल संचालन (उदाहरण के लिए, बैकअप) के लिए एक निश्चित मात्रा में मेमोरी आरक्षित करते हैं। शेष पेज कैश के लिए आवंटित।

दूसरे मामले में, तुरंत इष्टतम कैश आकार प्राप्त करना संभव नहीं है, क्योंकि लोड की प्रकृति विभिन्न प्रकार के डेटाबेस के लिए बहुत भिन्न हो सकती है, लेकिन कई पुनरावृत्तियों के बाद आप एक उत्कृष्ट परिणाम प्राप्त कर सकते हैं।

फायरबर्ड को कॉन्फ़िगर करने में सामान्य गलतियाँ

विशिष्ट त्रुटियों में निम्नलिखित शामिल हैं:

1) डीबी हेडर पेज पर पृष्ठ कैश का आकार स्पष्ट रूप से निर्दिष्ट किया गया है, जो फायरबर्ड.कॉन्फ़ और डेटाबेस में निर्दिष्ट मूल्यों से अधिक है।

विशेष रूप से अक्सर यह त्रुटि तब होती है जब आर्किटेक्चर को क्लासिक / सुपरक्लासिक से सुपरसर्वर में बदलते समय - यदि क्लासिक / सुपरक्लासिक कनेक्शन के लिए कैश आकार स्पष्ट रूप से संकेतित छोटे (500-2000 पृष्ठों) आकार के साथ ठीक काम करता है, तो सुपरसेवर के लिए बहुत बड़े कैश की आवश्यकता होती है।
जाँच करने के लिए, कमांड चलाएँ

 gstat -h databasepathname

और Page Buffers मान की जाँच करें - यह 0 होना चाहिए, फिर Firebird डेटाबेस से मूल्यों का उपयोग करेगा ।conf या firebird .conf।

शीर्ष लेख पृष्ठ पर पृष्ठ कैश सेटिंग को रीसेट करने के लिए, कमांड चलाएं

 gfix -buff 0 databasepathname

2) पेज कैश बढ़ाते समय, वे FileSystemCacheThreshold को बढ़ाना भूल जाते हैं, जिससे फ़ाइल कैश का डिस्कनेक्ट हो जाता है, जिससे प्रदर्शन कम हो जाता है।

3) डिफ़ॉल्ट डेटाबेस पृष्ठ आकार (4096 या 8192) का उपयोग करते हुए, जबकि बड़े डेटाबेस के लिए आपको 16K का उपयोग करने की आवश्यकता होती है।

निष्कर्ष

सामान्य तौर पर, आयरन पर 1000+ फायरबर्ड उपयोगकर्ता, लिनक्स द्वारा लोड और फायरबर्ड द्वारा कॉन्फ़िगर किए गए लोड के अनुसार, समस्याओं के बिना काम करते हैं। प्रदर्शन के संदर्भ में इस सर्वर पर एक मार्जिन है, जिसे 1500-1800 उपयोगकर्ताओं के लिए चरम भार पर परीक्षण किया गया था।

समान लोड के साथ फायरबर्ड डेटाबेस के लिए लिनक्स वितरण में, सबसे लोकप्रिय CentOS 7 है, अनुशंसित संस्करण फायरबर्ड 3.0 है।

यदि आपके कोई प्रश्न हैं, तो मुझे टिप्पणियों में या ईमेल ak@ibase.ru पर उत्तर देने में खुशी होगी।

1000+ उपयोगकर्ताओं के साथ 691 जीबी के डेटाबेस के लिए ट्यूनिंग फायरबर्ड और लिनक्स