[QUOTE=Madpoo;380391]Unless I see something obviously broken, there's the "too many cooks" thing and George would know from past experience what the problem probably is.[/QUOTE]

Or not...

All of my spiders, both GPU72's and worker client's, have been experiencing many errors today. I suspect many others have been so observing as well.

Perhaps you could keep trying to log into Primenet (and iff finally succesful) to simple observe what's going on without changing anything?

BTW, I would be very happy to underwrite the transport of your new donated server to its new home via UPS or FedEx.

[QUOTE=chalsall;380398]All of my spiders, both GPU72's and worker client's, have been experiencing many errors today. I suspect many others have been so observing as well.

Perhaps you could keep trying to log into Primenet (and iff finally succesful) to simple observe what's going on without changing anything?[/QUOTE]

I got in and there's still 3.5 GB of free space, so it's not crunched for that. It's not a lot, but enough. CPU use is low, but the system is still super laggy and I'm assuming it's doing a lot of paging again due to the memory pressure. I'd start up performance monitor and check but it's so slow it might take a while and only add to the overburdened system.

[QUOTE=chalsall;380398]BTW, I would be very happy to underwrite the transport of your new donated server to its new home via UPS or FedEx.[/QUOTE]

Once I get back from my super fun work trip near Newark (</sarcasm>) I'll check back in with George and James to see how things are looking. James supplied some fun new PHP to eliminate the old methods that used a SQL extended proc to verify found factors and run msieve, which I think was the last bit of thing we were dealing with.

I was talking to George about the migration plans to the new system and one approach we were tossing back and forth was to make this test system "live" for long enough to send the new box to Scott and get it swapped out. If we go that route then we could see things get better even sooner.

But as I'm sure we'd all agree, we really just want to make sure that all of the functionality is still good... v4 and v5 clients are able to do everything they need to do and the web site works as expected, just faster, faster and faster. :smile:

[QUOTE=Madpoo;380391]Unless I see something obviously broken, there's the "too many cooks" thing and George would know from past experience what the problem probably is.[/QUOTE]

Don't worry about getting in this cooks way. I have no idea what is wrong. I follow the only recipe I know: kill IIS, restart MSSQL, restart IIS.

Reboot complete - sorry it took so long, I was out having fun this morning.

[QUOTE=Prime95;380402]Don't worry about getting in this cooks way. I have no idea what is wrong. I follow the only recipe I know: kill IIS, restart MSSQL, restart IIS.

Reboot complete - sorry it took so long, I was out having fun this morning.[/QUOTE]

I'm doing some additional perfmon analysis... I've confirmed that really, truly, it's just memory pressure and excessive swapping. It's nothing that can really be solved given the 32-bit nature of the system.

One thing I think might help is to limit how much memory SQL is able to use so that, for instance, the website running on there as well won't be constantly fighting with SQL over how much physical RAM they can get.

I can tell by looking that SQL is already hitting memory limits with just 2 GB so limiting it to 1.5 GB and leaving that other 512MB for IIS and the OS isn't going to matter much to SQL but could matter a whole lot to the other components. In other words, it won't make SQL faster, but won't really make it much slower either so it's a benefit to everything else.

Page faults/sec is averaging 1600 or so... if you've ever had to diagnose memory pressure in Windows you'll know that's pretty high. :) That's with a current SQL tps of just 28-29 on average at the moment.

Anyway, to that end I set SQL to use just 1.5 GB (1536 MB) and restarted it, so we should see soon if it's having any impact on the responsiveness of everything else.

I probably should have set SQL's minimum memory to the same thing, but anyway, right now SQL is still filling it's memory buffer based on the current transactions it's dealing with. Things will reach a steady state, maybe 30-60 minutes, I'm guessing. Then we'll know if this is any better. :smile:

[QUOTE=Prime95;380402]sorry it took so long, I was out having fun this morning.[/QUOTE]Did you play 9 or 18? :grin:

[QUOTE=M29;380404]Did you play 9 or 18? :grin:[/QUOTE]

Guilty as charged -- 18.

[QUOTE=James Heinrich;380389]...hopefully put the whole misinterpreted results issue behind us.[/QUOTE]I see that the extended results data is stored correctly so it will be possible at a future date to go back and fix all the false-PM1 records that were found by mfakt*, at least where the mfakt* version string was recorded. There's no point fixing the data right at this moment since the old results-parsing code is still live and will continue to introduce false records, but when that's changed the data is fixable.

For now, however, I have hack-fixed the display code to display correctly (this is the same factor that is really stored as "F-PM1" in the database but is now shown as "F"):
[url]http://v5www.mersenne.org/report_exponent/default.php?exp_lo=68743163&full=1[/url]

Yay! Got the factor accepted! 2107 UTC

[QUOTE=Madpoo;380403]just memory pressure[/QUOTE]

Sometimes a fear of memory leaks has been mentioned in this place.
Have you spotted any hint of resource leakage?

[QUOTE=snme2pm1;380413]Sometimes a fear of memory leaks has been mentioned in this place.
Have you spotted any hint of resource leakage?[/QUOTE]

I haven't seen anything to make me think there's a leak. SQL itself is unlikely to leak and that's the only thing running that's chewing up that much RAM.

On the other hand, it's SQL 2005 RTM... it hasn't had any service packs or rollups applied at all and maybe somewhere in the service pack history is something about a memory leak. I'd be tempted to install SP4 and cumulative update #3 which was the last one for SQL 2005, but with the low disk space I'm not even sure it would succeed in installing. :smile:

Have you looked at disabling any unnecessary background services to free up memory?