Re: High CPU shoot during poll retry - Mailing list pgsql-odbc

From Gaurav Srivastava
Subject Re: High CPU shoot during poll retry
Date
Msg-id CAAXqS3BMGeypjdKs5tO-17hvJd8CaetYVFsQHZX_Djmj94nVuQ@mail.gmail.com
Whole thread Raw
In response to Re: High CPU shoot during poll retry  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-odbc
Hi Heikki,

Sincere thanks for your quick responses.

Can we have similar functionality added in psqlODBC as in unmodified code when nowait==False it waits for "infinite duration" ,Instead If we have a configured timed wait,anybody can configure it as per their requirement.

Waiting for infinite time would still cause query hung scenarios Please let me know if i am wrong or misunderstood.

Thanking again,
Gaurav Srivastava | Associate Consultant
GlobalLogic
P +91.120.4342000.2920  M +91.9953996631  S ta5ramn1
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

On Wed, Dec 17, 2014 at 7:16 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 12/17/2014 07:21 AM, Gaurav Srivastava wrote:
Hi Heikki,

Just to explain a bit more about the case "nowait==FALSE"

We used this fix "Rip out broken retry/timeout logic in
SOCK_wait_for_ready" as in few scenarios our clients also get stuck in
infinite wait and our design is such that none of our process can wait
little longer than few secs if this happens preventive actions are taken
resulting re-initialization of the process.


In order to avoid that wait situation we did slight modification i.e.
making "nowait" TRUE everywhere in SOCK_wait_for_ready() API which resolved
our poll() wait issue after your fix,thanks for that but later to that this
high CPU issue has come.

We resolved it using micro sleep,but still looking for a better solution,as
we don't have much understanding of ODBC.

Ok. Well, all I can say to that is "don't do that". There isn't anything wrong with SOCK_wait_for_ready, as it's used in unmodified psqlodbc.

One idea is to have a separate watchdog thread or alarm signal handler, and if an operation takes longer than you tolerate, have the watchdog thread forcibly close() the socket. That will wake up the thread blocked on the socket. You'll still need to hack psqlodbc to get the file descriptor of the socket so that you can close() it, but it seems less risky.

- Heikki

pgsql-odbc by date:

Previous
From: Gaurav Srivastava
Date:
Subject: Re: High CPU shoot during poll retry
Next
From: Gaurav Srivastava
Date:
Subject: Re: High CPU shoot during poll retry