5 ms·

What is the real-world use for these features? Who is this built for? Modern drives will read data at 500MB/s, sometimes even more. Your log files are approa

What is the real-world use for these features? Who is this built for? Modern drives will read data at 500MB/s, sometimes even more. Your log files are approaching tens if not hundreds of gigabytes before a sequential read stops being a viable option. Tinies modicum of partitioning by date and source basically makes it a complete nothingburger.

otterley 2mo ago
It feels like you didn't read the design rationale, because the use cases and issues are listed therein. Maybe you don't see the value, but that doesn't mean it's not there for others. I certainly find its query features useful.
- rcxdude 2mo ago
  The point is that ripgrep will give you basically all the same query features just by being fast. A more structured format makes sense, but the indexing is not obviously adding value in most cases.
  - otterley 2mo ago
    The difference between grep/ripgrep and querying by field is the difference between a full table scan and an index query. Query performance is a very good reason to have databases. ripgrep is certainly fast, but it's still O(N). Doing complete file scans also trashes the OS's buffer cache.
    - brohee 2mo ago
      Writing multiple pages for a few hundred actual bytes also thrashes the OS cache...
      - otterley 2mo ago
        Not if you use the correct cache hint flags on the write.
    - pineapplepizza6 2mo ago
      [dead]
    - VGHN7XDuOXPAzol 2mo ago
      I really want to love journald (it sounds like it's aiming for a good system) but I share the other commenter(s)' frustration here about journald being slower than just pulling out ripgrep on regular files. We have some services at work that log to text files and some to journald. The log volume to file is >> the log volume to journald. Yet `rg query myservice.2026-08-01.log` seems to always wind up being faster and better than something like `journalctl -u myservice.service --since '2026-08-01' --until '2026-08-02' -g 'query'`. (The tab completion and discoverability is also better, I guess)
      - otterley 2mo ago
        What do the metrics look like in practice? seems is a bit too handwavy. I get that impressions matter, but data is actionable.
        bombela 2mo ago
        I have been complaining about journald abysmal performances for almost as long as I can remember. Here is my latest documented benchmark from 2023, which was slightly better than the one I ran in 2020. $ time journalctl > /tmp/all.log real 1m11.364s user 0m52.299s sys 0m6.540s $ time wc -l /tmp/all.log 3659597 /tmp/all.log real 0m0.152s user 0m0.056s sys 0m0.096s $ time journalctl | grep sshd | wc -l 12944 real 0m53.973s user 0m49.535s sys 0m5.210s $ time grep sshd /tmp/all.log | wc -l 12944 real 0m0.429s user 0m0.332s sys 0m0.100s https://github.com/systemd/systemd/issues/2460#issuecomment-1577671723 https://github.com/systemd/systemd/issues/2460#issuecomment-...
        marginalia_nu 2mo ago
        I'm no fan of journald, but I have some methodological issues with this test. The reads from /tmp/all.log are almost certainly cached since you just wrote the file, and will basically boil down to a memcpy call, rather than actual disk I/O. Speed difference isn't as big as you would think on a modern SSD, but it isn't nothing either. Running this between calls should flush the changes to disk and then drop the page cache, making for a fairer test. $ sudo sync $ echo 3 | sudo tee /proc/sys/vm/drop_caches
- marginalia_nu 2mo ago
  I did, and I still don't get why you would want this monstrosity over a structured append-only log file. If you want to index the data, you can do that when you roll over the file. That way you get the exact same robustness guarantees, without the insane architecture. Like ultimately it isn't even fast, journalctl is so bad at rendering text that it's approximately still as slow as seeking in a 400 MB .log-file using less. Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space.
  - otterley 2mo ago
    > Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space. That I agree with. I don't personally use journalctl much these days, particularly now that practically everything's a container and all their logs are getting shipped off-host for indexing. But I get why, 14 years ago, it was considered a good idea.

otterley 2mo ago

It feels like you didn't read the design rationale, because the use cases and issues are listed therein. Maybe you don't see the value, but that doesn't mean it's not there for others. I certainly find its query features useful.

rcxdude 2mo ago
The point is that ripgrep will give you basically all the same query features just by being fast. A more structured format makes sense, but the indexing is not obviously adding value in most cases.
- otterley 2mo ago
  The difference between grep/ripgrep and querying by field is the difference between a full table scan and an index query. Query performance is a very good reason to have databases. ripgrep is certainly fast, but it's still O(N). Doing complete file scans also trashes the OS's buffer cache.
  - brohee 2mo ago
    Writing multiple pages for a few hundred actual bytes also thrashes the OS cache...
    - otterley 2mo ago
      Not if you use the correct cache hint flags on the write.
  - pineapplepizza6 2mo ago
    [dead]
  - VGHN7XDuOXPAzol 2mo ago
    I really want to love journald (it sounds like it's aiming for a good system) but I share the other commenter(s)' frustration here about journald being slower than just pulling out ripgrep on regular files. We have some services at work that log to text files and some to journald. The log volume to file is >> the log volume to journald. Yet `rg query myservice.2026-08-01.log` seems to always wind up being faster and better than something like `journalctl -u myservice.service --since '2026-08-01' --until '2026-08-02' -g 'query'`. (The tab completion and discoverability is also better, I guess)
    - otterley 2mo ago
      What do the metrics look like in practice? seems is a bit too handwavy. I get that impressions matter, but data is actionable.
      - bombela 2mo ago
        I have been complaining about journald abysmal performances for almost as long as I can remember. Here is my latest documented benchmark from 2023, which was slightly better than the one I ran in 2020. $ time journalctl > /tmp/all.log real 1m11.364s user 0m52.299s sys 0m6.540s $ time wc -l /tmp/all.log 3659597 /tmp/all.log real 0m0.152s user 0m0.056s sys 0m0.096s $ time journalctl | grep sshd | wc -l 12944 real 0m53.973s user 0m49.535s sys 0m5.210s $ time grep sshd /tmp/all.log | wc -l 12944 real 0m0.429s user 0m0.332s sys 0m0.100s https://github.com/systemd/systemd/issues/2460#issuecomment-1577671723 https://github.com/systemd/systemd/issues/2460#issuecomment-...
        marginalia_nu 2mo ago
        I'm no fan of journald, but I have some methodological issues with this test. The reads from /tmp/all.log are almost certainly cached since you just wrote the file, and will basically boil down to a memcpy call, rather than actual disk I/O. Speed difference isn't as big as you would think on a modern SSD, but it isn't nothing either. Running this between calls should flush the changes to disk and then drop the page cache, making for a fairer test. $ sudo sync $ echo 3 | sudo tee /proc/sys/vm/drop_caches
marginalia_nu 2mo ago
I did, and I still don't get why you would want this monstrosity over a structured append-only log file. If you want to index the data, you can do that when you roll over the file. That way you get the exact same robustness guarantees, without the insane architecture. Like ultimately it isn't even fast, journalctl is so bad at rendering text that it's approximately still as slow as seeking in a 400 MB .log-file using less. Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space.
- otterley 2mo ago
  > Anyone with any sort of scale where you actually need indexing immediately drops journald and uses loki or elasticsearch instead. Journald is not even remotely a contender in that space. That I agree with. I don't personally use journalctl much these days, particularly now that practically everything's a container and all their logs are getting shipped off-host for indexing. But I get why, 14 years ago, it was considered a good idea.