3 ms·

> My results don't match your conclusion. Alright. Let me entertain you. In the data I provided, counting the lines in a big log file was 469.5 times faster t

> My results don't match your conclusion. Alright. Let me entertain you. In the data I provided, counting the lines in a big log file was 469.5 times faster than journalctl took to output all the logs. From this information alone, it seems difficult to believe that journalctl --grep can be faster. Both had to read every single line of logs. But it was on a rather slow machine, and a couple years ago. Here /var/log and the current directory are on a "Samsung SSD 960 PRO 512GB" plugged via m2 nvme, formatted in ext4 and only 5% used. Though this shouldn't matter as I ran every command twice and collected the second run. To ensure fairness with everything in cache. The machine had 26GiB of buffer/cache in RAM during the test, indicating that everything is coming from the cache. In my tests, journalctl was ~107 times slower than rg and ~21 times slower than grep: - journalctl: 10.631s - grep: 0.505s - rg: 0.099s journactl also requires 4GiB of storage to store 605MB of logs. I suppose there is an inefficient key/value for every log line or something. For some reason journalctl also returned only 273 out of 25402 lines. It only returns one type of message "session closed/opened" but not the rest. Even though it gave me all the logs in the first place without `--grep`?! Let me know if I am still using it wrong. $ sudo hdparm -tT /dev/nvme0n1 /dev/nvme0n1: Timing cached reads: 33022 MB in 1.99 seconds = 16612.96 MB/sec Timing buffered disk reads: 2342 MB in 3.00 seconds = 780.37 MB/sec $ du -hsc /var/log/journal 4.0G /var/log/journal 4.0G total $ time journalctl > logs real 0m31.429s user 0m28.739s sys 0m1.581s $ du -h logs 605M logs $ time wc -l logs 3932131 logs real 0m0.146s user 0m0.065s sys 0m0.073s $ time journalctl --grep=sshd | wc -l 273 real 0m10.631s user 0m10.460s sys 0m0.172s $ time rg sshd logs | wc -l 25402 real 0m0.099s user 0m0.042s sys 0m0.059s $ time grep sshd logs | wc -l 25402 real 0m0.505s user 0m0.425s sys 0m0.085s PS: this way of using rg doesn't ignore any files, it is not used to find files recursively. But I don't have a .gitignore or similar in my /var/log anyways.

godelski 1y ago
> Let me know if I am still using it wrong. You're not using it wrong, but you are measuring wrong. Check out the filetype of the journal files $ file -bi /var/log/journal/1234blahblah/system@foobardedoopdedo.journal application/x-linux-journal; charset=binary Your measurement procedure is wrong because the `journalctl` command is doing something different. It isn't just reading a plain file, it is reading a binary file. On the other hand, `grep` and `rg` are reading straight text. > it seems difficult to believe that journalctl --grep can be faster. Why? It could be doing it in parallel. One thread starts reading at position 0 and reads till N, another starts at N+1 and reads to 2N, etc. That's a much faster read operation. But I'm guessing and have no idea if this is what is actually being done or not. P.S.: I know. As I specified in my earlier comment, I get burned with build artifacts and project logs. Things that most people would have in their .gitignore files but you can sure expect to grep through when debugging.
- burntsushi 1y ago
  Their measurement isn't wrong. It's demonstrating the exact point in question: that if the logs were just stored in plain text, then grepping them would be an order of magnitude faster (or multiple orders of magnitude in the case of ripgrep) than whatever `journalctl --grep` is doing.
  - godelski 1y ago
    Their measurements are wrong because the journalctl command is also performing a decompression operation. THEY ARE NOT DOING THE SAME THING > that if the logs were just stored in plain text So store them in plain text then cat /etc/systemd/journald.conf https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html
    - burntsushi 1y ago
      How it's doing the search is irrelevant. What's being measured here is the user experience. This isn't some kind of attempt to do an apples-to-apples grep comparison. This is about how long you have to wait for a search of your logs to complete.
- bombela 1y ago
  What matters in this discussion is the outcome. For the exact same logs: journalctl takes 10s to search through 4GiB. And misses most of the matches. (rip)grep takes (0.1)0.5s to search through 605MiB. In other words. journalctl consumes much more space, and a lot more time, to return an order or magnitude less results to the same query. What does journalctl offers, that makes this resource, time and correctness tradeoff worth it?

godelski 1y ago

> Let me know if I am still using it wrong. You're not using it wrong, but you are measuring wrong. Check out the filetype of the journal files $ file -bi /var/log/journal/1234blahblah/system@foobardedoopdedo.journal application/x-linux-journal; charset=binary Your measurement procedure is wrong because the `journalctl` command is doing something different. It isn't just reading a plain file, it is reading a binary file. On the other hand, `grep` and `rg` are reading straight text. > it seems difficult to believe that journalctl --grep can be faster. Why? It could be doing it in parallel. One thread starts reading at position 0 and reads till N, another starts at N+1 and reads to 2N, etc. That's a much faster read operation. But I'm guessing and have no idea if this is what is actually being done or not. P.S.: I know. As I specified in my earlier comment, I get burned with build artifacts and project logs. Things that most people would have in their .gitignore files but you can sure expect to grep through when debugging.

burntsushi 1y ago
Their measurement isn't wrong. It's demonstrating the exact point in question: that if the logs were just stored in plain text, then grepping them would be an order of magnitude faster (or multiple orders of magnitude in the case of ripgrep) than whatever `journalctl --grep` is doing.
- godelski 1y ago
  Their measurements are wrong because the journalctl command is also performing a decompression operation. THEY ARE NOT DOING THE SAME THING > that if the logs were just stored in plain text So store them in plain text then cat /etc/systemd/journald.conf https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html
  - burntsushi 1y ago
    How it's doing the search is irrelevant. What's being measured here is the user experience. This isn't some kind of attempt to do an apples-to-apples grep comparison. This is about how long you have to wait for a search of your logs to complete.
bombela 1y ago
What matters in this discussion is the outcome. For the exact same logs: journalctl takes 10s to search through 4GiB. And misses most of the matches. (rip)grep takes (0.1)0.5s to search through 605MiB. In other words. journalctl consumes much more space, and a lot more time, to return an order or magnitude less results to the same query. What does journalctl offers, that makes this resource, time and correctness tradeoff worth it?