[QUOTE=Prime95;380255]Nope, you were just lucky.

The site does seem happier with 5GB of free disk space. Madpoo is out of town this week so there won't be any work on the new server til he gets back.[/QUOTE]

Yeah, it's been a hectic past couple days, relocating systems from a New York datacenter over to New Jersey. :)

I think when I was looking at the current system I may have been overly aggressive in keeping the database log file small to help with the nightly backups we're doing to the test site. Currently the log file tends to grow pretty quick up to 2.5-3 GB after running for a day. When it gets that big, it takes longer to backup over an Internet connection so I'd been doing a series of a couple log backups in a row with a logfile shrink after each, so I could get it down to a small size.

But what typically happens during the day is there's some long running transactions which naturally fills that log right back up, and logfile expansion is a somewhat expensive I/O operation. I think I'm better off dealing with large log backups and avoiding having that slow disk on the current system expanding all through the day like that.

It's like a catch-22, where a transaction is slow so causes the log to fill more, which causes the logfile to expand, which slows down the system and slows down the transaction, etc. Rinse and repeat through the day and we're right back to a 3GB logfile. I'm just going to leave it like that unless it really started growing out of control, but 2-4 GB seems to be it's daily sweet spot. Doesn't leave much spare room, but enough for now.

The main data file is 54 GB but could be shrunk to 45 or so... Out of curiosity I shrunk it on the test server to see how long it took and on there it took a good 15 minutes. I can only imagine how long the current server would take, but I'd guess it'd be shrinking that for the better part of a day or two, and while that's happening the log file would be growing like crazy.

There are also index optimizations that are done in offline mode and it just takes far too long on the current system to do that. I may try that out on the new system and see how long those take because that'd be a nice weekly task to do and help overall performance. It looks like George is making good use of indexes, but they do get worked over and need rebuilding, it just takes so long on the current system that going without indexes while they're optimizing is a long and slow ordeal.

[QUOTE=Madpoo;380282]Is GPU72 getting exponent assignments through the Primenet API at all, or do you mean Primenet isn't currently storing info on factoring above certain bit depths which GPU72 might be re-doing in some cases?[/QUOTE]

GPU72 has several spiders which reserves candidates from Primenet via the APIs, and then "lends" them out to people for higher-level TF'ing, and then often P-1'ing. There /shouldn't/ be any duplication of work.

[QUOTE=Madpoo;380282]Is GPU72 getting exponent assignments through the Primenet API at all, or do you mean Primenet isn't currently storing info on factoring above certain bit depths which GPU72 might be re-doing in some cases?[/QUOTE]
Once a factor is found by TF, P-1 or ECM the current bitlevel of TF is 'lost' on the Primenet server. To me this is not much of an issue since (factor = composite). This information could be handy for those who want to find more factors/fully factorize exponents and want to do more TF on those exponents.

[QUOTE=VictordeHolland;380286]Once a factor is found by TF, P-1 or ECM the current bitlevel of TF is 'lost' on the Primenet server.[/QUOTE]Not entirely. The data is still hiding in there (at least for results from the last few years) but previously the web interface may have been more reluctant to talk about pre-factor details. I reworked that page several months ago to get it to show whatever info it has on the "full" report. You can see from [url=http://v5www.mersenne.org/report_exponent/default.php?exp_lo=68687083&full=1]this random example[/url] of a recently-found factor that the prior NF history is still there.

[QUOTE=Madpoo;380283]There are also index optimizations that are done in offline mode and it just takes far too long on the current system to do that. I may try that out on the new system and see how long those take because that'd be a nice weekly task to do and help overall performance. It looks like George is making good use of indexes, but they do get worked over and need rebuilding, it just takes so long on the current system that going without indexes while they're optimizing is a long and slow ordeal.[/QUOTE]

I just did an index reorganize task on the test server... took 1 hour, 12 minutes. Considering the sizes of some of those indices it's not surprising it took that long. I checked beforehand and they were severely fragmented. Ran it again right after and it only took 8 1/2 minutes.

It's definitely something to add to a nightly maint. task on a new system, doing a reorg of those to keep the fragmentation to a low level. Keeping it up is the key.

[QUOTE=Madpoo;380307]... offline ... a nightly maint. task[/QUOTE]

Me wonders as to the definition of "night", and impact on mersenne.org response to people's enquiries and submissions, prime95 and misfit.

[QUOTE=snme2pm1;380335]Me wonders as to the definition of "night"[/QUOTE]Presumably that would be set to the typical period of least average load on the server, which may or may not conform to any particular user's (or even the of the server's) geographic location's definition of "night".

TF partial range
 

[QUOTE=James Heinrich;380290]I reworked that page several months ago[/QUOTE]

I noticed that there is much more comprehensive result information now visible, at odds with assertions from some quarters in the past that there is no record of partial (or not) range TF factored result.
I can see a tell-tale asterisk.
Hopefully that indicator is well agreed among the various agents.
[B]... F 729540971773795344071;[TF:69:70*:mfakto 0.14-Win cl_barrett15_71_gs_2][/B]

[QUOTE=snme2pm1;380335]Me wonders as to the definition of "night", and impact on mersenne.org response to people's enquiries and submissions, prime95 and misfit.[/QUOTE]

I bet that anything in the "wee hours" (e.g. 0300) in any of the continental US time zones would work fairly well. Might not be perfect, but should work well.

These results included a Factor Found. I don't remember seeing the error below before:
[CODE]Processing result: nHTTP/1.1 502 Gateway Error Server: Microsoft-IIS/5.0[/CODE]

[QUOTE=snme2pm1;380338]I noticed that there is much more comprehensive result information now visible, at odds with assertions from some quarters in the past that there is no record of partial (or not) range TF factored result.
I can see a tell-tale asterisk.
Hopefully that indicator is well agreed among the various agents.
[B]... F 729540971773795344071;[TF:69:70*:mfakto 0.14-Win cl_barrett15_71_gs_2][/B][/QUOTE]

[url=http://v5www.mersenne.org/report_exponent/default.php?exp_lo=68743163&full=1]Nope[/url]. I just factored M68743163 with StopAfterFactor=2 in mfaktc, and this is all it produced: F-PM1 2463386658202793009209. No indication of the agent or that factoring was only partial for the bit depth.