CPU Spike caused by semanage commands
Anamitra Dutta Majumdar (anmajumd)
anmajumd at cisco.com
Wed Nov 21 17:57:26 UTC 2012
Dan,
Thanks for your response.
Why would semanage perform a recompile of the policies. Is it possible to
enforce semanage not to recompile the policies in order to prevent the
spike.
Thanks,
Anamitra
On 11/21/12 2:13 AM, "Daniel J Walsh" <dwalsh at redhat.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 11/20/2012 06:02 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>>
>> We are in the process of upgrading our product to RHEL6 os. And during
>> setting of SELinux contexts using semanage commands we see 100 % CPU
>>usage
>> as below
>>
>> top - 19:22:33 up 1:00, 1 user, load average: 1.25, 1.15, 1.58 Tasks:
>> 171 total, 2 running, 169 sleeping, 0 stopped, 0 zombie Cpu(s):
>> 24.7%us, 0.2%sy, 0.0%ni, 75.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>>Mem:
>> 6113004k total, 5841096k used, 271908k free, 22600k buffers Swap:
>> 2047992k total, 0k used, 2047992k free, 5078044k cached
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>
>>
>> 4189 root 20 0 575m 410m 3296 R 100.0 6.9 0:08.17 semanage
>>
>>
>> 21 root 20 0 0 0 0 S 0.3 0.0 0:00.48 events/2
>>
>>
>> 60 root 39 19 0 0 0 S 0.3 0.0 0:00.41 khugepaged
>>
>>
>> 3337 root 20 0 15088 1396 1020 R 0.3 0.0 0:01.29 top
>>
>>
>> 11471 root 39 19 0 0 0 S 0.3 0.0 0:14.53 kipmi0
>>
>>
>> 1 root 20 0 19396 1532 1208 S 0.0 0.0 0:01.10 init.real
>>
>>
>> 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
>>
>>
>> 3 root RT 0 0 0 0 S 0.0 0.0 0:00.03 migration/0
>>
>>
>> 4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
>>
>>
>> 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
>>
>>
>> 6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
>>
>>
>> 7 root RT 0 0 0 0 S 0.0 0.0 0:00.09 migration/1
>>
>>
>> 8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
>>
>>
>> 9 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftirqd/1
>>
>>
>> 10 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
>>
>>
>> 11 root RT 0 0 0 0 S 0.0 0.0 0:00.04 migration/2
>>
>>
>> 12 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/2
>>
>>
>> 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2
>>
>>
>> 14 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
>>
>>
>> 15 root RT 0 0 0 0 S 0.0 0.0 0:00.05 migration/3
>>
>>
>> 16 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
>>
>>
>> 17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3
>>
>>
>> 18 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/3
>>
>>
>> 19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 events/0
>>
>>
>> 20 root 20 0 0 0 0 S 0.0 0.0 0:00.03 events/1
>>
>>
>> 22 root 20 0 0 0 0 S 0.0 0.0 0:00.89 events/3
>>
>>
>> 23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuset
>>
>>
>> 24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper
>>
>>
>> 25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 netns
>>
>>
>> 26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 async/mgr
>>
>>
>> 27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pm
>>
>>
>> 28 root 20 0 0 0 0 S 0.0 0.0 0:00.02 sync_supers
>>
>>
>> 29 root 20 0 0 0 0 S 0.0 0.0 0:00.01 bdi-default
>>
>>
>> 30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0
>>
>>
>> 31 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/1
>>
>>
>> 32 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/2
>>
>>
>> 33 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/3
>>
>>
>> You have new mail in /var/spool/mail/root [root at vos-cm144 ~]# ps -efZ |
>> grep semanage system_u:system_r:initrc_t:s0 root 4189 4188 96
>>19:22
>> ? 00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P user -R
>> sysadm_r system_r specialuser_u
>>
>> Is this an expected behavior .
>>
>> Thanks, Anamitra
>>
>>
>>
>> -- selinux mailing list selinux at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>
>semanage is performing a recompile of policy which is causing the spike.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.12 (GNU/Linux)
>Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
>iEYEARECAAYFAlCsqUcACgkQrlYvE4MpobN6hQCgmMOIX7t4oLddImoUwhnByIWm
>SVUAn24d4y61FnMD++L9DGnHUy0cG6pl
>=FWuT
>-----END PGP SIGNATURE-----
More information about the selinux
mailing list