Slashdot Mirror
Facebook VP Slams Intel's, AMD's Chip Performance Claims
narramissic writes "In an interview on stage at GigaOm's Structure conference in San Francisco on Thursday, Jonathan Heiliger, Facebook's VP of technical operations, told Om Malik that the latest generations of server processors from Intel and AMD don't deliver the performance gains that 'they're touting in the press.' 'And we're, literally in real time right now, trying to figure out why that is,' Heiliger said. He also had some harsh words for server makers: 'You guys don't get it,' Heiliger said. 'To build servers for companies like Facebook, and Amazon, and other people who are operating fairly homogeneous applications, the servers have to be cheap, and they have to be super power-efficient.' Heiliger added that Google has done a great job designing and building its own servers for this kind of use."
Can we get like a panel of hardware engineers to have a discussion with this guy and can I get some popcorn?
Slashdotters might want to take a look at the details of the Google servers to see what Heiliger is looking for. There's also a video tour.
Put identity in the browser.
Let's see... IBM, Sun, Fujitsu, Itanium (yeah, its still Intel, but has great performance)... All of these can offer equivalent or much better performance at these kinds of applications than what they're using. Don't bitch if you're not willing to consider the alternatives.
At low DC voltages, you can't really do long cable runs without either suffering substantial resistive losses or using cable so thick you could club a seal to death with it.
the two points are somewhat independent of each other. The second I suspect is due to their being a lack of any standard for power efficent servers. Google did it by running single voltage power supplies. A standard around something like this would be useful, and not just for servers I suspect.
read my mind at http://the-willows.blogspot.com/
Facebook is written in PHP; there are no compile flags.
apache and the php engine have plenty of compile flags. not to mention whatever the database is.
As someone who designs and deploys large storage environments for a living, I call BS. While the current generation of HBAs are 8Gb FibreChannel, I would say that the "average server" (as you put it) could happily live on a 1Gb HBA. Recall that almost all servers, or atleast those you care about, have DUAL HBA connections to their respective storage. So that's actually 2Gb of storage connectivity. Sure there are servers which have multiple HBAs, or use a higher utilization of the HBAs, such as database servers or backup/media servers. Most servers today are deployed with dual 4Gb HBAs as the 8Gb SFPs/optics are still quite pricey, and you cannot, in all seriousness, purchase 1 or 2Gb FC HBAs.
Even as we deploy VMware based servers, the VMware servers themselves tend to be more memory/cpu strapped than IO.
It would be very rare, or almost impossible for a server to be driving linerate HBAs, with still plenty of headroom left in the CPU. Even basic test tools like IOmeter require significant CPU usage to drive an HBA to capacity. And that is when it's writing/reading all zeros. It's doesn't actually need to do anything with the data. As would be the case if a database server was requesting 2Gb/s from a disk array, and then had to join/sort/add/whatever the tables retrieved.
I think they run AC to the row or rack of servers, then they have just one super efficient PSU powering all the servers in a rack rather than 42 separate power supplies (plus UL enclosures, connectors, extension cords, etc, etc)
Essentially Google builds "rack-sized" blade centers... or at least catching up to what IBM and HP are doing but on a bigger scale, like full racks or multiple racks managed at once rather than just one chassis.
I do agree that chip makers aren't thinking "big enough" with things like their Blade lines.. Google wants to see reference specs that include options for bare motherboards to slide right into your basic 42 unit rack with IO, disk and power all pulled out to the raw basics so Google can decide how to manage the bits rather than having stock OEM boards with such limited options. Google wants to manage a "rack" as a single machine and optimize power and parts across 40 servers as one group, not 40 separate little systems.
They collect a large amount of data on people and mine that for marketing information to turn around and target those same users.
It's the same model as google.
Since when do we listen to manufacturer's claims? You take the new hardware, stress test it with your custom software, record results, plan servers accordingly. How hard is it really to commission a server design that meets your needs and then QA some prototypes?
Good-bye
No, they don't. They use motherboards built to their own specification that require only 12V power. This power is supplied by the server's own PSU, which takes 240V input. The PSU hooks into a 12V sealed lead acid battery, implementing UPS functionality (there is no centralized UPS).
I think it's a very elegant design.
# hdparm -Tt /dev/sdc
/dev/sdc: /dev/sdc | grep Model /dev/sda
/dev/sda: /dev/sda | grep Model
Timing cached reads: 5120 MB in 2.00 seconds = 2562.04 MB/sec
Timing buffered disk reads: 84 MB in 3.02 seconds = 27.77 MB/sec # hdparm -i
Model=ST3200822A, FwRev=3.01, SerialNo=xxxxxx
# hdparm -Tt
Timing cached reads: 6078 MB in 1.99 seconds = 3052.95 MB/sec
Timing buffered disk reads: 338 MB in 3.01 seconds = 112.22 MB/sec
# hdparm -i
Model=ST31000333AS, FwRev=SD1B, SerialNo=xxxxxx
It's not even a full order of magnitude faster, but 112MB/s is still nearly four times faster. And these are both magnetic discs, rather than SSDs.
You need a 'CAT5 of Nine Tails'. Google it: I've seen them made with usable sets of labeled connectors and adapters. on the ends to serve as an amusing collection of adapters, actually packed in a toolbox, and amusing as heck to whip out when a client had lost the appropriate adapter to go from their funky 3Com serial jack to normal laptop serial port, or needed a crossover cable to tie two machines directly together without a switch back in the pre-GigE days when network ports became hermaphroditic.