nscd ...

[claus]

Hallo allerseits,

gibt es eine Möglichkeit, dem nscd zu sagen, dass er einen bestimmten Cache zu einer bestimmten Zeit leeren und gleich wieder neu befüllen soll? Es geht um unseren Gruppen Cache ... (500 Gruppen), den wir genau einmal am Tag aktualisieren wollen und sonst sollen diese vielen, vielen Anfragen nicht an den Server geschickt werden, weil das die Performance unserer Anwendung stark in Mitleidenschaft zieht (Was ich mir zwar nicht vorstellen kann, was aber nachweisbar so ist, habe ich gerade noch einmal ausprobiert).

Ich habe bisher folgendes probiert:

Code: [Auswählen]

nscd -i group
invalidiert den Cache, befüllt ihn aber nicht direkt wieder, denn ich hatte erwartet, einen Haufen Anfragen an den LDAP Server zu sehen.

Auch eine wiederholte ldapsearch auf alle Gruppen hat nichts bewirkt, es befinden sich weder alle Gruppen im Cache, noch ist die Zahl an Cache-Treffer sehr hoch.

Auch ein find . -type f oben in der Hierachie bewirkt nichts.

Mit unserem Provider habe ich deswegen auch schon geredet, die waren auch der Auffassung, dass das etwas bringen sollte.

Was kann man da tun? Wie kann ich Solaris dazu bewegen, alle Gruppen abzufragen und auch im nscd cache abzulegen?


Etwas ratlos,

Claus

[aunda]

Auch ein find . -type f oben in der Hierachie bewirkt nichts.

Arrrg.

Ich dachte ja ein

Code: [Auswählen]

getent group würde helfen. Hab ich aber ausprobiert und war nix.

Geholfen hat aber ein

Code: [Auswählen]

-bash-3.00$ for i in `getent group  | awk -F':' '{print $1}'`; do getent group $i; done
Vorher:

Code: [Auswählen]

-bash-3.00$ nscd -g
...
group cache:
...
        11  total entries
...
Nachher:

Code: [Auswählen]

-bash-3.00$ nscd -g
...
group cache:
...
       334  total entries
...

Code: [Auswählen]

-bash-3.00$ getent group | awk -F':' '{print $1}' | sort | uniq | wc -l
     329

MfG Andreas

[claus]

Ok, das funktioniert ja bestens, danke schön - aber ich verstehe nicht, warum? Kannst Du mir das bitte erklären?

Claus

[Drusus]

Moin,

also ganz verstehe ich dein Problem hier nicht. Wenn ich deine urspruengliche Problembeschreibung lese, dann sollen offenbar einfach nur die Gruppeneintraege moeglichst lange (einen Tag) im nscd gecached werden.

Alles was du dafuer brauchst in die Aenderung der /etc/nscd.conf Datei um dort "positive-time-to-live group" auf 86400 zu setzen. Schon werde die Eintraege einen Tag lang lokal im nscd vorgehalten und erst danach einmal erneut angefragt. Optional kannst du noch den "keep-hot-count" fuer die Gruppe auf einen hoeheren Wert setzen (in dem Fall wird nach dem Ablauf der positive-time-to-live Zeit der Eintrag nicht aus dem Cache entfernt sondern lediglich geprueft ob der noch gueltig ist).

Die Sache mit Cache entleeren und wieder fuellen ist erstens Unsinn und zweitens weiss ich nun nicht ob/welche Frage du dazu konkret hast. Mit dem "Cache fuellen" erzeugst du ja gerade wieder die Last, die du eigentlich vermeiden moechtest. Wird eine Gruppe tatsaechlich benoetigt, so wird sie halt beim ersten Aufruf geholt - und dabei ist es ja egal wann dieses "erste Mal" ist.

Im Falle von "ldapsearch" wird der nscd komplett umgangen. Im Falle von enumerations (d.h. Abfrage der ganzen Tabelle - z.B. per "getent group") cached der nscd bewusst nicht (um nicht den Cache mit unsinnigen Daten zu belasten).

Tschau,
  Drusus.

[aunda]

Ok, das funktioniert ja bestens, danke schön - aber ich verstehe nicht, warum? Kannst Du mir das bitte erklären?

Das mit dem getent oder das mit dem find?

find . -type f zeigt keine Gruppen an.
find . -type f -ls schon (hier würde Dein nscd-Cache sich auch aufbauen).

getent group benötigt jeweils den folgenden Eintrag. Logisch wäre es, dazu direkt den LDAP-Server zu befragen.
getent group name kann erst mal beim nscd gucken.

Nur mal so daher geredet, ohne in den Quelltext zu gucken, den ich sowieso nicht verstehen würde :-)

Grüße aus Rockenberg,

Andreas

[claus]

Moin,

also ganz verstehe ich dein Problem hier nicht. Wenn ich deine urspruengliche Problembeschreibung lese, dann sollen offenbar einfach nur die Gruppeneintraege moeglichst lange (einen Tag) im nscd gecached werden.

Genau, allerdings soll das flushen des Caches genau zu einer festgelegten Uhrzeit stattfinden, egal wie alt der Cache wirklich ist. Weiterhin soll der Cache dann wieder befüllt werden, am Besten, bevor ein User vorbeikommt und dann drei Minuten verliert.

Alles was du dafuer brauchst in die Aenderung der /etc/nscd.conf Datei um dort "positive-time-to-live group" auf 86400 zu setzen. Schon werde die Eintraege einen Tag lang lokal im nscd vorgehalten und erst danach einmal erneut angefragt. Optional kannst du noch den "keep-hot-count" fuer die Gruppe auf einen hoeheren Wert setzen (in dem Fall wird nach dem Ablauf der positive-time-to-live Zeit der Eintrag nicht aus dem Cache entfernt sondern lediglich geprueft ob der noch gueltig ist).

Ok, dann setze ich den hot-count noch hoch.

Die Sache mit Cache entleeren und wieder fuellen ist erstens Unsinn und zweitens weiss ich nun nicht ob/welche Frage du dazu konkret hast. Mit dem "Cache fuellen" erzeugst du ja gerade wieder die Last, die du eigentlich vermeiden moechtest. Wird eine Gruppe tatsaechlich benoetigt, so wird sie halt beim ersten Aufruf geholt - und dabei ist es ja egal wann dieses "erste Mal" ist.

Ja das ist richtig, das klingt unsinnig, allerdings möchten wir die Last ja kontrolliert erzeugen, zu einer Uhrzeit, bei der weder Amerikaner noch Deutsche noch Japaner betroffen werden, also drei Uhr morgens.

Im Falle von "ldapsearch" wird der nscd komplett umgangen. Im Falle von enumerations (d.h. Abfrage der ganzen Tabelle - z.B. per "getent group") cached der nscd bewusst nicht (um nicht den Cache mit unsinnigen Daten zu belasten).

Ok, genau diese Information hat mir gefehlt, ich hatte eigentlich erwartet, dass auch ein ldapsearch über nscd läuft, da heisst dabei haben wir noch Optimierungspotentiel beim unserem Code.

Vielen Dank Drusus

Claus