[QUOTE=Madpoo;400042]... Tomorrow is "patch Tuesday" anyway and it may be a good opportunity to get the server caught up on updates and reboot to clear out any gremlins.[/QUOTE]

I've looked over the April fixes from Microsoft and tried them out on some dev systems (I try to do that and avoid some of the nastier surprises). Looks good and a few worthwhile patches in there.

I'm going to apply these and reboot Primenet in about 30 minutes from now... let's call it 15:50 UTC.

Downtime will be about 20 minutes since I'm also going to apply some firmware updates on the host machine and a SQL rollup patch.

It turns out one of those fixes is a remote root hole in IIS: [url]https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/[/url]

[QUOTE=Mark Rose;400141]It turns out one of those fixes is a remote root hole in IIS: [url]https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/[/url][/QUOTE]

Yes, precisely. :) Bugs in HTTP.SYS are never good.

Well, I have half of the patches installed, but in typical MS fashion, since I skipped updating last month, Windows Update is making me reboot and then install more and reboot again.

So it's taking me longer than the 20 minutes I had planned for. The virtual host machine is done at least and the firmware patches applied. Now I'm just waiting on getting the Primenet server itself caught up. It's up for now so it's handling web requests for the moment.

In a few more minutes I'll shut down the website again and finish it off.

[QUOTE=Madpoo;400142]In a few more minutes I'll shut down the website again and finish it off.[/QUOTE]

All done and everything back up and running.

Grrr.. strange PN error
 

Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 56) was deadlocked on trial factoring (huh? :shock: haha)
lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction., SQL state 40001 in SQLExecDirect in C:\inetpub\www\report_top_500_custom\default.php on line 92

[QUOTE=LaurV;400352]Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 56) was deadlocked on trial factoring (huh? :shock: haha)
lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction., SQL state 40001 in SQLExecDirect in C:\inetpub\www\report_top_500_custom\default.php on line 92[/QUOTE]

Yeah, I think some of the SQL queries that the website does could/should be updated to avoid locks when possible.

It also wouldn't hurt to hide the error messages, but hey, we're all friends here, and seeing the errors helps figure out the problem. :smile:

Something odd is happening for me with mersenne.org.

When I'm not logged in, it goes fast.

When I am logged in, all requests eventually time out after several minutes with a 500 error.

This is happening on browsers on two different machines as well as using mfloop.py on four different machines. I can't submit any results right now.

Okay, I stopped my minutely spider, and it now responds again. I guess some kind of database lock kept piling up.

[QUOTE=Mark Rose;400948]Something odd is happening for me with mersenne.org.

When I'm not logged in, it goes fast.

When I am logged in, all requests eventually time out after several minutes with a 500 error.

This is happening on browsers on two different machines as well as using mfloop.py on four different machines. I can't submit any results right now.[/QUOTE]

Weird. I don't know what pages you're crawling exactly, but it's weird that being logged in or not makes such a difference. There are pages where a logged in user will display more information, and the SQL query takes a different set of parameters. In that sense, if what you're crawling doesn't change whether you're logged in or not and it works faster logged out, then go with that.

[QUOTE=Madpoo;400979]Weird. I don't know what pages you're crawling exactly, but it's weird that being logged in or not makes such a difference. There are pages where a logged in user will display more information, and the SQL query takes a different set of parameters. In that sense, if what you're crawling doesn't change whether you're logged in or not and it works faster logged out, then go with that.[/QUOTE]

I have spiders that submit results every minute, if there are any. I was also trying to look at the full details of M1277 when the error started. All my logged in requests would hang, until I stopped the spiders for a while, and whatever was locking things got released.

Bleh. Looks like I lost 825 GHz-days of work or so. Ah well :/

I keep about 300 GHz-d/d in reserve (where I have to pay for power)... so I'll press that into service.

[QUOTE=Madpoo;400979]Weird. I don't know what pages you're crawling exactly, but it's weird that being logged in or not makes such a difference.[/QUOTE]

There is a field in the user record that is updated each web page. I think its called dt_last_visited. I guess that locks the row for too long a period, although why it doesn't autocommit it I don't know. One quick change might be to update that query to only update dt_last_visited if it has been at least an hour since the last update. Something like "where dt_last_visited < dateadd (hour, getdate(), -1)"