[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, offene filedescriptors und Vererbungslehre (länger))



On Mon, 2006-11-13 at 11:27 +0100, Peter J. Holzer wrote:
[...]
> Es könnte sein, dass der OpenLDAP select verwendet, das nur eine
> hartkodierte Menge an Filedescriptoren verwalten kann (per default
> 1024). In dem Fall hat er nicht wirklich ein Problem damit, sie zu

Aus der "1024 file descriptors should be enough for anybody" Abteilung:

Die Beschränkung ist *uralt* und kommt leider aus POSIX/SUS - da ist
select(2) deklariert als:
----  snip  ----
int select(int nfds, fd_set *restrict readfds,
       fd_set *restrict writefds, fd_set *restrict errorfds,
       struct timeval *restrict timeout);
----  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. ]
Dem Linux-Kernel ist die Beschränkung BTW herzlich egal - der Aufrufer
muß den größten zu beachtenden Filedescriptor sowieso mitgeben und der
Kernel muß sich drauf verlassen können - im schlimmsten Fall killt der
Kernel den (buggy) Prozeß mit SIGSEGV o.ä..

Etwas Zukunftsicheres hätte statt "fd_set" in der "select(2)"
Deklaration "unsigned int *" oder "unsigned char *" genommen und die
Verantwortung für ausreichend große Buffer auf den Programmierer
abgeschoben (so wie bei vielen anderen Funktionen in C und/oder Unix).

> öffnen, sondern sie danach sinnvoll zu verwenden (und möglicherweise hat
> sich der Programmierer gedacht, da ist es gescheiter, gleich beim Öffnen
> darauf zu achten, dass es nicht mehr werden können, als nachher
> seltsames Verhalten zu haben).
> 
> Ich würde mal mit strace schauen, was passiert, wenn eine Connection
> geöffnet wird. 

Ja, sowas mal mitzutracen und anzuschauen ist kein Fehler.

> Wenn der Verdacht mit dem select stimmt, dann könnte es helfen,
> OpenLDAP mit poll statt select zu rekompilieren, vorausgesetzt, der

poll(2) ist sowieso die bessere Alternative - zumal es im Linux-Kernel
drin sowieso nur "poll" gibt (und ohne eine Referenz liefern zu können -
und im glibc Source zu stochern - konvergiert select(2) zu einem
User-Space-Wrapper für poll(2)).

> OpenLDAP unterstützt das. (Aber wenn OpenLDAP "genial skaliert", dann
> sollte es, denn ein Single-Process-Server, der select verwendet,
> skaliert nicht genial.

Naja, so sehr ich ein Fan von non-blocking I/O und non-fork()ing Servern
bin, aber bei Multi-CPU-Maschinen könnte ein "single-threaded"
poll()-only Server nicht so toll sein.

> http://www.openldap.org/its/index.cgi/Incoming?id=2813;page=2 deutet
> auch in die Richtung.


	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




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