Hacker News Reader

Comment by bombela | Hacker News Reader

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-...

View on HN

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

I tried similar. Each command looped 5 times, ignore the best and worst times, and average the mean three.

    journalctl >/tmp/all.log  0m59.763s
    journalctl | grep -c sshd 0m57.767s  (otherwise >all is the only example encumbered by write speeds)
    wc -l /tmp/all.log        0m0.336s
    grep -c sshd /tmp/all.log 0m1.776s

You didn't use the query feature of journalctl, so you basically had it do an entire table conversion. Of course that's not going to show its performance value.

This is what you should be running for a proper comparison:

1. `echo 3 | sudo tee /proc/sys/vm/drop_caches`

2. `time journalctl -u ssh.service >/dev/null`

3. `journalctl >/tmp/all.log`

4. `echo 3 | sudo tee /proc/sys/vm/drop_caches`

5. `time grep -q sshd /tmp/all.log`

Reply on news.ycombinator.com