Results 1 to 2 of 2

Thread: Why CPU utilization is 80% in SUSE 11 but 0 in SUSE 10

  1. #1

    Why CPU utilization is 80% in SUSE 11 but 0 in SUSE 10

    Our service receive (C/C++) data from network (using select) and process the data and forward to network. Its designed as producer (1 thread, receive from network) and consumer(6 thread, manipulate the data and forward to network). In consumer it sleep for some time (4ms using select) and check if any data need to process. (i know this is not good design).

    For high traffic from network , CPU utilization over 80% in suse 11 but 0~1% in suse 10 on same hardware.

    I know clock precision in suse 10 is 4ms and suse 11 its 4ns. I check the CPU uses of each thread (using top -H). All producer and consumer thread utilization in suse 11 is over 10% but in suse 10 its 0%. I tried to analyse strace output. In suse 11, select is taking 98% of time but in suse 10 its taking around 70%. I checked the oprofile output in suse 10 and suse 11 but could not findout what to analyse.

    I also have written one sample server and client which just recive the message from sample client. Message rate 9000 msg /second. In SUSE 11, each server and client are taking over 7% but same test application take 0% in suse 10.

    Plz help me to analyze. Thanks !!

    /** server select logic **/
    if (select(fdmax+1, &read_fds, NULL, NULL, NULL) == -1)
    {
    perror("select");
    exit(4);
    }
    /** client **/
    while(1)
    {
    for(int i =0; i<400; ++i)
    {
    /* send the message line to the server */
    n = write(sockfd, buf, strlen(buf));
    if (n < 0)
    printf("ERROR writing to socket\n");
    }
    m_sleepTime.tv_sec = 0;
    m_sleepTime.tv_usec = 4000; // in 1 second, 250 times
    if (-1 == select(FD_SETSIZE, NULL, NULL, NULL, &m_sleepTime))
    {
    printf("Select Failed\n");
    }
    }

  2. Re: Why CPU utilization is 80% in SUSE 11 but 0 in SUSE 10

    Hi akumar007,

    select() is not intended as a substitute for usleep()/nanosleep() and I'd assume that the pselect() kernel implementation has changed WRT optimization: You have not specified any file handles to check, so I wouldn't be surprised to see that the call returns immediately while in SLES10's kernel, it may have waited although no handles to watch where given.

    Regards,
    Jens
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •