6 жилийн дараа systemd-journald нь хэт их хадгалах ачааллын асуудлыг хүлээн зөвшөөрсөн.

systemd төслийн хөгжүүлэгчид "systemd-journald" бүрэлдэхүүн хэсэгт удаан хугацаанд байсаар ирсэн архитектурын асуудлыг судалж, засаж эхэлсэн бөгөөд энэ нь диск рүү бичигдсэн өгөгдлийн хэмжээ (бичих олшруулалт) нь логын бодит хэмжээнээс хамаагүй өндөр байхад хүргэдэг.

Энэ түүх 2020 оны 3-р сараас эхтэй бөгөөд алдаа хянах системд ойролцоогоор 500 KB текст лог үүсгэх нь SSD дээр 700 MB-аас дээш физик бичих үйлдэл хийхэд хүргэдэг болохыг харуулсан тайлан гарсан. Systemd хөгжүүлэгчид энэ асуудлыг эрс үгүйсгэж, "та файлын систем хэрхэн ажилладагийг ойлгохгүй байна" гэж хариулж, профайл үүсгэхээс татгалзаж, "арга хэмжээ авах боломжгүй" гэсэн шийдвэрээр торгуулийг хаасан. Хөгжүүлэгчдийн сэтгэгдэл хэрэглэгчдээс олон зуун татгалзсан санал авсан боловч төслийн байр суурь өөрчлөгдөөгүй хэвээр байв.

2026 оны эхээр хоёр дахь асуудлын тайланг ирүүлсэн бөгөөд энэ үеэр бие даасан хөгжүүлэгч ValdikSS нь тусгаарлагдсан cgroup болон давталтын төхөөрөмжүүдийг ашиглан нарийвчилсан профайл үүсгэсэн бөгөөд энэ нь асуудал хэрхэн үүсдэг механизмыг тодорхой харуулсан: санах ойн зураглалтай файлууд (mmaps) болон хоёртын хэш хүснэгтүүдийг ашигласнаас болж 750 байт хэмжээтэй ганц текст мессеж бичихэд ч санах ойн хурууны хээ өөрчлөгдөж, 4 килобайтын бүтэн хуудсыг диск рүү цутгаж, блок төхөөрөмжийн түвшинд 50-70 KB I/O үүсгэхэд хүргэдэг.

Өчигдрийн Hacker News-ийн нүүр хуудсан дээрх мэдээлэл болон няцаашгүй синтетик туршилтууд нийтлэгдсэний дараа төслийн хөгжүүлэгчид өөрсдийн уриалгыг өөрчилж, journald-ийн кэш цэвэрлэх механизм болон индекс хадгалах бүтцийг оновчтой болгох чиглэлээр ажиллаж эхэлсэн.

Эх сурвалж: opennet.ru

DDoS хамгаалалт, VPS VDS сервер бүхий сайтуудад найдвартай хостинг худалдаж аваарай 🔥 DDoS хамгаалалттай, VPS VDS сервертэй найдвартай вэбсайт хостинг худалдаж аваарай | ProHoster