| Author |
Topic |
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2006-03-15 : 04:54:46
|
| We have the problem at the moment where some .NET code using datareaders might bomb out and not exit properly - thus not triggering all the proper garbage collection auto dispose functions etc...The result is that a client-side datareader can be kept open indeffintely on the server because of the unmanaged code issue.Obviously I'm getting the developers to tidy their shizzle up and stablize it.But is there a way that I can say server-side that if a process has been running for more than 10 hours, kill it? Or if it's eating up more than x amount of memory/cpu/physicalIO, kill it? |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2006-03-15 : 06:01:31
|
well sp_who2 gives you some info about that...i think you can make a scheduled job that runs sp_who2, parse the result and kill desired spids with "kill proccessNuber"Go with the flow & have fun! Else fight the flow |
 |
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2006-03-15 : 06:52:02
|
| crumbs, that seems a bit tedious, isnt there a more elegant way? |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2006-03-15 : 07:11:22
|
well to periodically check for something we use scheduled jobs.to get running processes we use sp_helpto kill processes we use killso if there is i'd love to have it too Go with the flow & have fun! Else fight the flow |
 |
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2006-03-15 : 08:21:38
|
| ok, thanks spirit one. I'll see how well that works |
 |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2006-03-15 : 08:49:59
|
@CoolerBob:here's some code to help you along the way. I've just modified comething else, so test, and see that it's good enough for you.use mastergoif exists (select 'SP exists' from sysobjects where name = 'Up_KillDatabaseLongUsers' and xtype = 'p') drop proc Up_KillDatabaseLongUsersgoset nocount onset quoted_identifier offgocreate procedure Up_KillDatabaseLongUsers (@Duration int=100, @DBName varchar(255))as-- Create By: Regan Galbraith-- Create On: 2004-07-20-- Purpose: ---- This stored procedure was written to facilitate the automatic cleanign down of lost/disconnected spids.-- It works through a database, killing all connected spids that are not its own spid, and have been connected longer -- than the specified duration.---- Example:-- exec Up_KillDatabaseLongUsers 1000000,'Master'---- Possible future additions:-- logging work done to a table, net send person killed,error handling---- Change Control: version 1 - creation and adding of comment-- v1.1 - change 2004-07-26 - Regan Galbraith-- added [ ] to cater for dbs named with numerics or reserved words-- v1.2 - change 2006-03-15 - Regan Galbraith-- modified base sp to serve as example for web query--BEGINset nocount ondeclare @DurationStr varchar(25)set @DurationStr = str(@Duration)exec ('use [' + @DBname + '] declare @spid varchar(9)declare @KillNumber intset @KillNumber = 0 DECLARE spid_cursor CURSOR FOR select ltrim(rtrim(str(spid))) from master..sysprocesses where dbid in (select dbid from master..sysdatabases where name = '''+@DBname+''') and spid <> @@spid and datediff(second,last_batch,getdate()) between ' +@DurationStr+ ' and 0 and loginame not in (''sa'') --UserId exclusion listOPEN spid_cursorFETCH NEXT FROM spid_cursor INTO @spid WHILE (@@FETCH_STATUS <> -1) BEGIN declare @sql varchar (100) select @sql=''kill ''+@spid print @sql exec (@sql) set @KillNumber = @KillNumber + 1 FETCH NEXT FROM spid_cursor INTO @spid END close spid_cursor DEALLOCATE spid_cursorselect @KillNumber as [Number of Spids killed]')ENDgoexec Up_KillDatabaseLongUsers 1000000,'Master'basically, it should kill of any users that have a calculated duration > than your number. Some pointers/warnings here:-I have seen cases where the last_batch = '1900-01-01 00:00.000'. That generates a MASSIVE time difference that I fear may be problematic. You should consider excluding those last_batches (I didn't add "and last_batch <> '1900-01-01 00:00.000' " above. Consider, test and decide.-look carefully at you exclusion list. You don't want to be killing of important/system users.-there is naturally a risk that you need to consider having a job that automatically KILLS long runners - you might consider changin the above so that it generates the kill list, and you can use manually, after ensuring that you really want to kill that thread.-you could expand above to use a cursor, looping through many databases, rather than at a database level. ((if anyone knows of a way of doing this kind of things without cursors, let me know!))-you could add some logic that generates a net send to the person you are killing, and also log the "kill" info (who, when, etc) to a table, so you can see who you are killing, how often, etc. I certainly would do that, if I had to do the above in a production environment.The code could be cleaner - use it as a start popint, and "best practice" it by doing error handling, parameter checking, etc*##* *##* *##* *##* Chaos, Disorder and Panic ... my work is done here! |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2006-03-15 : 09:05:22
|
nice!Go with the flow & have fun! Else fight the flow |
 |
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2006-03-15 : 12:05:51
|
| a boer maak n plan! |
 |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2006-03-15 : 16:57:56
|
| Ya no well fine! CoolerBob - are you dalk 'n Suid-Afrikaner?My mom always said: Moenie jou languages op-mix nie - dit sounds nice nice nie!:-)Hopefully you can do something with the code - let us (or just me) know - I'd be interested to see a finalized product.*##* *##* *##* *##* Chaos, Disorder and Panic ... my work is done here! |
 |
|
|
|