Request a Demo
Home   >   mailing lists

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 CAAXqS3BFjOe8MBwprVqLwTH4BFvU55v6fGjd77XTZdj19raDuQ@mail.gmail.com
Whole thread
In response to Re: High CPU shoot during poll retry  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: High CPU shoot during poll retry
List pgsql-odbc
Tree view
We are providing timeout value as 0 or  -1 in poll() timeout field meaning zero timeout or infinite wait . During zero timeout case poll will immediately return with return value as zero and come out of loop.But from the places where this api SOCK_wait_for_ready()is called , it is checked that return value is 0 or more

if (SOCK_wait_for_ready(sock, FALSE, FALSE) >= 0)
                                                
                                goto retry;
In case of zero timeout if reading fd is not ready, it will go into continuous retries and in case of access load suppose 200k registrations,10k calls running it will result CPU to shoot very high.

This is the actual problem statement,please let me know if i was able to made my point clear.

If yes,then other than putting usleep() before every retry can we provide better solution? I solved my issue using usleep

Thanks and Regards,


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 Sat, Dec 13, 2014 at 2:27 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 12/12/2014 12:31 PM, Gaurav Srivastava wrote:
Hi All,

In ODBC library later to change done as part of commit Title  "Rip out
broken retry/timeout logic in SOCK_wait_for_ready." in file socket.c

Now  the cpde snippet for SOCK_wait_for_ready() is like:

        do {
#ifdef  HAVE_POLL
                 fds.fd = sock->socket;
                 fds.events = output ? POLLOUT : POLLIN;
                 fds.revents = 0;
                *  ret = poll(&fds, 1, nowait ? 0 : -1); *
mylog("!!!  poll ret=%d revents=%x\n", ret, fds.revents);
#else
                 FD_ZERO(&fds);
                 FD_ZERO(&except_fds);
                 FD_SET(sock->socket, &fds);
                 FD_SET(sock->socket, &except_fds);
                 if (nowait)
                 {
                         tm.tv_sec = 0;
                         tm.tv_usec = 0;
                 }
                 ret = select((int) sock->socket + 1, output ? NULL : &fds,
output ? &fds : NULL, &except_fds, nowait ? &tm : NULL);
#endif /* HAVE_POLL */
                 gerrno = SOCK_ERRNO;
          } *while (ret < 0 && EINTR == gerrno);*



So whenever there is no fd is ready to be read it will immediately return
and solve the issue of infinite query hung but  due to immediate return it
will go for continuous retries and causing CPU to shoot very high.This is
one of the case we are suffering in our scenario after upgrading ODBC.

Why do you think it will go into continuous retries?

- Heikki

pgsql-odbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: High CPU shoot during poll retry
Next
From: Heikki Linnakangas
Date:
Subject: Re: High CPU shoot during poll retry