پس از ۶ سال، systemd-journald مشکل بار ذخیره‌سازی بیش از حد را پذیرفت.

توسعه‌دهندگان پروژه systemd شروع به مطالعه و رفع یک مشکل معماری قدیمی در مؤلفه "systemd-journald" کرده‌اند که باعث می‌شود مقدار داده‌های نوشته شده روی دیسک (تقویت نوشتن) به طور قابل توجهی بیشتر از حجم واقعی لاگ‌ها باشد.

این داستان به مارس ۲۰۲۰ برمی‌گردد، زمانی که گزارشی در سیستم ردیابی اشکال ثبت شد که نشان می‌داد تولید تقریباً ۵۰۰ کیلوبایت لاگ متنی منجر به بیش از ۷۰۰ مگابایت عملیات نوشتن فیزیکی روی SSDها می‌شود. توسعه‌دهندگان systemd این مشکل را به صراحت انکار کردند و با پاسخ «شما نحوه کار سیستم فایل‌ها را نمی‌فهمید» پاسخ دادند، از انجام پروفایلینگ خودداری کردند و تیکت را با حکم «غیرقابل پیگیری» بستند. اظهارات توسعه‌دهندگان صدها رأی منفی از کاربران دریافت کرد، اما موضع پروژه همچنان پابرجا ماند.

در اوایل سال ۲۰۲۶، گزارش دومی ارائه شد که طی آن، توسعه‌دهنده مستقل ValdikSS با استفاده از دستگاه‌های cgroup و loop ایزوله، پروفایل‌بندی دقیقی انجام داد و به وضوح مکانیسم وقوع این مشکل را نشان داد: به دلیل استفاده از فایل‌های نگاشت‌شده در حافظه (mmaps) و جداول هش دودویی، نوشتن حتی یک پیام متنی ۷۵۰ بایتی منجر به تغییر اثر انگشت‌های حافظه می‌شود و باعث می‌شود صفحات کامل ۴ کیلوبایتی به دیسک منتقل شوند و ۵۰ تا ۷۰ کیلوبایت ورودی/خروجی در سطح دستگاه بلوک ایجاد شود.

پس از گزارش صفحه اول دیروز Hacker News و انتشار آزمایش‌های مصنوعی غیرقابل انکار، توسعه‌دهندگان این پروژه لحن خود را تغییر داده و کار بر روی بهینه‌سازی مکانیسم‌های پاکسازی حافظه پنهان و ساختار ذخیره‌سازی شاخص journald را آغاز کرده‌اند.

منبع: opennet.ru

خرید هاست قابل اعتماد برای سایت های دارای حفاظت DDoS، سرورهای VPS VDS 🔥 خرید هاستینگ معتبر با محافظت در برابر حملات DDoS، سرورهای VPS و VDS | ProHoster