[firebird-support] Re: Handling deadlocks with classic mode
Steve, Thanks for the response. We are running Windows. I'm not sure how much information about the fb_inet_server processes I can gather -- other than how long they've been running. Not sure how to get the IP address of the connecting client. I'm going to just start killing the oldest fb_inet_server processes, but I don't know how I can distinguish the listener process. If I kill that one by mistake, I guess I'll have to reboot the whole server because I don't know how to restart just the listener. Is there a way to identify the listener process? vince --- In firebird-support@yahoogroups.com, Steve Wiser wrote: > > What OS are you running on the server? For Classic, if you can find the > offending process you can just kill that particular process to resolve > deadlocks or long running queries. We normally use linux and find the > processes using lsof to get the open connection to the db tied back to the > IP address of the offending computer. I am not sure how to do that on > Windows though. > > -steve > > -- > Steve Wiser > President > Specialized Business Software > 6325 Cochran Road, Unit 1 > Solon, OH 44139 > > www.specializedbusinesssoftware.com > www.docunym.com > (440) 542-9145 - fax (440) 542-9143 > Toll Free: (866) 328-4936 > > > > > On Tue, Oct 18, 2011 at 9:44 PM, vincent999x wrote: > > > ** > > > > > > hello, > > We recently switched from superserver mode to classic mode (still stuck on > > Firebird 1.5 unfortunately) to take advantage of the 2nd CPU on the server > > and to prevent intensive queries from slowing down the whole system. It has > > worked out well except that we seem to see more deadlocks now. > > > > Currently, we have one user who has been unable to update a record for 3 > > days now (keeps getting a deadlock condition), so it seems that as a last > > resort I might have to restart Firebird to break this deadlock. > > > > Here's my question -- how do I do that? Do I have to kill all of the > > fb_inet_server processes? The easiest way for me is to reboot the server, > > but is there a better way? We have a GUI tool (Easy-IP DB manager), but it > > only kills the Firebird listener process. > > > > Two other things I've noticed with classic vs. superserver: > > 1) I'm having more trouble altering stored procedures. It seems classic > > mode won't let you update a stored procedure if it's currently being run. I > > don't recall this problem with superserver mode. > > 2) In superserver mode, when I abnormally terminated from IBExpert (our SQL > > query tool) due to the query taking too long -- the system response time > > improved immediately. However, in classic mode, the fb_inet_server process > > continues to run even though I abnormally terminated from IBExpert. > > > > Thanks in advance for any assistance. I know the long-term solution is to > > write better code, but for the short-term I need a way to break deadlocks > > without rebooting the database server constantly. > > > > vince > > > > > > > > > > > > This message and any files transmitted with it may contain information that > > is privileged, confidential, and exempt from disclosure under applicable > > law. They are intended solely for the use of the intended recipient. If > > you are not the intended recipient, distributing, copying, disclosing, or > > reliance on the contents of this communication is strictly prohibited. If > > this has reached you in error, kindly destroy this message and notify the > > sender immediately. Thank you for your assistance. > > > > We attempt to sweep harmful content (e.g. viruses) from e-mail and > > attachments, however we cannot guarantee their safety and can accept no > > liability for any resulting damage. The recipient is responsible to verify > > the safety of this message and any attachments before accepting them. > > > [Non-text portions of this message have been removed] >
[firebird-support] Re: Handling deadlocks with classic mode
Ann, Thanks for the suggestion. If I can tie a deadlock to a process ID, that will work out great. I was intimidated by the lock manager before but after looking at its printout again, it doesn't seem that bad. Thomas, We do not have SysInternals ProcessExplorer on our server, but I see that it is freely available so we will shortly. Thanks to all for your help. I think I have enough information and tools now to solve my Firebird issues. Regards, vince --- In firebird-support@yahoogroups.com, Ann Harrison wrote: > > Vince, > > > Thanks for the response. We are running Windows. I'm not sure how much > > information about the fb_inet_server processes I can gather -- other than > > how long they've been running. Not sure how to get the IP address of the > > connecting client. I'm going to just start killing the oldest > > fb_inet_server processes, but I don't know how I can distinguish the > > listener process. If I kill that one by mistake, I guess I'll have to > > reboot the whole server because I don't know how to restart just the > > listener. > > > > Is there a way to identify the listener process? > > > > > > > Get a full lock print, find the deadlock, find the owner block for the > deadlocked resource, and you'll find the process id of the listener there. > Helen's book describes the contents of the lock print. > > Good luck, > > Ann > > > [Non-text portions of this message have been removed] >
Re: [firebird-support] Re: Handling deadlocks with classic mode
>Thanks for the response. We are running Windows. I'm not sure how much > information about the fb_inet_server processes I can gather -- other than how > long they've been running. Not sure how to get the IP address of the > connecting client. I'm going to just start killing the oldest fb_inet_server > processes, but I don't know how I can distinguish the listener process. If > I kill that one by mistake, I guess I'll have to reboot the whole server > because I don't know how to restart just the listener. > > Is there a way to identify the listener process? If it runs as a Windows service, open SysInternals ProcessExplorer. You should see a fb_inet_server.exe process under the winit.exe/system.exe node. Restarting the listener process is simply restaring the service (if it runs as a Windows service) or by executing fb_inet_server.exe with the -a (as an application) switch. -- With regards, Thomas Steinmaurer * Upscene Productions - Database Tools for Developers http://www.upscene.com/ * My Blog http://blog.upscene.com/thomas/index.php * Firebird Foundation Committee Member http://www.firebirdsql.org/en/firebird-foundation/ > vince > > --- In firebird-support@yahoogroups.com, Steve Wiser wrote: >> >> What OS are you running on the server? For Classic, if you can find the >> offending process you can just kill that particular process to resolve >> deadlocks or long running queries. We normally use linux and find the >> processes using lsof to get the open connection to the db tied back to the >> IP address of the offending computer. I am not sure how to do that on >> Windows though. >> >> -steve >> >> -- >> Steve Wiser >> President >> Specialized Business Software >> 6325 Cochran Road, Unit 1 >> Solon, OH 44139 >> >> www.specializedbusinesssoftware.com >> www.docunym.com >> (440) 542-9145 - fax (440) 542-9143 >> Toll Free: (866) 328-4936 >> >> >> >> >> On Tue, Oct 18, 2011 at 9:44 PM, vincent999x wrote: >> >>> ** >>> >>> >>> hello, >>> We recently switched from superserver mode to classic mode (still stuck on >>> Firebird 1.5 unfortunately) to take advantage of the 2nd CPU on the server >>> and to prevent intensive queries from slowing down the whole system. It has >>> worked out well except that we seem to see more deadlocks now. >>> >>> Currently, we have one user who has been unable to update a record for 3 >>> days now (keeps getting a deadlock condition), so it seems that as a last >>> resort I might have to restart Firebird to break this deadlock. >>> >>> Here's my question -- how do I do that? Do I have to kill all of the >>> fb_inet_server processes? The easiest way for me is to reboot the server, >>> but is there a better way? We have a GUI tool (Easy-IP DB manager), but it >>> only kills the Firebird listener process. >>> >>> Two other things I've noticed with classic vs. superserver: >>> 1) I'm having more trouble altering stored procedures. It seems classic >>> mode won't let you update a stored procedure if it's currently being run. I >>> don't recall this problem with superserver mode. >>> 2) In superserver mode, when I abnormally terminated from IBExpert (our SQL >>> query tool) due to the query taking too long -- the system response time >>> improved immediately. However, in classic mode, the fb_inet_server process >>> continues to run even though I abnormally terminated from IBExpert. >>> >>> Thanks in advance for any assistance. I know the long-term solution is to >>> write better code, but for the short-term I need a way to break deadlocks >>> without rebooting the database server constantly. >>> >>> vince >>> >>> >>> >>> >>> >>> This message and any files transmitted with it may contain information that >>> is privileged, confidential, and exempt from disclosure under applicable >>> law. They are intended solely for the use of the intended recipient. If >>> you are not the intended recipient, distributing, copying, disclosing, or >>> reliance on the contents of this communication is strictly prohibited. If >>> this has reached you in error, kindly destroy this message and notify the >>> sender immediately. Thank you for your assistance. >>> >>> We attempt to sweep harmful content (e.g. viruses) from e-mail and >>> attachments, however we cannot guarantee their safety and can accept no >>> liability for any resulting damage. The recipient is responsible to verify >>> the safety of this message and any attachments before accepting them. >> >> >> [Non-text portions of this message have been removed] >> > > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > Yahoo! Groups Links > > >
Re: [firebird-support] Re: Handling deadlocks with classic mode
Vince, > Thanks for the response. We are running Windows. I'm not sure how much > information about the fb_inet_server processes I can gather -- other than > how long they've been running. Not sure how to get the IP address of the > connecting client. I'm going to just start killing the oldest > fb_inet_server processes, but I don't know how I can distinguish the > listener process. If I kill that one by mistake, I guess I'll have to > reboot the whole server because I don't know how to restart just the > listener. > > Is there a way to identify the listener process? > > Get a full lock print, find the deadlock, find the owner block for the deadlocked resource, and you'll find the process id of the listener there. Helen's book describes the contents of the lock print. Good luck, Ann [Non-text portions of this message have been removed]
