[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RANT]: Uralt Standards (was Re: [luga] ulimit, offenefiledescriptors und Vererbungslehre (länger))



Ein Wort zuvor: gut gebrüllt Löwe !

Am 13.11.2006 schrieb "Bernd Petrovitsch" <bernd@firmix.at>:
[snip]
>Dieser (eigentlich sinnlose) "fd_set" Typ kann FD_SETSIZE
>Filedescriptoren verwalten (ist idR 1024). Um das größer zu machen, muß
>man nur die Konstante raufsetzen und "nur" die (GNU-)libc neu
>kompilieren (weil FD_SETSIZE auch in den Hilfsfunktionen/macros zur
>fd_set Verwaltung - FD_CLR(), etc. - verwendet wird). [ Oder halt die
>Macros nicht verwenden und erst alles selber machen. ]
[...]

On Mon, 2006-11-13 at 11:27 +0100, Peter J. Holzer wrote:
[...]
>> http://www.openldap.org/its/index.cgi/Incoming?id=2813;page=2 deutet
>> auch in die Richtung.

Oh ja ! Vor allem die Passage:

[quote]
This limit is not imposed by openldap. It's from glibc. OpenLDAP uses the
select() system call which, in a default glibc installation, can handle up
to 1024 descriptors. Increasing this limit can only be done by recompiling
glibc with a bigger FD_SETSIZE.
Another alternative would be to port OpenLDAP to use poll() instead of
select(). poll() doesn't have such a limit.
[/quote]

macht Mut. Ich stehe unglaublich drauf, auf einem Produktivsystem das
über 100 User mit Fileservice versorgt (falls ich das noch nicht erwähnt
haben sollte ;-) ) eine selber kompilierte glibc und einen gepatchten
slapd einzusetzen. Wozu hat man denn eine Distribution ?

Ich lade jetzt ein CentOS runter und schau was OpenLDAP dort
veranstaltet, nachdem ich die DB übertragen habe. Wenn die auch nach
1024 offenen FDs das Handtuch werfen habe ich wohl ein mittelschweres
Problem am Hals.

Sollte es tatsächlich so sein, dass nur kommerzielle Distros wirklich gut
skalieren ? Und wenn ja, warum fließen deren Patches nicht in die
Community zurück ? (das war eine rhetorische Frage, falls das jemandem
unklar geblieben ist)

Was ich allerdings wirklich nicht verstehe ist der Mechanismus der da
abläuft: Ein Client unter KDE mit Mailclient, Office und Browser hat
tatsächlich so um die 40 offenen TCP Verbindungen mit dem LDAP Server.
Und das ist nicht etwa ein Kenelprozess, der da anfragt, oder gar der
nscd (den zu aktivieren hat übrigens die Zahl der Verbindungen um eins
erhöht und um nix vermindert :-P) - nein, es sind Dinge wie soffice.bin,
kicker, firefox, wineserver ... zum größten Teil im Userkontext.

Offenbar habe ich da einen Denkfehler, aber meiner Meinung kümmert sich
das Betriebssystem um Berechtigungen und dergleichen. Die Applikation
fragt das OS Dinge wie "Zu welcher Gruppe gehört der User XY denn ?"
oder "bitte gib mir ein Filehandle für /home/ich/meins.odt" und ob die
Antwort von /etc/group, nis, ldap oder /dev/kristallkugel kommt
entscheidet PAM mittels nsswitch und basta.

Aber scheinbar ist dem nicht so. Offensichtlich will jedes Programm
persönlich beim Chef nachfragen.

Ich hab' noch so viel zu lernen ... ;-)

Goesta

--
#!/usr/bin/perl
foreach $c (split(/ /,"47 6f 65 73 74 61 20 53 6d 65 6b 61 6c 0d 0a")) {
print pack("C", hex($c));}



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010