1:12 a.m.
Hi,
Any suggestions or maybe already available features in the pipeline for tuning the
database, and specifically the audit_log table?
The problem today is that with multiple applications accessing the engine through the
RestAPI, especially deployments with CloudForms, create huge amount of login records in
the audit_table. Which, in turns, consumes most of the available memory on the machine
running the engine and the database and results in a terrible performance of engine and
inaccessible Web UI.
The solution today is to delete those records from the table [1]:
=> delete from audit_log where message like '%logged%';
Are there any current tunings we can apply to the database?
And if not - do we have any RFEs on limiting the records entered to the database or a way
to delete/filter those records somehow from the WebUI?
All I could find was RFE#1120659 [2], but it does not describe the exact issue.
--
Thanks,
Marina.
[1] https://access.redhat.com/solutions/2110011
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
9:33 a.m.
Juan - we should try to reduce this number consumed by CFME, if possible.
CC-ing Eli for DB related tips.
On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin <mkalinin(a)redhat.com> wrote:
Hi,
Any suggestions or maybe already available features in the pipeline for
tuning the database, and specifically the audit_log table?
The problem today is that with multiple applications accessing the engine
through the RestAPI, especially deployments with CloudForms, create huge
amount of login records in the audit_table. Which, in turns, consumes most
of the available memory on the machine running the engine and the database
and results in a terrible performance of engine and inaccessible Web UI.
The solution today is to delete those records from the table [1]:
=> delete from audit_log where message like '%logged%';
Are there any current tunings we can apply to the database?
And if not - do we have any RFEs on limiting the records entered to the
database or a way to delete/filter those records somehow from the WebUI?
All I could find was RFE#1120659 [2], but it does not describe the exact
issue.
--
Thanks,
Marina.
[1] https://access.redhat.com/solutions/2110011
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
10:08 a.m.
On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali <oourfali(a)redhat.com> wrote:
Juan - we should try to reduce this number consumed by CFME, if
possible.
CC-ing Eli for DB related tips.
Reminds me of https://gerrit.ovirt.org/#/c/55743/ .
Y.
On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin <mkalinin(a)redhat.com>
wrote:
> Hi,
>
> Any suggestions or maybe already available features in the pipeline for
> tuning the database, and specifically the audit_log table?
>
> The problem today is that with multiple applications accessing the engine
> through the RestAPI, especially deployments with CloudForms, create huge
> amount of login records in the audit_table. Which, in turns, consumes most
> of the available memory on the machine running the engine and the database
> and results in a terrible performance of engine and inaccessible Web UI.
>
> The solution today is to delete those records from the table [1]:
> => delete from audit_log where message like '%logged%';
>
>
> Are there any current tunings we can apply to the database?
> And if not - do we have any RFEs on limiting the records entered to the
> database or a way to delete/filter those records somehow from the WebUI?
> All I could find was RFE#1120659 [2], but it does not describe the exact
> issue.
>
>
> --
> Thanks,
> Marina.
>
>
> [1] https://access.redhat.com/solutions/2110011
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:46 a.m.
------=_Part_65949358_553852405.1461386776000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi all,
So far I created this solution for immediate remedy:
https://access.redhat.com/solutions/721423
I created this general RFE, that would help in our situation:
https://bugzilla.redhat.com/show_bug.cgi?id=1329793
However, this RFE is not all what I have in my mind.
I am thinking if there is anyway we can limit the number of identical records in
audit_log?
Or, as Oved suggested, something to do with RestAPI and CFME to reduce the amount of
logging?
BTW, does current version of CFME already contains this feature:
http://old.ovirt.org/Features/RESTSessionManagement
?
Thank you,
Marina.
----- Original Message -----
On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali <
oourfali(a)redhat.com > wrote:
> Juan - we should try to reduce this number consumed by CFME, if
possible.
> CC-ing Eli for DB related tips.
Reminds me of https://gerrit.ovirt.org/#/c/55743/ .
This commit is great, however not relevant for my case, since event_notification_hist is
empty.
Y.
> On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin <
mkalinin(a)redhat.com >
> wrote:
> > Hi,
>
> > Any suggestions or maybe already available features in the
pipeline for
> > tuning the database, and specifically the audit_log table?
>
> > The problem today is that with multiple applications
accessing the engine
> > through the RestAPI, especially deployments with CloudForms, create huge
> > amount of login records in the audit_table. Which, in turns, consumes
> > most
> > of the available memory on the machine running the engine and the
> > database
> > and results in a terrible performance of engine and inaccessible Web UI.
>
> > The solution today is to delete those records from the
table [1]:
>
> > => delete from audit_log where message like '%logged%';
>
> > Are there any current tunings we can apply to the
database?
>
> > And if not - do we have any RFEs on limiting the records entered to the
> > database or a way to delete/filter those records somehow from the WebUI?
>
> > All I could find was RFE#1120659 [2], but it does not describe the exact
> > issue.
>
> > --
>
> > Thanks,
>
> > Marina.
>
> > [1] https://access.redhat.com/solutions/2110011
>
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
>
> > _______________________________________________
>
> > Users mailing list
>
> > Users(a)ovirt.org
>
> > http://lists.ovirt.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
--
--
mku
------=_Part_65949358_553852405.1461386776000
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: Verdana; font-size: 12pt;
color: #00=
0066"><div>Hi
all,<br></div><div><br></div><div>So far I created
this solut=
ion for immediate remedy:</div><div><a
href=3D"https://access.redhat.com/so=
lutions/721423">https://access.redhat.com/solutions/721423</a>
<br></div><d=
iv><br></div><div>I created this general RFE, that would help in our
situat=
ion:<br></div><div><a
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=
=3D1329793">https://bugzilla.redhat.com/show_bug.cgi?id=3D1329793</a></div>=
<div><br></div><div>However, this RFE is not all what I have in my
mind.<br=
</div><div>I am thinking if there is anyway we can limit
the number of ide=
ntical records in audit_log?<br></div><div>Or,
as Oved suggested, something=
to do with RestAPI and CFME to reduce the amount of
logging?<br></div><div=
BTW, does current version of CFME already contains this
feature:<br></div>=
<div><a
href=3D"http://old.ovirt.org/Features/RESTSessionManagement">...
/old.ovirt.org/Features/RESTSessionManagement</a></div><div>?<br></div><div=
<br></div><div>Thank
you,<br></div><div>Marina.<br></div><div><br></div><h=
r id=3D"zwchr"><blockquote style=3D"border-left:2px solid
#1010FF;margin-le=
ft:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;tex=
t-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" d=
ata-mce-style=3D"border-left: 2px solid #1010FF; margin-left: 5px; padding-=
left: 5px; color: #000; font-weight: normal; font-style: normal; text-decor=
ation: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><di=
v dir=3D"ltr"><br><div
class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali <span
dir=3D"ltr"><<a hre=
f=3D"mailto:oourfali@redhat.com" target=3D"_blank"
data-mce-href=3D"mailto:=
oourfali@redhat.com">oourfali(a)redhat.com</a>&gt;</span>
wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex" data-mce-style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px=
; border-left-style: solid; border-left-color: #cccccc; padding-left: 1ex;"=
<div dir=3D"ltr">Juan - we should try to reduce this
number consumed by CF=
ME, if possible.<div>CC-ing Eli for DB related
tips.</div></div></blockquot=
e><div><br></div><div>Reminds me of <a
href=3D"https://gerrit.ovirt.org/#/c=
/55743/" target=3D"_blank"
data-mce-href=3D"https://gerrit.ovirt.org/#/c/55=
743/">https://gerrit.ovirt.org/#/c/55743/</a>
.</div></div></div></div></bl=
ockquote><div>This commit is great, however not relevant for my case, since=
event_notification_hist is empty.<br></div><blockquote
style=3D"border-lef=
t:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight=
:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,=
sans-serif;font-size:12pt;" data-mce-style=3D"border-left: 2px solid #1010F=
F; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; f=
ont-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans=
-serif; font-size: 12pt;"><div dir=3D"ltr"><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>Y.</div><blockquote
class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex" data-mce-style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; bo=
rder-left-color: #cccccc; padding-left: 1ex;"><div
class=3D""><div class=3D=
"h5"><div class=3D"gmail_extra"><br><div
class=3D"gmail_quote">On Fri, Apr =
15, 2016 at 1:12 AM, Marina Kalinin <span dir=3D"ltr"><<a
href=3D"mailto=
:mkalinin@redhat.com" target=3D"_blank"
data-mce-href=3D"mailto:mkalinin@re=
dhat.com">mkalinin(a)redhat.com</a>&gt;</span>
wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" dat=
a-mce-style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-le=
ft-style: solid; border-left-color: #cccccc; padding-left:
1ex;">Hi,<br><di=
v><br></div> Any suggestions or maybe already available features in the
pip=
eline for tuning the database, and specifically the audit_log table?<br><di=
v><br></div> The problem today is that with multiple applications
accessing=
the engine through the RestAPI, especially deployments with CloudForms, cr=
eate huge amount of login records in the audit_table. Which, in turns, cons=
umes most of the available memory on the machine running the engine and the=
database and results in a terrible performance of engine and inaccessible =
Web UI.<br><div><br></div> The solution today is to delete those
records fr=
om the table [1]:<br> =3D> delete from audit_log where message like
'%lo=
gged%';<br><div><br></div><br> Are there any current
tunings we can apply t=
o the database?<br> And if not - do we have any RFEs on limiting the record=
s entered to the database or a way to delete/filter those records somehow f=
rom the WebUI?<br> All I could find was RFE#1120659 [2], but it does not de=
scribe the exact issue.<br><span><span style=3D"color: #888888;"
data-mce-s=
tyle=3D"color: #888888;" color=3D"#888888"><br> <br>
--<br> Thanks,<br> Mar=
ina.<br> <br> <br> [1] <a
href=3D"https://access.redhat.com/solutions/21100=
11" rel=3D"noreferrer" target=3D"_blank"
data-mce-href=3D"https://access.re=
dhat.com/solutions/2110011">https://access.redhat.com/solutions/2...
<br> [2] <a
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1120659" =
rel=3D"noreferrer" target=3D"_blank"
data-mce-href=3D"https://bugzilla.redh=
at.com/show_bug.cgi?id=3D1120659">https://bugzilla.redhat.com/sho...
id=3D1120659</a><br> _______________________________________________<br>
Us=
ers mailing list<br> <a href=3D"mailto:Users@ovirt.org"
target=3D"_blank" d=
ata-mce-href=3D"mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href=3D"=
http://lists.ovirt.org/mailman/listinfo/users" rel=3D"noreferrer"
target=3D=
"_blank"
data-mce-href=3D"http://lists.ovirt.org/mailman/listinfo/users"...
tp://lists.ovirt.org/mailman/listinfo/users</a><br> <br> <br>
</span></span=
</blockquote></div><br></div></div></div><br>_____________________________=
__________________<br> Users mailing list<br><a
href=3D"mailto:Users@ovirt.=
org" target=3D"_blank"
data-mce-href=3D"mailto:Users@ovirt.org">Users@ovirt=
.org</a><br><a
href=3D"http://lists.ovirt.org/mailman/listinfo/users" rel=
=3D"noreferrer" target=3D"_blank"
data-mce-href=3D"http://lists.ovirt.org/m=
ailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/us...
<div><br></div></blockquote></div><br></div></div></blockquote><div><br><d=
iv><br></div></div><div><br></div><div>--
<br></div><div><span name=3D"x"><=
/span>--<br> mku<span
name=3D"x"></span><br></div></div></body></html>
------=_Part_65949358_553852405.1461386776000--
8:17 a.m.
On Apr 23, 2016 7:46 AM, "Marina Kalinin" <mkalinin(a)redhat.com> wrote:
Hi all,
So far I created this solution for immediate remedy:
https://access.redhat.com/solutions/721423
I created this general RFE, that would help in our situation:
https://bugzilla.redhat.com/show_bug.cgi?id=1329793
However, this RFE is not all what I have in my mind.
I also don't think we should have such tool as mentioned in the RFE.
I am thinking if there is anyway we can limit the number of identical
records in audit_log?
Identical records might imply some issue, so I don't think they should be
limited. What we can add configuration for is maybe the frequency in which
the data is purged, which is 30 days currently, afair.
Or, as Oved suggested, something to do with RestAPI and CFME to
reduce
the amount of logging?
BTW, does current version of CFME already contains this feature:
http://old.ovirt.org/Features/RESTSessionManagement
?
CFME uses the session. However, I think that we don't reuse the session
among unrelated requests.
Not 100% sure about that.
Juan?
Thank you,
Marina.
________________________________
>
>
>
> On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali <oourfali(a)redhat.com>
wrote:
>>
>> Juan - we should try to reduce this number consumed by CFME, if
possible.
>> CC-ing Eli for DB related tips.
>
>
> Reminds me of https://gerrit.ovirt.org/#/c/55743/ .
This commit is great, however not relevant for my case, since
event_notification_hist is empty.
>
> Y.
>>
>>
>> On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin <mkalinin(a)redhat.com>
wrote:
>>>
>>> Hi,
>>>
>>> Any suggestions or maybe already available features in the pipeline
for
tuning the database, and specifically the audit_log table?
>>>
>>> The problem today is that with multiple applications accessing the
engine through the RestAPI, especially deployments with CloudForms, create
huge amount of login records in the audit_table. Which, in turns, consumes
most of the available memory on the machine running the engine and the
database and results in a terrible performance of engine and inaccessible
Web UI.
>>>
>>> The solution today is to delete those records from the table [1]:
>>> => delete from audit_log where message like '%logged%';
>>>
>>>
>>> Are there any current tunings we can apply to the database?
>>> And if not - do we have any RFEs on limiting the records entered to
the
database or a way to delete/filter those records somehow from the WebUI?
>>> All I could find was RFE#1120659 [2], but it does not
describe the
exact issue.
>>>
>>>
>>> --
>>> Thanks,
>>> Marina.
>>>
>>>
>>> [1] https://access.redhat.com/solutions/2110011
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
--
--
mku
1:54 p.m.
On 04/23/2016 07:17 AM, Oved Ourfali wrote:
On Apr 23, 2016 7:46 AM, "Marina Kalinin" <mkalinin(a)redhat.com
<mailto:mkalinin@redhat.com>> wrote:
>
> Hi all,
>
> So far I created this solution for immediate remedy:
> https://access.redhat.com/solutions/721423
>
> I created this general RFE, that would help in our situation:
> https://bugzilla.redhat.com/show_bug.cgi?id=1329793
>
> However, this RFE is not all what I have in my mind.
I also don't think we should have such tool as mentioned in the RFE.
> I am thinking if there is anyway we can limit the number of identical
records in audit_log?
Identical records might imply some issue, so I don't think they should
be limited. What we can add configuration for is maybe the frequency in
which the data is purged, which is 30 days currently, afair.
> Or, as Oved suggested, something to do with RestAPI and CFME to reduce
the amount of logging?
> BTW, does current version of CFME already contains this feature:
> http://old.ovirt.org/Features/RESTSessionManagement
> ?
CFME uses the session. However, I think that we don't reuse the session
among unrelated requests.
Not 100% sure about that.
Juan?
CFME does use the persistent authentication mechanism. It creates new
sessions (which triggers the audit log message) in the following situations:
1. When CFME starts it creates a new session to poll RHEV-M events. This
session is reused as long as CFME is running.
2. When a refresh of the inventory is performed. Each refresh creates a
new session.
3. When performing actions like start or shutdown a VM. Each of these
actions creates a new session.
So unless there is a high level of activity in the environment (starting
virtual machines, stopping them, etc) there shouldn't be a high amount
of activity in the logs.
In systems where high activity is detected I'd suggest to configure the
RHEVM-M web server log file so that we will have a clear idea of what is
creating sessions. This can be achieved adding the following line to the
/etc/httpd/conf.d/ssl.conf file:
CustomLog logs/api_log "%h %t \"%r\"
User-Agent=\"%{User-Agent}i\"
JSESSIONID=\"%{JSESSIONID}C\" Prefer=\"%{Prefer}i\" %>s"
Then restart the web server:
# service httpd restart
The content of that "api_log" file would help us what is really sending
requests that trigger the login/logout audit messages.
Note that the additional log file consumes resources, both CPU and disk
space, so it should be disabled once the relevant information is captured.
>
> Thank you,
> Marina.
>
> ________________________________
>>
>>
>>
>> On Sun, Apr 17, 2016 at 9:33 AM, Oved Ourfali <oourfali(a)redhat.com
<mailto:oourfali@redhat.com>> wrote:
>>>
>>> Juan - we should try to reduce this number consumed by CFME, if
possible.
>>> CC-ing Eli for DB related tips.
>>
>>
>> Reminds me of https://gerrit.ovirt.org/#/c/55743/ .
>
> This commit is great, however not relevant for my case, since
event_notification_hist is empty.
>>
>> Y.
>>>
>>>
>>> On Fri, Apr 15, 2016 at 1:12 AM, Marina Kalinin <mkalinin(a)redhat.com
<mailto:mkalinin@redhat.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Any suggestions or maybe already available features in the pipeline
for tuning the database, and specifically the audit_log table?
>>>>
>>>> The problem today is that with multiple applications accessing the
engine through the RestAPI, especially deployments with CloudForms,
create huge amount of login records in the audit_table. Which, in turns,
consumes most of the available memory on the machine running the engine
and the database and results in a terrible performance of engine and
inaccessible Web UI.
>>>>
>>>> The solution today is to delete those records from the table [1]:
>>>> => delete from audit_log where message like '%logged%';
>>>>
>>>>
>>>> Are there any current tunings we can apply to the database?
>>>> And if not - do we have any RFEs on limiting the records entered to
the database or a way to delete/filter those records somehow from the WebUI?
>>>> All I could find was RFE#1120659 [2], but it does not describe the
exact issue.
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Marina.
>>>>
>>>>
>>>> [1] https://access.redhat.com/solutions/2110011
>>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1120659
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)ovirt.org <mailto:Users@ovirt.org>
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org <mailto:Users@ovirt.org>
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
>
>
> --
> --
> mku
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
5:07 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HxUlBB9m1VEcJj0dO9sBDwd2v86tIQdk5
Content-Type: multipart/mixed; boundary="HjK7R6pAQfhTK2JA4pVCDr6ifqD6oPb94"
From: Sven Kieske <svenkieske(a)gmail.com>
To: users(a)ovirt.org
Message-ID: <571F7625.9010906(a)gmail.com>
Subject: Re: [ovirt-users] audit_log table performance tuning
References: <640699674.62984134.1460671956028.JavaMail.zimbra(a)redhat.com>
In-Reply-To: <640699674.62984134.1460671956028.JavaMail.zimbra(a)redhat.com>
--HjK7R6pAQfhTK2JA4pVCDr6ifqD6oPb94
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 15.04.2016 00:12, Marina Kalinin wrote:
Hi,
=20
Any suggestions or maybe already available features in the pipeline for=
tuning
the database, and specifically the audit_log table?=20
=20
The problem today is that with multiple applications accessing the engi=
ne through
the RestAPI, especially deployments with CloudForms, create hu=
ge amount of login records in the audit_table. Which, in turns, consumes =
most of the available memory on the machine running the engine and the da=
tabase and results in a terrible performance of engine and inaccessible W=
eb UI.
=20
The solution today is to delete those records from the table [1]:
=3D> delete from audit_log where message like '%logged%';
=20
=20
Are there any current tunings we can apply to the database?=20
And if not - do we have any RFEs on limiting the records entered to the=
database
or a way to delete/filter those records somehow from the WebUI?=
All I could find was RFE#1120659 [2], but it does not describe the
exac=
t issue.
=20
=20
Hi,
I remember filing a BZ about this topic some years ago.
I will mail it tomorrow to this thread as I had this exact issue, as a
user of the rest api (without any persistent authentication).
the answer, as I recall (I haven't access to this BZ atm), was to simply
truncate the event log, which is far from a "solution" at all.
kind regards
Sven
--HjK7R6pAQfhTK2JA4pVCDr6ifqD6oPb94--
--HxUlBB9m1VEcJj0dO9sBDwd2v86tIQdk5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJXH3YlAAoJEAq0kGAWDrqlCDkL/1aXdxwchuwNzcdILTZrVxII
w5LjTf++y307UmjM+31u+kZ1jdSiSDr5Xi/9FtKxDixJoQEDkUMTUXv8vPd+CxgW
3xtahcAaQPTOPu3U1yoDTVmyBDx5bi9T6QhMYqVhfiXQfyxJbMEC5iUZAlR4kNF4
Rcg99jaQlfPiQS+L7hUdSjL3gGzNQ9GLRTDiVDVBMFgtyWB3RQp1wU9rfe1OHXtw
zwM23A8qVAQegmiGYBp2uz5D0AxwFdnUjz/IVs6rOP8rHpRSN3hUaDVCIEyOtkHW
19bvDQQoIPBhhrmlVojxTvFuV+UrRXb0jZ7xDD445niCg2MSJv7shtj8wB12Hg1i
LnkRYti8XRnV/V4SZMiBjYMpnexdM6BD6wdwaeeWwu1iQVlekWD4eHiZGAViPD+k
O+/O1JxrvP9Mho3vuuXmmWbGl6eHh8x9WQGXOFLtZsy8XY+bhT2lfMJXjDKd51te
AlmhHIkwE3Dfkp70SKTXJu6Mtgsh6TVCGF6q6GoVfw==
=sSZH
-----END PGP SIGNATURE-----
--HxUlBB9m1VEcJj0dO9sBDwd2v86tIQdk5--
12:41 a.m.
----- Original Message -----
On 15.04.2016 00:12, Marina Kalinin wrote:
> Hi,
>
> Any suggestions or maybe already available features in the pipeline for
> tuning the database, and specifically the audit_log table?
>
> The problem today is that with multiple applications accessing the engine
> through the RestAPI, especially deployments with CloudForms, create huge
> amount of login records in the audit_table. Which, in turns, consumes most
> of the available memory on the machine running the engine and the database
> and results in a terrible performance of engine and inaccessible Web UI.
>
> The solution today is to delete those records from the table [1]:
> => delete from audit_log where message like '%logged%';
>
>
> Are there any current tunings we can apply to the database?
> And if not - do we have any RFEs on limiting the records entered to the
> database or a way to delete/filter those records somehow from the WebUI?
> All I could find was RFE#1120659 [2], but it does not describe the exact
> issue.
>
>
Hi,
I remember filing a BZ about this topic some years ago.
I will mail it tomorrow to this thread as I had this exact issue, as a
user of the rest api (without any persistent authentication).
Sven, Did you find
anything?
I still cannot put my head around the right solution for this case. So I would appreciate
to see your bug.
the answer, as I recall (I haven't access to this BZ atm), was to simply
truncate the event log, which is far from a "solution" at all.
kind regards
Sven
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
--
mku
3130
days inactive
3144
days old
7 comments
5 participants
participants (5)
-
Juan Hernández -
Marina Kalinin -
Oved Ourfali -
Sven Kieske -
Yaniv Kaul