10

मेरे पास एक Ubuntu 16.04 बैकअप सर्वर है जिसमें 8x10TB HDD के साथ SATA 3.0 बैकप्लेन है। 8 हार्डडिस्क एक RAID6 के लिए इकट्ठे किए गए हैं, एक EXT4 फाइलसिस्टम उपयोग में है। यह फाइलसिस्टम बहुत सी सेक संचालन के साथ छोटी फाइलों की एक बड़ी मात्रा को संग्रहीत करता है, लेकिन कम आईओ थ्रूपुट। वास्तव में, विभिन्न सर्वरों से कई छोटी फाइलें होती हैं जो हर दिन rsnapshot के माध्यम से स्नैपडॉट हो जाती हैं (एक ही फाइल के लिए कई INODES)। फ़ाइल सिस्टम (60TB नेट) 50% उपयोग से अधिक होने के बाद से मेरा बहुत खराब प्रदर्शन है। उपयोग 75% और ए पर है

du -sch /backup-root/

कई दिन (!) लगते हैं। मशीन में 8 करोड़ और 16G RAM है। RAM पूरी तरह से OS Filesystem Cache द्वारा उपयोग किया जाता है, 8 में से 7 कोर हमेशा IOWAIT की वजह से निष्क्रिय हो जाते हैं।

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

मुझे इस तरह के फाइल सिस्टम उपयोग के साथ अनुभव की कमी है। मेरे पास इसके लिए क्या विकल्प हैं। इस परिदृश्य के साथ फाइलसिस्टम क्या बेहतर प्रदर्शन करेगा? क्या ओएस-बिल्ड-इन की तुलना में अन्य कैशिंग विकल्पों के लिए रैम को शामिल करने का कोई विकल्प है?

बड़ी RAID असेंबली पर आप बहुत बड़ी मात्रा में छोटी फ़ाइलों को कैसे संभालते हैं?

धन्यवाद, सेबस्टियन

ubuntu-16.04 ext4 performance-tuning

— t2m
स्रोत

2

तेजी से डिस्क, अधिमानतः एसएसडी। पढ़ने के लिए जितना संभव हो उतना रैम कैशिंग। 16GiB पर्याप्त RAM के समान ग्रह में भी नहीं है। बहुत सारे, यहां तक कि 512GBB या उससे अधिक के बहुत सारे प्राप्त करें। और निश्चित रूप से उपयोग नहीं करते RAID 6.

— माइकल हैम्पटन

आपके जवाब के लिए धन्यवाद। मुझे एसएसडी विकल्प के बारे में पता है, लेकिन यह एक 7000 $ सर्वर या 70000 $ सर्वर के बीच अंतर का समर्थन करता है। RAM संकेत एक अच्छा है, लेकिन मुझे डर है कि मैं केवल कुंवारी जैसी फाइलसिस्टम प्रदर्शन प्राप्त करूंगा यदि मैं पूरी तरह से SEEK संचालन के लिए DISK IO से बचता हूं जिसका अर्थ है 60TB नेट। क्षमता एक 60TB RAM कैश, है ना? मैंने अतीत में EXT2 / 3/4 की तुलना में अन्य फाइल सिस्टम से परहेज किया, लेकिन अब मैं इस दिशा में विकल्पों के लिए पूरी तरह से खुला हूं, अगर वे मदद करेंगे। :)

— t2m

इस डिस्क कॉन्फ़िगरेशन में RAID6 प्रतिस्थापन के लिए आपकी क्या सिफारिश है?

— t2m

1

"वास्तव में विभिन्न सर्वरों से कई छोटी फाइलें होती हैं जो हर दिन rsnapshot के माध्यम से स्नैपडॉट हो जाती हैं (एक ही फाइल में कई INODES निर्देशित होती हैं।" - मुझे लगता है कि आप एक ही इनोड में कई लिंक / नाम का अर्थ लगाते हैं । जब किसी फाइल को हार्ड-लिंक करना होता है, तो वहाँ होता है। केवल एक इनोड, लेकिन दो (या अधिक) लिंक / नाम।

— मार्सेलम

1

यार, अगर वह 7000 USD का सर्वर है तो STOP GETTING RIPPED OFF। और PCIe SSD में 1000 USD को सर्वर में जोड़ने से कोई जादुई रूप से इसे 70k SSD सर्वर नहीं बना देगा।

