She's dead (again) Jim....
 

Reboot, rinse, repeat....

What's the hardware config for the backend? If we need a bandaid approach to keep it running, I have some SAS and/or SATA disks I could possibly send you depending on the geographic location (San Diego?). What's the server model number, RAID controller, etc?

She may not be dead, Jim, but she's one sick puppy.

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

[QUOTE=kladner;378190]She may not be dead, Jim, but she's one sick puppy.[/QUOTE]

Yes, I did a "preventative" restart 5 minutes ago.

[QUOTE=Prime95;378193]Yes, I did a "preventative" restart 5 minutes ago.[/QUOTE]

Thanks!

[QUOTE=Prime95;378193]Yes, I did a "preventative" restart 5 minutes ago.[/QUOTE]

So far so good...Thanks George! :smile:

She's mortally wounded, James.

[QUOTE=NBtarheel_33;378246]She's mortally wounded, James.[/QUOTE]

George...

Would it help if GPU72 didn't run its queries so often?

Would it help if very old log files were deleted from Primenet's harddrives?

This issue is clearly critical. Primenet now seems more unstable than stable most of the time (happy to share the logs empirically demonstrating this).

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==


EDIT: Oops same message as kladner.

[QUOTE=chalsall;378253]Would it help if GPU72 didn't run its queries so often?[/quote]

I have no idea. If I knew why the database crashes so often I might could answer that question more intelligently.

[quote]Would it help if very old log files were deleted from Primenet's harddrives?[/QUOTE]

I've been cleaning up some. This latest crash was not related to disk space -- just an ordinary database death for no good reason.

Well unless I am missing something, our options are to either get rid of the data or to expand storage capacity. I always think there is no such thing as too much data, but I also like to live in that perfect world where storage space is not an issue. GIMPS and I clearly don't live together in that world.

How much data is kept for every exponent? I can only work from memory at this point because the server is dead, but when I look up an exponent, I vaguely remember seeing every stage of trial factoring, including who did it and when; any P-1 work, including who did it, when and what the bounds were; LL and DC tests, if applicable, with 64-bit residues, and who did it and when.

For the sake of history, I think that keeping every bit of data we can is important, but if it's a choice between server stability and precision of data, I'd choose stability any day. To this end, perhaps if we simplified all activity before xx/yy/zzzz, we would free up enough space to keep us going until a new server is arranged?

Presently an exponent might look like:

[CODE]No factors below 2^66
No factors from 2^66 to 2^68, TheMawn, 20/03/2010
No factors from 2^68 to 2^69, Joe Pesci, 16/04/2010
No factors from 2^69 to 2^70, Factor_Dude_669, 05/05/2010
P-1 B1=135000 B2=1697500, P-1_Dude_669, 03/07/2011
No factors from 2^70 to 2^72, TheMawn, 19/11/2010
MXXXXXXXX is not prime Res64: BLABLA, curtisc, 03/01/2012
No factors from 2^72 to t^73, John Travolta, 01/02/2012
No factors from 2^73 yo 2^74, FourHorsemen, 01/07/2013
P-1 B1=249000 B2=3125000, Darian Durant, 07/07/2013
MXXXXXXXX is not prime Res64: BLABLA, DC_Dude_669, 16/07/2013[/CODE]

If we wanted to simplify the data, we really have a lot of options. I don't really care who did the TF and when. How often have we found erroneous TF results? Do we really care if we found out that Factor_Dude_669 missed a factor three years ago? Would we do anything about it? Then why bother remembering?

Same goes for the P-1. What value do we really get from the time stamp and the user ID?

For the LL and DC, I understand that the user and date are a bit more important if we ever saw a particular user having a high error rate or is suspected of falsifying results, so it might be worth keeping those. If a DC hasn't been completed yet or if the DC comes out incorrect, it would be very important that we continue to keep all the information we can, however.

If the data looked like:

[CODE]
No factors below 2^74
P-1 B1=135000 B2=1697500
P-1 B1=249000 B2=3125000
MXXXXXXXX is not prime Res64: BLABLA, curtisc
MXXXXXXXX is not prime Res64: BLABLA, DC_Dude_669[/CODE]

We might save a lot of space and lose little of importance. If we were to compress everything before, say, 01/01/2014, and keep the rest on an external source until we get the issues permanently resolved, this could buy us some time?


EDIT: Now that the server is back up, I went and looked at the history for M55174403, one that I am working on right now. It looks a bit different than I remembered. In fact, there is a little box with the reader's digest of the work done on the exponent, but there is also a detailed history. Temporarily getting rid of that might reduce the strain all the same?