[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 26/03/14 21:16, Simon Waters wrote: > On 25/03/14 18:58, bad apple wrote: >> >> What strange world do you live in where optimising the kernel on >> mission-critical production systems is "playing around"?!!! > > I'd regard it as playing around unless there was some clear problem for > which this was the only viable solution. > > Nearly everything I touch these day, including virtualization can be > handled by stock Debian kernels (or occasionally other distros). Whilst > I've had great fun tweaking kernels and building kernel modules in the > past, if I want reproducible behaviour, compatibility with third party > code etc, then the kernel will stay stock unless there is something > truly compelling. > > Woah, steady on there chief: kernel configuration is about as far from 'playing around' as it gets and in all the bigger and/or more sophisticated shops I've ever worked in it's considered an essential part of the long, complicated and thorough process of smoothing out the weak links in every stage of a production environment. Do I need to point out that stock kernels are exactly that: big, fat stupid blobs that by definition are the lowest common denominator configuration that will hopefully work for as many people as possible. Of course, this is absolutely fine for desktops, low-usage and non-specialised servers, 98% of all end users, etc. It's generally speaking not acceptable for workstations and 'proper' servers. Even things like AUFS being compiled in is a crapshoot (required for lxc-docker, etc) on distro-supplied stock kernels, just to pick one of countless issues. Hardening your systems will require (not merely perhaps find useful) kernel patching for things like PAX and GRSEC, swapping out CPU and IO schedulers as required for workload, inserting HBA drivers, etc, etc. I'm running servers and workstations with real time requirements, in-kernel-memory-dedupe (UKMSD) and support for super funky new cutting edge hardware. Tux-on-Ice (actually working hibernation support for Linux) isn't in any mainstream kernel I'm aware of (although I think some marginal players like Sabayon may ship it) and so on. I don't build custom kernels for fun, I build them because the situation warrants - actually, demands - it. It's *not* playing around (funnily enough, I'm also rather busy as well) and I'm frankly amazed that anyone would characterise it as that, especially without having the faintest idea what sort of things I'm working with. Funnily enough, we don't just randomly cock about in make xconfig either... *rolls eyes* Believe it or not, we have extremely strict documentation, build rules and testing/benching/QA procedures in place complete with revision control to work out of. Obviously enough, all of the shops where I do this consider the considerable effort, time and money required to perform this kernel tuning alongside all of the other stages from sysctl tweaks to network throughput tuning very worth their while. Are you guys next going to tell me you've never bothered to tune a MTU or TTL before? Jesus... Regards * Sorry if I sound a little peeved, strictly no offence intended to anyone but I seriously can't believe that two of you so far regard custom kernels as some kind of pointless voodoo that's only done by neckbeards for fun on their home slackware boxes. As you obviously know the kernel is the single most important bit of your entire Linux ecosystem (if you disagree, feel free to switch to GNU/Hurd or kFreeBSD/Debian and I'll wait here for you to come back crying when you have), was explicitly designed to be modular, tunable and rebuildable by end users and you neglect the potential of shaping it to your needs at your own peril :] After all, it wasn't me who posted with critical performance problems on my Linux server... probably because I don't have any. I wonder why! -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq