That is interesting and if someone posts details I am definitely interested.  Always looking to test new distros and see performance.

“seriously outperform”? Is there really substantial performance gains of one Linux distro over another? I mean..you can have some ‘fluff’ installed which could slow things down. But, for ‘standard’ Linux OS installs, are there really any great performance gains shown for one distro over another? I haven’t been into Linux long, but I’d be curious of this as well. Won’t change what we use in-house, but from a knowledge-gaining standpoint, would be curious to see; actually, any perf metrics amongst different Linux distros would be worthwhile to see, if there are any.

You tend to see sometimes emotions come into play. Remember the old Windows vs Linux wars of the 90s’? That used to happen to some extent among Linux folks too. I got attacked on a forum once because I said that I found gentoo a bit of a learning curve. Now mainly you see what I call the RPM vs APT going on (Centos/Redhat vs Ubuntu/Debian). Still it has never been too vicious but when someone states some big claims like I heard I start to wonder if this is just a preference thing or is there any truth to it.

Oh yes...I do remember. Oh, the days  

Even so though...if there are some kind of perf metrics amongst differing Linux distros, I’d like to see them. Let’s just say for argument’s sake, Rock is higher performing. Is it “that much” higher performing? Is it really due to the kernel, or is it due to the underlying storage & storage config it’s installed on? 

Well to be fair Ubuntu was more bleeding edge than Centos. Centos as well was backed up by a Corporate proprietary Red Hat. The kernels would be the same I think? That is too deep for me. Networking stacks? I mean back in the early 2000’s I definitely saw better performance on Linux programs that had been ported to FreeBSD. Keep in mind I was using the FreeBSD port system that was not just pushing out the same package for everyone but with the port system it build the package specifically for you system, lean and very mean https://docs.freebsd.org/en/books/handbook/ports/. Still alive and well today. Makes me want to boot up a VM and play around with it again. I had it working as a Squid proxy and authentication server for a small work network and it was great. That is 20 years ago… ah.. mid life crisis strikes again… I must focus on posting only on Kubernetes makes me feel young :)

RH has systems like that now with ‘minimal’ installs. I don’t believe Debian systems do, but could be wrong. Even so, I would think, even if ‘minimal’ installs showed better performance, would it even be noticeable from an end-user standpoint? I mean, regardless of distro, to your point...the underlying kernel is generally the same.

If I remember correctly, Anton shared some performance comparison between different Linux distributions in one of the digests. And there were differences, but not that huge. Let's see if I can look it up.

Hmm...don't recall seeing that one; or, I just looked over it  Let me (us) know if you find it @regnor 

Yup they all should have mini-install or net install variations

I say this because I remember the pain I caused myself doing a Debian minimum install and then finding out how much more I actually needed :) 

On that note the most difficult (due to its crazy hardening and security) to maneuver in is OpenBSD.. https://www.openbsd.org/

Also no matter what Linux you are using you can really cut it down to the bare bones. But if we are talking just default Rocky and Default Ubuntu then I can’t see there being a huge difference and like Regnor said Veeam surely would have seen this when they were doing support tests.

“they all should have mini-install” Agree..the only downside to minimal installs is the lack of actually needed troubleshooting tools being installed. Depending on the need of the system, they may not be needed. I always like having them though, cuz you never know! 

Very true! Believe me with containers that feeling is taken to an all new level. I remember when I first learned how to get a shell in a container and at first had that warm cozy feeling.. oh look this one even has bash (many don’t and only have sh, and many others don’t even have a shell!), but then I went to use some of my usual troubleshooting tools. On a side note that is one of the important parts of Kubernetes security (containers in general), preventing bad actors from getting too many privileges in a container an then being able in various ways to add binary files in the container.

Ok Folks you have inspired me. Come on over to the Kubernetes Korner where I am going to create a post on what I was talking about, i.e. being a bad guy! Give me a few min to type it up and create some screenshots!!

Great post Geoff

Any time I hear something about substantial performance gains, I wonder what had to be done to get those performance gains.  My thought process goes back to the discussions Anton had about using software-based RAID on prosumer and small business NAS’s like QNAP and Synology - what shortcuts were taken to give that better performance, and does it affect reliability and data integrity?  Perhaps that’s an apples and oranges comparison, but it still makes me wonder when something newish and unproven-ish comes out with bold claims and I need to see the results and I’ll let others be the pioneers testing that out for the long run to determine if it’s reliable.  Since I’m more of a windows guy, when I do venture into Linux territory, I’d rather have slower but proven and reliable because I can get out of my element quickly if things go south and it’s not something I’m terribly familiar with.

@coolsport00 Well I can't seem to find the digest I was looking for; there are just too many of them Probably the easiest would be to setup different distributions and do some real-life comparison.

I have quite a few of his old digest emails as well. I tried to do a search in OWA, but it didn’t work too well. And, if I didn’t feel some of his digests were relevant to me, I deleted them, so I didn’t have all of the messages. So I may not even have that specific one.   Thanks for checking though

Speaking of Nerd wars… this week I met someone still fighting the Systemd vs SysV init wars… :) I understand both sides of the argument and realize that in the *nix world change just for change sake is detested (which was not the case in the above situation) but wow I thought that was now a done thing.

This depends: There’s many different versions with different kernels available:

Ubuntu talks about it here: https://ubuntu.com/kernel.  and herehttps://ubuntu.com/kernel/lifecycle

Ubuntu 22.04.1 LTS  is supported with a v5.15 kernel. However one could also get this supported version: Ubuntu 20.04.0 LTS with kernel v5.4. Then there’s the non-LTS versions.

RedHat: Similar: https://access.redhat.com/articles/3078

Suse: Similar: https://www.suse.com/support/kb/doc/?id=000019587

I did a quick test with Rocky Linux 9.2 and the latest Veeam Hardened ISO (Ubuntu 20.04):

• Same hardware
• Same source VMs
• virtual hotadd proxy
• repository attached via 10GE

Of course this is no detailed benchmark, but in this case both distributions performed exactly equally and the limiting component has been the 10GE connection.

I did a quick test with Rocky Linux 9.2 and the latest Veeam Hardened ISO (Ubuntu 20.04):

• Same hardware
• Same source VMs
• virtual hotadd proxy
• repository attached via 10GE

Of course this is no detailed benchmark, but in this case both distributions performed exactly equally and the limiting component has been the 10GE connection.

 

This is interesting to see that they are pretty much equal in speeds.  Thanks for sharing this Regnor.

I did a quick test with Rocky Linux 9.2 and the latest Veeam Hardened ISO (Ubuntu 20.04):

• Same hardware
• Same source VMs
• virtual hotadd proxy
• repository attached via 10GE

Of course this is no detailed benchmark, but in this case both distributions performed exactly equally and the limiting component has been the 10GE connection.

 

Appreciate that.  Curious where the expected speed increase, if any, can be seen, but because this looks pretty similar.

Maybe differences can be only be seen when the repository is under high load. Or when it's doing proxy and repository together.

Perhaps @Geoff Burke can get some more details?