you should look at the number of connections on the server netstat -an on the db side. if you are seeing alot of close_wait .. Well let me say it this way.. IF you have alot of established.. this is good. if you have a fair amount of anything else mixed in..
This means too many threads for the db server to handle. hope that helps some. too many threads to the DB can squash the DB and make it slow. not enough with leave it idle.. Follow best practice guides --- or Good practices for the Itil V3 crowd. On Thu, Oct 15, 2009 at 12:53 PM, remedybts <remedy.engin...@gmail.com>wrote: > Hi, > > I'm fairly new to Remedy. > I tried looking this up but couldn't find a quick answer. > > We have Remedy 7.1 patch 3 and Sql 2005. > ITSM 7.1 with SLM, SRM 2.1 > I recently changed the fast threads to 16min/max > And once in a while our support staff would get a database timeout > when saving/modifying a ticket. > > It used to be 12min/max > > I don't think my SQL 2005 server is taxed much with CPU usage around > 20-40%. > > Could the increased threads cause the database timeouts? > Should I bring that number down to 14? > > Thanks > -- > View this message in context: > http://www.nabble.com/Database-timeout-Remedy-7.1-tp25910432p25910432.html > Sent from the ARS (Action Request System) mailing list archive at > Nabble.com. > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum > Sponsor:rmisoluti...@verizon.net<sponsor%3armisoluti...@verizon.net>ARSlist: > "Where the Answers Are" > -- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
