Re: High CPU shoot during poll retry

From: Gaurav Srivastava <gaurav(dot)srivastava(at)globallogic(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: High CPU shoot during poll retry
Date: 2014-12-17 14:01:19
Message-ID: CAAXqS3BMGeypjdKs5tO-17hvJd8CaetYVFsQHZX_Djmj94nVuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/>
http://www.globallogic.com/email_disclaimer.txt

On Wed, Dec 17, 2014 at 7:16 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
>
>

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Heikki Linnakangas 2014-12-17 15:01:38 Re: High CPU shoot during poll retry
Previous Message Heikki Linnakangas 2014-12-17 13:46:45 Re: High CPU shoot during poll retry