[Oisf-users] Processing threads limit of 16?

[Cooper F. Nelson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Huh, I was certain that would work.  For my own edification, could dump
/proc/interrupts to a file and send it to me?

Another thing you could try would be to use dual-interface NIC and
load-balance the flows across them.  You could probably do this with
either a bonded interface on your router, or a dedicated switch, like an
Arista.

- -Coop

On 3/2/2015 7:45 AM, Barkley, Joey wrote:
> I gave this a shot but never could quite make it work. I still only
> had data logging in the stats log on the first 16 cores (even though
> I had specified even numbered cores from 0-30). But that’s OK as I am
> still having RAM usage issues anyway. I think my processing is
> relatively stable at this point with all the configuration changes
> all of you have suggested in other threads. I’m just trying to tweak
> now and reduce my RAM usage so I can possibly run another instance of
> Suricata and use 16 more cores.
> 
> Thanks again for all the help!
> 
> 
>> On Feb 17, 2015, at 12:15 PM, Cooper F. Nelson <cnelson at ucsd.edu>
>> wrote:
>> 
> Sorry to hear that, my condolences.
> 
> I'll save you some time and show you how to easily set the IRQ
> vectors for the Intel nics on cores 0-30, even cores only.
> 
> 1.  Stop the irqbalance daemon.
> 
> 2.  Edit the set_irq_affinity script (this ships with the driver).
> 
> Find this line: for VEC in `seq 0 1 $MAX`
> 
> ..and change it to:
> 
> for VEC in `seq 0 2 30`
> 
> Then run the script with the Intel eth device as its argument.
> 
> In the suricata.yaml file, set the 'detect-cpu-set' directive as
> follows:
> 
>>>> - detect-cpu-set: cpu: [
>>>> 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 ] mode: "exclusive"
>>>> # run detect threads in these cpus # Use explicitely 3 threads
>>>> and don't compute number by using # detect-thread-ratio
>>>> variable: #threads: 2 prio: default: "high"
> 
> 
> -Coop
> 
> 
> On 2/16/2015 9:23 PM, Barkley, Joey wrote:
>>>> Thanks Eric and Coop. I’ve had a death in the family and won’t
>>>> be able to work on this for a few more days, but I’ll try the
>>>> cluster_flow setting (though in my previous attempts that
>>>> seemed to result in quite a high % of kernel_drops) and also
>>>> the trick Coop talked about with setting the cores to even/odd
>>>> irq balancing. I like that last idea, but will be a little
>>>> tricky.
>>>> 
>>>> 
> 
>> 
> 
> 
> _______________________________________________ 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 
> Training now available: http://suricata-ids.org/training/
> 

- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU9JCfAAoJEKIFRYQsa8FW3NwH/0MFL0lM7L1nEU/FphztV/x+
QwMHOjaUwL3FtXJ+Es7Bnzr+8/W91+lWAkGySZ/Nm8WjRamvgnj3JjhN36oCK/ok
bspmAUVQVYatTGfaKG6RoGJtEgT+lzpYtKmsyK0T9Mdb189amPjtrALlOu+iI9U6
MnLGJjyet8Hft/CSqYcGvBQc4rBKFb8L4/fo5c347cktruhKkIf6zDwT8zhcXSTQ
d/BOIhQurSkDociFgbRk7a93Bzi6mopzRC7qorMrZGSB/sqw6NdfBDnAT2RXZgB9
o6ZbLJVorCujow049Pn34EbVm+kLrny8HKCSs1koa0coQeMLHKNjSK0N1ikdwgM=
=fxcN
-----END PGP SIGNATURE-----