၆ နှစ်အကြာတွင် systemd-journal သည် သိုလှောင်မှုဝန်ထုပ်ဝန်ပိုး အလွန်အကျွံဖြစ်ခြင်းပြဿနာကို အသိအမှတ်ပြုခဲ့သည်။

systemd ပရောဂျက် တီထွင်သူများသည် "systemd-journald" အစိတ်အပိုင်းတွင် ရေရှည်တည်ရှိနေသော ဗိသုကာဆိုင်ရာ ပြဿနာကို လေ့လာပြီး ပြင်ဆင်နေကြပြီး ၎င်းသည် disk သို့ ရေးသားထားသော ဒေတာပမာဏ (write amplification) သည် log များ၏ တကယ့်ပမာဏထက် သိသိသာသာ မြင့်မားစေပါသည်။

ဒီဇာတ်လမ်းဟာ ၂၀၂၀ ခုနှစ် မတ်လကတည်းက စတင်ခဲ့တာဖြစ်ပြီး bug tracking system မှာ 500 KB ခန့်ရှိတဲ့ text log တွေကို ထုတ်လုပ်လိုက်တာကြောင့် SSD တွေမှာ physical write operation 700 MB ကျော် ဖြစ်သွားတယ်လို့ ပြသထားတဲ့ အစီရင်ခံစာတစ်စောင် တင်သွင်းခဲ့ပါတယ်။ systemd developer တွေက ဒီပြဿနာကို ပြတ်ပြတ်သားသား ငြင်းဆိုခဲ့ပြီး "filesystem တွေ ဘယ်လိုအလုပ်လုပ်လဲဆိုတာ မင်းနားမလည်ဘူး" လို့ တုံ့ပြန်ခဲ့သလို profiling လုပ်ဖို့လည်း ငြင်းဆန်ခဲ့ပြီး "လုပ်ဆောင်လို့မရ" လို့ ဆုံးဖြတ်ချက်ချခဲ့ပါတယ်။ developer တွေရဲ့ မှတ်ချက်တွေကြောင့် အသုံးပြုသူတွေဆီကနေ ရာနဲ့ချီတဲ့ downvote တွေ ရရှိခဲ့ပေမယ့် project ရဲ့ ရပ်တည်ချက်ကတော့ ခိုင်မာခဲ့ပါတယ်။

၂၀၂၆ ခုနှစ် အစောပိုင်းတွင် ဒုတိယပြဿနာအစီရင်ခံစာတစ်စောင်ကို တင်သွင်းခဲ့ပြီး၊ လွတ်လပ်သော developer ValdikSS သည် သီးခြား cgroup နှင့် loop devices များကို အသုံးပြု၍ အသေးစိတ်ပရိုဖိုင်ပြုလုပ်ခဲ့ပြီး ပြဿနာဖြစ်ပွားရသည့် ယန္တရားကို ရှင်းရှင်းလင်းလင်း ပြသခဲ့သည်- memory-mapped files (mmaps) နှင့် binary hash table များကို အသုံးပြုခြင်းကြောင့် 750-byte text message တစ်ခုတည်းကို ရေးသားခြင်းသည်ပင် memory fingerprints များကို ပြုပြင်မွမ်းမံစေပြီး 4-kilobyte စာမျက်နှာအပြည့်အစုံကို disk သို့ flush လုပ်ကာ block device level တွင် ရလဒ် I/O 50 မှ 70 KB အထိ ထုတ်လုပ်ပေးသည်။

မနေ့က Hacker News ရဲ့ မျက်နှာဖုံးအစီရင်ခံစာနဲ့ ငြင်းလို့မရတဲ့ synthetic tests တွေ ထုတ်ဝေပြီးနောက်၊ project ရဲ့ maintainers တွေဟာ သူတို့ရဲ့ အသုံးအနှုန်းတွေကို ပြောင်းလဲပြီး journald ရဲ့ cache flushing mechanisms တွေနဲ့ index storage structure ကို optimize လုပ်ဖို့ စတင်လုပ်ဆောင်ခဲ့ကြပါတယ်။

source: opennet.ru