Re: limiting the (systemd) journal size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, Sep 27, 2022, at 12:13 PM, Daniel P. Berrangé wrote:
> On Tue, Sep 27, 2022 at 10:12:57AM -0600, Chris Murphy wrote:
>> Hi,
>> 
>> Fedora uses systemd-journald for system logging. By default it is a
>> persistent log kept on /var, and uses up to 4G disk space, although
>> in certain circumstances it can go a bit higher. See 'man journald.conf'
>> for details.
>
> snip
>
>> The obvious bike-shedding questions are:
>> Is 4G is too much or too little? If so what amount it should be?
>> Is size still the correct approach? Or should we consider a max
>> retention time? And if so, what would it be and how granular
>> should it be?
>
> In context of modern physical machines, 4G is probably barely
> noticeable for most people, given common physical disks measure
> 100's of GBs as a starting point.

Dual-boot is pretty common, and so are 128G NVMe drives in new laptops. So it's "sufficiently not rare" that Fedora is being installed into less than 50G that it needs to be accounted for.


>
> Some people run Fedora on pretty old hardware where disk sizes
> may be more limited.
>
> Virtual machines are probably the place with the biggest disk
> usage constraints where, 4GB could be pretty impactful when
> a VM may only have a few 10's of GB of storage purchased.

Agree. It is possibly similar to the small storage cheap dual-boot baremetal case.


> You mentioned '10%' earlier, is that is another existing
> limit that's already applied, in addition to the 4GB absolute
> size limit ?

Yes. SystemMaxUse= defaults to 10% of the file system size, capped to 4G. I'm not certain this is a hard limit, i.e. I think if journals take up just under 4G and a new journal file can be created, it's allowed to grow to the max size which I think is 128M (I've only ever seen 128M sized journals, so it's anecdotal evidence not man page or code based). So it could plausibly grow to ~4.1GiB?


> If so that'd obviously benefit the small disk
> scenarios.  A relative limit is going to be way oversized
> for large disk scenarios though.
>
> Both absolute and relative size limits look complementary
> and neccessary.

Currently SystemKeepFree= is 15% of file system size. Once free space goes below that limit, systemd will stop growing its usage, but won't reduce its usage.


> I wonder if max retention is actually useful at all though,
> at least for generic out of the box usage
>
> For systems with low rate of logging, the size of the journal
> will grow slowly enough that max retention won't have a notable
> impact for along time.
>
> For systems with high rate of logging, a generic max retention
> probably won't be aggressive enough to constrain the disk usage
> quickly enough to stop problems arising.
>
> Max rentention time doesn't take into account available disk
> storage in any way.

Correct, it allows a significant float based on usage, consider space consumption relatively less important than the value reduction of the journal entries over time. This is what rsyslogd does, which I think its default retention is two weeks (?) and is configurable. If you think most users most of the time have no need or expectation of needing journal entries beyond X weeks, then you'd presumably be a proponent of a relatively more dominant retention time policy (while still allowing for the max use limit).

>
> While there might a sweet spot, its effectiveness looks to
> be somewhat limited, narrow in scope & unlikely to please a
> broad enough userbase. IOW, combination of abs+rel size limits
> look a more generally effective OOTB setting to avoid storage
> over use.
>
> Max retention time looks most relevant/useful as a mechanism for
> implementing organizational policies on data record keeping times,
> and quite site specific.

True but also pretty common in the era before systemd-journald in which it really was predominately time based rentention.

-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux