Re: High CPU shoot during poll retry

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/>
http://www.globallogic.com/email_disclaimer.txt

On Sat, Dec 13, 2014 at 2:27 AM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
>