Return-Path: 
 <users-return-1123-apmail-trafficserver-users-archive=trafficserver.apache.org@trafficserver.apache.org>
X-Original-To: apmail-trafficserver-users-archive@www.apache.org
Delivered-To: apmail-trafficserver-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id AA9509740
	for <apmail-trafficserver-users-archive@www.apache.org>;
 Thu, 13 Oct 2011 08:00:56 +0000 (UTC)
Received: (qmail 28257 invoked by uid 500); 13 Oct 2011 08:00:56 -0000
Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org
Received: (qmail 28228 invoked by uid 500); 13 Oct 2011 08:00:56 -0000
Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@trafficserver.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@trafficserver.apache.org>
List-Post: <mailto:users@trafficserver.apache.org>
List-Id: <users.trafficserver.apache.org>
Reply-To: users@trafficserver.apache.org
Delivered-To: mailing list users@trafficserver.apache.org
Received: (qmail 28215 invoked by uid 99); 13 Oct 2011 08:00:56 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Oct 2011 08:00:56 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of briangeffon@gmail.com
 designates 209.85.215.170 as permitted sender)
Received: from [209.85.215.170] (HELO mail-ey0-f170.google.com)
 (209.85.215.170)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Oct 2011 08:00:50 +0000
Received: by eyg7 with SMTP id 7so1558418eyg.29
        for <multiple recipients>; Thu, 13 Oct 2011 01:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=references:from:in-reply-to:mime-version:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        bh=MWVELEn5jjcYW/yQZh2JClfFVzQPqnSmidKxeiBmI64=;
        b=VoHWWPsbt4mfwiPkWKxOpUS51Q2O5gZkQFLJGEJUQSZwKyoDWKPnWyUd+R0p/YWzjV
         8/8HxKUu7Jsymg/LtLlAG1E0yIF+oHMEvIo7JGhCOuFSINkwhUq6iK4rcoAFkBBC0ZWt
         BZdrzDTLuid6OMegTGjp6afff9eypaf+iGjqo=
Received: by 10.223.14.85 with SMTP id f21mr4404114faa.37.1318492829344; Thu,
 13 Oct 2011 01:00:29 -0700 (PDT)
References: <ea580b24-7378-4d60-9802-f11009837807@iris>
From: Brian Geffon <briangeffon@gmail.com>
In-Reply-To: <ea580b24-7378-4d60-9802-f11009837807@iris>
Mime-Version: 1.0 (iPhone Mail 8E200)
Date: Thu, 13 Oct 2011 01:00:25 -0700
Message-ID: <-5742300653707473961@unknownmsgid>
Subject: Re: High idle cpu utilization on RHEL6
To: "users@trafficserver.apache.org" <users@trafficserver.apache.org>
Cc: "dev@trafficserver.apache.org" <dev@trafficserver.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Igor,

No I am not using SELinux, any other ideas on what might be causing
this, it seems very strange. I suppose it should be worth noting this
is an 8 core machine, could the thread auto scaling just be allocating
more resources to cover the idle threads?

Thanks!



On Oct 2, 2011, at 11:22 AM, "Igor Gali=C4=87" <i.galic@brainsware.org> wro=
te:

>
>
> ----- Original Message -----
>> On Wed, Sep 28, 2011 at 3:35 PM, Brian Geffon <briangeffon@gmail.com>
>> wrote:
>>
>>> Hi,
>>> I'm encountering something strange with ATS3.0.1 on Red Hat
>>> Enterprise
>>> Linux 6, using a vanilla build with no modules enabled and the
>>> default
>>> records.config /w zero entries in the remap file, ATS is idling at
>>> very high
>>> CPU (around 15-20%).
>>>
>>> root     13509  0.0  0.0  58512  2392 ?        Ss   19:15   0:00
>>> /usr/local/ats3.0.1plain//bin/traffic_cop
>>> nobody   13511  0.1  0.0 480072 16632 ?        Sl   19:15   0:00
>>> /usr/local/ats3.0.1plain/bin/traffic_manager
>>> nobody   13521 ***16.9***  0.1 1584628 114224 ?      Sl   19:15
>>>  2:06
>>> /usr/local/ats3.0.1plain/bin/traffic_server -M -A,7:X
>>>
>>> So I used strace to try to determine what might be causing this,
>>> and here
>>> is what i've found:
>>>
>>> [root@machine]# strace -c -p 13521
>>> Process 13521 attached - interrupt to quit
>>> ^CProcess 13521 detached
>>> % time     seconds  usecs/call     calls    errors syscall
>>> ------ ----------- ----------- --------- --------- ----------------
>>> 100.00    3.589451         796      4510           epoll_wait
>>> ------ ----------- ----------- --------- --------- ----------------
>>> 100.00    3.589451                  4510           total
>>> [root@machine]#
>>>
>>>
>>> It appears that it's entirely epoll_wait, and each call is taking
>>> 796
>>> microseconds! So I have to concerns with this, first, why would
>>> epoll_wait
>>> take such a long amount of time, 796 microseconds seems like a long
>>> time,
>>> and more importantly, how could it possibly be called so
>>> frequently, does
>>> ATS use a short timeout when doing epoll_waits?
>>>
>>> I would really appreciate any feedback regarding this, has anyone
>>> else
>>> experienced this? Is there anywhere else I might look to determine
>>> the cause
>>> of this? Could this be classified as _normal_ behavior?
>>>
>>>
>>>
>> It is working as designed. The epoll timeout is set to 0 or 10 msec
>> on
>> linux. Could there be very little or no load going through this
>> instance?
>> That would explain why you are only seeing epoll_wait. In that case
>> there
>> isn't really anything wrong, the process is just burning through
>> epoll_waits
>> looking for something to do when nothing is available. Once the
>> process
>> starts taking enough traffic, you will start to see user space and
>> other
>> kernel functions start to take cpu time.
>
> That still doesn't quite explain the high load on an Idle system.
>
> Brian: Do you happen to have SELinux enabled?
>
>> Sridhar
>
> i
>
> --
> Igor Gali=C4=87
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3  EF6F 43AD 80A4 5779 3257