धेरै संख्यामा साना फाइलहरूसँग काम गर्ने ह्याकहरू

लेखको लागि विचार लेखमा टिप्पणीहरूमा छलफलबाट सहज रूपमा जन्मिएको थियो "इनोडको बारेमा केहि".

तथ्य यो हो कि हाम्रो सेवाहरूको आन्तरिक विशिष्टता साना फाइलहरूको ठूलो संख्याको भण्डारण हो। यस समयमा हामीसँग सयौं टेराबाइटहरू त्यस्ता डाटाहरू छन्। र हामीले केही स्पष्ट र त्यति स्पष्ट नभएका रेकहरू भेट्टायौं र तिनीहरूलाई सफलतापूर्वक नेभिगेट गर्यौं।

त्यसैले, म हाम्रो अनुभव साझा गर्दैछु, सायद यो कसैलाई उपयोगी हुनेछ।

समस्या एक: "यन्त्रमा कुनै ठाउँ बाँकी छैन"

माथि उल्लेखित लेखमा उल्लेख गरिए अनुसार, समस्या फाइल प्रणालीमा नि: शुल्क ब्लकहरू छन्, तर इनोड समाप्त भएको छ।

तपाइँ कमाण्डको साथ प्रयोग गरिएको र नि: शुल्क इनोडहरूको संख्या जाँच गर्न सक्नुहुन्छ df -ih:

म लेख पुन: बताउने छैन; छोटकरीमा, डिस्कले डेटाको लागि दुवै ब्लकहरू र मेटा-सूचनाका लागि ब्लकहरू समावेश गर्दछ, जसलाई inodes (सूचकांक नोड) पनि भनिन्छ। तिनीहरूको नम्बर सेट गरिन्छ जब फाइल प्रणाली सुरु हुन्छ (हामी ext2 र यसको उत्तराधिकारीको बारेमा कुरा गर्दैछौं) र थप परिवर्तन गर्दैन। डाटा ब्लकहरू र इनोडहरूको सन्तुलन औसत तथ्याङ्कीय डाटाबाट गणना गरिन्छ, तर हाम्रो अवस्थामा, जब त्यहाँ धेरै साना फाइलहरू छन्, ब्यालेन्स इनोडहरूको संख्यामा सर्नु पर्छ - त्यहाँ ती मध्ये धेरै हुनुपर्दछ।

В Linux हामीले पहिले नै विभिन्न ब्यालेन्सहरू सहित विकल्पहरू प्रदान गरिसकेका छौं, र यी सबै पूर्व-गणना गरिएका कन्फिगरेसनहरू फाइलमा छन्। /etc/mke2fs.conf.
तसर्थ, mke2fs मार्फत फाइल प्रणालीको प्रारम्भिक प्रारम्भिकताको समयमा, तपाईंले चाहेको प्रोफाइल निर्दिष्ट गर्न सक्नुहुन्छ।

यहाँ फाइलबाट केही उदाहरणहरू छन्:

    small = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 4096
    }

    big = {
        inode_ratio = 32768
    }

    largefile = {
        inode_ratio = 1048576
        blocksize = -1
    }

तपाईंले mke2fs कल गर्दा "-T" विकल्प प्रयोग गरेर इच्छित प्रयोग केस चयन गर्न सक्नुहुन्छ। यदि कुनै तयार समाधान छैन भने तपाईले आवश्यक प्यारामिटरहरू म्यानुअल रूपमा सेट गर्न सक्नुहुन्छ।

थप विवरणहरूको लागि पुस्तिकाहरूमा वर्णन गरिएको छ mke2fs.conf и mke2fs.

माथि उल्लेखित लेखमा नछोइएको सुविधा भनेको तपाईले डाटा ब्लकको साइज सेट गर्न सक्नुहुन्छ। जाहिर छ, ठूला फाइलहरूको लागि ठूलो ब्लक साइज हुनु अर्थपूर्ण हुन्छ, साना फाइलहरूको लागि सानो हुनुको अर्थ हुन्छ।

