She is down again, with SQL error code 08S01 - Communication link failure.

[QUOTE=VictordeHolland;379035]She is down again, with SQL error code 08S01 - Communication link failure.[/QUOTE]<aol>Me too!</aol> On vacation. Paying for wifi, where it used to be free.

[QUOTE=chalsall;378981]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.

[/QUOTE]

That seems to be right. But much more than Oliver, we have TJAOI submitting thousands of small factors nearly every day. If there´s really a correlation between factors being checked in and Primenet glitches, it should be easily spotted following TJAOI submissions.

[QUOTE=VictordeHolland;379035]She is down again, with SQL error code 08S01 - Communication link failure.[/QUOTE]

Same at 16:43 UTC.

Down here as well, with:

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

I'm having difficulty logging in to restart the services. I'm pursuing other means of rebooting.

[QUOTE=Prime95;379060]I'm having difficulty logging in to restart the services. I'm pursuing other means of rebooting.[/QUOTE]

Please forgive me for being annoying, but, for example, 1and1, EC2 and Rackspace provide easy means of rebooting servers without being physically in front of them.

And, further, I earlier today lowered GPU72's spidering against Primenet. No real big downside -- clients for TF'ing and P-1'ing will still be able to get assignments. But their results won't be recognized until Primenet comes back on-line.

17:05 UTC

It's Baaaaack!

[QUOTE=Prime95;378923]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]

So that's 5 i/o requests per second. Even if every one triggers 5 more that's still only 25.

A quick search for [URL="http://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-with-sqlio/"]MS SQL server throughput[/URL] suggest even M$ server can manage writes of hundreds per second and reads of up to 15,000 per second.

Is this running on an old IBM-XT or something similar. Even a mobile phone can be a web server nowadays...

[QUOTE=Gordon;379069]So that's 5 i/o requests per second. Even if every one triggers 5 more that's still only 25.

A quick search for [URL="http://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-with-sqlio/"]MS SQL server throughput[/URL] suggest even M$ server can manage writes of hundreds per second and reads of up to 15,000 per second.

Is this running on an old IBM-XT or something similar. Even a mobile phone can be a web server nowadays...[/QUOTE]

Yeah, it doesn't seem like an excessive amount of activity, but I don't know what the hardware is like. I maintain a bunch of pretty active websites and the MS SQL backend can handle a LOT more IOPS on a system with dual X5550's and 24GB of RAM. The usual bottlenecks are disk subsystem... in our case the size of the database can eventually be cached entirely in that 24GB of RAM (with room to spare), so just getting the disks to read/write as fast as possible is the key. It's on an external storage unit, 12 x 144GB 15K SAS drives. Logs and data are using separate spindles which is another key point.

My guess is the same as others... it could be some delays in checking those "factor found" results... just a bottleneck as it checks a bunch that come in all at once? It should delay checking them or limit that to only half of the available CPU's or something so it doesn't entirely bog down the system.

Without re-architecting the whole process, the "simple" solution is to throw hardware at it. Works every time it's tried... find the bottleneck and instead of making it work better with what it has, just remove the bottleneck by beefing up that subsystem.

I'm taking the server down to see how long it takes to rebuild some indexes.

I freed up 4GB of server disk space by downloading log files to my computer. This should give me enough disk space to rebuild some indexes which are over 90% fragmented.

Unfortunately, indexes can only be rebuilt online with the Enterprise Edition of SQLServer.