{"id":36999,"date":"2019-10-31T22:15:13","date_gmt":"2019-10-31T19:15:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov\/"},"modified":"2019-10-31T22:15:13","modified_gmt":"2019-10-31T19:15:13","slug":"haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Pomys\u0142 na artyku\u0142 zrodzi\u0142 si\u0119 spontanicznie podczas dyskusji w komentarzach do artyku\u0142u <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/462849\/\">\u201eCo\u015b o inode\u201d<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/e488f5985cfb0b3274f57f6baeeedf01.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFaktem jest, \u017ce wewn\u0119trzn\u0105 specyfik\u0105 dzia\u0142ania naszych us\u0142ug jest przechowywanie ogromnej liczby drobnych plik\u00f3w. Obecnie mamy oko\u0142o setek terabajt\u00f3w takich danych. Napotkali\u015bmy na kilka oczywistych i nieco mniej oczywistych pu\u0142apek i skutecznie je pokonali\u015bmy.<\/p>\n<p>Dlatego dziel\u0119 si\u0119 naszym do\u015bwiadczeniem, mo\u017ce si\u0119 komu\u015b przyda.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Pierwszy problem: \u201eBrak miejsca na urz\u0105dzeniu\u201d<\/h2>\n<p>\nJak wspomniano w wy\u017cej wspomnianym artykule, problem polega na tym, \u017ce wolne bloki w systemie plik\u00f3w s\u0105 dost\u0119pne, ale inody si\u0119 wyczerpa\u0142y.<\/p>\n<p>Liczb\u0119 u\u017cywanych i wolnych inod\u00f3w mo\u017cna sprawdzi\u0107 komend\u0105 <code>df -ih<\/code>:<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/ceb86a22562aa08c8ffbbde2c2618545.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNie b\u0119d\u0119 streszcza\u0142 artyku\u0142u, kr\u00f3tko m\u00f3wi\u0105c, na dysku s\u0105 bloki bezpo\u015brednio dla danych oraz bloki dla metainformacji, zwane inodami (index node). Ich liczba jest ustalana podczas inicjalizacji systemu plik\u00f3w (mowa o ext2 i jej potomkach) i p\u00f3\u017aniej si\u0119 nie zmienia. R\u00f3wnowaga mi\u0119dzy blokami danych a inodami jest obliczana na podstawie \u015brednich danych, w naszym przypadku, gdzie jest wiele drobnych plik\u00f3w, r\u00f3wnowaga powinna przesuwa\u0107 si\u0119 na korzy\u015b\u0107 liczby inod\u00f3w \u2014 ich powinno by\u0107 wi\u0119cej.<\/p>\n<p>W Linuxie przewidziano r\u00f3\u017cne warianty z r\u00f3\u017cn\u0105 r\u00f3wnowag\u0105, a wszystkie te wst\u0119pnie obliczone konfiguracje znajduj\u0105 si\u0119 w pliku <code>\/etc\/mke2fs.conf<\/code>.<br \/>\nDlatego przy pierwszej inicjalizacji systemu plik\u00f3w za pomoc\u0105 mke2fs mo\u017cna wskaza\u0107 odpowiedni profil.<\/p>\n<p>Oto kilka przyk\u0142ad\u00f3w z pliku:<\/p>\n<pre><code class=\"json\">    small = {\n        blocksize = 1024\n        inode_size = 128\n        inode_ratio = 4096\n    }\n\n    big = {\n        inode_ratio = 32768\n    }\n\n    largefile = {\n        inode_ratio = 1048576\n        blocksize = -1\n    }\n<\/code><\/pre>\n<p>\n\u0412\u044b\u0431\u0440\u0430\u0442\u044c \u043d\u0443\u0436\u043d\u044b\u0439 \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u043c\u043e\u0436\u043d\u043e \u043e\u043f\u0446\u0438\u0435\u0439 &#171;-T&#187; \u043f\u0440\u0438 \u0432\u044b\u0437\u043e\u0432\u0435 mke2fs. \u0422\u0430\u043a\u0436\u0435 \u043c\u043e\u0436\u043d\u043e \u0432\u0440\u0443\u0447\u043d\u0443\u044e \u0437\u0430\u0434\u0430\u0442\u044c \u043d\u0443\u0436\u043d\u044b\u0435 \u043f\u0430\u0440\u0430\u043c\u0435\u0442\u0440\u044b, \u0435\u0441\u043b\u0438 \u043d\u0435\u0442 \u0433\u043e\u0442\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u0448\u0435\u043d\u0438\u044f.<\/p>\n<p>Wi\u0119cej szczeg\u00f3\u0142\u00f3w opisano w podr\u0119cznikach dla <code>mke2fs.conf<\/code> i <code>mke2fs<\/code>.<\/p>\n<p>Nieporuszona w wy\u017cej wymienionym artykule cecha \u2014 mo\u017cna okre\u015bli\u0107 rozmiar bloku danych. Oczywi\u015bcie dla du\u017cych plik\u00f3w ma sens wi\u0119kszy rozmiar bloku, dla ma\u0142ych \u2014 mniejszy. <\/p>\n<p>Nale\u017cy jednak wzi\u0105\u0107 pod uwag\u0119 tak interesuj\u0105c\u0105 cech\u0119, jak architektura procesora.<br \/>\nKiedy\u015b pomy\u015bla\u0142em, \u017ce potrzebuj\u0119 wi\u0119kszego rozmiaru bloku dla du\u017cych plik\u00f3w zdj\u0119\u0107. To dzia\u0142o si\u0119 w warunkach domowych, na domowym magazynie danych marki WD z architektur\u0105 ARM. Nie zastanawiaj\u0105c si\u0119 d\u0142ugo, ustawi\u0142em rozmiar bloku na 8k lub 16k zamiast standardowych 4k, wcze\u015bniej mierz\u0105c oszcz\u0119dno\u015bci. Wszystko by\u0142o \u015bwietnie, a\u017c do momentu, gdy sam magazyn przesta\u0142 dzia\u0142a\u0107, podczas gdy dysk nadal by\u0142 sprawny. Po w\u0142o\u017ceniu dysku do zwyk\u0142ego komputera z klasycznym procesorem Intela, otrzyma\u0142em niespodziank\u0119: rozmiar bloku nie jest obs\u0142ugiwany. Dobra, dane s\u0105, wszystko w porz\u0105dku, ale nie mo\u017cna ich odczyta\u0107. Procesory i386 i podobne nie potrafi\u0105 pracowa\u0107 z rozmiarami bloku, kt\u00f3re nie odpowiadaj\u0105 rozmiarowi strony pami\u0119ci, a ten wynosi dok\u0142adnie 4k. W ko\u0144cu skorzystali\u015bmy z narz\u0119dzi u\u017cytkownika, wszystko by\u0142o wolne i smutne, ale uratowali\u015bmy dane. Dla zainteresowanych \u2014 google'y po nazwie narz\u0119dzia <code>fuseext2<\/code>. Mora\u0142: albo przemy\u015bl wszystkie przypadki z g\u00f3ry, albo nie udawaj superbohatera i korzystaj ze standardowych ustawie\u0144 dla domownik\u00f3w.<\/p>\n<p>UPD. Zgodnie z uwag\u0105 u\u017cytkownika <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/berez\/\" class=\"user_link\">berez<\/a><\/noindex> dodatkowo wyja\u015bniam, \u017ce dla i386 rozmiar bloku nie powinien przekracza\u0107 4k, ale nie musi by\u0107 dok\u0142adnie 4k, to znaczy dozwolone s\u0105 1k i 2k.<\/p>\n<p>A wi\u0119c, jak my rozwi\u0105zali\u015bmy problemy.<\/p>\n<p>Po pierwsze, napotkali\u015bmy problem, gdy wielotera bajtowy dysk by\u0142 zape\u0142niony danymi, a my nie mogli\u015bmy zmieni\u0107 konfiguracji systemu plik\u00f3w.<\/p>\n<p>Po drugie, potrzebne by\u0142o pilne rozwi\u0105zanie.<\/p>\n<p>Ostatecznie doszli\u015bmy do wniosku, \u017ce musimy zmieni\u0107 r\u00f3wnowag\u0119, zmniejszaj\u0105c liczb\u0119 plik\u00f3w.<br \/>\nAby zmniejszy\u0107 liczb\u0119 plik\u00f3w, postanowiono umie\u015bci\u0107 pliki w jednym wsp\u00f3lnym archiwum. Bior\u0105c pod uwag\u0119 nasz\u0105 specyfik\u0119, umieszczali\u015bmy w jednym archiwum wszystkie pliki za pewien okres czasu i przeprowadzali\u015bmy archiwizacj\u0119 codziennym zadaniem cron w nocy.<\/p>\n<p>Wybrano archiwum zip. W komentarzach do poprzedniego artyku\u0142u sugerowano tar, ale jest jedna trudno\u015b\u0107: nie ma on spisu tre\u015bci, a pliki s\u0105 w nim u\u0142o\u017cone w spos\u00f3b sekwencyjny (nie bez powodu \u201etar\u201d to skr\u00f3t od \u201eTape Archive\u201d, dziedzictwo ta\u015bmowych no\u015bnik\u00f3w), tzn. je\u015bli trzeba przeczyta\u0107 plik na ko\u0144cu archiwum \u2014 nale\u017cy przeczyta\u0107 ca\u0142e archiwum, poniewa\u017c nie ma w nim przesuni\u0119\u0107 dla ka\u017cdego pliku wzgl\u0119dem pocz\u0105tku archiwum. Dlatego to jest d\u0142ugotrwa\u0142a operacja. W zip jest znacznie lepiej: ma on wspomniany spis tre\u015bci i przesuni\u0119cia plik\u00f3w wewn\u0105trz archiwum, a czas dost\u0119pu do ka\u017cdego pliku nie zale\u017cy od jego lokalizacji. A w naszym przypadku mo\u017cna by\u0142o ustawi\u0107 opcj\u0119 kompresji \u201e0\u201d, poniewa\u017c wszystkie pliki by\u0142y ju\u017c wcze\u015bniej skompresowane w gzip.<\/p>\n<p>Klienci pobieraj\u0105 pliki przez nginx, a wed\u0142ug starego API po prostu podaje si\u0119 nazw\u0119 pliku, na przyk\u0142ad tak:<\/p>\n<pre><code class=\"plaintext\">http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n<p>\nAby dekompresowa\u0107 pliki na bie\u017c\u0105co, znaleziono i pod\u0142\u0105czono modu\u0142 nginx-unzip-module (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/youzee\/nginx-unzip-module\">https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) i skonfigurowano dwa upstreamy.<\/p>\n<p>W rezultacie powsta\u0142a taka konfiguracja:<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/56f5210669fecfe194ac5907d563aa1d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDwa hosty w ustawieniach wygl\u0105da\u0142y tak:<\/p>\n<pre><code class=\"json\">server {\n  listen *:8081;\n\n  location \/ {\n    root      \/home\/filestorage;\n  }\n}<\/code><\/pre>\n<p><\/p>\n<pre><code class=\"json\">server {\n  listen *:8082;\n\n  location ~ ^\/hydra\/(d+)\/(.+)$ {\n    root      \/home\/filestorage;\n    file_in_unzip_archivefile \"\/home\/filestorage\/hydra\/$1\/$2.zip\";\n    file_in_unzip_extract \"$2\/$3\";\n    file_in_unzip;\n  }\n}\n<\/code><\/pre>\n<p>\nI konfiguracja upstream\u00f3w na wy\u017cszym nginx:<\/p>\n<pre><code class=\"json\">upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n<p>\nJak to dzia\u0142a:<\/p>\n<ul>\n<li>Klient idzie na front nginx<\/li>\n<li>Front nginx stara si\u0119 dostarczy\u0107 plik z pierwszego upstreamu, tzn. bezpo\u015brednio z systemu plik\u00f3w<\/li>\n<li>Je\u015bli pliku nie ma \u2014 pr\u00f3buje dostarczy\u0107 z drugiego upstreamu, kt\u00f3ry stara si\u0119 znale\u017a\u0107 plik w archiwum<\/li>\n<\/ul>\n<p><\/p>\n<h2>Drugi problem: znowu \u201eNo space left on device\u201d<\/h2>\n<p>\nTo drugi problem, na kt\u00f3ry natkn\u0119li\u015bmy si\u0119, gdy w katalogu jest wiele plik\u00f3w.<br \/>\nPr\u00f3bujemy stworzy\u0107 plik, system narzeka, \u017ce nie ma miejsca. Zmieniamy nazw\u0119 pliku i ponownie pr\u00f3bujemy go stworzy\u0107.<\/p>\n<p>Udaje si\u0119.<\/p>\n<p>Wygl\u0105da mniej wi\u0119cej tak:<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/f365358b59bf81d450a236dfb58e4874.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSprawdzenie inod\u00f3w nic nie da\u0142o \u2014 jest ich du\u017co wolnych. <br \/>\nSprawdzenie miejsca \u2014 to samo.<br \/>\nPomy\u015bleli\u015bmy, \u017ce mo\u017ce w katalogu jest zbyt wiele plik\u00f3w, a na to jest ograniczenie, ale zn\u00f3w nie: Maksymalna liczba plik\u00f3w na katalog: ~1.3 \u00d7 10^20<\/p>\n<p>Tak czy inaczej plik mo\u017cna stworzy\u0107, je\u015bli zmieni si\u0119 nazw\u0119.<br \/>\nWniosek \u2014 problem le\u017cy w nazwie pliku.<\/p>\n<p>Dalsze poszukiwania pokaza\u0142y, \u017ce problem le\u017cy w algorytmie haszowania podczas budowania indeksu katalogu, przy du\u017cej liczbie plik\u00f3w wyst\u0119puj\u0105 kolizje ze wszystkimi tego konsekwencjami. Wi\u0119cej informacji mo\u017cna przeczyta\u0107 tutaj: <noindex><a rel=\"nofollow\" href=\"https:\/\/ext4.wiki.kernel.org\/index.php\/Ext4_Disk_Layout#Hash_Tree_Directories\">https:\/\/ext4.wiki.kernel.org\/index.php\/Ext4_Disk_Layout#Hash_Tree_Directories<\/a><\/noindex><\/p>\n<p>Mo\u017cna wy\u0142\u0105czy\u0107 t\u0119 opcj\u0119, ale\u2026 wyszukiwanie pliku po nazwie mo\u017ce sta\u0107 si\u0119 nieprzewidywalnie d\u0142ugie podczas przeszukiwania wszystkich plik\u00f3w. <\/p>\n<pre><code class=\"bash\"> tune2fs -O \"^dir_index\" \/dev\/sdb3\n<\/code><\/pre>\n<p>\nOg\u00f3lnie rzecz bior\u0105c, jako tymczasowe rozwi\u0105zanie, mo\u017ce to zadzia\u0142a\u0107.<\/p>\n<p>Moral: du\u017co plik\u00f3w w katalogu \u2014 to zazwyczaj \u017ale. Tak robi\u0107 nie nale\u017cy.<\/p>\n<p>Zazwyczaj w takich przypadkach tworzy si\u0119 zagnie\u017cd\u017cone katalogi, wed\u0142ug pierwszych liter nazwy pliku lub wed\u0142ug innych parametr\u00f3w, na przyk\u0142ad wed\u0142ug dat, w wi\u0119kszo\u015bci przypadk\u00f3w to ratuje sytuacj\u0119.<br \/>\nJednak \u0142\u0105czne liczba ma\u0142ych plik\u00f3w \u2014 to wci\u0105\u017c \u017ale, nawet je\u015bli zostan\u0105 podzielone wed\u0142ug katalog\u00f3w \u2014 wtedy patrz na pierwszy problem.<\/p>\n<h2>Problem trzeci: jak zobaczy\u0107 list\u0119 plik\u00f3w, je\u015bli jest ich du\u017co<\/h2>\n<p>\nW naszej sytuacji, kiedy mamy du\u017co plik\u00f3w, w taki czy inny spos\u00f3b stykamy si\u0119 z problemem, jak zobaczy\u0107 zawarto\u015b\u0107 katalogu.<\/p>\n<p>Standardowe rozwi\u0105zanie \u2014 komenda <code>ls<\/code>.<br \/>\nDobrze, zobaczmy, co si\u0119 dzieje przy 4772098 plikach:<\/p>\n<pre><code class=\"bash\">\n$ time ls \/home\/app\/express.repository\/offercache\/ &gt;\/dev\/null\n\nreal\t0m30.203s\nuser\t0m28.327s\nsys\t0m1.876s\n<\/code><\/pre>\n<p>\n30 sekund\u2026 to do\u015b\u0107 d\u0142ugo. Przy czym g\u0142\u00f3wny czas zajmuje przetwarzanie plik\u00f3w w przestrzeni u\u017cytkownika, a nie dzia\u0142anie j\u0105dra.<\/p>\n<p>Ale jest rozwi\u0105zanie:<\/p>\n<pre><code class=\"bash\">\n$ time find \/home\/app\/express.repository\/offercache\/ &gt;\/dev\/null\n\nreal\t0m3.714s\nuser\t0m1.998s\nsys\t0m1.717s\n<\/code><\/pre>\n<p>\n3 sekundy. 10 razy szybciej.<br \/>\nHurra!<\/p>\n<p><b>UPD.<\/b><\/p>\n<p>Jeszcze szybsze rozwi\u0105zanie od u\u017cytkownika <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/berez\/\" class=\"user_link\">berez<\/a><\/noindex> \u2014 wy\u0142\u0105czenie sortowania w <code>ls<\/code><\/p>\n<pre><code class=\"bash\">\ntime ls -U \/home\/app\/express.repository\/offercache\/ &gt;\/dev\/null\nreal\t0m2.985s\nuser\t0m1.377s\nsys\t0m1.608s\n<\/code><\/pre>\n<h2>Problem czwarty: wysoki LA podczas pracy z plikami<\/h2>\n<p>\nOkazjonalnie zdarza si\u0119 sytuacja, w kt\u00f3rej trzeba skopiowa\u0107 du\u017c\u0105 ilo\u015b\u0107 plik\u00f3w z jednej maszyny na drug\u0105. Przy tym cz\u0119sto znacznie wzrasta LA, poniewa\u017c wszystko sprowadza si\u0119 do wydajno\u015bci samych dysk\u00f3w.<\/p>\n<p>Najsensowniejszym rozwi\u0105zaniem, kt\u00f3re przychodzi na my\u015bl \u2014 to u\u017cycie SSD. Naprawd\u0119 \u015bwietne. Pytanie tylko o koszt wielotera\u0142owych SSD.<\/p>\n<p>Ale je\u015bli dyski s\u0105 zwyk\u0142e, pliki trzeba skopiowa\u0107, a to dodatkowo produkcyjny system, gdzie przeci\u0105\u017cenia prowadz\u0105 do niezadowolonych g\u0142os\u00f3w klient\u00f3w? Jest co najmniej dwa przydatne narz\u0119dzia: <code>mi\u0142y<\/code> i <code>ionice<\/code>.<\/p>\n<p><code>mi\u0142y<\/code> \u2014 zmniejsza priorytet procesu, w zwi\u0105zku z czym scheduler przydziela wi\u0119cej kwant\u00f3w czasu innym, bardziej priorytetowym procesom.<br \/>\nW naszej praktyce pomog\u0142o ustawienie nice na maksymalny (19 \u2014 to minimalny priorytet, -20 (minus 20) \u2014 maksymalny).<\/p>\n<p><code>ionice<\/code> \u2014 odpowiednio koryguje priorytet wej\u015bcia\/wyj\u015bcia (I\/O scheduling)<\/p>\n<p>Je\u015bli u\u017cywasz RAID i nagle potrzebuje on synchronizacji (po nieudanym reboocie lub potrzebne jest przywr\u00f3cenie macierzy RAID po wymianie dysku), w niekt\u00f3rych sytuacjach warto zmniejszy\u0107 pr\u0119dko\u015b\u0107 synchronizacji, aby pozosta\u0142e procesy mog\u0142y dzia\u0142a\u0107 w miar\u0119 normalnie. W tym pomo\u017ce nast\u0119puj\u0105ce polecenie:<\/p>\n<pre><code class=\"bash\">\necho 1000 &gt; \/proc\/sys\/dev\/raid\/speed_limit_max\n<\/code><\/pre>\n<p><\/p>\n<h2>Problem pi\u0105ty: Jak synchronizowa\u0107 pliki w czasie rzeczywistym<\/h2>\n<p>\nMamy te same ogromne ilo\u015bci plik\u00f3w, kt\u00f3re musimy zbackupowa\u0107 na drugi serwer, aby unikn\u0105\u0107... Pliki s\u0105 ca\u0142y czas zapisywane, dlatego aby zminimalizowa\u0107 straty, nale\u017cy je kopiowa\u0107 maksymalnie szybko.<\/p>\n<p>Standardowe rozwi\u0105zanie: Rsync przez SSH.<\/p>\n<p>To dobry wariant, je\u015bli nie trzeba tego robi\u0107 co kilka sekund. A plik\u00f3w jest du\u017co. Nawet je\u015bli ich nie kopiujemy \u2014 i tak trzeba jako\u015b zrozumie\u0107, co si\u0119 zmieni\u0142o, a por\u00f3wnanie kilku milion\u00f3w plik\u00f3w to czas i obci\u0105\u017cenie dysk\u00f3w.<\/p>\n<p>Tzn. musimy od razu wiedzie\u0107, co trzeba skopiowa\u0107, bez uruchamiania por\u00f3wnania za ka\u017cdym razem.<\/p>\n<p>Ratunek \u2014 <code>lsyncd<\/code>. <code>Lsyncd<\/code> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/axkibe.github.io\/lsyncd\/\">Demon synchronizacji na \u017cywo (Mirror)<\/a><\/noindex>. Dzia\u0142a r\u00f3wnie\u017c przez rsync, ale dodatkowo monitoruje system plik\u00f3w pod k\u0105tem zmian, korzystaj\u0105c z inotify i fsevents, i uruchamia kopiowanie tylko dla tych plik\u00f3w, kt\u00f3re zosta\u0142y dodane lub zmienione.<\/p>\n<h2>Problem sz\u00f3sty: jak zrozumie\u0107, kto obci\u0105\u017ca dyski<\/h2>\n<p>\nPewnie wszyscy to wiedz\u0105, ale dla pe\u0142ni obrazu: do monitorowania podsystemu dyskowego istnieje polecenie <code>iotop<\/code> \u2014 co\u015b w rodzaju <code>top<\/code>, ale pokazuje procesy, kt\u00f3re najbardziej aktywnie wykorzystuj\u0105 dyski.<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/56612c618469ef340a31ae446d65ed4e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSwoj\u0105 drog\u0105, stary dobry top r\u00f3wnie\u017c pozwala zrozumie\u0107, czy s\u0105 problemy z dyskami, czy nie. Do tego s\u0105 dwa najbardziej odpowiednie parametry: <b>Load Average<\/b> i <b>IOwait<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Wskaz\u00f3wki przy pracy z du\u017c\u0105 ilo\u015bci\u0105 ma\u0142ych plik\u00f3w\" src=\"\/wp-content\/uploads\/2019\/08\/01a0565947de65d13b0045f7180caf5d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPierwszy pokazuje, ile proces\u00f3w czeka na obs\u0142ug\u0119, zazwyczaj wi\u0119cej ni\u017c 2 ju\u017c wskazuje, \u017ce co\u015b jest nie tak. Przy aktywnym kopiowaniu na serwery zapasowe dopuszczamy do 6-8, po tym sytuacja uwa\u017cana jest za nieprawid\u0142ow\u0105.<\/p>\n<p>Drugi \u2014 w jakim stopniu procesor jest zaj\u0119ty operacjami dyskowymi. IOwait &gt;10% \u2014 pow\u00f3d do niepokoju, chocia\u017c na naszych serwerach o specyficznym profilu obci\u0105\u017cenia bywa stabilnie 40-50%, i to naprawd\u0119 norma.<\/p>\n<p>Na tym zako\u0144cz\u0119, chocia\u017c z pewno\u015bci\u0105 istnieje wiele kwestii, z kt\u00f3rymi nie mieli\u015bmy do czynienia, z przyjemno\u015bci\u0105 czekam na komentarze i opisy interesuj\u0105cych rzeczywistych przypadk\u00f3w.<br \/>\n<br \/>\u0179r\u00f3d\u0142o: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/srg\/blog\/462967\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0418\u0434\u0435\u044f \u0441\u0442\u0430\u0442\u044c\u0438 \u0440\u043e\u0434\u0438\u043b\u0430\u0441\u044c \u0441\u043f\u043e\u043d\u0442\u0430\u043d\u043d\u043e \u0438\u0437 \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043a \u0441\u0442\u0430\u0442\u044c\u0435 \u00ab\u041a\u043e\u0435-\u0447\u0442\u043e \u043e\u0431 inode\u00bb. \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0438\u0445 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u043e\u0433\u0440\u043e\u043c\u0430\u0434\u043d\u043e\u0433\u043e \u0447\u0438\u0441\u043b\u0430 \u043c\u0435\u043b\u043a\u0438\u0445 \u0444\u0430\u0439\u043b\u043e\u0432. \u041d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u0443 \u043d\u0430\u0441 \u043f\u043e\u0440\u044f\u0434\u043a\u0430 \u0441\u043e\u0442\u0435\u043d \u0442\u0435\u0440\u0430\u0431\u0430\u0439\u0442 \u0442\u0430\u043a\u0438\u0445 \u0434\u0430\u043d\u043d\u044b\u0445. \u0418 \u043c\u044b \u043d\u0430\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0438\u0441\u044c \u043d\u0430 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0447\u0435\u0432\u0438\u0434\u043d\u044b\u0435 \u0438 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u0433\u0440\u0430\u0431\u0435\u043b\u044c\u043a\u0438 \u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u043e \u043f\u043e \u043d\u0438\u043c \u043f\u0440\u043e\u0448\u043b\u0438\u0441\u044c. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u0434\u0435\u043b\u044e\u0441\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27728,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36999","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0418\u0434\u0435\u044f \u0441\u0442\u0430\u0442\u044c\u0438 \u0440\u043e\u0434\u0438\u043b\u0430\u0441\u044c \u0441\u043f\u043e\u043d\u0442\u0430\u043d\u043d\u043e \u0438\u0437 \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043a \u0441\u0442\u0430\u0442\u044c\u0435 \u00ab\u041a\u043e\u0435-\u0447\u0442\u043e \u043e\u0431 inode\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0425\u0430\u043a\u0438 \u043f\u0440\u0438 \u0440\u0430\u0431\u043e\u0442\u0435 \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0447\u0438\u0441\u043b\u043e\u043c \u043c\u0435\u043b\u043a\u0438\u0445 \u0444\u0430\u0439\u043b\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0418\u0434\u0435\u044f \u0441\u0442\u0430\u0442\u044c\u0438 \u0440\u043e\u0434\u0438\u043b\u0430\u0441\u044c \u0441\u043f\u043e\u043d\u0442\u0430\u043d\u043d\u043e \u0438\u0437 \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043a \u0441\u0442\u0430\u0442\u044c\u0435 \u00ab\u041a\u043e\u0435-\u0447\u0442\u043e \u043e\u0431 inode\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:15:13+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:15:13+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Triki przy pracy z du\u017c\u0105 liczb\u0105 ma\u0142ych plik\u00f3w | ProHoster","description":"Pomys\u0142 artyku\u0142u zrodzi\u0142 si\u0119 spontanicznie z dyskusji w komentarzach do artyku\u0142u \u201eCo\u015b o inode\u201d.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0425\u0430\u043a\u0438 \u043f\u0440\u0438 \u0440\u0430\u0431\u043e\u0442\u0435 \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0447\u0438\u0441\u043b\u043e\u043c \u043c\u0435\u043b\u043a\u0438\u0445 \u0444\u0430\u0439\u043b\u043e\u0432 | ProHoster","og:description":"\u0418\u0434\u0435\u044f \u0441\u0442\u0430\u0442\u044c\u0438 \u0440\u043e\u0434\u0438\u043b\u0430\u0441\u044c \u0441\u043f\u043e\u043d\u0442\u0430\u043d\u043d\u043e \u0438\u0437 \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043a \u0441\u0442\u0430\u0442\u044c\u0435 \u00ab\u041a\u043e\u0435-\u0447\u0442\u043e \u043e\u0431 inode\u00bb.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:15:13+00:00","article:modified_time":"2019-10-31T19:15:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36999","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 05:41:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:35:26","updated":"2026-01-22 05:41:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/36999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=36999"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/36999\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/27728"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=36999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=36999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=36999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}