> Let me comment on that. We did not yet add indexes to the BDII
> because of contradictory evidence and worries about the overall
> effect: each index will speed up a particular query, but it also
> takes a possibly significant amount of CPU time to create the index,
> which may slow down the BDII operation! This is a concern for very
> busy top-level BDIIs like lcg-bdii.cern.ch.
>
> Last week we discussed doing some experiments to decide which
> indexes should be added. I suspect we will essentially implement
> Valentin's recommendations.
Top-level BDII is something where you need to experiment a little bit and find
out what is optimal to be indexed, according to the situation for your
particular BDII.
On BDII_site, however, the situation is simpler. I applied the procedure
outlined on this Wiki page:
http://wiki.egee-see.org/index.php/Fixing_BDII_response_time
And I found out that the following queries are the most frequent (log file
contain data for 4 days):
3692 filter="(GlueVOViewLocalID=seegrid)"
3698 filter="(GlueVOViewLocalID=dteam)"
3699 filter="(GlueVOViewLocalID=see)"
3700 filter="(GlueVOViewLocalID=ops)"
3701 filter="(GlueVOViewLocalID=esr)"
3721 filter="(GlueVOViewLocalID=cms)"
3722 filter="(GlueVOViewLocalID=atlas)"
3729 filter="(GlueVOViewLocalID=aegis)"
11730 filter="(objectClass=*)"
114650 filter="(|(objectClass=GlueSchemaVersion)(objectClass=GlueTop))"
So, objectClass and GlueVOViewLocalID are relevant attributes, while all other
are less significant (order of magnitude less frequent than
GlueVOViewLocalID), and you can safely index db on a BDII_site according to
those two attributes...
Best regards, Antun
|