— टॉम टॉम

11

मेरे पास एक समान (यद्यपि छोटा) सेटअप है, एक RAID6 सरणी में 12x 2TB डिस्क के साथ, बहुत ही उद्देश्य ( rsnapshotबैकअप सर्वर) के लिए उपयोग किया जाता है ।

पहला, du -hsइतने बड़े और इस्तेमाल किए गए, फाइल सिस्टम पर इतना समय लगना पूरी तरह से सामान्य है । इसके अलावा duहार्डलिंक के लिए खाते हैं, जो स्पष्ट IO लोड के अलावा काफी और बर्फीले सीपीयू लोड का कारण बनते हैं।

आपकी सुस्ती फ़ाइलस्टैट मेटाडेटा बहुत दूर (एलबीए के संदर्भ में) ब्लॉकों में स्थित होने के कारण है, जिससे बहुत सी तलाश होती है। एक सामान्य 7.2K RPM डिस्क के बारे में ~ 100 IOPS प्रदान करता है, आप देख सकते हैं कि सभी मेटाडेटा को लोड करने के लिए घंटों, यदि दिन नहीं, तो कैसे की आवश्यकता होती है।

कुछ आप (गैर-विनाशकारी रूप से) स्थिति को सुधारने की कोशिश कर सकते हैं:

अपने अनुक्रमणिका नहीं होने के लिए सुनिश्चित हो (आप उस से बचने के लिए prunefs सुविधा का उपयोग कर सकते हैं ), या मेटाडेटा कैश ट्रैशिंग आपके बैकअप समय को गंभीर रूप से बिगाड़ देगा;mlocate/slocate/backup-root/
उसी कारण से, duपर चलने से बचें /backup-root/। यदि आवश्यक हो, तो duकेवल विशिष्ट उप-फ़ोल्डर में रुचि रखते हुए चलाएं ;
कम vfs_cache_pressureअधिक रूढ़िवादी एक (10 या 20) को डिफ़ॉल्ट मान (100) से। यह कर्नेल को मेटाडेटा कैशिंग पसंद करेगा, बजाय डेटा कैशिंग के; बदले में, rsnapshot/rsyncखोज चरण को गति देना चाहिए ;
उदाहरण के लिए lvmcache या bcache के माध्यम से आप एक राइटथेट मेटाडेटा कैशिंग डिवाइस को जोड़ने का प्रयास कर सकते हैं । यह मेटाडेटा डिवाइस स्पष्ट रूप से एक एसएसडी होना चाहिए;
अपनी उपलब्ध रैम को बढ़ाएं।
जैसा कि आप ext4 का उपयोग कर रहे हैं, इनोड आवंटन मुद्दों से अवगत रहें ( एक उदाहरण के लिए यहां पढ़ें )। यह सीधे प्रदर्शन के लिए सहसंबद्ध नहीं है, लेकिन यह एक महत्वपूर्ण कारक है जब एक पूर्व-आधारित फाइल सिस्टम पर इतनी सारी फाइलें होती हैं।

अन्य चीजें जो आप आजमा सकते हैं - लेकिन ये विनाशकारी संचालन हैं:

दोनों -ftypeऔर -finobtविकल्प सेट के साथ XFS का उपयोग करें ;
लिनक्स पर ZFS का उपयोग करें (संपीड़ित ARC और primarycache=metadataसेटिंग के साथ ZoL) (और, शायद, केवल पढ़ने के लिए कैश के लिए एक L2ARC)।

— shodanshok
स्रोत

इस उत्तर के लिए बहुत बहुत धन्यवाद। जैसा कि आप उम्मीद कर सकते हैं, मुझे अब पढ़ने के लिए कुछ मिला है। Vfs_cache_pressure विकल्प बहुत दिलचस्प है। मैंने अब कुछ मिनटों के लिए कैश के साथ खेला है और मुझे लगता है, सिस्टम थोड़ा अधिक संवेदनशील हो गया (निर्देशिका लिस्टिंग, स्वतः पूर्ण, आदि ..)। मैं अन्य बिंदुओं की भी जांच करूंगा और प्रतिक्रिया दूंगा। एक बार फिर धन्यवाद।

