[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


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

[luga] ulimit, offene filedescriptors und Vererbungslehre (länger)



Liebe Leute,

  wie bereits zuvor in dieser Liste berichtet habe ich ein Problem mit
dem SLAPD und der Zahl an Filedescriptoren die er öffnet. Das werden im
Laufe eines Tages nämlich immer öfter mehr als 1024 pro Prozess, wozu
das Betriebssystem "njet" sagt, was wiederum den SLAPD daran hindert
zusätzliche Anfragen zu beantworten, was dann den Clients nicht so ganz
taugt ... :-P

  Die meisten offenen  Files sind TCP-Sockets und das so etwa 35 pro
Client (!).

  Herumkurbeln an den Konfigurationsdateien am Server oder Client (z.B.:
"idletimeout" in der slapd.conf auf irgedwas kurzes setzen) bringt nur
Instabilität der Client Applikationen (OpenOffice.org tut sich da
besonders hervor und verreckt einfach wenn man Dokumente ändern will).

  Die OpenLDAP Leute sagen sowieso der SLAPD ist super und skaliert
genial, also muss ich beim OS dafür sorgen, dass er genug FDs aufmachen
darf.

  Ich habe bereits versucht im init-Script vom SLAPD, unmittelbar bevor
der Daemon gestartet wird, folgendes einzubauen:

<code>
start_slapd() {
        echo -n " slapd"
# 8.9.06 GS ... ulimit gesetzt wegen zu vieler offener Files
        ulimit -n 2048
        if [ -z "$SLAPD_SERVICES" ]; then
                reason="`start-stop-daemon --start --quiet --oknodo \
                        --pidfile "$SLAPD_PIDFILE" \
                        --exec /usr/sbin/slapd -- $SLAPD_OPTIONS 2>&1`"
        else
                reason="`start-stop-daemon --start --quiet --oknodo \
                        --pidfile "$SLAPD_PIDFILE" \
                        --exec /usr/sbin/slapd -- -h "$SLAPD_SERVICES"
$SLAPD_OPTIONS 2>&1`"
        fi
}
</code>

  Daher sollte nach "/etc/init.d/slapd restart" das Limit für den SLAPD
und seine Kinderlein bei 2048 lliegen. Tut es aber scheinbar nicht, denn
die Zores bleiben.

  Um der Sache auf den Grund zu gehen habe ich zwei Testscripts gebaut:

1. fd-bomb.sh

<code>
#!/bin/bash
# FD-Bomb.sh
# v0.1 10.11.2006 GS
# setzt ulimit und ruft dann fd-bomb.pl auf

for LIMIT in 512 1024 2048 ; do
  echo "---------------------------------------------"
  echo "setze ulimit auf $LIMIT..."
  ulimit -n $LIMIT
  echo "das aktuelle Limit fuer filedeskriptoren ist: `ulimit -n`"
  echo "starte FD-Bomb ..."
  ./fd-bomb.pl
done
</code>

2. fd-bomb.pl

<code>
#!/usr/bin/perl -w
# FD-Bomb.pl
# v0.1 10.11.2006 GS
# oeffnet so viele Filehandles wie moeglich
# use strict;
my $nr=0;
my $fh;
my $workdir='/tmp';
print "\n";
while (1) {
  $fh="FH$nr";
  open($fh, "> $workdir/fd-bomb_$nr") or die "\n\nIt's over:
$!\n";
  print "opened file #$nr\r";
  ++$nr;
}
</code>

  Und wenn man das ausprobiert sieht auch alles gut aus:

<shell>
> root@sprocket:/mnt/local/fd-bomb# ./fd-bomb.sh
> ---------------------------------------------
> setze ulimit auf 512...
> das aktuelle Limit fuer filedeskriptoren ist: 512
> starte FD-Bomb ...
> 
> opened file #487
> 
> It's over: Too many open files
> ---------------------------------------------
> setze ulimit auf 1024...
> das aktuelle Limit fuer filedeskriptoren ist: 1024
> starte FD-Bomb ...
> 
> opened file #969
> 
> It's over: Too many open files
> ---------------------------------------------
> setze ulimit auf 2048...
> das aktuelle Limit fuer filedeskriptoren ist: 2048
> starte FD-Bomb ...
> 
> opened file #1881
> 
> It's over: Too many open files
</shell>

  Kann mir jetzt einer erklären warum das für den SLAPD nicht
funktioniert ?

  Und kann mir jemand sagen wie ich das für einen laufenden Prozess
gültige ulimit herausfinden kann ?

  Ach ja, das Ganze findet statt auf einem Debian Sarge, also mit:
Kernel: Linux zaphod 2.4.28-abi #2 SMP Sam Nov 12 14:31:26 CET 2005 i686
GNU/Linux (selbst kompiliert wegen SCO Binary Kompatibilität)
Ldap: slapd 2.2.23-8

  besten Dank im Voraus

  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