c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

AW: [ctsrvdev] ipcop uml und 2.6 host

Absender: Niedermeier Günter
Datum: Fr, 02.12.2005 23:06:25
In-reply-to: <000001c5f77a$07707b10$0801a8c0@Nia>


Hallo Peter und Jens,

ich habe "meine" UML Kernel's 2.4.27/29/31 mit den Beigaben
der SuSE-9.0 kompiliert.

Seit anfang September habe ich etwa 20 oder mehr 4,5GB große DVD Images
herunter geladen (Auf meiner "produktiv" Maschine mit einem 3072/512
DSL)
Auf diesem Cop läuft so nebenbei auch noch QoS_NG, Copfilter,
Trafficcontroll
AdvProxy und noch ein paar Kleinigkeiten die nebenbei diverse Grafiken
erzeugen.

Die UML läuft ABSOLUT stabil.

Allerdings läuft diese UML bei mir mit 256MB Ram und einer 384MB großen
Swap,
und die sind gut ausgelastet.

Gehostet ist das Ganze auf einem Athlon XP1800 und SuSE-9.3.

Die längste uptime waren bisher 37 Tage, und die habe ich nur
unterbrochen als
ich den neuen IPCop 1.4.10 auf UML umgebaut und auf der SuSE-9.3
installiert habe.

Geschäftlich benutze ich mittlerweilen auch den 1.4.10 allerdings auf
dem ct-server 1.10.

Bei diesem war die längste uptime 23 Tage, und da werden täglich auch
mehrere
hundert MB hin und her geschoben.

Hardware ist in diesem Fall ein P2/300 mit 256 MB. 128MB davon gehen an
die UML.

Meine Erfahrungswerte habe mir gezeigt, dass 16 oder 32 MB für den UML
Cop
selbst bei minimaler Konfig nicht ausreichend sind.

Peter, ich würde Dir empfehlen, den C3 ins Regal zurück zu stellen,
und durch einen richtigen Prozessor z.B. P2 o.ä. zu ersetzen.

Ein Bekannter hatte mich auch mal bekniet, ihm auf einem C3 den VDR mit
mplayer und div.
Erweiterungen zu installieren. Nach zwei oder drei Wochen sind wir dann
auf einen
P2/450 umgestiegen, weil der C3 NUR Ärger gemacht hat. Danach lief die
Kiste wie geschmiert.


_________________________________
@Jens:

Solltest Du den Cop 1.4.10 von mir noch im Einsatz haben, dann bitte
folgende Datei

/usr/lib/perl5/5.8.5/i386-linux/auto/POSIX/load_imports.a

auf

/usr/lib/perl5/5.8.5/i386-linux/auto/POSIX/load_imports.al

umbenennen. Das spart Dir 'ne Menge Fehlersuche ;-)
_________________________________



Gruß

Günter