— t2m

"प्राथमिक कैश = मेटाडेटा सेटिंग (और, शायद, केवल पढ़ने के लिए कैश के लिए एक L2ARC)।" ZFS दोनों नहीं कर सकता, मेरे पास इसके सबसे प्रमुख पक्षों में एक राइट अप था: medium.com/p/zfs-is-raid5-of-2010s-eefaeeea2396

— poige

@ राम की मात्रा कम होने के कारण, मैं L2ARC में मेटाडेटा कैशिंग के बारे में बोल रहा था (एआरसी में पहले से ही कैश्ड के अलावा)। आखिरकार, डेटा कैशिंग को rsnapshotबैकअप सर्वर के लिए कोई बड़ा अंतर नहीं होना चाहिए ।

— षोडशशोक

1

मैंने स्पष्ट किया कि L2ARC में एकमात्र चीज मेटाडेटा होगी, फिर कोई बात नहीं। :) RAM राशि के अनुसार, 16 GB उस HDD समग्र आयतन के लिए बिल्कुल भी रैम नहीं है। उचित न्यूनतम 128 जीबी के आसपास होगा, इसलिए यदि यह किसी भी तरह से अपग्रेड कर रहा है, तो आप अब 16 जीबी तक सीमित नहीं होंगे

— poige

@marcelm आप सही हैं: मैं -hपूरी तरह से अलग चीजों ( ... के लिए) के -Hलिए भ्रमित हूं rsync। मैंने अपना उत्तर अपडेट कर दिया।

— शोडान्शोक

6

यह फाइलसिस्टम बहुत सी सेक संचालन के साथ छोटी फाइलों की एक बड़ी मात्रा को संग्रहीत करता है, लेकिन कम आईओ थ्रूपुट।

🎉

यह वह चीज है जो आजकल बहुत से लोग पकड़ते हैं। काश, पारंपरिक FSes यहाँ किसी भी पैमाने पर नहीं है। जब आप सेट-अप की बात आती है, तो मैं आपको शायद कुछ सलाह दे सकता हूं: HDTs पर RAID-6 पर EXT4 :

लोअर vm.vfs_cache_pressureनीचे, 1. करने के लिए कहते हैं कि यह चाहते हैं पूर्वाग्रह cacheing बदल ही डेटा के बजाय अधिक मेटाडाटा (inode, dentry) संरक्षण की दिशा में है और यह संख्या को कम करने का प्रयास है की में सकारात्मक प्रभाव होना चाहिए
अधिक RAM जोड़ें । यद्यपि यह एक ऐसे सर्वर के लिए अजीब लग सकता है जो किसी भी गुल्लक को नहीं चलाता है, याद रखें: तलाश को कम करने का एकमात्र तरीका अधिक मेटाडेटा को तेज भंडारण में रखना है, यह देखते हुए कि आपके पास 16 जीबी है केवल ऐसा लगता है कि यह अपेक्षाकृत आसान होना चाहिए RAM की मात्रा बढ़ाएं
जैसा कि मैंने कहा है कि EXT4 आपके पास उपयोग के मामले के लिए अच्छा विकल्प नहीं है, लेकिन फिर भी आप कुछ विशेषताओं का उपयोग कर सकते हैं जो दर्द को शांत करने के लिए होती हैं:
- बाहरी पत्रिका का समर्थन किया जाता है ताकि आप SSD (बेहतर प्रतिबिंबित) को जोड़ने की कोशिश कर सकें और पत्रिका को वहां रख सकें। " Ext4: बाहरी जर्नल केवेट " देखें
- स्विच करने का प्रयास पत्रिका मोड करने के लिए "सभी डेटा जा रहा है जर्नल 'के साथ बढ़तेdata=journal
एकल FS दायरे से बाहर की फ़ाइलों को स्थानांतरित करने का प्रयास करें । उदाहरण के लिए, यदि आपके पास LVM-2 है, तो आप कम आकार के वॉल्यूम बना सकते हैं और कुछ समय के लिए उनका उपयोग कर सकते हैं, फिर जब यह पूर्ण हो जाता है, तो एक और एक बनाएं।
- यदि आपके पास LVM-2 नहीं है, तो आप ऐसा करने की कोशिश कर सकते हैं / dev / loop के साथ लेकिन यह उतना सुविधाजनक नहीं है और शायद कम परफॉर्मेंट भी

