OFFICIAL "SERVER PROBLEMS" THREAD

[Chuck]

I can access Primenet pages but MISFIT cannot upload results.

 
 5/30/2014 9:07:06 AM:Stand by for queue check...
5/30/2014 9:07:11 AM:Checking GIOM_STAGED for files to upload
5/30/2014 9:07:11 AM:Found 5 file(s)
5/30/2014 9:07:11 AM:Begin upload process for GIOM_STAGED\130459223203721471-9c23e.txt
5/30/2014 9:08:42 AM:Error! The remote server returned an error: (502) Bad Gateway.
Will try the upload again in about 30 minutes...

[lycorn]

There must be some issue with uploading "Factors found" lines. It´s now more than 3 hours since the server last recorded an "F" in the Recent Cleared report

[James Heinrich]

Originally Posted by lycorn

There must be some issue with uploading "Factors found" lines. It´s now more than 3 hours since the server last recorded an "F" in the Recent Cleared report

Factors are validated on submission. That's where the memory leak occurs: in the spawned process that validates the submitted factor. Eventually it causes primenet to grind to a halt, but in this intermediate state between working and broken you can submit all the no-factor results you want just fine, but it'll hang on any factor reports. Once George gives it a swift kick in the reboot it'll be back to normal.

[LaurV]

Same here, Misfit crashed today (?!?!?!?) then I came back from work and restarted, try to report, crashed again. I removed all "factor found" from all files, reported again, went through immediately. Trying to report factors, there is an "error 502 (bad gateway)", i.e. Misfit says that "the server reported that..." and it crashes (i.e. non responsive for a while). This is very strange. Went back to older misfit (2.6.4) and it does not crash, but still the same error, and can't report factors.

Backed them up for now
Will report them later.

[brilong]

I've also experienced multiple problems over the last few weeks. At first I thought it was the submit_spider Perl script I'm using. Occasionally it gives output like this (missing the number before GHz):

20140530_144705 INFO:  M69277711 submitted; 13.8069 GHz Days credit.
Use of uninitialized value $GHzDays in concatenation (.) or string at /home/horde/GIMPS/gpu0/submit_spider line 154, <IN> line 12.
20140530_144728 INFO:  M69277711 submitted;  GHz Days credit.

It turns out the server is causing this issue (notice the 23 second gap). I've been able to resubmit the same entry again and it usually works fine, but it's a manual process.

I've also had issues submitting new factors. Even when I try to submit them on the Manual webpage, I get an error:

CGI Timeout

The specified CGI application exceeded the allowed time for processing. The server has deleted the process.

It appears submit_spider needs to be improved to catch these errors, sleep a while and try resubmitting. It does NOT label the results file "not_submitted" with the bad entry in this particular case.

[chalsall]

Originally Posted by brilong

It appears submit_spider needs to be improved to catch these errors, sleep a while and try resubmitting. It does NOT label the results file "not_submitted" with the bad entry in this particular case.

Thank you for the detailed bug report. I will try to find cycles to deal with this this weekend, and report when an update is available dealing with this issue.

[kracker]

Yep, primenet is down (again)...

[kladner]

Same here: UTC 1733.

EDIT: Back up by UTC 1825.

[Prime95]

She's rebooted.

I'm not convinced the factoring program is the problem -- though there definitely is a problem related to it. The factoring program the server uses is msieve, albeit a very old version, which is fairly high quality software. The problem could just as easily be some other resource leakage during the spawning of the msieve process by SQLServer. In theory, any resource leak by msieve should be cleaned up when the msieve process terminates.

When Primenet was originally written, msieve was not called for factors less than something like 30 digits as we were TFing in mid-60s bit area (msieve is only called to test if the factor is composite and break it down into prime factors). This worked well until someone started submitting composite 25-or-so digit factors of Mersenne numbers that already had known tiny factors (P-1 or ECM on small Mersennes).

BTW, does anyone know how to auto-reboot the MS SQLServer and IIS services?

[kracker]

Originally Posted by Prime95

She's rebooted.

I'm not convinced the factoring program is the problem -- though there definitely is a problem related to it. The factoring program the server uses is msieve, albeit a very old version, which is fairly high quality software. The problem could just as easily be some other resource leakage during the spawning of the msieve process by SQLServer. In theory, any resource leak by msieve should be cleaned up when the msieve process terminates.

When Primenet was originally written, msieve was not called for factors less than something like 30 digits as we were TFing in mid-60s bit area (msieve is only called to test if the factor is composite and break it down into prime factors). This worked well until someone started submitting composite 25-or-so digit factors of Mersenne numbers that already had known tiny factors (P-1 or ECM on small Mersennes).

BTW, does anyone know how to auto-reboot the MS SQLServer and IIS services?

Dunno, try updating msieve?

[chalsall]

Originally Posted by Prime95

She's rebooted.

Thanks George.

Originally Posted by Prime95

The problem could just as easily be some other resource leakage during the spawning of the msieve process by SQLServer. In theory, any resource leak by msieve should be cleaned up when the msieve process terminates.

Agree. But, are you absolutely sure that MS SQLS is what launches msieve? I would have thought it would instead be the MS IIS which launches that sub-process.

Originally Posted by Prime95

BTW, does anyone know how to auto-reboot the MS SQLServer and IIS services?

I don't personally. But I suspect there are many here skilled in such arts.

Very sincere regards.