Cik ilgā laikā var izdzēst miljonu mapju?

Lai arī studijas Latvijas Universitātē esmu beidzis jau vairākus gadus atpakaļ, no tām man "mantojumā" ir palicis serveris
ante.lv, kuru savulaik izmantojām dažādu atvērtā pirmkoda rīku (FTP failu apmaiņai, Subversion versiju kontrolei, tīmekļa servera ar XWiki u.c.) darbināšanai. Serveris praktiski bez izmaiņām ir darbojies kopš 2015. gada. Ja neskaita vispārīgu Sigmanet resursu pārraudzību un servera pārraudzību ar Munin, tas praktiski gadiem ir dzīvojis kā nepieskatīts bārenis (vai patstāvīgs pieaugušais, ja serveru gadus rēķina kā suņu gadus.)

Pirms pāris dienām no Munin saņēmu e-pastu, ka šim serverim ir bīstami piepildīts disks.

Katrs zina, ka diskā var ierakstīt tikai noteiktu daudzumu datu (parasti daudzus simtu GB vai dažus TB), bet bez tā diskā ir ierobežots arī maksimālais failu un mapju skaits. Ja operētājsistēma un failu sistēma ir sakarīga (t.i. 64-bitu operētājsistēma un EXT4 failu sistēma, kas ir Linux standarts¹), tad šis skaits ir tik liels, ka pieejamais failu un mapju skaits parasti netiek izsmelts, jo failu datiem vietas pietrūkst ātrāk. Bet šim serverim diskā izlietotais datu apjoms bija normāls²:

Tam nez' kāpēc sāka trūkt failu un mapju rādītāja ierakstiem, jeb "inodēm" atvēlētā vieta:

Kā redzams, no rezervētajām 1,2 miljoniem bija izlietoti ap 1,1 miljoni, brīviem paliekot "tikai" nepilniem 100 tūkstošiem ierakstu. Lai satura rādītāja "inodēm" sāktu trūkt vietas, failiem ir jābūt ļoti daudziem un ļoti maziem. Vispirms es turēju aizdomās uz servera ejošo Yacy vienraga meklēšanas dzinēju, bet tur vaina (it kā)³ nebija.

Lai arī visu žurnāla failu arhivēšana notiek automātiski, kaut kas tur var aizķerties, tāpēc izpildīju laika gaitā papildinātu skriptu, kura saturs ir sekojošs:

Tas izdrukāja:

un tad praktiski apstājās. Sapratu, ka kaut kas nav labi ar failu meklēšanu var mapē. Ātrdarbības uzlabošanai, tīmekļa serviss uz šī servera iet ar kešošanu, kas glabā visus XWiki dinamiski un tāpēc lēnāk ģenerētos datus kā statiskus HTML failus. Lai arī keša attīrīšana darbojas automātiski, pieņēmu, ka kaut kas tajā ir salūzis. Izpildīju komandu:

Serveris pēc teju stundu ilgām pārdomām atgrieza:

Tomēr, izmantoto inožu apjoms diskā praktiski nemainījās.

Pēc StackExchange padoma mēģināju sameklēt, kurā tieši vietā mapē ir šis nenormālais failu/mapju apjoms, bet nespēju sagaidīt skripta beigas. Uz cita servera skripts ar aptuveni 300 tūkstošiem failu (gan vienu, gan otru variantu) izpildījās aptuveni 2 minūtēs, bet uz ante.lv likās, ka es no garlaicības nomiršu ātrāk, nekā tas parādīs atbildi.

Beigās sapratu, ka jāstrādā vien pašam ar savu prātu (un rokām) un pakāpeniski pildīju šādas komandas:

Sliktā/aizdomīgā mape bija tā, kuras nosaukums tika izdrukāts, bet apnika gaidīt meklējuma rezultātu. Tā pamazām atklāju, ka / mapē sliktā mape bija var, tajā — apache2, bet tajā — mod_disk_cache.

mod_disk_cache mapē Apache keša serviss glabā HTML failus, kuru atrašanās vietu nosaka faila satura jaucējsumma, pierakstīta Base-64 kodējumā. Katrā no mapes līmeņiem ir ap 100 mapēm, kurā atkal ir ap 100 mapēm, tad vēl un vēl ap 100 mapēm, kurās (ja ir) atrodas kešotie HTML faili:

Lai arī regulāri izsauktais htcacheclean process izdzēš vecos HTML failus, atklājās, ka tas neizdzēš tukšās mapes un pēc vairāku gadu servera darbības /var/cache/apache2/mod_disk_cache mapē bija pāri miljonam apakšmapju, vairums ko kurām bija tukšas. Rezultātā, diskā sāka trūkt vietas satura rādītāja "inodēm", bet pieejamais apjoms failu datiem pietika.

Kad sapratu vainu, risinājums bija vienkāršs.

Apturēju apache serveri:

Un liku izdzēst visu mapi:

(Vispirms dzēšanas komandu palaidu kā interaktīvu procesu, bet tad sapratu, ka tas ies tik ilgi, ka ir jāatstāj kā fona process ar & komandas beigās, jāatstāj serveris strādājot un jāiet gulēt.)

Es pārvaldu vairākus serverus, kuros darbojas Apache tīmekļa serviss ar kešošanu, bet līdz šim nevienu serveri nebiju darbinājis tik ilgi, lai pamanītu, ka mapju skaits kešā tikai pieaug. Iespējams, ka serveri kāds ļaunprātis bija pārbaudījis uz izturību, jo Munin pārskatā redzam, ka izmantoto inožu apjoms straujāk ir pieaudzis pēdējo mēnešu laikā:

Nākamajā rītā apskatījos, ka mape ir izdzēsta un diska "satura rādītājs" ir atbrīvots:

Atjaunoju jaunu, tukšu keša servisa mapi, uzliku pieejas tiesības un palaidu Apache servisu:

No Munin pārraudzības grafika noteicu, ka 1087706 mapes ir izdzēstas divu stundu laikā, jeb aptuveni 150 mapes sekundē.

Tālākais uzskatāmi parāda, ka atkarībā no tā, kā mēra laiku un darbu, miljonu mapju var izdzēst acumirklī vai tikai vairākās dienās:

1. Ja zinat, ko likt dzēst, komandas ievade prasa tikai sekundi⁴.
2. Ja nezinat, kur ko dzēst, tad meklēšanā un risināšana — stundu.
3. Ja skaita tikai servera laiku mapju dzēšanai — divas stundas.
4. Ja skaita problēmas risināšanā patērēto darbu kopā ar garlaikošanos, gaidot komandu rezultātus (un fonā darot ko citu) — 4 stundas.
5. Ja skaita problēmas risināšanas sākumu līdz tās pilnīgai atrisināšanai nākamajā dienā — 14 stundas.
6. Ja skaita laiku no pirmā Munin saņemtā problēmas ziņojuma un problēmas atrisināšanai — trīs dienas.

1. ^ Piemēram, 32-bitu Windows ar FAT32 failu sistēmu, maksimālais failu skaits var būt tikai daži simti tūkstošu failu, ar ko serverim dažkārt var pietrūkt.
2. ^ Šeit un turpmāk, praktiski visas komandas ir pildītas ar root lietotāja tiesībām.
3. ^ Meklējot vainas vienmēr jāpamana, kad vērts pārtraukt "rakt" vienā izvēlētajā virzienā, jo var gadīties, ka vaina nav tur, un ir "jārok" kaut kur citur.
4. ^ Pirms komandas apstiprināšanas tiek stingri rekomendēts to pārlasīt un apdomāt vismaz dažas sekundes.