युपीडी। : चूंकि यह लिनक्स सॉफ्टवेयर RAID (LSR) RAID-6 है, यहाँ अतिरिक्त आइटम जाता है:

एलएसआर के पास स्वयं के ट्यूनिंग विकल्प हैं जो बहुत से लोग अनदेखी करने लगते हैं
- स्ट्राइप कैश , जिसे इस प्रकार अधिकतम सेट किया जा सकता है: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- लेकिन इसे सावधानी से करें (यदि आवश्यक हो तो कम मूल्य का उपयोग करें) क्योंकि आकार चंक-साइज़ मल्टीपल है और आपके द्वारा चुने गए चंक साइज़ के आधार पर यह रैम की अलग-अलग राशि लेगा।
- बाहरी पत्रिका जो उन पर भी दिखाई जा सकती है SSD ( लेकिन वर्तमान में एमडी डिवाइस w / o जर्नल बनाया गया है उसे एक का उपयोग करने के लिए परिवर्तित नहीं किया जा सकता है )।

- शायद यही है कि स्क्रे री-डिज़ाइन से w / o में क्या सुधार किया जा सकता है।

फ़ाइल सिस्टम (60TB नेट) 50% उपयोग से अधिक होने के बाद से मेरा प्रदर्शन बहुत खराब है। फिलहाल, उपयोग 75% पर है

यह बहुत गंभीर मुद्दा है क्योंकि उच्च डिस्क स्थान अधिभोग स्तर केवल विखंडन को खराब करता है। और अधिक विखंडन का अर्थ है अधिक तलाश। आश्चर्य नहीं कि 50% तक पहुंचने से पहले इसने अधिक-या-कम स्वीकार्य प्रदर्शन क्यों दिया। बहुत सारे मैनुअल में स्पष्ट सिफारिशें हैं कि एफएस को 75-80% के पीछे बढ़ने की अनुमति न दें।

— poige
स्रोत

आप स्पष्ट रूप से संकेत दे रहे हैं कि छापे -6 पर ext4 वह रास्ता नहीं है जिस पर आप जाएंगे। क्या आप उस सेटअप की रूपरेखा तैयार करने का मन बनाएंगे जिसे आप सुझाएंगे?

— मार्सेलम

2

वास्तव में इसे रेखांकित करने के लिए यह बहुत जटिल काम है। कुछ मामलों के लिए पारंपरिक FS का चयन करना ठीक होगा, भले ही किसी के पास बहुत सारी फाइलें हों, अन्य (मामलों) के लिए यह शुरुआत में कोई रास्ता नहीं है। आप एक अच्छे परिचय पर एक नज़र डाल सकते हैं कि CEPH ने POSIX FS को बिल्कुल क्यों छोड़ दिया और DB पर स्विच कर दिया। BTW, जब उन्होंने FS का उपयोग किया तो उन्होंने XFS को प्राथमिकता दी। मैं शायद यही करूँगा। RAID-6 के रूप में, यह प्रमुख IOPS गुणक है - प्रत्येक लेखन के लिए इसे 2 अन्य उपकरणों पर समता को अद्यतन करना होगा। तो, शायद किसी तरह का RAID-x0 दृष्टिकोण। ऑन-फ्लाई कम्प्रेशन सपोर्ट के साथ इसमें RAID-10 का भी उपयोग करने की समझ हो सकती है। बेशक वहाँ हो तरीकों में से ...

— poige

1

... SSD कैशिंग (bcache, dm-cache, ZFS के इन-हाउस ZIL + L2ARC) के साथ इसे और तेज करने के लिए, लेकिन प्रभावी ढंग से अक्षम करने के तरीकों में से कुछ की अपनी बाधाएं हो सकती हैं। तो यही कारण है कि मैंने "बहुत जटिल" कहा है। उन आवश्यकताओं और संसाधनों को जानना होगा जो लक्ष्य को प्राप्त करने के लिए उपलब्ध होंगे।

— पोएज

1

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

— मार्सेलम

0

RAID6 इस मामले में आपकी बहुत मदद नहीं करता है, ZFS जैसी कोई चीज बहुत तेजी से मेटाडेटा और डायरेक्ट्री एक्सेस को सक्षम कर सकती है जबकि उसी के बारे में गति बनाए रख सकती है।

