From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.1] sepgsql - userspace access vector cache |
Date: | 2011-07-14 19:46:26 |
Message-ID: | CADyhKSUUr9VrX6jUBPrd6nXRzNq+X8EAa1Y63HGreL8wgSUjJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So, I hope someone to volunteer to review these patches.
Thanks,
2011/7/11 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> I rebased the userspace access vector cache patch to the latest tree.
>
> I'll describe the background of this patch because this thread has not been
> active more than a week.
> The sepgsql asks in-kernel selinux when it needs to make its access control
> decison, so it always causes system call invocations.
> However, access control decision of selinux for a particular pair of security
> label is consistent as long as its security policy is not reloaded.
> Thus, it is a good idea to cache access control decisions recently used in
> userspace.
> In addition, current GetSecurityLabel() always open pg_seclabel catalog and
> scan to fetch security label of database objects, although it is a situation we
> can utilize syscache mechanism.
>
> The "uavc-syscache" patch adds a new SECLABELOID syscache.
> It also redefine pg_seclabel.provide as Name, instead of Text, according to
> the suggestion from Tom.
> (To avoid collation conscious datatype)
>
> The "uavc-selinux-cache" patch adds cache mechanism of contrib/sepgsql.
> Its internal api to communicate with selinux (sepgsql_check_perms) was
> replaced by newer sepgsql_avc_check_perms that checks cached access
> control decision at first, prior to system call invocations.
>
> The result of performance improvement is obvious.
>
> * Test 2. time to run 50,000 of SELECT from empty tables
> selinux | SECLABELOID syscache
> avc | without | with
> ---------+-----------------------
> without | 185.59[s] | 178.38[s]
> ---------+-----------------------
> with | 23.58[s] | 21.79[s]
> ---------+-----------------------
>
> I strongly hope this patch (and security label support on shared objects) to
> get unstreamed in this commit-fest, because it will perform as a basis of
> other upcoming features.
> Please volunteer the reviewing!
>
> Thanks,
>
> 2011/7/2 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
>> The attached patch re-defines pg_seclabel.provider as NameData, instead of Text,
>> and revert changes of catcache.c about collations; to keep consistency with the
>> security label support on shared objects.
>> All the format changes are hidden by (Get|Set)SecurityLabel(), so no
>> need to change
>> on the patch to contrib/sepgsql.
>>
>> Thanks,
>>
>> 2011/6/13 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
>>> 2011/6/13 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>>> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>>>> For syscache, length of a typical security label in selinux is
>>>>> less than 64 bytes. If we assume an entry consume 128bytes
>>>>> including Oid pairs or pointers, its consumption is 128KBytes
>>>>> per 1,000 of tables or others.
>>>>> (Do we have a way to confirm syscache status?)
>>>>
>>>> I was thinking you might start a new session, SELECT pg_backendd_pid()
>>>> to get the PID, use top/ps to get its memory usage; then do a bunch of
>>>> stuff and see how much it's grown. The difference between how much it
>>>> grows with and without the patch is the amount of additional memory
>>>> the patch consumes.
>>>>
>>> I checked memory consumption of the backend with / without
>>> patches. Because sepgsql_restorecon() tries to reset security
>>> label of all the schemas, relations, columns and procedures,
>>> an execution of this function is suitable to emphasize differences
>>> between two cases in maximum.
>>>
>>> The results shows us about 3MB of additional consumption
>>> in VmRSS, even if it caches all the security label of the objects
>>> being created in the default (3331 entries).
>>>
>>> * without patches before/after sepgsql_restorecon()
>>>
>>> VmPeak: 150812 kB -> 170864 kB
>>> VmSize: 150804 kB -> 154712 kB
>>> VmLck: 0 kB -> 0kB
>>> VmHWM: 3800 kB -> 22248 kB
>>> VmRSS: 3800 kB -> 10620 kB
>>> VmData: 1940 kB -> 5820 kB
>>> VmStk: 196 kB -> 196 kB
>>> VmExe: 5324 kB -> 5324 kB
>>> VmLib: 2468 kB -> 2468 kB
>>> VmPTE: 108 kB -> 120 kB
>>> VmSwap: 0 kB -> 0kB
>>>
>>> * with patches before/after sepgsql_restorecon()
>>> VmPeak: 150816 kB -> 175092 kB
>>> VmSize: 150808 kB -> 158804 kB
>>> VmLck: 0 kB -> 0 kB
>>> VmHWM: 3868 kB -> 25956 kB
>>> VmRSS: 3868 kB -> 13736 kB
>>> VmData: 1944 kB -> 9912 kB
>>> VmStk: 192 kB -> 192 kB
>>> VmExe: 5324 kB -> 5324 kB
>>> VmLib: 2472 kB -> 2472 kB
>>> VmPTE: 100 kB -> 124 kB
>>> VmSwap: 0 kB -> 0 kB
>>>
>>> Thanks,
>>> --
>>> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>>>
>>
>>
>>
>> --
>> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>>
>
>
>
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
pgsql-v9.2-uavc-selinux-cache.v4.patch | application/octet-stream | 37.3 KB |
pgsql-v9.2-uavc-syscache.v4.patch | application/octet-stream | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-07-14 19:58:05 | Re: Understanding GIN posting trees |
Previous Message | Tom Lane | 2011-07-14 19:19:59 | Re: pg_class.relistemp |