Hacker News Reader

Comment by jws | Hacker News Reader

Just an echo of the NYTimes non-story.

Bizarrely, this one self repudiates its own title near the end where they contacted a person that knows what they are doing…

Over at Mozilla, Datacenter Operations Manager Derek Moore says he probably averages around 6 to 10 percent CPU utilization from his server processors, but he doesn’t see that as a problem because he cares about memory and networking.

…

After we contacted him, Moore took a look at the utilization rates of about 1,000 Mozilla servers. Here’s what he found: the average CPU utilization rate was 6 percent; memory utilization was 80 percent; network I/O utilization was 42 percent.

CPU use is irrelevant to most internet servers.

Over the week, I operate my car engine at about 1.2% capacity. Maybe they should write about that.

View on HN

Ideally the software would be flexible enough to utilize all resources on a machine. A better resource balance would let you reduce the total number of machines and save money. Rather than having 1000 servers at 80% RAM and 6% CPU, you could have many fewer at 80% RAM and 80% CPU.

A cache gives you CPU in exchange for memory. Compression gives you memory in exchange for CPU. I imagine that almost all internet services can be improved by using more compression if they have so much idle CPU. That's what http://code.google.com/p/snappy/ is for essentially.

But the root problem is that our software isn't flexible enough. Capitalism is basically working in this case. Right now we don't have the programming technology to adjust software to fit a machine well -- it's cheaper just to throw more servers at it. Re-optimizing and testing software is very, very expensive. But computing is taking up a growing portion of the world's power, and software is getting better and more flexible.

Eventually the economics will adjust so that we're incentivized to get much higher utilization.

CPU helps with two things; throughput and latency. Having idle CPU means you're not constrained on CPU for maximizing throughput. But that doesn't mean you'd be just as well off with a slower CPU at a higher usage rate, because then you'd be sacrificing latency.

It might not be a large proportion out of all the other sources of latency, but it is one.

I can't say I understand that. If RAM utilization is so vastly out-scaled as compared to CPU utilization, there's a significant resource use inefficiency at play.

Machines consume a baseline amount of power whether they're used or not; that power usage obviously increases with utilization, but ideally you'd have full utilization across the board.

If memory usage is so much higher than CPU usage, I have to wonder what it is that Mozilla is doing wrong with their architecture. Are they using pre-fork-style servers? Are they just provisioning poorly? What is it?

> CPU use is irrelevant to most internet servers.

Why? The CPU is used when the machine does anything. Ideally you're operating the machines at full capacity, less overhead to handle load spikes.

> Over the week, I operate my car engine at about 1.2% capacity. Maybe they should write about that.

What you're doing is inefficient, and they do write about that. The solution is called car sharing and public transportation.

What you're doing is inefficient, and they do write about that. The solution is called car sharing and public transportation.

I drive 10000 miles per year. That's about average, but nowhere near running an engine at full power 24x7.

I don't have two spare hours each day to cover the public transit time delta. (4-8 times longer than driving) Maybe if I laid off HN…

>If memory usage is so much higher than CPU usage, I have to wonder what it is that Mozilla is doing wrong with their architecture. Are they using pre-fork-style servers? Are they just provisioning poorly? What is it?

Or are they just serving up web pages to users? That's RAM and bandwidth heavy, but very CPU light. You still need the machines to scale your load, but you're not going to be using the CPU.

Realistically, for just about any application, you're going to be RAM-bound before you're CPU-bound. The exceptions are(off the top of my head) scientific computing and video rendering, both of which are CPU heavy, and are very deterministic in their behaviors, which allows for heavy optimization of L2 and L3 cache misses.

> Or are they just serving up web pages to users? That's RAM and bandwidth heavy, but very CPU light. You still need the machines to scale your load, but you're not going to be using the CPU.

That depends very much on the efficiency of software your architecture. A well-architected web app can scale up RAM and CPU utilization much more closely than something modeled on zero shared state independent processes.

Additionally, even if your scaling model of RAM before CPU is the only possible one, that doesn't make the utilization effecient, and implies that higher efficiency could still be reached by scaling up RAM per machine.

To make the comparison fair, you would have to have your engine idling the rest of the time. As part of a group of 1000 cars.

This whole article does feel like it was written in 2008, like the report it refers to. Many of the conservative boring corporations that used to have many underutilized servers in their data centers have been actively moving towards virtualization and cloud like solutions since then.

Most cloud hosts are memory bound as well on the hypervisor - this is a consequence of the applications being memory-bound. Low CPU utilization rates are not at all uncommon for cloud environments. Storage bottlenecks are also very common.

CPU use is irrelevant to most internet servers.

If that's the case, then why aren't they using lower power, lower performance CPUs? If their servers are only running at 10% CPU load, then maybe the CPU in their servers is significantly overpowered for their needs and they could get by with some less powerful CPUs in order to save power and money.

Just because you don't need the cycles all of the time, doesn't mean you should get rid of them.

True. But it does feel like there's some sort of opportunity here if someone made an architecture tuned to this sort of scenario.

Reply on news.ycombinator.com