यद्यपि, यो प्रोसेसर वास्तुकला रूपमा यस्तो रोचक सुविधा विचार लायक छ।
मैले एक पटक सोचे कि ठूला फोटो फाइलहरूको लागि मलाई ठूलो ब्लक साइज चाहिन्छ। यो घरमा भयो, ARM आर्किटेक्चरमा WD नामको होम फाइल स्टोरमा। कुनै हिचकिचाहट बिना, मैले पहिले बचत नापेर, मानक 8k को सट्टा 16k वा 4k मा ब्लक साइज सेट गरें। र भण्डारण आफै असफल नभएसम्म सबै ठीक थियो, र डिस्क अझै जीवित थियो। नियमित इन्टेल प्रोसेसरको साथ नियमित कम्प्युटरमा डिस्क स्थापना गरिसकेपछि, मैले आश्चर्यचकित पाएँ: एक असमर्थित ब्लक साइज। हामी आइपुगेका छौं। डाटा त्यहाँ छ, सबै ठीक छ, तर यो पढ्न असम्भव छ। i386 र समान प्रोसेसरहरूले ब्लक साइजहरूसँग काम गर्न सक्दैन जुन मेमोरी पृष्ठको साइजसँग मेल खाँदैन, जुन ठीक 4k हो। सामान्यतया, कुरा प्रयोगकर्ता स्पेसबाट उपयोगिताहरूको प्रयोगको साथ समाप्त भयो, सबै कुरा ढिलो र दुःखी थियो, तर डाटा बचत गरिएको थियो। यदि कसैलाई रुचि छ भने, उपयोगिताको नाम गुगल गर्नुहोस् fuseext2। नैतिक: या त सबै मामिलाहरू पहिल्यै सोच्नुहोस्, वा सुपरहिरो भएको नाटक नगर्नुहोस् र गृहिणीहरूका लागि मानक सेटिङहरू प्रयोग गर्नुहोस्।

UPD। प्रयोगकर्ता टिप्पणी अनुसार berez म स्पष्ट गर्न चाहन्छु कि i386 को लागि ब्लक साइज 4k भन्दा बढी हुनु हुँदैन, तर यो ठ्याक्कै 4k हुनु हुँदैन, अर्थात्। 1k र 2k स्वीकार्य छन्।

त्यसोभए, हामीले कसरी समस्याहरू समाधान गर्यौं?

पहिलो, हामीले एउटा समस्याको सामना गर्यौं जब बहु-टेराबाइट डिस्क डाटाले भरिएको थियो, र हामीले फाइल प्रणाली कन्फिगरेसन परिवर्तन गर्न सकेनौं।

दोस्रो, तुरुन्त समाधान आवश्यक थियो।

नतिजाको रूपमा, हामी निष्कर्षमा पुग्यौं कि हामीले फाईलहरूको संख्या घटाएर ब्यालेन्स परिवर्तन गर्न आवश्यक छ।
फाइलहरूको संख्या कम गर्न, फाइलहरूलाई एउटा साझा अभिलेखमा राख्ने निर्णय गरियो। हाम्रो विशिष्टताहरूलाई ध्यानमा राख्दै, हामीले निश्चित समयावधिमा सबै फाइलहरू एउटै अभिलेखमा राख्यौं, र प्रत्येक रात क्रोन कार्य प्रयोग गरेर अभिलेख राख्यौं।

जिप संग्रह चयन गरियो। अघिल्लो लेखको टिप्पणीहरूमा, टार सुझाव गरिएको थियो, तर यसमा एउटा कठिनाई छ: यसमा सामग्रीको तालिका छैन, र यसमा भएका फाइलहरू स्ट्रिममा भण्डार गरिएको छ (यो "टार" संक्षिप्त नाम मात्र होइन। "टेप अभिलेख" को लागि, टेप ड्राइभको विरासत), अर्थात्। यदि तपाईंले अभिलेखको अन्त्यमा फाइल पढ्न आवश्यक छ भने, तपाईंले सम्पूर्ण अभिलेख पढ्न आवश्यक छ, किनकि यसले अभिलेखको सुरुमा प्रत्येक फाइलको लागि अफसेटहरू समावेश गर्दैन। र त्यसैले यो एक लामो अपरेशन छ। zip मा सबै कुरा धेरै राम्रो छ: यससँग अभिलेख भित्र सामग्री र फाइल अफसेटहरूको समान तालिका छ, र प्रत्येक फाइलमा पहुँच समय यसको स्थानमा निर्भर गर्दैन। खैर, हाम्रो केसमा, "0" मा कम्प्रेसन विकल्प सेट गर्न सम्भव थियो, किनभने सबै फाइलहरू पहिले नै gzip मा संकुचित थिए।

