All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Michal Marciniszyn <michal.marciniszyn@gooddata.com>
Cc: selinux@tycho.nsa.gov, Paul Moore <paul@paul-moore.com>
Subject: Re: Performance issues - huge amount of AVC misses
Date: Tue, 8 Dec 2015 12:06:29 -0500	[thread overview]
Message-ID: <56670E15.60305@tycho.nsa.gov> (raw)
In-Reply-To: <CAL8PO=2TMsT=DUJ-1oKKC+OutuHWVH1VqTsNDqKxKRVwon7Urw@mail.gmail.com>

On 12/08/2015 11:21 AM, Michal Marciniszyn wrote:
> Hi,
>
> there are neither categories nor MLS used on the system. I'll get the
> amount of different types used by the system (I need to do some digging,
> will get the data tomorrow). Most of classes will be regular file,
> directories and some symbolic links. There will be a lots of files as
> AFAIK vertica uses lots of smaller files.
>
> I'll try to reduce amount of dontaudit rules and I'll see how much this
> reduces cache misses. The hard truth is, that vertica is looking at many
> places during the run, most of which it does not need. Maybe the way we
> have rules defined is creating a lot of stress on the amount of rules in
> the policy, I'll try to get the data on that.

Cache misses aren't related to your number of dontaudit rules (or your 
number of rules at all, for that matter).  The optimal AVC size is 
driven by the number of unique (source security context, target security 
context, target security class) triples being accessed during the 
workload.  Each entry holds a complete access vector decision structure, 
including permissions that are allowed, permissions that are audited 
when denied, and permissions that are audited when allowed.

I would recommend trying different values for the cache threshold and 
see how it performs. Collecting information on the number of domains, 
types, and classes involved in your workload may be helpful in 
determining the optimal value, but some experimentation will likely be 
required regardless.

Reducing the number of rules may help with the performance overhead when 
there is an AVC miss, but the first step is to reduce the AVC misses.

  parent reply	other threads:[~2015-12-08 17:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 10:25 Performance issues - huge amount of AVC misses Michal Marciniszyn
2015-12-08 10:44 ` Dominick Grift
2015-12-08 14:56   ` Michal Marciniszyn
2015-12-08 15:05     ` Daniel J Walsh
2015-12-08 15:10     ` Dominick Grift
2015-12-08 15:35     ` Stephen Smalley
2015-12-08 16:21       ` Michal Marciniszyn
2015-12-08 16:29         ` Dominick Grift
2015-12-08 17:06         ` Stephen Smalley [this message]
2015-12-08 15:29 ` Stephen Smalley
2015-12-08 16:16   ` Michal Marciniszyn
2015-12-09 10:07 ` Milos Malik
2015-12-09 10:19   ` Michal Marciniszyn
2015-12-09 13:15     ` Michal Marciniszyn
2015-12-09 15:05       ` Stephen Smalley
2015-12-09 16:07         ` Joe Nall
2015-12-09 17:07           ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56670E15.60305@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=michal.marciniszyn@gooddata.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.