[Oisf-users] Suricata using 35% cpu with no load?
Peter Manev
petermanev at gmail.com
Fri Jul 31 13:47:21 UTC 2015
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
More information about the Oisf-users
mailing list