— जॉन कीट्स
स्रोत

0

RAID-6 धारियां ड्राइव, इसलिए सभी IO सभी ड्राइव पर जाते हैं। यह कई छोटी फ़ाइलों के साथ बहुत अक्षम है। हालांकि यह शायद आपकी मुख्य समस्या नहीं है ...

Ext4 लाखों फ़ाइलों के साथ बड़े फाइल सिस्टम के लिए अच्छी तरह से अनुकूल नहीं है। XFS का उपयोग करें । मेरे पास एक्सएफएस फाइलसिस्टम 1,2 पीबी जितना बड़ा है और 1 बिलियन फाइलें जितनी हैं, कोई समस्या नहीं है। बस XFS का उपयोग करें ।

— wazoox
स्रोत

0

मेरे सवाल का जवाब देने वाले सभी को धन्यवाद।

यह है, मैंने इसे कैसे हल किया:

सबसे पहले, मैंने बोर्ड में अधिकतम मात्रा में RAM जोड़ा। दुर्भाग्य से, बोर्ड केवल 64GB तक रैम का समर्थन करता है। मैंने विस्तार के बाद व्यवहार को देखा, और यह निराशाजनक था। हालाँकि सभी उपलब्ध RAM का उपयोग IO कैश के लिए किया गया था, लेकिन RSNAPSHOT-Backup के प्रदर्शन में मामूली सुधार नहीं हुआ।

इसलिए मुझे बड़ी गदा खींचनी पड़ी। मैंने दो 1TB NVME डिस्क जोड़े और उन्हें एक RAID 1 में जोड़ा। RAID 6 में 8x 10TB HDDs शामिल थे, जो एक RAID 1 (2x 2xTB HDD, ext4 से युक्त) और एक RAID 5 (6x10TB HDD को मिलाकर) से असंतुष्ट हो गया। RAID 1 में अब ऑपरेटिंग सिस्टम और सर्वर की कार्यशील प्रति है (जो इस ड्राइव पर दिन में 4 बार rsynced मिलता है)।

RAID5 अब एक BCACHE समर्थित डिवाइस है, जो NVME-RAID 1 द्वारा समर्थित है और ext4 के साथ स्वरूपित है। इस ड्राइव में RSNAPSHOT- कॉपियां शामिल हैं। हर रात, फ़ाइलों को RAID1 से RAID5 तक rynynced मिलता है, जो पूर्व RAID6 की तुलना में RAID5 के IO-throughput को आधा करता है, जिसमें काम करने वाली प्रतियां और बैकअप स्नैपशॉट शामिल थे। BCache के लिए धन्यवाद, शाब्दिक रूप से प्रत्येक एकल फ़ाइल को डिस्क पर नहीं लिखा जाता है, लेकिन एक ब्लॉक में सभी परिवर्तन एक बार लिखे जाते हैं, भले ही इसमें कई हंड्रेड एकल फ़ाइल परिवर्तन शामिल हों। इसने HDDs पर IOps को और कम कर दिया।

अंत में, मैंने अपना RSnapshot कॉन्फ़िगरेशन बदल दिया। पूर्व में, 31 दैनिक स्नैपशॉट और 18 मासिक स्नैपशॉट थे, जिसके परिणामस्वरूप 49 बैकअप पीढ़ी थी। अब, मेरे पास शास्त्रीय 7d / 4w / 12m / 1y-Design है, जो बैकअप पीढ़ियों की मात्रा को 24 तक कम कर देता है।

इन परिवर्तनों के बाद (और ऊपर उल्लिखित 64 जीबी रैम के साथ), एक स्नैपशॉट की अवधि ~ 20hrs से 1.5 घंटे तक कम हो गई। BCache उपकरणों की 82% की कैश-हिट-दर है (6 सप्ताह के नियमित संचालन के बाद)।

मिशन पूरा हुआ। अपने विचारों और इनपुट के लिए आप सभी का धन्यवाद।

— t2m
स्रोत

बहुत बड़े Filesystems और उच्च IOWAIT पर प्रदर्शन में सुधार के लिए विकल्प

यह है, मैंने इसे कैसे हल किया: