[Oisf-users] Suricata using 35% cpu with no load?

Duane Howard duane.security at gmail.com
Tue Aug 11 18:39:48 UTC 2015


Drops to ~7-10% with that change. Sorry for the delayed response.

On Sat, Aug 1, 2015 at 10:24 AM, Peter Manev <petermanev at gmail.com> wrote:

> On Fri, Jul 31, 2015 at 7:39 PM, Duane Howard <duane.security at gmail.com>
> wrote:
> > Just build 2.1beta4 and it's the same thing.
> >
> > On Fri, Jul 31, 2015 at 10:22 AM, Duane Howard <duane.security at gmail.com
> >
> > wrote:
> >>
> >> yaml sent off list.
>
> From the privately shared yaml -
> flow:
>   memcap: 1.5gb
>   hash-size: 15728640
>
> divide flow.memcap  by 3 and flow.hash-size by 10 - reload and please
> let us know if any difference.
>
> Thanks
>
> >>This is the only machine I've tried on right now, and
> >> I can't use the other one that is similarly configured because it's
> being
> >> used for other stuff at the moment. I did pretty extensive
> experimentation
> >> with 2.0.6 a while back on hardware and didn't see this issue. I'll try
> >> installing 2.1 and playing with it later today to see if I can reproduce
> >> that way.
> >>
> >> On Fri, Jul 31, 2015 at 6:47 AM, Peter Manev <petermanev at gmail.com>
> wrote:
> >>>
> >>> On Thu, Jul 30, 2015 at 11:27 PM, Duane Howard <
> duane.security at gmail.com>
> >>> wrote:
> >>> > strace only shows the process doing constant:
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > nanosleep({0, 10000000}, NULL)          = 0
> >>> > ....
> >>> >
> >>>
> >>> Hmm strange. I have not experianced that before.
> >>> Does this happen on any VM or just this one in particular?
> >>> Can you switch to 2.1beta4 and see if any difference. Please feel free
> >>> to send me your suricata.yaml if you would like - I can see if this is
> >>> enough to reproduce the issue.
> >>>
> >>> thanks
> >>>
> >>>
> >>> >
> >>> > On Thu, Jul 30, 2015 at 2:17 PM, Duane Howard
> >>> > <duane.security at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> I can reproduce. I ran it on a single low volume real NIC with the
> >>> >> same
> >>> >> result. Nothing terribly interesting in suricata.log with -vv
> enabled:
> >>> >> Here's the logs after rule and config loading:
> >>> >>
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Core dump size set to unlimited.
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Unified2-alert initialized:
> filename
> >>> >> suricata.u2, limit 128 MB
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Syslog output initialized
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Unable to find af-packet config for
> >>> >> interface "eth0" or "default", using default value
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Going to use 1 thread(s)
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Enabling zero copy mode
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - RunModeIdsAFPWorkers initialised
> >>> >> 30/7/2015 -- 21:14:06 - <Notice> - all 1 packet processing threads,
> 3
> >>> >> management threads initialized, engine started.
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Using interface 'eth0' via socket 7
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - All AFP capture threads are
> running.
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Thread AFPacketeth01 using socket 7
> >>> >> 30/7/2015 -- 21:14:06 - <Info> - Starting to read on AFPacketeth01
> >>> >> ^C30/7/2015 -- 21:15:27 - <Notice> - Signal Received.  Stopping
> >>> >> engine.
> >>> >> 30/7/2015 -- 21:15:27 - <Info> - 0 new flows, 0 established flows
> were
> >>> >> timed out, 0 flows in closed state
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - time elapsed 81.925s
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Kernel: Packets
> 3372,
> >>> >> dropped 0
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Packets 3345, bytes
> >>> >> 1318862
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - Stream TCP processed 2723 TCP
> packets
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Alerts 0
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - Alert unified2 module wrote 0
> alerts
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - host memory usage: 390144 bytes,
> >>> >> maximum:
> >>> >> 16777216
> >>> >> 30/7/2015 -- 21:15:28 - <Info> - cleaning up signature grouping
> >>> >> structure... complete
> >>> >> 30/7/2015 -- 21:15:28 - <Notice> - Stats for 'eth0':  pkts: 3372,
> >>> >> drop: 0
> >>> >> (0.00%), invalid chksum: 0
> >>> >>
> >>> >>
> >>> >> On Thu, Jul 30, 2015 at 2:02 PM, Peter Manev <petermanev at gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>>
> >>> >>> On 30 jul 2015, at 21:50, Duane Howard <duane.security at gmail.com>
> >>> >>> wrote:
> >>> >>>
> >>> >>>
> >>> >>> Can you reproduce this problem at will? Anything in verbose mode in
> >>> >>> Suricata.log?
> >>> >>>
> >>> >>> Can you narrow it down to a relation of a single interface
> >>> >>> configuration
> >>> >>> (as you mention in your initial mail)?
> >>> >>>
> >>> >>> Thanks
> >>> >>>
> >>> >>>
> >>> >>> This is Suricata version 2.0.8 RELEASE
> >>> >>> Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET
> >>> >>> HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK
> >>> >>> SIMD support: none
> >>> >>> Atomic intrisics: 1 2 4 8 byte(s)
> >>> >>> 64-bits, Little-endian architecture
> >>> >>> GCC version 4.6.3, C version 199901
> >>> >>> compiled with -fstack-protector
> >>> >>> compiled with _FORTIFY_SOURCE=2
> >>> >>> L1 cache line size (CLS)=64
> >>> >>> compiled with LibHTP v0.5.17, linked against LibHTP v0.5.17
> >>> >>> Suricata Configuration:
> >>> >>>   AF_PACKET support:                       yes
> >>> >>>   PF_RING support:                         yes
> >>> >>>   NFQueue support:                         no
> >>> >>>   NFLOG support:                           no
> >>> >>>   IPFW support:                            no
> >>> >>>   DAG enabled:                             no
> >>> >>>   Napatech enabled:                        no
> >>> >>>   Unix socket enabled:                     no
> >>> >>>   Detection enabled:                       yes
> >>> >>>
> >>> >>>   libnss support:                          no
> >>> >>>   libnspr support:                         no
> >>> >>>   libjansson support:                      no
> >>> >>>   Prelude support:                         no
> >>> >>>   PCRE jit:                                no
> >>> >>>   LUA support:                             no
> >>> >>>   libluajit:                               no
> >>> >>>   libgeoip:                                yes
> >>> >>>   Non-bundled htp:                         yes
> >>> >>>   Old barnyard2 support:                   no
> >>> >>>   CUDA enabled:                            no
> >>> >>>
> >>> >>>   Suricatasc install:                      yes
> >>> >>>
> >>> >>>   Unit tests enabled:                      no
> >>> >>>   Debug output enabled:                    no
> >>> >>>   Debug validation enabled:                no
> >>> >>>   Profiling enabled:                       no
> >>> >>>   Profiling locks enabled:                 no
> >>> >>>   Coccinelle / spatch:                     no
> >>> >>>
> >>> >>> Generic build parameters:
> >>> >>>   Installation prefix (--prefix):          /usr
> >>> >>>   Configuration directory (--sysconfdir):  /etc/suricata/
> >>> >>>   Log directory (--localstatedir) :        /var/log/suricata/
> >>> >>>
> >>> >>>   Host:                                    x86_64-pc-linux-gnu
> >>> >>>   GCC binary:                              gcc
> >>> >>>   GCC Protect enabled:                     no
> >>> >>>   GCC march native enabled:                no
> >>> >>>   GCC Profile enabled:                     no
> >>> >>>
> >>> >>>
> >>> >>> On Thu, Jul 30, 2015 at 1:41 PM, Peter Manev <petermanev at gmail.com
> >
> >>> >>> wrote:
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On 30 jul 2015, at 20:58, Duane Howard <duane.security at gmail.com>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>> When closing suri it reports 0 packets for the interface I'm
> mainly
> >>> >>>> concerned with. There's also nothing in fast or other logs to
> >>> >>>> indicate
> >>> >>>> traffic.
> >>> >>>>
> >>> >>>> 30/7/2015 -- 19:58:41 - <Notice> - Stats for 'bond0':  pkts: 0,
> >>> >>>> drop: 0
> >>> >>>> (-nan%), invalid chksum: 0
> >>> >>>>
> >>> >>>>
> >>> >>>> What is the output of suricata --build-info ?
> >>> >>>>
> >>> >>>> If you have perf tools installed have a look at what in Suricata
> >>> >>>> uses
> >>> >>>> the most CPU -
> >>> >>>> perf top -p pidofsuri
> >>> >>>>
> >>> >>>> Thanks
> >>> >>>>
> >>> >>>>
> >>> >>>> On Thu, Jul 30, 2015 at 12:57 PM, Alan Wanderley dos Santos
> >>> >>>> <alan.santos at rnp.br> wrote:
> >>> >>>>>
> >>> >>>>> Didi you see the fast.log and others logs?
> >>> >>>>>
> >>> >>>>> Maybe there are some traffic (icmp or broadcast for example)
> coming
> >>> >>>>> to
> >>> >>>>> virtual machine, even little being data, can generated a lot of
> >>> >>>>> logs and
> >>> >>>>> degree the performance.
> >>> >>>>>
> >>> >>>>> I had a similar situation on a VM of testing.
> >>> >>>>>
> >>> >>>>> Just a shot into darkness rsrs
> >>> >>>>>
> >>> >>>>> Regards,
> >>> >>>>>
> >>> >>>>> -----------------------------------------------
> >>> >>>>> Alan Santos
> >>> >>>>> Analista de Segurança
> >>> >>>>> Centro de Atendimento a Incidentes de Segurança (CAIS)
> >>> >>>>> Rede Nacional de Ensino e Pesquisa (RNP)
> >>> >>>>> (19) 3787-3314 | alan.santos at rnp.br
> >>> >>>>>
> >>> >>>>> ________________________________
> >>> >>>>> De: "Duane Howard" <duane.security at gmail.com>
> >>> >>>>> Para: "oisf-users" <oisf-users at openinfosecfoundation.org>
> >>> >>>>> Enviadas: Quinta-feira, 30 de julho de 2015 16:50:51
> >>> >>>>> Assunto: [Oisf-users] Suricata using 35% cpu with no load?
> >>> >>>>>
> >>> >>>>> I've got a random virtual testing machine, and I'm seeing
> Suricata
> >>> >>>>> sitting at about 35% CPU load, even though there's absolutely no
> >>> >>>>> traffic
> >>> >>>>> heading to it at the moment. Is there an easy way to get Suricata
> >>> >>>>> to tell me
> >>> >>>>> what it's doing that would cause this? It occurs on real
> interfaces
> >>> >>>>> with low
> >>> >>>>> traffic, loopback, as well as bonds where there's no trafic.
> >>> >>>>> ./d
> >>> >>>>>
> >>> >>>>> _______________________________________________
> >>> >>>>> Suricata IDS Users mailing list:
> >>> >>>>> oisf-users at openinfosecfoundation.org
> >>> >>>>> Site: http://suricata-ids.org | Support:
> >>> >>>>> http://suricata-ids.org/support/
> >>> >>>>> List:
> >>> >>>>>
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>> >>>>> Suricata User Conference November 4 & 5 in Barcelona:
> >>> >>>>> http://oisfevents.net
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> Suricata IDS Users mailing list:
> >>> >>>> oisf-users at openinfosecfoundation.org
> >>> >>>> Site: http://suricata-ids.org | Support:
> >>> >>>> http://suricata-ids.org/support/
> >>> >>>> List:
> >>> >>>>
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>> >>>> Suricata User Conference November 4 & 5 in Barcelona:
> >>> >>>> http://oisfevents.net
> >>> >>>
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Peter Manev
> >>
> >>
> >
>
>
>
> --
> Regards,
> Peter Manev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150811/81d8214d/attachment-0002.html>


More information about the Oisf-users mailing list