> Hi Peter,
>
> Hast Du noch nicht einfach mal unsere Kernel ausprobiert?
> Das würde uns natürlich auch brennend interessieren, ob die bei Euch
> instabil sind, uns (mir) kam noch keine einzige Info diesbzgl. rein...
>
> Ich hab auf dem normalen, aber mit upgrade aktualisierten
> ctsrv kompiliert.
> Compiler war Standard - denke das war schon gcc 3.3.5 wie
> aktuell auch.
>
> Ich lasse aktuell mal den ipcop-1.4.9 in einer sarge-chroot
> (debootstrap
> sarge...)
> kompilieren, um dann mal ein bischen mit Deinen Hinweisen zu
> testen/patchen.
> 700MHz PIII mit 384MB ;-) auf meinem produktiven Server.
>
> IPCop lief bei mir bis jetzt stabil - reboot war nicht nötig
> (Hab aber nur
> 384kbit DSL :-(((, da ist wohl nix mit Stress-Download...
> Aber grosse files
> gehen...halt nur stabil mit 48kB...
>
> Wir haben also immer noch Unterschiede in allen Bereichen:
> - gcc ist unterschiedlich
> - ipcop version ist unterschiedlich
> - kompilier-umgebung ist unterschiedlich (zum. bei mir)
>
> Bitte teste doch mal unsere kernels...das Ergebnis ist schon
> interessant!
>
> Viele Grüsse
> Jens
>

> >
> > Hallo allerseits,
> >
> > ich komme leider nur kleckerweise vorwärts. Ich habe jetzt
> > mit den HInweisen aus http://www.ctserver.org/ftopic507.html
> > eine neuere Version unserers Build-Ansatzes für den Kernel
> > des IPCop zusammengebaut. Inbesondere auf den aktuelleren
> > UML-Patch umgestellt und den erwähnten Fix eingebaut.
> >
> > Zum Testen, ob das dafür sorgt, dass die IPCop-UML dann
> > stabil unter einem 2.6.12-ct-1-Kernel läuft, bin ich vorerst
> > bei der letzten IPCop- Fassung (1.4.6) geblieben. Die
> > IPCop-"Abstürze" unter Last, die mich zu der erneuten Warnung
> > vor 2.6 als Host veranlasst haben, waren damit perfekt zu
> > reproduzieren.
> >
> > Leider kann ich nach wie vor durch längere Downloads Aussetzer
> > provozieren: Zum bekannten Fehlerbild (IPCop-Instanz beendet
> > sich) gesellt sich als neue Form ein Stehenbleiben des
> > Downloads (der IPCop lebt weiter).
> >
> > Ich will noch einige Dinge ausprobieren, möchte aber auch auf
> > diesem Weg eine Suche nach möglichen Ursachen anstoßen - dazu
> > eine genauere Beschreibung des Testszenarios und der
> > beteiligten Systeme:
> >
> > - Server ist ein C3 mit 533 MHz, Kernel 2.6.12-ct-1
> >
> > - IPCop 1.4.6 mit Kernel 2.4.29
> >
> > - als Testclient dient Mac OS X 10.3, Download eines ISOs mit curl
> >
> > Der IPCop wird über das mit der Version 1.4.6 gelieferte
> > init-Skript gestartet, das heißt, er läuft in einer
> > chroot-Umgebung. Das Kernel- Binary ist dazu statisch gelinkt
> > (CONFIG_SKAS und CONFIG-TT gesetzt; nicht aber
> > CONFIG_STATIC_LINK - das ist kaputt, CONFIG_TT hat den
> > gleichen Effekt). Hier die vollständigen Optionen aus dem
> > .config, das in Build-Umgebung eingebaut ist:
> >
> > CONFIG_USERMODE=y
> > CONFIG_MODE_SKAS=y
> > CONFIG_MODE_TT=y
> > # CONFIG_UML_SMP is not set
> > # CONFIG_UML_WATCHDOG is not set
> > CONFIG_UML_SOUND=n
> > CONFIG_UML_NET=y
> > CONFIG_UML_NET_ETHERTAP=y
> > CONFIG_UML_NET_TUNTAP=y
> > CONFIG_UML_NET_SLIP=y
> > CONFIG_UML_NET_SLIRP=y
> > CONFIG_UML_NET_DAEMON=y
> > CONFIG_UML_NET_MCAST=y
> > # CONFIG_UML_NET_PCAP is not set
> > CONFIG_STATIC_LINK=n
> > CONFIG_HOSTFS=n
> > CONFIG_HUMFS=n
> > CONFIG_HPPFS=n
> > CONFIG_MCONSOLE=y
> > CONFIG_MAGIC_SYSRQ=n
> > CONFIG_HOST_2G_2G=n
> > CONFIG_UML_SMP=n
> > CONFIG_NEST_LEVEL=0
> > CONFIG_KERNEL_HALF_GIGS=1
> > CONFIG_PROC_MM=n
> > CONFIG_KERNEL_STACK_ORDER=2
> > CONFIG_UML_REAL_TIME_CLOCK=y
> > CONFIG_SSL=y
> > CONFIG_FD_CHAN=y
> > CONFIG_NULL_CHAN=y
> > CONFIG_PORT_CHAN=y
> > CONFIG_PTY_CHAN=y
> > CONFIG_TTY_CHAN=y
> > CONFIG_XTERM_CHAN=y
> > CONFIG_SSL_CHAN="pty"
> > CONFIG_CON_CHAN=xterm
> > CONFIG_CON_ZERO_CHAN=fd:0,fd:1
> > CONFIG_TTY_LOG=n
> > CONFIG_BLK_DEV_UBD=y
> > # CONFIG_BLK_DEV_UBD_SYNC is not set
> > CONFIG_COW=y
> > CONFIG_MMAPPER=n
> > CONFIG_PPP_MPPE=m
> > CONFIG_DEBUG_SLAB=n
> > CONFIG_DEBUGSYM=n
> > CONFIG_O1_OPTIM=n
> >
> > Mich würde interessieren:
> >
> > -  ob ich der einzige bin, der einen so lahmen Server
> > einsetzt ;-) (Der Fehler ließ sich auch mit schnelleren
> > Systemen reproduzieren; ich habe vorerst nur das o.g.
> > Test-Set gequält)
> >
> > - ob/wie die für die funktionierenden UML-IPCops gesetzten
> > Kernel- Optionen (.config) abweichen
> >
> > - welche Compiler beim Übersetzen des Kernels zum Einsatz
> > kommen (bei mir ist es der für den IPCop selbst verwendete
> > 3.3.3 in der chroot- Umgebung des IPCop)
> >
> > - was für maximale uptimes mit der Kombination 2.6.12-ct-1
> > und UML- IPCop erreicht worden sind?
> >
> > Danke+Gruß,
> > Peter