9:59 p.m.
Dear Audit team.
My name is Nguyen Minh Tien. I came from Singapore. I am working as a
developer for Garena LTD. Last week, I met a problem with Audit on our
product servers. The Auditd process had caused of some pick time on our
server. In that times, system CPU cost a lot, around 100%. And the Load
average is over 30. We have tried to find the root cause and have failed.
Could you help us for that case?
The servers, which meet the performance issue, use Redhat 6.8 and their
kernel is 2.6.32.
--
Best regards
_________________________
Nguyen Minh Tien - SA Team
email: nguyenmt(a)garena.com
7:57 a.m.
Hello,
On Thursday, December 1, 2016 11:59:47 AM EST Minh Tien Nguyen wrote:
My name is Nguyen Minh Tien. I came from Singapore. I am working as
a
developer for Garena LTD. Last week, I met a problem with Audit on our
product servers. The Auditd process had caused of some pick time on our
server. In that times, system CPU cost a lot, around 100%. And the Load
average is over 30. We have tried to find the root cause and have failed.
Could you help us for that case?
The servers, which meet the performance issue, use Redhat 6.8 and their
kernel is 2.6.32.
You might want to check the flush setting for /etc/audit/auditd.conf. I would
recommend using incremental and set the freq to something like 200 or 500.
Using sync or data will kill performance, but the event is written to disk
before processing the next event.
-Steve
8:07 a.m.
He Steve Grubb.
Nice to heard from you. Thank you so much for your help. We will try to set
that config and see the result.
Thanks & best regards.
On Thu, Dec 1, 2016 at 9:57 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
On Thursday, December 1, 2016 11:59:47 AM EST Minh Tien Nguyen wrote:
> My name is Nguyen Minh Tien. I came from Singapore. I am working as a
> developer for Garena LTD. Last week, I met a problem with Audit on our
> product servers. The Auditd process had caused of some pick time on our
> server. In that times, system CPU cost a lot, around 100%. And the Load
> average is over 30. We have tried to find the root cause and have failed.
> Could you help us for that case?
>
> The servers, which meet the performance issue, use Redhat 6.8 and their
> kernel is 2.6.32.
You might want to check the flush setting for /etc/audit/auditd.conf. I
would
recommend using incremental and set the freq to something like 200 or 500.
Using sync or data will kill performance, but the event is written to disk
before processing the next event.
-Steve
--
Best regards
_________________________
Nguyen Minh Tien - SA Team
email: nguyenmt(a)garena.com
8:50 a.m.
We ran into exactly the same issue with the update to 6.8. Using flush and
setting freq to 300 fixed the issue we were experiencing.
Ed
On Thu, Dec 1, 2016 at 9:00 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
On Thursday, December 1, 2016 11:59:47 AM EST Minh Tien Nguyen wrote:
> My name is Nguyen Minh Tien. I came from Singapore. I am working as a
> developer for Garena LTD. Last week, I met a problem with Audit on our
> product servers. The Auditd process had caused of some pick time on our
> server. In that times, system CPU cost a lot, around 100%. And the Load
> average is over 30. We have tried to find the root cause and have failed.
> Could you help us for that case?
>
> The servers, which meet the performance issue, use Redhat 6.8 and their
> kernel is 2.6.32.
You might want to check the flush setting for /etc/audit/auditd.conf. I
would
recommend using incremental and set the freq to something like 200 or 500.
Using sync or data will kill performance, but the event is written to disk
before processing the next event.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
2942
days inactive
2942
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Edward Bailey -
Minh Tien Nguyen -
Steve Grubb