Ron Trompert wrote:
> Hi Patricia and Stephen,
>
> When I do an ldapsearch on our own bdii mu3.matrix.sara.nl and
> lcgbdii02.gridpp.rl.ac.uk I get:
>
> [ron@mu7 ron]$ time ldapsearch -x -h mu3.matrix.sara.nl -b
> "mds-vo-name=local,o=grid" -p 2170 >/tmp/pipo
>
> real 0m1.195s
> user 0m0.720s
> sys 0m0.070s
> [ron@mu7 ron]$ lcgbdii02.gridpp.rl.ac.uk
> [ron@mu7 ron]$ time ldapsearch -x -h lcgbdii02.gridpp.rl.ac.uk -b
> "mds-vo-name=local,o=grid" -p 2170 >/tmp/pipo2
>
> real 0m0.979s
> user 0m0.680s
> sys 0m0.000s
>
> Which is rather similar and both bdii's contain almost the same amount
> of information. However, when I do the following lcg-infosites commands
> I get:
>
> [ron@mu7 ron]$ time /opt/lcg/bin/lcg-infosites --vo cms se --is
> mu3.matrix.sara.nl:2170 >/tmp/pipo
>
> real 1m37.624s
> user 0m1.850s
> sys 0m0.500s
>
> [ron@mu7 ron]$ time /opt/lcg/bin/lcg-infosites --vo cms se --is
> lcgbdii02.gridpp.rl.ac.uk:2170 >/tmp/pipo2
>
> real 0m10.473s
> user 0m1.860s
> sys 0m0.420s
>
> This is quite a difference. However, it appears that the difference is
> caused by diffences in response times of the bdii's:
>
> [ron@mu7 ron]$ time ldapsearch -LLL -x -h lcgbdii02.gridpp.rl.ac.uk:2170
> -p 2170 -b o=grid
> '(&(ObjectClass=GlueSLTop)(GlueForeignKey=GlueSEUniqueID=lxfs04.jinr.ru)
> )' GlueSLArchitectureType
> dn:
> GlueSLUniqueID=lxfs04.jinr.ru,Mds-Vo-name=rujinrlcg2,mds-vo-name=local,o
> =g
> rid
> GlueSLArchitectureType: disk
>
>
> real 0m0.099s
> user 0m0.020s
> sys 0m0.000s
> [ron@mu7 ron]$ time ldapsearch -LLL -x -h mu3.matrix.sara.nl:2170 -p
> 2170 -b o=grid
> '(&(ObjectClass=GlueSLTop)(GlueForeignKey=GlueSEUniqueID=lxfs04.jinr.ru)
> )' GlueSLArchitectureType
> dn:
> GlueSLUniqueID=lxfs04.jinr.ru,Mds-Vo-name=rujinrlcg2,mds-vo-name=local,o
> =g
> rid
> GlueSLArchitectureType: disk
>
>
> real 0m0.722s
> user 0m0.020s
> sys 0m0.000s
>
> The only question now is, why is mu3.matrix.sara.nl:2170 so slow? It's a
> 3 GHz dual XEON machine with 2 GB of memory running both the RB and the
> BDII. Any ideas?
Yes: your slapd cache is too small. See this bug:
http://savannah.cern.ch/bugs/?func=detailitem&item_id=6615
|