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 <steve@...> 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 <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]
>
