[Oisf-users] Suricata using 35% cpu with no load?
Peter Manev
petermanev at gmail.com
Sat Aug 1 17:24:53 UTC 2015
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
More information about the Oisf-users
mailing list