Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why and how we’re migrating many of our servers from Linux to the BSDs

it-notes.dragas.net

Post reply on HN
Print view View original

41–50 of 237 posts

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#41

Post by inopinatus »

mmooss wrote: post #39
pilingual wrote: post #35

Earlier quoted context omitted.

Ah, pair. Reminds me of this gem: http://www.archub.org/ycoutage.txt

Seems reasonable to me: ... This site and this directory were driving up server load averages, which causes instability for all users on this server. Our block on this site appears to have blocked over 150,000 connections in about half an hour. This is simply more than is appropriate for a shared server. You may want to review your domain's traffic logs to see what kind of traffic this site is getting. The logs for t…

Sure, it's reasonable, if your desired outcome is to lose a customer by

a) demonstrating a lack of burst or headroom capacity and/or graceful degradation/priority scheduling capability, and

b) being a dick about it.

Alternatively one may intervene with a positive approach and framing viz. "we have temporarily [provisioned additional capacity / relocated your storage to another spindle / mirrored your content to a less congested host / etc] in order to handle your traffic, can we call you tomorrow to move you to a service plan that can handle your growth". Even just throttling the account in some appropriate fashion would've been better than the blunt "we dropped you like a hot potato" that was actually communicated. This was in 2010, by which time any ISP that wasn't operating as amateur hour had the tools for all these things.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#42

Post by [deleted] »

mmooss wrote: post #39
pilingual wrote: post #35

Earlier quoted context omitted.

Ah, pair. Reminds me of this gem: http://www.archub.org/ycoutage.txt

Seems reasonable to me: ... This site and this directory were driving up server load averages, which causes instability for all users on this server. Our block on this site appears to have blocked over 150,000 connections in about half an hour. This is simply more than is appropriate for a shared server. You may want to review your domain's traffic logs to see what kind of traffic this site is getting. The logs for t…

[deleted]

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#43

Post by jdbernard »

vfclists wrote: post #5

> “If nothing is working, what am I paying you for? If everything’s working, what am I paying you for?” Bloke is not acquainted with Keynesian economics. https://www.youtube.com/watch?v=9OhIdDNtSv0 https://www.youtube.com/watch?v=NO_tTnpof_o All a man needs is food in his stomach and a place to rest at the end of the day. Everything else is vanity What proportion of global GDP is dedicated to fulfilling our basic mat…

> I would work for myself, following my own philosophy.

Sounds like he understood it just fine. He owns the means of production.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#44

Post by binkHN »

jsiepkes wrote: post #38
shrubble wrote: post #33

Earlier quoted context omitted.

"One of the reasons Linux persists despite not having something up to the level of ZFS is that most of ZFS features are redundant to larger enterprise customers." ZFS is used heavily on Linux and runs well, though there are some limitations which are being addressed over time in the OpenZFS project. It is used across all areas that Linux serves, whether laptop, desktop, home server all the way to enterprise. https://…

ZFS on Linux is not really usable for most users because every kernel update can break your ZFS compatibility. Meaning unless you want to put in the time to manually test every kernel update and ensure your kernel version stays in-sync with OpenZFS you can very likely end up with an unbootable system.

This is one of the main reasons Void Linux is "stuck" on kernel 6.6.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#45

Post by cyberax »

hedora wrote: post #24
cyberax wrote: post #19

Earlier quoted context omitted.

> The client is paying for the VM. The underlying system is an abstraction. The VM change was sufficient enough to alter the runtime of a task by several times. This is NOT a small inconsequential change. You _have_ to warn your clients when you do stuff like this.

The workload got several times faster. The customer’s only concern was that they might be accidentally running on a more expensive instance. In every system I’ve worked on, the agreement is in terms of an SLO. We never gave our customers any sort of expectation (or guarantee) that we wouldn’t suddenly wildly beat our SLO targets (and, in fact, we often did, due to routine upgrades). Having said that, certain customer…

> The workload got several times faster.

And he found it out only by talking to the customer, indicating approximately zero testing from his side.

It might have gone the other way easily.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#46

Post by binkHN »

rstuart4133 wrote: post #31

All I can say is experiences differ. I'm a long time Debian user, and now use FreeBSD for work. Both are far better than the proprietary competition, but I'd take Debian/Linux over FreeBSD when building a random server. To give but one example, I recently reported a bug when FreeBSD didn't boot after upgrade from 13 to 14. Worse the disk format was somehow altered so when the reboot tried to boot off 13 due to zfs bo…

There is more than one Linux distribution that's designed to work without systemd.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#47

Post by cyberax »

hedora wrote: post #25
cyberax wrote: post #20

Earlier quoted context omitted.

No, it's not. S3 has a very well defined API with easily measureable performance parameters. So AWS updates can make sure they don't make things worse. This is not possible with a client's workload unless you can actually test it. That's why AWS will warn you multiple times if they need to migrate your EC2 instance onto a different hardware node. Even if it is technically "better". Of course, the fact that clients tr…

The author also converted some of these VMs to jails, so I assume they have root on the VMs (and the customers want them to admin the host). That means they should be able to see the application level performance metrics.

Yeah, so he got surprised when his customer mentioned how their workloads became faster.

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#49

Post by kopirgan »

pilingual wrote: post #35
kopirgan wrote: post #32

One of the website providers I use (Pair) for 20+ years used to be exclusively FreeBSD. I believe they use a lot of Linux now. Not sure why.

Ah, pair. Reminds me of this gem: http://www.archub.org/ycoutage.txt

If this was their first and only mail on that yeah it's not the best way to handle. But then my sites don't generate anywhere near the traffic as YC even YC of 2010

Re: Why and how we’re migrating many of our servers from Linux to the BSDs

#50

Post by hi-v-rocknroll »

Gud wrote: post #40
hi-v-rocknroll wrote: post #37

Earlier quoted context omitted.

Meta does a lot of things that don't scale for reliable/trustworthy systems and aren't suitable for all use-cases. (I also used to work there too.) ZFS is only reliable where it was battled-tested: on Solaris. ZoL has been infinitely tinkered with and smashed up that it's nothing like running a Thumper as a NAS. XFS + mdadm on Linux is, without a doubt, far more reliable than ZoL. Ask me how I know. I have the scars…

ZFS has been plenty battle tested on FreeBSD.

Not hardly, and not in the way you think. They replaced their arguably purer ZFS port to replace it with ZoL. As such, it's nowhere near as tested and proven as existing solutions like ext4 and xfs Redhat has deployed to millions of machines for decades. ZFS has too many religious fanboys who hype it without considering that boring and reliable are less risky than betting on code that hasn't had nearly the same scale of enterprise experience.
Post reply on HN