ग्राहकहरूले nginx मार्फत फाइलहरू पुन: प्राप्त गर्छन्, र पुरानो API अनुसार, केवल फाइल नाम निर्दिष्ट गरिएको छ, उदाहरणका लागि यो जस्तै:

http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5

फ्लाईमा फाइलहरू अनप्याक गर्न, हामीले nginx-unzip-module मोड्युल फेला पार्यौं र जडान गर्यौं (https://github.com/youzee/nginx-unzip-module) र दुई अपस्ट्रिमहरू सेट अप गर्नुहोस्।

परिणाम निम्न कन्फिगरेसन थियो:

सेटिङहरूमा दुई होस्टहरू यस्तो देखिन्थे:

server {
  listen *:8081;

  location / {
    root      /home/filestorage;
  }
}

server {
  listen *:8082;

  location ~ ^/hydra/(d+)/(d+)/(.*)$ {
    root      /home/filestorage;
    file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip";
    file_in_unzip_extract "$2/$3";
    file_in_unzip;
  }
}

र अपस्ट्रीम nginx मा अपस्ट्रीम कन्फिगरेसन:

upstream storage {
  server server.com:8081;
  server server.com:8082;
}

यस्ले कसरी काम गर्छ:

• ग्राहक अगाडि nginx मा जान्छ
• Front nginx ले पहिलो अपस्ट्रीमबाट फाइल सेवा गर्ने प्रयास गर्दछ, अर्थात्। प्रत्यक्ष फाइल प्रणालीबाट
• यदि त्यहाँ कुनै फाइल छैन भने, यसले दोस्रो अपस्ट्रीमबाट पठाउने प्रयास गर्दछ, जसले फाइललाई अभिलेख भित्र फेला पार्न प्रयास गर्दछ।

समस्या दुई: फेरि "यन्त्रमा कुनै ठाउँ बाँकी छैन"

डाइरेक्टरीमा धेरै फाइलहरू हुँदा हामीले सामना गरेको यो दोस्रो समस्या हो।
हामी फाईल बनाउन खोजिरहेका छौं, प्रणालीले ठाउँ नभएको गुनासो गर्छ। हामी फाइलको नाम परिवर्तन गर्छौं र यसलाई फेरि सिर्जना गर्ने प्रयास गर्छौं।

यो बाहिर जान्छ।

यो केहि यस्तो देखिन्छ:

इनोडहरू जाँच गर्दा केहि पनि दिएन - त्यहाँ धेरै नि: शुल्क छन्।
स्थानको जाँच पनि उस्तै छ।
हामीले सोचे कि डाइरेक्टरीमा धेरै फाइलहरू हुन सक्छन्, र त्यहाँ यसमा सीमा छ, तर फेरि होइन: प्रति डाइरेक्टरी फाइलहरूको अधिकतम संख्या: ~1.3 × 10^20

हो, र यदि तपाईंले नाम परिवर्तन गर्नुभयो भने तपाईंले फाइल सिर्जना गर्न सक्नुहुन्छ।
निष्कर्ष - समस्या फाइल नाम मा छ।

थप खोजहरूले डाइरेक्टरी अनुक्रमणिका निर्माण गर्दा समस्या ह्यासिङ एल्गोरिथ्ममा भएको देखाएको छ; फाइलहरूको ठूलो संख्याको साथ, सबै आगामी परिणामहरूसँग टक्करहरू अवलोकन गरिन्छ। तपाईं यहाँ थप विवरणहरू पढ्न सक्नुहुन्छ: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

तपाईंले यो विकल्प असक्षम गर्न सक्नुहुन्छ, तर... नामद्वारा फाइल खोज्दा सबै फाइलहरू खोज्दा अप्रत्याशित रूपमा लामो हुन सक्छ।

 tune2fs -O "^dir_index" /dev/sdb3

सामान्यतया, यो काम गर्न सक्ने एक अस्थायी समाधान हो।

नैतिक: डाइरेक्टरीमा धेरै फाइलहरू सामान्यतया खराब कुरा हो। यो गर्न आवश्यक छैन।

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

समस्या तीन: यदि त्यहाँ धेरै छन् भने फाइलहरूको सूची कसरी हेर्ने

हाम्रो अवस्थामा, जब हामीसँग धेरै फाइलहरू छन्, एक तरिका वा अर्को हामीले डाइरेक्टरीका सामग्रीहरू कसरी हेर्ने भन्ने समस्याको सामना गर्यौं।

मानक समाधान - आदेश ls.
ठीक छ, 4772098 फाइलहरूमा के हुन्छ हेरौं:

$ time ls /home/app/express.repository/offercache/ >/dev/null

real	0m30.203s
user	0m28.327s
sys	0m1.876s

३० सेकेन्ड... धेरै हुनेछ। यसबाहेक, धेरैजसो समय प्रयोगकर्ता स्पेसमा फाइलहरू प्रशोधन गर्नमा खर्च गरिन्छ, र कर्नेलको सञ्चालनमा होइन।

तर त्यहाँ एक समाधान छ:

$ time find /home/app/express.repository/offercache/ >/dev/null

real	0m3.714s
user	0m1.998s
sys	0m1.717s

३ सेकेन्ड। 3 पटक छिटो।
हुरै!

UPD।

प्रयोगकर्ताबाट अझ छिटो समाधान berez - क्रमबद्ध अक्षम ls

time ls -U /home/app/express.repository/offercache/ >/dev/null
real	0m2.985s
user	0m1.377s
sys	0m1.608s

समस्या चार: फाइलहरूसँग काम गर्दा ठूलो LA

समय-समयमा एक स्थिति उत्पन्न हुन्छ जब तपाइँ फाइलहरूको गुच्छा एक मेसिनबाट अर्कोमा प्रतिलिपि गर्न आवश्यक हुन्छ। एकै समयमा, LA अक्सर अवास्तविक रूपमा बढ्छ, किनकि सबै कुरा डिस्कको प्रदर्शनमा निर्भर गर्दछ।

तपाईले गर्न चाहनुहुने सबैभन्दा स्मार्ट कुरा भनेको SSD प्रयोग गर्नु हो। साचिकै दामी। मात्र प्रश्न बहु-टेराबाइट SSDs को लागत हो।

तर यदि डिस्कहरू सामान्य छन् भने, तपाईंले फाइलहरू प्रतिलिपि गर्न आवश्यक छ, र यो उत्पादन प्रणाली पनि हो, जहाँ ओभरलोडले ग्राहकहरूबाट असन्तुष्ट विस्मयादिबोधकहरू निम्त्याउँछ? त्यहाँ कम्तिमा दुई उपयोगी उपकरणहरू छन्: nice и ionice.

nice - प्रक्रियाको प्राथमिकता घटाउँछ, तदनुसार अनुसूचकले अन्य, उच्च प्राथमिकता प्रक्रियाहरूमा थप समय स्लाइसहरू वितरण गर्दछ।
हाम्रो अभ्यासमा, यसले अधिकतममा राम्रो सेट गर्न मद्दत गर्‍यो (19 न्यूनतम प्राथमिकता हो, -20 (माइनस 20) अधिकतम हो)।

ionice - तदनुसार I/O तालिका समायोजन गर्दछ

यदि तपाइँ RAID प्रयोग गर्दै हुनुहुन्छ र यसलाई अचानक सिङ्क्रोनाइज गर्न आवश्यक छ (असफल रिबुट पछि वा तपाइँले डिस्क प्रतिस्थापन गरेपछि RAID एरेलाई पुनर्स्थापना गर्न आवश्यक छ), त्यसपछि केहि परिस्थितिहरूमा यसले सिङ्क्रोनाइजेसन गति कम गर्न अर्थपूर्ण हुन्छ ताकि अन्य प्रक्रियाहरूले थप काम गर्न सकून्। वा कम पर्याप्त रूपमा। निम्न आदेशले यसको लागि मद्दत गर्नेछ:

echo 1000 > /proc/sys/dev/raid/speed_limit_max

समस्या पाँच: वास्तविक समयमा फाइलहरू कसरी सिङ्क्रोनाइज गर्ने

हामीसँग अझै पनि उस्तै ठूलो संख्यामा फाइलहरू छन् जसलाई बेवास्ता गर्न दोस्रो सर्भरमा ब्याकअप गर्न आवश्यक छ... फाइलहरू निरन्तर लेखिँदै छन्, त्यसैले न्युनतम हानि हुनको लागि, तपाईंले तिनीहरूलाई सकेसम्म चाँडो प्रतिलिपि गर्न आवश्यक छ।

मानक समाधान: SSH मा Rsync।

यो एक राम्रो विकल्प हो जब सम्म तपाइँ यसलाई हरेक केहि सेकेन्डमा गर्न आवश्यक छैन। र त्यहाँ धेरै फाइलहरू छन्। यदि तपाइँ तिनीहरूलाई प्रतिलिपि गर्नुहुन्न भने, तपाइँ अझै पनि के परिवर्तन भएको छ भनेर बुझ्न आवश्यक छ, र धेरै मिलियन फाइलहरू तुलना गर्न समय लाग्छ र डिस्कहरूमा लोड हुन्छ।

ती। हामीले तुरुन्तै जान्न आवश्यक छ कि के प्रतिलिपि गर्न आवश्यक छ, हरेक पटक तुलना चलाउन बिना।

उद्धार - lsyncd. Lsyncd - प्रत्यक्ष सिङ्किङ (मिरर) डेमन। यसले rsync मार्फत पनि काम गर्दछ, तर थप रूपमा inotify र fsevens प्रयोग गरेर परिवर्तनहरूको लागि फाइल प्रणालीलाई निगरानी गर्दछ र देखा परेका वा परिवर्तन भएका फाइलहरूलाई मात्र प्रतिलिपि गर्न थाल्छ।

समस्या छ: कसले डिस्क लोड गर्दैछ भनेर कसरी बुझ्ने

सबैलाई सायद यो थाहा छ, तर तैपनि, तस्वीर पूरा गर्न: त्यहाँ डिस्क उपप्रणाली निगरानी गर्न आदेश छ। iotop - जस्तै top, तर सबैभन्दा सक्रिय रूपमा डिस्क प्रयोग गर्ने प्रक्रियाहरू देखाउँछ।

खैर, राम्रो पुरानो शीर्षले तपाईंलाई डिस्कमा समस्या छ वा छैन भनेर बुझ्न अनुमति दिन्छ। यसको लागि दुईवटा सबैभन्दा उपयुक्त विकल्पहरू छन्: औसत लोड गर्नुहोस् и पर्खनुहोस्.

पहिलोले सेवाको लागि कतारमा कति प्रक्रियाहरू छन् भनेर देखाउँछ, सामान्यतया 2 भन्दा बढी - केहि पहिले नै गलत भइरहेको छ। ब्याकअप सर्भरहरूमा सक्रिय रूपमा प्रतिलिपि गर्दा, हामी 6-8 सम्म अनुमति दिन्छौं, त्यसपछि स्थिति असामान्य मानिन्छ।

दोस्रो भनेको प्रोसेसर डिस्क सञ्चालनमा कति व्यस्त छ। IOwait>10% चिन्ताको कारण हो, यद्यपि हाम्रो सर्भरहरूमा विशिष्ट लोड प्रोफाइलको साथ यो लगातार 40-50% छ, र यो वास्तवमै सामान्य हो।

म यहाँ समाप्त गर्नेछु, यद्यपि त्यहाँ धेरै बिन्दुहरू छन् जुन हामीले सामना गर्नुपरेको छैन, म टिप्पणीहरू र रोचक वास्तविक केसहरूको विवरणहरूको लागि पर्खन पाउँदा खुसी हुनेछु।

स्रोत: www.habr.com