[QUOTE=chalsall;378336]Seconded!

It would be a real shame if Mersenne.org Version 6 happened the same way as Version 5....[/QUOTE]

What do you recommend for migration?

[QUOTE=flashjh;378349]What do you recommend for migration?[/QUOTE]

I've said before; I'll say again...

1and1 have served me well for many years, for many servers. (And, for the record, I make no commission recommending them.) EC2 or RackSpace et al should also be considered.

Renting or leasing servers generally makes more sense than collocating a server of your own in an ISP's rack now-a-days.

[QUOTE=chalsall;378350]I've said before; I'll say again...

1and1 have served me well for many years, for many servers. (And, for the record, I make no commission recommending them.) EC2 or RackSpace et al should also be considered.

Renting or leasing servers generally makes more sense than collocating a server of your own in an ISP's rack now-a-days.[/QUOTE]

EC2 should only be considered if going with a clustered system (such as Percona XtraDB Cluster). They will occasionally retire hardware, sometimes with only days of notice. EC2 is also expensive if you don't buy a reservation.

[QUOTE=Mark Rose;378354]EC2 should only be considered if going with a clustered system (such as Percona XtraDB Cluster). They will occasionally retire hardware, sometimes with only days of notice. EC2 is also expensive if you don't buy a reservation.[/QUOTE]

I will defer to you for EC2 advice.

I will stick to my recommendation of 1and1. Reliable, and inexpensive.

And, just as an aside, I ran an experiment for a client recently: I tried to get in touch with a "human" at EC2 -- after two days (via both phone and email), no contact.

It took less than 90 seconds to reach a "human" at 1and1 via a 1-800 number which worked here in Bim.

[QUOTE="mersenne.org]Warning: odbc_pconnect() [function.odbc-pconnect]: SQL error: [Microsoft][ODBC SQL Server Driver][Shared Memory]General network error. Check your network documentation., SQL state 08S01 in SQLConnect in C:\v5\www\2013\v5server\0.96_database.inc.php on line 21
pnErrorResult=3 pnErrorDetail=Database unavailable ==END==[/QUOTE]
Check your network documentation. Hmmm...

It better go to the log, not to the viewers. Some may be compelled to spend hours checking their network documentation, and shaking random wires on their computer... :smile:

[QUOTE=Batalov;378495]It better go to the log, not to the viewers. Some may be compelled to spend hours checking their network documentation, and shaking random wires on their computer... :smile:[/QUOTE]

The green one is not the culprit. After twenty minutes of shaking I was only able to wreck my sound system but the website was still down.

[QUOTE=Prime95;378260]I have no idea. If I knew why the database crashes so often I might could answer that question more intelligently.[/QUOTE]

George: Silence from a leader is rarely welcome.

[QUOTE=chalsall;378518]George: Silence from a leader is rarely welcome.[/QUOTE]

Not everyone can/does spend 10 hours a day in front of a monitor.

[QUOTE=kracker;378520]Not everyone can/does spend 10 hours a day in front of a monitor.[/QUOTE]

Agreed.

Those who can't should step down.

And, like George, I can't.

I found the IIS log files. Some random stats:

Server is handling about 14000 prime95 HTTP requests per hour. Each request is a CGI, PHP, and at least a few SQL statements.

Server is also handling about 3000 web requests per hour. This includes GPU72 spider requests. It counts individual CSS/GIF/JPEG/PNG files as well as PHP request that will fire off some SQL statements.

I'm not sure if that is a lot or a little or if that gets me any closer to finding bottlenecks.

[QUOTE=Prime95;378923]I'm not sure if that is a lot or a little or if that gets me any closer to finding bottlenecks.[/QUOTE]

From my perspective, the correlation seems to be a large number of "factor found" results being submitted. As an example, just after Oliver submits his weekly queue Primenet seems to stagger a bit.

There has been earlier discussion that the external program used to ensure a factor submitted (forgot its name) is actually a factor might be causing a memory (or some other resource) leak. Importantly, the fault might not be that of the called program, but could be that of the calling program and/or the OS.

I would be very happy to work with you, Scott and James to try to narrow this down. GPU72 isn't overly aggressive in its spidering (in my mind), but it could be reduced further for analysis purposes.