752 baiti. Tik liels ir viens systemd-journald ieraksts ar visiem iekšējiem laukiem, ja to izvada kā JSON. Izstrādātājs ar segvārdu ValdikSS 3. augustā nomērīja, cik daudz journald šī viena ieraksta dēļ patiesībā uzraksta diskā: uz ext4 vismaz 55 kilobaiti, uz btrfs 108 kilobaiti.
Skaitļi parādījās systemd kļūdu ziņojumā 40262, ko 3. janvārī atvēra lietotājs XANi. Viņa Debian 13 virtuālā mašīna ar systemd 257.9 rakstīja divas žurnāla rindas sekundē, bet hipervizors tai rādīja ap 50 diska operāciju sekundē. Tas pats bija pieteikts jau 2020. gadā. Toreiz ziņojumu aizvēra ar argumentu, ka iotop rādījumi neesot ticami, tāpēc šoreiz mērīts citādi.
Cilpas ierīce tmpfs iekšā
journald raksta savos failos caur mmap, tāpēc parastie ievadizvades mērītāji tam neder. ValdikSS izveidoja atsevišķu ext4 cilpas ierīci tmpfs atmiņā, piemontēja to uz /var/log/journal un tad lasīja divus skaitītājus: bloku ierīces statistiku no /sys/block un journald cgroup failu io.stat. Sistēma testa laikā bija pilnīgi klusa, saspiešana izslēgta, SyncIntervalSec uzstādīts uz 10 sekundēm. Kodola atlikto ierakstu taimeri viņš nogrieza līdz sekundes daļām, lai skaitītāji rādītu izmaiņas uzreiz pēc katras testa komandas.
Rezultāts: viena komanda logger -p info test deva vismaz 55 kilobaitus ierakstu. Desmit tādas pašas rindas pēc kārtas deva to pašu apjomu. Četrpadsmit ziņojumu sērija saskaitījās 386 kilobaitos bloku līmenī, no kuriem 319 kilobaitus cgroup skaitītājs piedēvēja tieši journald procesam.
Uz btrfs ar izslēgtu kopēšanu rakstīšanas laikā (chattr +C) viens ziņojums journald cgroup skaitītājā deva 110 592 baitus. Bloku līmenī pirmais ziņojums pēc testa sākuma savāca ap 420 kilobaitiem, jo failu sistēma katru izmaiņu liek jaunā vietā un līdzi pārraksta metadatus.
Salīdzinājumam viņš to pašu teksta rindu pievienoja parastam failam ar dd un abiem sinhronizācijas karodziņiem. Tas maksāja no 4 līdz 7 kilobaitiem, tas ir, vienu vai divus diska blokus. Tāpat strādā vecais syslog.
Kā tas izskatās uz reāla datora, aprīlī parādīja cits ziņojuma dalībnieks. Viņš meklēja sava datora periodiskās bremzēšanas iemeslu un sākumā turēja aizdomās videokarti. Tad iotop uzkrāšanas režīms parādīja, ka 15 minūtēs journald diskā ir ierakstījis gandrīz 7 gigabaitus, bet 22 minūtēs jau gandrīz 11 gigabaitus. Paralēli žurnālā atkārtojās paša journald paziņojums, ka atmiņas spiediena dēļ tas iztukšo kešatmiņu.
SyncIntervalSec nenozīmē to, ko daudzi domā
Pa ceļam atklājās vēl viena lieta. journald neuzglabā ierakstus atmiņā līdz nākamajai sinhronizācijai. Tas raksta pastāvīgajā failā uzreiz, bet pēc SyncIntervalSec tikai izsauc fsync. Iestatījums, ko daudzi rokasgrāmatās lasa kā ierakstu buferēšanu, tātad samazina vienīgi sinhronizācijas izsaukumu skaitu.
journald ieraksta katru rindu diskā. SyncIntervalSec ir tikai fdatasync un fsync aizture, nevis datu ieraksta aizture.
Trīs versijas par vainīgo
13. augustā ziņojumā ierakstījās kodola izstrādātājs Andy Lutomirski. Viņš pirms gadiem bija uzbūvējis datubāzi, kas ar mmap pievieno ierakstus žurnālam, gājis ar to uz LSF/MM konferenci un rakstījis kodola ielāpus, lai mmap ieraksti sāpētu mazāk. Ielāpi joprojām nav pieņemti. Viņa secinājums par savu darbu bija skarbāks: dizains bija nepareizs un pwrite būtu bijis daudz labāks.
Ziņojuma autors XANi tam nepiekrīt. Viņš uzskata, ka vainīgs ir formāts: katrs ieraksts atkārto boot ID un citus laukus, kas jau ir kaimiņu ierakstos, bet meklēšanai noderīga indeksa nav. Tāpēc formāts ir dārgs gan rakstīšanā, gan lasīšanā. Hacker News diskusijā to pašu apraksta komentētājs, kas savulaik pats laboja journald kļūdas: dati vienā failā ir izkaisīti pa nesaistītām nobīdēm, kuras ir mazākas par diska bloku, tāpēc katra sīka izmaiņa liek pārrakstīt visu bloku.
Trešā versija nāk no failu sistēmu puses. 14. augustā ziņojumā tika ielikts bcachefs autora Kent Overstreet komentārs no Reddit, kur viņš pēc pārbaudes uz XFS raksta, ka mmap ieraksti ir sabojāti visās failu sistēmās kopš lielo folio ieviešanas kodolā. Tam pievienotais komentārs piebilst, ka mākoņu pakalpojumu sniedzēji folio tāpēc neizmanto.
Ko var darīt tagad
Ziņojumā minēti četri risinājumi, kas nav labojums.
Storage=volatilefailā journald.conf tur žurnālu tikai atmiņā. Darbvirsmai der, serverim ar auditu ne.- ext4 montēšanas iespēja
lazytimeretāk atjaunina inode laika zīmogus diskā. LogFilterPatterns, kas pieejams no systemd 253, ļauj apklusināt konkrētus pakalpojumus.- rsyslog raksta parastu tekstu, tāpēc atgriež ierakstus pie viena vai diviem blokiem.
Saspiešanas izslēgšana, ko iesaka pirmais komentārs ziņojumā, XANi gadījumā neko nemainīja: viņa žurnāla rindas bija pārāk īsas, lai saspiešana vispār ieslēgtos.
Seši gadi bez uzturētāja atbildes
Pirmo reizi šo pašu problēmu pieteica 2020. gada 1. aprīlī. Autors rādīja, ka 4049 žurnāla rindas ar kopējo teksta apjomu 488 kilobaiti izraisīja vairāk nekā 700 megabaitus ierakstu uz SSD. Ziņojumu aizvēra 2021. gada 11. februārī bez labojuma. Tagad mērījumi nāk no bloku ierīces un cgroup skaitītājiem, taču zem ziņojuma 40262 kopš 3. janvāra ir 15 komentāri un neviens no tiem nepieder systemd uzturētājam. 14. augustā daļa XANi komentāru par faila formātu tika paslēpti kā tēmai neatbilstoši.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.