Difference between revisions of "User talk:Bergsmit"

From Wiki

Jump to: navigation, search
(Wat zou er aan de hand zijn: new section)
(Wat zou er aan de hand zijn)
 
(One intermediate revision by the same user not shown)
Line 7: Line 7:
 
Groetjes
 
Groetjes
 
Hannie
 
Hannie
 +
 +
de belangrijkste computer is gecrashed en de andere zijn te klein om alles te draaien. Ze zijn hard aan het werk de boel te herstellen.
 +
 +
--[[User:Bergsmit|Fred Bergman (User:Bergsmit)]] 14:35, 1 August 2011 (UTC)
 +
== Compilatie van mijn en Geni berichten van dit weekend ==
 +
 +
http://www.facebook.com/genidotcom
 +
 +
Geni: We're working to resolve the technical problems and hope to finish soon but can't commit to a firm time.
 +
 +
This is by far the worst database failure we've had to date. There will be no loss -- everything is triple / quadruple redundant but we need this machine running because our other database servers don't have the horsepower to run the site. We'll get it back up.The problem isn't the backups or read/write access, it's getting the machine running to handle the load.We've spent a ton on hardware.. much of it is for the new graph service, which would NOT have this problem because it's completely distributed.The system diagram is pretty complex.. redundant load balancers, core switches, slave switches, a dozen web servers, a half dozen database machines, fiber-connected storage server, and now 5 graph servers as well.Originally our heftiest machines came from Rackables, but the graph servers (which are just as powerful) are SuperMicro (basically 2nd tier manufacturer). We're also experimenting with SSD disks in the graph machines, but because it's so expensive we have to be judicious in what we store on them An 8-core Intel Core i7 2600 benchmarks about 70 GFLOPs, compared to 1.9 GFLOPs in the Cray 2. :-) (but database performance is more about I/O than CPU)
 +
 +
There will be no loss -- everything is triple / quadruple redundant inback-up but this machine needs running because all the other database servers don't have the horsepower to run the site.
 +
 +
Geni is pretty sure it's a corrupt index, because they were able to dump every table without the server going into recovery mode.Before you ask, yes Geni is already discussing ways to make sure this doesn't happen again.
 +
 +
We apologize for the downtime. We're refreshing the database to remove corruption in the server's internal files. There shouldn't be any lost data, but unfortunately it's taking longer than we'd hoped.
 +
 +
http://www.facebook.com/ge​nidotcom
 +
 +
Geni.com Turns out 5 years of data takes a LONG TIME. I cannot commit to when we'll be able to bring the site back up, but it will be more than 1 hour.
 +
Page: ‎32,212 people like this.
 +
 +
5 yrs. of data? WOW! Fred, you are an angel to keep updating all of this. Having been married to a computer scientist, I know the @#$% they are going through to get geni back up and running. You do such a superb job no one should complain!
 +
 +
--[[User:Bergsmit|Fred Bergman (User:Bergsmit)]] 14:34, 1 August 2011 (UTC)

Latest revision as of 14:36, 1 August 2011

On this talkpage you can send messages to
Bergsmit
Click here to start a new discussion.

  • Please click your signature under your message with the edit-bar or type:~~~~.


Wat zou er aan de hand zijn

Hallo Fred moeten wij vrezen voor onze inbreng?

Groetjes Hannie

de belangrijkste computer is gecrashed en de andere zijn te klein om alles te draaien. Ze zijn hard aan het werk de boel te herstellen.

--Fred Bergman (User:Bergsmit) 14:35, 1 August 2011 (UTC)

Compilatie van mijn en Geni berichten van dit weekend

http://www.facebook.com/genidotcom

Geni: We're working to resolve the technical problems and hope to finish soon but can't commit to a firm time.

This is by far the worst database failure we've had to date. There will be no loss -- everything is triple / quadruple redundant but we need this machine running because our other database servers don't have the horsepower to run the site. We'll get it back up.The problem isn't the backups or read/write access, it's getting the machine running to handle the load.We've spent a ton on hardware.. much of it is for the new graph service, which would NOT have this problem because it's completely distributed.The system diagram is pretty complex.. redundant load balancers, core switches, slave switches, a dozen web servers, a half dozen database machines, fiber-connected storage server, and now 5 graph servers as well.Originally our heftiest machines came from Rackables, but the graph servers (which are just as powerful) are SuperMicro (basically 2nd tier manufacturer). We're also experimenting with SSD disks in the graph machines, but because it's so expensive we have to be judicious in what we store on them An 8-core Intel Core i7 2600 benchmarks about 70 GFLOPs, compared to 1.9 GFLOPs in the Cray 2. :-) (but database performance is more about I/O than CPU)

There will be no loss -- everything is triple / quadruple redundant inback-up but this machine needs running because all the other database servers don't have the horsepower to run the site.

Geni is pretty sure it's a corrupt index, because they were able to dump every table without the server going into recovery mode.Before you ask, yes Geni is already discussing ways to make sure this doesn't happen again.

We apologize for the downtime. We're refreshing the database to remove corruption in the server's internal files. There shouldn't be any lost data, but unfortunately it's taking longer than we'd hoped.

http://www.facebook.com/ge​nidotcom

Geni.com Turns out 5 years of data takes a LONG TIME. I cannot commit to when we'll be able to bring the site back up, but it will be more than 1 hour. Page: ‎32,212 people like this.

5 yrs. of data? WOW! Fred, you are an angel to keep updating all of this. Having been married to a computer scientist, I know the @#$% they are going through to get geni back up and running. You do such a superb job no one should complain!

--Fred Bergman (User:Bergsmit) 14:34, 1 August 2011 (UTC)

Personal tools