Subject: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sat, 02 Mar 2019 12:10:51 GMT View Forum Message <> Reply to Message Hallo an alle, nachdem ich nun einige Wochen probiert und getestet habe, bin ich der Problemlösung zwar noch keinen Schritt näher gekommen, habe aber zumindest eine Richtung in der gesucht werden muss.
Mit Hilfe einer Proxmox-Gruppe hat sich gezeigt, dass in der Tat Eisfair selbst - das ist kein Vorwurf - der Schuldige an diesem Verhalten ist. Und, wie ich finden konnte, kenne bereits andere dieses Verhalten von Eisfair als Proxmox-VM. https://web.nettworks.org/forum/index.php?t=msg&goto=42056
In die Richtung, doch Eisfair als "Schuldigen" in Betracht zu ziehen hat mich ein User in einer Proxmox-Gruppe damit gebracht, dass er bei Tests mit Eisfair auf Proxmox merkte, dass auch bei Ihm Eisfair ungewöhnlich Träge im Vergleich zu anderen Distributionen ist und dies bereits bei der Grafikausgabe beginnt. Da ich Proxmox-Neuling bin hatte ich natürlich noch keinen Vergleich, aber hier sind meine nachvollzogenen (einleuchtenden) Werte mit einen einfachen "time lsmod" in der Proxmox Konsole (noVNC), real 0m3.583s user 0m0.020s sys 0m3.552s und mit Putty (ssh) real 0m0.019s user 0m0.004s sys 0m0.012s
Das selbe "time lsmod" in der Proxmox Konsole (noVNC) auf einem "frischem" Kubuntu bringt, real 0m0,012s user 0m0,000s sys 0m0,013s mit ssh habe ich keinen Test mehr gemacht.
Soweit ist zumindest die Grafikausgabe sehr verlangsamt, und die im Forum angesprochene unerklärliche Grundlast kann auch ich bestätigen. Die sehr langsame Ausgabe merkt man bereits beim Booten der VM wenn die Pinguine für die Anzahl der Prozessoren eingeblendet werden welche ja eigentlich "zack" da sind in der VM aber deutlich einer nach dem anderen Zeilenweise Aufgebaut werden.
Page 1 of 165 ---- Generated from net(t)forum Mein nicht repräsentativer aber doch Vergleichbarer Test mit "time eisman update" zeigt bei eisfair64 direkt auf der Maschine installiert einen Wert zwischen 30 und 40 Sekunden und auf der selben Maschine aber als VM unter Proxmox einen Wert von ca. 5 Minuten, aber unabhängig ob in der Proxmox Konsole oder per ssh. Interessant wäre evtl. noch, eisfair-1 brachte deutlich weniger Zeit aber immer noch als VM auffällig mehr wie als HM.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Uwe Kunze on Sat, 02 Mar 2019 14:27:05 GMT View Forum Message <> Reply to Message > Und, wie ich finden konnte, kenne bereits andere dieses Verhalten von > Eisfair als Proxmox-VM.
> ... dass er bei Tests > mit Eisfair auf Proxmox merkte, dass auch bei Ihm Eisfair ungewöhnlich > Träge im Vergleich zu anderen Distributionen ist und dies bereits bei > der Grafikausgabe beginnt
Für die Grafikausgabe kann ich das nicht nur für PROXMOX bestätigen (habe etwa 10 eisfairs unter verschiedenen Proxmox-Maschinen laufen), sondern auch für VIRTUALBOX. Im Vergleich zu einer virtuellen Ubuntu-Installation ist der eis da tatsächlich sehr träge ... egal, ob man das eingebaute noVNC oder andere rdp-Clients benutzt.
Allerdings kann ich nicht bestätigen, dass der eisfair generell Performance-Probleme unter Proxmox hat (wie z.B. die beschriebene Trägheit des eisman-Updates usw.)
Gruß Uwe
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Uwe Kunze on Sat, 02 Mar 2019 14:35:00 GMT View Forum Message <> Reply to Message Ergänzung zum vorherigen Post:
> Interessant wäre evtl. noch, eisfair-1 brachte deutlich weniger Zeit > aber immer noch als VM auffällig mehr wie als HM.
Page 2 of 165 ---- Generated from net(t)forum Alle meine virtualisierten eisfair sind (derzeit) 32Bit-Installationen .... leider habe ich übersehen, dass es Dir hier vorrangig um die 64Bit-Version geht ... sorry.
Gruß Uwe
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by H. D. Oezbilen on Sat, 02 Mar 2019 15:33:21 GMT View Forum Message <> Reply to Message Hallo Detlef,
> eisman update" zeigt bei eisfair64 direkt auf der Maschine installiert > einen Wert zwischen 30 und 40 Sekunden und auf der selben Maschine aber > als VM unter Proxmox einen Wert von ca. 5 Minuten, aber unabhängig ob in > der Proxmox Konsole oder per ssh. > Interessant wäre evtl. noch, eisfair-1 brachte deutlich weniger Zeit > aber immer noch als VM auffällig mehr wie als HM. vllt. hilft Dir dieser Ansatz.
Ich habe mehrere Debian (8.x) auf HP G6 ML 370, alte HW, aber immer noch hurtig. 1x w2k12r2 3x Debian 1x IDE alt eis, top bei 3-4 (v. 24). D.h. die HW hat noch viiiiel Luft. Damit ist mal die HW klassifiziert.
Auf einem dieser HW ist ein (test) eisx64 installiert.
Ich kenne Proxmox (etwas her), doch es ist ein nur ein Debain mit einer GUI drueber.
Mein Vorschlag an Dich waere, setzte doch bitte mal ein Deb. 8x/9.x auf. Wenn Du diese Maschine ehe nur fuer die Virt. nimmst, kannst Du direkt nach apt install xyz auch die X-Gui installieren, paar Dateien Editieren und Du kannst mit cygwin-X drauf zugreifen. IM LAN OK, ueber Remote etwas traege, deswegen ...
.... installierst Du bitte noch das xrdp. Da Du auch ssh hat, kommst Du gesichert auf eine GUI, dort/dafuer(vorher) installierst Du auch den Virtual Machine Manager (VMM).
Ich weiss nicht, ob Proxmox spice hat, gar das alte 8.x Debian bietet fuer die Steuerung der GUI der VMs spice an (USB Redir v. Client).
@Leistung der vm der erste Lauf (seit Monaten kein update auf eisx64) dauert so lang: real 2m24
Page 3 of 165 ---- Generated from net(t)forum user 0m33 sys 0m21 der zweite Lauf hingegen real 0m47 user 0m6 sys 0m4
Auch die beiden Tux kommen ratz-fatz, die Graphikausgabe (auf x-per xrdp ueber die DSL-Leitung 40M raus) ist flott, *obwohl* der eis z.Z. noch auf IDE und vga/e1000 ist. Bisher hatte ich wenig Zeit die virtio in eisx64 einzubinden, da muss man ja noch manuell paar Sachen anpassen.
Insofern, diese Performanceverluste, die Du in deinem Beitrag beschreibst habe ich unter Debian pur nicht, obwohl der eis *nur* eine IDE/vga/e1000 Einheit ist.
(z.B. kommt der ur-alt x86 eis unter VM auf dieser Einheit mit IDE/e1000 max. auf 25/27 MByte Transfer. Ist halt alt und Null virtio. ;-))
Deswegen, mal Debian installieren, X nachziehen, VMM und xrdp (per ssh/openvpn), dann hast Du die ganze Einheit voll im Zugriff. Plus, dass Du ein Plain-Debian hast, und nicht die Filterschicht Proxmox.
Klar, proxmox hat eine WEBGui ueber die vm-Funktionen gelegt, aber dafuer ist man auch v. der Config/CLI weg. Was einem mehr wert ist?
Damals hing Proxmox lange bei 2.6.32 *der* Kernel fuer Virt, auch fuer Xen. Aber die Entwicklung, qemu/kvm zog weiter, immer auf Proxmox warten (auch die Lic-Bestimmungen, updates etc), fand ich dann doch nervig.
Wenn ich Dir mit dem Deb. helfen kann, PM, OK? Derya
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sat, 02 Mar 2019 17:42:35 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 16:33 schrieb D. Oezbilen: > Hallo Detlef,
Hallo,
> Mein Vorschlag an Dich waere, setzte doch bitte mal ein Deb. 8x/9.x auf. > Wenn Du diese Maschine ehe nur fuer die Virt. nimmst, kannst Du direkt > nach apt install xyz auch die X-Gui installieren, paar Dateien Editieren > und Du kannst mit cygwin-X drauf zugreifen. IM LAN OK, ueber Remote > etwas traege, deswegen ... >
Page 4 of 165 ---- Generated from net(t)forum > ... installierst Du bitte noch das xrdp. Da Du auch ssh hat, kommst Du > gesichert auf eine GUI, dort/dafuer(vorher) installierst Du auch den > Virtual Machine Manager (VMM). kann ich mal Probieren, hab ja die letzten Wochen die Maschine etliche male neu aufgesetzt. Aktuelles Debian habe ich da, weil ich Proxmox sowieso nicht direkt vom ISO sondern über den Umweg einer Debianinstallation auf die dann Proxmox nachgezogen wird gemacht habe. Grund, ich möchte zunächst eine altmodische Standard-Partitionierung mit ext4 Boot, Swap und Root-Partition. Und ja, ich habe den Test auch schon bei Proxmox mit der Standartinstallation gemacht. Selbes Ergebnis.
> > Ich weiss nicht, ob Proxmox spice hat, gar das alte 8.x Debian bietet > fuer die Steuerung der GUI der VMs spice an (USB Redir v. Client).
Kann man in der Webgui einstellen, aber ich habe mich damit überhaupt noch nicht weiter beschäftigt. Bin erst ganz am Anfang beim einrichten und schauen was geht.
> @Leistung der vm > > der erste Lauf (seit Monaten kein update auf eisx64) dauert so lang: > real 2m24 > user 0m33 > sys 0m21
Das kommt in etwa an die Werte welche ich hier mit der 32bit VM von eisfair erreicht hatte.
> Bisher hatte ich wenig Zeit die virtio in eisx64 einzubinden, da muss > man ja noch manuell paar Sachen anpassen.
Was die Platten angeht kann ich sagen, dass ich in meinen Tests der letzten Wochen gemerkt habe, dass der vitrio-scsi etwas langsamer ist als der LSI 53C895A. Sieht man schön beim Start, wenn die Pünktlichen nach lilo "hochgezählt" werden.
> Insofern, diese Performanceverluste, die Du in deinem Beitrag > beschreibst habe ich unter Debian pur nicht, obwohl der eis *nur* eine > IDE/vga/e1000 Einheit ist. > > (z.B. kommt der ur-alt x86 eis unter VM auf dieser Einheit mit IDE/e1000 > max. auf 25/27 MByte Transfer. Ist halt alt und Null virtio. ;-))
In den letzten Wochen alles getestet, Netzwerk, Plattenleistung, alles normale Werte. Plattenleistung in der VM interessanter weise sogar besser als eisfair direkt auf der Maschine. Rechenleistung mit einem Kern auch normal. Getestet mit time echo "scale=5000; 4*a(1)" | bc -l >/dev/null wobei es ohne >/dev/null und auf der Proxmox noVNC wieder miserable werte sind.
Page 5 of 165 ---- Generated from net(t)forum Alle Werte erscheinen normal, es dürfte nicht diese Zeitunterschiede geben. Ich habe noch gar nicht erkundet, wo es sich überall bemerkbar macht aber zumindest bei jeder Installation wenn die Abhängigkeiten überprüft werden, beim Kernel dauert das entpacken sehr lange und gleich danach "überlegt" er ewig lang wegen den Scsi-Treibern. Beim Booten ist BFB Auffällig, die dort "angedrohten" 2 Minuten werden gut erreicht und so setzt es sich fort.
Die Installation hätte ich für die neue Maschine fast fertig aber ehrlich gesagt, so möchte ich den neuen eisfair nicht produktiv einsetzen.
Mal ein "verrückter" Gedanke zum Testen. Gibt es eine Boot-Option um die lokale Ausgabe komplett inkl. allen Treibern und sonst was zu deaktivieren? Ich hätte ja noch ssh und würde mal Testen wollen ob und in wieweit diese Sachen zusammen hängen.
> Wenn ich Dir mit dem Deb. helfen kann, PM, OK?
Wenn das mal kein Fehler war, evtl. komme ich darauf zurück. ;-)
> Derya
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sat, 02 Mar 2019 17:46:06 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 18:42 schrieb Detlef Paschke: >> @Leistung der vm >> >> der erste Lauf (seit Monaten kein update auf eisx64) dauert so lang: >> >> real 2m24 >> user 0m33 >> sys 0m214 > > Das kommt in etwa an die Werte welche ich hier mit der 32bit VM von > eisfair erreicht hatte.
Zur Präzisierung, bei einem Durchlauf ohne neue Pakete.
Viele Grüße
Page 6 of 165 ---- Generated from net(t)forum Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Sat, 02 Mar 2019 19:03:32 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 13:10 schrieb Detlef Paschke:
> In die Richtung, doch Eisfair als "Schuldigen" in Betracht zu ziehen hat > mich ein User in einer Proxmox-Gruppe damit gebracht, dass er bei Tests > mit Eisfair auf Proxmox merkte, dass auch bei Ihm Eisfair ungewöhnlich > Träge im Vergleich zu anderen Distributionen ist und dies bereits bei > der Grafikausgabe beginnt. eisfair unterstützt bewusst keine beschleunigte Grafik - es handelt sich um einen Server. Um das zu ändern müsste man viel mehr Grafik-Treiber in den Kernel fest einbauen bzw. sich darauf verlassen, dass udev die benötigten schon selbst lädt.
> Da ich Proxmox-Neuling bin hatte ich natürlich noch keinen Vergleich, > aber hier sind meine nachvollzogenen (einleuchtenden) Werte mit einen > einfachen "time lsmod" in der Proxmox Konsole (noVNC), > > real 0m3.583s > user 0m0.020s > sys 0m3.552s
[...] > > Das selbe "time lsmod" in der Proxmox Konsole (noVNC) auf einem > "frischem" Kubuntu bringt, > > real 0m0,012s > user 0m0,000s > sys 0m0,013s
Welche Kernel-Versionen vergleichen wir hier?
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance)
Page 7 of 165 ---- Generated from net(t)forum Posted by Detlef Paschke on Sat, 02 Mar 2019 19:57:19 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 20:03 schrieb Thomas Bork:
Hallo Thomas,
> Am 02.03.2019 um 13:10 schrieb Detlef Paschke: > > eisfair unterstützt bewusst keine beschleunigte Grafik - es handelt sich > um einen Server. Um das zu ändern müsste man viel mehr Grafik-Treiber in > den Kernel fest einbauen bzw. sich darauf verlassen, dass udev die > benötigten schon selbst lädt. das sollte auf keinen Fall ein Vorwurf sein, ich wollte im Grunge nur darlegen, was ich bis dato bezüglich dieser Geschichte in Erfahrung bringen konnte. Eisfair64 soll ja hier auch als Server eingesetzt werden, als virtualisierter Server, so ungewöhnlich nun auch nicht.
Ich dachte sogar schon, dass eisfair hier irgend welche Grafiksachen lädt, die man sich evtl. sogar sparen könnte um die Sache zu beschleunigen. Aber wie Du schreibst oder ich es verstehe, verzichten wir auf all das und somit fällt das schon mal raus.
> >> Da ich Proxmox-Neuling bin hatte ich natürlich noch keinen Vergleich, >> aber hier sind meine nachvollzogenen (einleuchtenden) Werte mit einen >> einfachen "time lsmod" in der Proxmox Konsole (noVNC), >> >> real 0m3.583s >> user 0m0.020s >> sys 0m3.552s > > [...] >> >> Das selbe "time lsmod" in der Proxmox Konsole (noVNC) auf einem >> "frischem" Kubuntu bringt, >> >> real 0m0,012s >> user 0m0,000s >> sys 0m0,013s > > Welche Kernel-Versionen vergleichen wir hier?
Das ist ein ganz frisches Kubuntu welches ich nur mal zum Testen aufgesetzt habe, uname -r sagt 4.15.0-45-generic.
Recht vergleichbar wären aber zumindest die Werte von eisfair einmal in der Proxmox-Konsole und einmal per ssh.
Ob diese langsame Ausgabe in der Proxmox-Konsole (was mir Scheiß egal wäre) und das allgemein träge arbeiten aber irgendwie zusammen hängen
Page 8 of 165 ---- Generated from net(t)forum konnte ich noch nicht näher bestimmen.
Und was mir auch so merkwürdig erschien war, dass bei meinem nicht repräsentativen Test mit "time eisman update" der eisfair1 ca. 2:30 min. gebraucht hat und der eisfair64 gut doppelt so lang.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sat, 02 Mar 2019 20:18:49 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 20:57 schrieb Detlef Paschke: > das sollte auf keinen Fall ein Vorwurf sein, ich wollte im Grunge nur > darlegen, was ich bis dato bezüglich dieser Geschichte in Erfahrung > bringen konnte. Eisfair64 soll ja hier auch als Server eingesetzt > werden, als virtualisierter Server, so ungewöhnlich nun auch nicht.
Und dann ist da eben die ständige Grundlast die ich hier sehe wenn eisfair nur so vor sich hin tuckelt. Keine Arbeit, nix zu tun außer alle 5 Minuten IPMI- und SMART-Werte lesen und per ftp weiterreichen, Grundlast um die 20% Kubuntu zur gleichen Zeit, okay ohne die IPMI, SMART und ftp Sachen aber evtl. Spitzen jeweils nicht beachtet, Grundlast ca. 2%.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Sat, 02 Mar 2019 21:36:21 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 20:57 schrieb Detlef Paschke:
>> Welche Kernel-Versionen vergleichen wir hier? > Das ist ein ganz frisches Kubuntu welches ich nur mal zum Testen > aufgesetzt habe, uname -r sagt 4.15.0-45-generic.
Page 9 of 165 ---- Generated from net(t)forum Nun ja, ich denke zwischen 3.16.x und 4.15.x hat sich einiges getan ;-) ...
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sat, 02 Mar 2019 21:50:28 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 22:36 schrieb Thomas Bork: > Am 02.03.2019 um 20:57 schrieb Detlef Paschke: > >>> Welche Kernel-Versionen vergleichen wir hier? >> Das ist ein ganz frisches Kubuntu welches ich nur mal zum Testen >> aufgesetzt habe, uname -r sagt 4.15.0-45-generic. > > Nun ja, ich denke zwischen 3.16.x und 4.15.x hat sich einiges getan ;-) ...
Ach komm, dass kann ja nun auch nicht die einzige Reaktion sein. Ich finde garantiert genügend alte 2.2er 2.4er und 2.6er Distributionen bei denen es dieses Verhalten nicht gibt.
Ich habe übrigens gerade mal Ubuntu-Server 18.10 installiert neuste Updates gemacht, ging relativ schnell, und auch mal das nette time lsmod in der Proxmox-Konsole. Etwas langsamer als in der Kubuntu-Desktop aber trotzdem in 0,4 sek. erledigt.
Morgen suche ich mal ein altes Serversystem und mache einen Vergleich, für heute mache ich Schluss, "Heute" ist sowieso fast vorbei.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Sun, 03 Mar 2019 01:13:15 GMT View Forum Message <> Reply to Message Am 02.03.2019 um 21:18 schrieb Detlef Paschke: > Am 02.03.2019 um 20:57 schrieb Detlef Paschke: >> das sollte auf keinen Fall ein Vorwurf sein, ich wollte im Grunge nur >> darlegen, was ich bis dato bezüglich dieser Geschichte in Erfahrung >> bringen konnte. Eisfair64 soll ja hier auch als Server eingesetzt >> werden, als virtualisierter Server, so ungewöhnlich nun auch nicht.
Page 10 of 165 ---- Generated from net(t)forum > > Und dann ist da eben die ständige Grundlast die ich hier sehe wenn > eisfair nur so vor sich hin tuckelt. Keine Arbeit, nix zu tun außer alle > 5 Minuten IPMI- und SMART-Werte lesen und per ftp weiterreichen, > Grundlast um die 20% > Kubuntu zur gleichen Zeit, okay ohne die IPMI, SMART und ftp Sachen aber > evtl. Spitzen jeweils nicht beachtet, Grundlast ca. 2%.
Ein Desktop Linux und ein Selbst zusammen gefrickelter Debian+KVM+Qemu+irgendwas und dann mit/ohne IPMI, SMART und irgendwelchen ftp-kram den KEIN OS (dabei auch noch verschiedene Kernelversionen) von haus aus selbst macht...
.... und DAS nennst du VERGLEICHBAR? Das ist'n Witz oder?
Sorry, aber worum geht es hier. Das der Relativ neue Eis-64 in deiner Umgebung ein paar Prozentpünktchen langsamer ist als ein Eis-32.
Du bist wie du sagst mit Proxmox neuling. Und IMHO hab ich dir schon mal gesagt das der Test-Eis-64 hier zwar etwas langsamer sein könnte aber beileibe nicht so langsam wie es deine Epischen und AFAIK kaum vergleichbaren Schilderungen nahelegen. Klingt als Schleiche der bei dir. Hier nicht.
Und ich habe zwei OOTB Proxmox hier. Der eine mit 8 Kernen, 12 GB RAM und RAID aber Server-Hardware (der macht IPMI aber kaum SMART) und der andere ein AMD-Phenom mit 4 Kernen, 6 GB RAM und ohne Raid (Ohne IPMI aber mit SMART). Und nach meinem Empfinden läuft Eisfair darauf OOTB gut genug. So gut das ich kein Interesse hab die zu virtio-isieren.
Was ich viel sinnvoller fände wäre ein qemu-guest-agent paket für den EIS damit der vom Host geregelt runter gefahren werden kann oder Snapshots nicht gelegentlich fehlgehen. Das scheint mir deutlich wichtiger als "Ausgabe ist zu lahm, muß wohl die Grafik bei Eis-64 sein" zu rufen.
Ich weiß jetzt nicht mehr warum du auf dem Eis-64 bestehst und welche unheimlich Schweren Jobs der bei dir Stemmen soll (die ein Eis-32 nicht schaffte) aber wenn du nicht den Fehler machtest einen 32-bit host zu installieren und erwartest das 64-bit gäste darunter laufen wie auf Baremetal dann finde ich das alles etwas überdramatisiert. Und die vergleiche mal so, mal so, und insgesamt schlecht bis gar nicht vergleichbar.
BTW, Proxmox ist nach meinem Erleben ein kaum modifiziertes Debian und Rennt mit LVM hier schnell genug. Aber das willst du; soweit ich erinnere; ja auch nicht haben. Mir scheint es daher so das dein Problem eher in deiner Verkorksten Installationweise (Kein ZFS, Kein LVM) besteht. Das du den mal OOTB mit LVM installiertest und einen Eis-64 darauf probefuhrst... kann mich nicht erinneren so was hier von dir gelesen zu haben.
Page 11 of 165 ---- Generated from net(t)forum Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 10:20:13 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 02:13 schrieb Kay Martinen: > Was ich viel sinnvoller fände wäre ein qemu-guest-agent paket für den > EIS damit der vom Host geregelt runter gefahren werden kann oder > Snapshots nicht gelegentlich fehlgehen. Das scheint mir deutlich > wichtiger als "Ausgabe ist zu lahm, muß wohl die Grafik bei Eis-64 sein" > zu rufen.
Geht problemlos mit dem Power-Button-Paket. War das erste was ich hier probiert und Raus bekommen habe.
Und wie ich schon schrob, das identische Verhalten mit einem Proxmox direkt von der ISO mit den Standarteinstellungen installiert und Unterschiede in der Grundlast von nahezu 20% ein Witz...? Nun gut.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 11:16:59 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 02:13 schrieb Kay Martinen: > IPMI, SMART und > irgendwelchen ftp-kram da fällt mir noch ein Denkfehler von gestern Abend ein, war auch schon spät.
Die Abfragen alle 5 Min. macht Proxmox und gibt sie per ftp weiter an eisfair. Eisfair empfängt also nur alle 5 Min. die *.txt Dateien per ftp und wie ich auch schrob, irgend welche spitzen hatte ich nicht beachtet. Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um die 0,5% Grundlast.
Page 12 of 165 ---- Generated from net(t)forum Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 11:28:10 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Die Abfragen alle 5 Min. macht Proxmox und gibt sie per ftp weiter an > eisfair. Eisfair empfängt also nur alle 5 Min. die *.txt Dateien per ftp > und wie ich auch schrob, irgend welche spitzen hatte ich nicht beachtet. > Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu > Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um > die 0,5% Grundlast.
Mit top oder htop müsste sich doch feststellen lassen, welche Prozesse speziell viel Last erzeugen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Hilix on Sun, 03 Mar 2019 12:00:10 GMT View Forum Message <> Reply to Message Hallo Kay,
Am 03.03.19 um 02:13 schrieb Kay Martinen: > Was ich viel sinnvoller fände wäre ein qemu-guest-agent paket für den > EIS damit der vom Host geregelt runter gefahren werden kann oder > Snapshots nicht gelegentlich fehlgehen. Das scheint mir deutlich > wichtiger als "Ausgabe ist zu lahm, muß wohl die Grafik bei Eis-64 sein" > zu rufen. ich nutze wohl "nur" KVM und virt-manager. Seit ich in der Eisfair-VM immer die Pakete acpica und power_button installiere, funktioniert ein Shutdown der VM von der KVM-Host-Kommandozeile mit "virsh shutdown
Page 13 of 165 ---- Generated from net(t)forum wahrscheinlich (im Endeffekt) die gleiche libvirt-Funktion.
Gruß. / Hilmar.
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 12:12:56 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 12:28 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Detlef Paschke wrote: > >> Die Abfragen alle 5 Min. macht Proxmox und gibt sie per ftp weiter an >> eisfair. Eisfair empfängt also nur alle 5 Min. die *.txt Dateien per ftp >> und wie ich auch schrob, irgend welche spitzen hatte ich nicht beachtet. >> Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu >> Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um >> die 0,5% Grundlast. > > Mit top oder htop müsste sich doch feststellen lassen, welche Prozesse > speziell viel Last erzeugen. schaue ich gleich noch mal nach, ist mir beim letzten mal nichts wirklich aufgefallen. Ich werde dazu auch noch mal einen ganz neuen eisfair aufsetzen und nur die aktuellen Kernel- und Base-Updates machen.
Ich habe auch das Gefühl, dass jede weitere Diskussion darüber wenig Sinn macht da sie in Richtung "...was willst Du oder erwartest Du denn eigentlich..." geht. Diese Unterschiede in Grundlast und Zeit für ein DB-Update (auch der Unterschied zwischen eisfair-1 und eisfair64 welche dabei doch sicher das selbe machen sollten) sind mir aufgefallen und da ich nicht annehme, dass es gewollt ist, sollten sie doch hier besprochen werden dürfen. Und da mir nun User aus einer Proxmox-Gruppe bestätigt haben, das zumindest was die Ausgabe auf der Proxmox-Konsole angeht, Eisfair auffällig träge reagiert, halte ich das für erwähnenswert.
Auf der anderen Seite dürfen sich die Entwickler dann aber auch nicht beschweren, wenn die User Pakete nutzen nach dem Motto "wenn ich nichts sage schmeckts" und nie eine Rückmeldung abgeben. Ich erinnere mich da z.B. an die immer noch bestehende Geschichte, als ein User sich meldete weil sein Samba-Drucker seit einigen Versionen sehr langsam reagiert. Sowohl ich als auch Du nach eigenen Tests haben das bestätigen können. Ich konnte in der Zwischenzeit feststellen, dass dies alle Samba-Drucker also auch pdf und fax betrifft und habe es eine Zeit lang nach jeder neuen Samba-Version getestet und hier die Meldung abgegeben, dass dieses Problem weiterhin besteht.
Page 14 of 165 ---- Generated from net(t)forum Ich glaube, Thomas der ja das Samba-Paket betreut, hat sich kein wo könnte die Ursache liegen. Dein Vorschlag dazu war dann, Samba-Drucker halt nicht zu nutzen und per lprng zu drucken. Nun ja, "Herr Doktor, immer wenn ich so mache tut das unheimlich weh... Dann machen Sie halt nicht so".
So, dass wollte ich mal loswerden und nun kann die Wut aller auf mich ein prasseln aber Auffälligkeiten hier melden halte ich für Eisfair weiterhin für unerlässlich.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Hilix on Sun, 03 Mar 2019 12:34:22 GMT View Forum Message <> Reply to Message Hallo Detleff,
Am 03.03.19 um 12:16 schrieb Detlef Paschke: > Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu > Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um > die 0,5% Grundlast. ein solches Verhalten von Eisfair-VM's (E64) kann ich bei mir nicht beobachten: Sie haben "im Leerlauf" eine CPU-Last von 2%. (KVM-Host: ArchLinux (2-Core-Pentium/1,2GHz). Könnte es nicht doch am Proxmox-Host liegen? (Ich verwende "nur" KVM/Qemu mit virt-manager bzw. virsh).
Gruß / Hilmar.
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 12:43:40 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Mit top oder htop müsste sich doch feststellen lassen, welche Prozesse >> speziell viel Last erzeugen. >
Page 15 of 165 ---- Generated from net(t)forum > schaue ich gleich noch mal nach, ist mir beim letzten mal nichts > wirklich aufgefallen. Ich werde dazu auch noch mal einen ganz neuen > eisfair aufsetzen und nur die aktuellen Kernel- und Base-Updates machen. > > Ich habe auch das Gefühl, dass jede weitere Diskussion darüber wenig > Sinn macht da sie in Richtung "...was willst Du oder erwartest Du denn > eigentlich..." geht. > Diese Unterschiede in Grundlast und Zeit für ein DB-Update (auch der > Unterschied zwischen eisfair-1 und eisfair64 welche dabei doch sicher > das selbe machen sollten) sind mir aufgefallen und da ich nicht annehme, > dass es gewollt ist, sollten sie doch hier besprochen werden dürfen.
Ich verwende selbst keine Virtualisierung und kann da nicht selbst etwas untersuchen/testen.
Übrigens wird sich beim nächsten Base-Update bzgl. des DB-Updates gravierendes tun, da Daniel das komplett neu geschrieben hat - da ist ein Geschwindigkeitszuwachs um mehere Größenordnungen zu erwarten.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 12:57:30 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 13:34 schrieb Hilmar Böhm: > Hallo Detleff,
Hallo Hilmar,
> Am 03.03.19 um 12:16 schrieb Detlef Paschke: >> Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu >> Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um >> die 0,5% Grundlast. > > ein solches Verhalten von Eisfair-VM's (E64) kann ich bei mir nicht beobachten: Sie haben "im Leerlauf" eine CPU-Last von 2%. > (KVM-Host: ArchLinux (2-Core-Pentium/1,2GHz). Könnte es nicht doch am Proxmox-Host liegen? (Ich verwende "nur" KVM/Qemu mit > virt-manager bzw. virsh). teste ich gern da die Maschine derzeit ja sowieso noch nicht im produktiven Einsatz ist. Ich muss mir nur mal raus suchen, was und wie ich alles installieren muss. Ich habe ja bereits in einer Proxmox-Gruppe dieses Thema angesprochen, weil ich selbst natürlich auch nicht weiß, ob dieses Verhalten nun an Proxmox oder an Eisfair liegt - mein Verdacht war ja eher Proxmox da Eisfair ja sehr schlank und ohne schie schie ist - aber nachdem mir dort nun auch bestätigt wurde, dass Eisfair zumindest bei der Ausgabe über
Page 16 of 165 ---- Generated from net(t)forum die Proxmox-Konsole auffällig träge reagiert und ich dies hier mit verschiedensten Distributionen nachvollziehen kann, war ich der Meinung, dies hier noch einmal anzusprechen.
Das ist bei weitem nicht bös oder abwertend gemeint, ich bin treuer Eisfair-User seit dem Eisfair aus dem fli4l-Projekt einstanden ist (war es der 2.2er Kernel?) und mein produktiver Eisfair hat seit dem einiges an neuer Hardware und Updates aber nie eine Neuinstallation gebraucht.
Auffällig ist einfach dieser enorme Unterschied bei eisman update und demzufolge auch bei Installationen (was sich noch zeigt, soweit bin ich noch gar nicht), der bei eisfair auf der Hardware nicht einmal 40sek. braucht als VM aber je nach dem bis knapp über 5min. Würde das Update auf HM 15min. brauchen und in der VM 4-5min. mehr wäre es vom Verhältnis scheiß egal aber so ist es doch auffällig.
> Gruß / Hilmar.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Helmut Backhaus on Sun, 03 Mar 2019 13:25:31 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 03.03.19 um 13:43 schrieb Marcus Roeckrath: > > Ich verwende selbst keine Virtualisierung und kann da nicht selbst etwas > untersuchen/testen.
Dann hast Du wohl mehr Platz wie wir ... :-))
> > Übrigens wird sich beim nächsten Base-Update bzgl. des DB-Updates > gravierendes tun, da Daniel das komplett neu geschrieben hat - da ist ein > Geschwindigkeitszuwachs um mehere Größenordnungen zu erwarten. >
Ist das nur für E-64 oder auch für E-1?
Wenn das für beide wäre, wäre das SUPER COOL!!!
Ich hab beim ffmpeg wieder Stunden zugebracht, und das gleich 2 mal kurz
Page 17 of 165 ---- Generated from net(t)forum hintereinander ...
-- Gruß, Helmut
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 13:37:38 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 13:43 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Ich verwende selbst keine Virtualisierung und kann da nicht selbst etwas > untersuchen/testen. ich wurde auch erst "infiziert" als ich vor fast 10 Jahren im Rahmen einer "Maßnahme für behinderte Menschen" mal das Rechenzentrum in unserem örtlichen Klinikum betreten durfte und in den folgenden Wochen von Servervirtualisierung angesteckt wurde. Mangels geeigneter Hardware hat es bis Heute gedauert damit zu beginnen.
> Übrigens wird sich beim nächsten Base-Update bzgl. des DB-Updates > gravierendes tun, da Daniel das komplett neu geschrieben hat - da ist ein > Geschwindigkeitszuwachs um mehere Größenordnungen zu erwarten.
Das ist schön zu hören aber die Frage ist ja, wo der auffällige Unterschied herkommt.
Ich muss meine Aussage aber etwas Revidieren und das mache ich auch. Ich habe gerade einen ganz jung freudigen eisfair64 aufgesetzt, identische VM, nur die neusten Base- und Kernel-Updates, ein bisschen ssh war noch mit dabei. Keine weitere Konfiguration, IP bekommt er per DHCP, ssh blieb aus.
Die Grundlast ist in der Tat bis auf 0,8% gesunken, also völlig unauffällig. Bei einem eisman update geht die Last auf ca. 40% die kürzeste Zeit nach mehreren Versuchen war 3m36.944s also doch noch ein Stück weniger wenn er gar nix weiter zu tun hat aber doch noch auffällig.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Page 18 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 13:39:16 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 14:25 schrieb Helmut Backhaus: > Ich hab beim ffmpeg wieder Stunden zugebracht, und das gleich 2 mal kurz > hintereinander ... also doch auch? ;-)
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Gerd Walter on Sun, 03 Mar 2019 13:45:19 GMT View Forum Message <> Reply to Message Am 02.03.19 um 20:03 schrieb Thomas Bork:
>> Da ich Proxmox-Neuling bin hatte ich natürlich noch keinen Vergleich, >> aber hier sind meine nachvollzogenen (einleuchtenden) Werte mit einen >> einfachen "time lsmod" in der Proxmox Konsole (noVNC), >> >> real 0m3.583s >> user 0m0.020s >> sys 0m3.552s > > [...] >> >> Das selbe "time lsmod" in der Proxmox Konsole (noVNC) auf einem >> "frischem" Kubuntu bringt, >> >> real 0m0,012s >> user 0m0,000s >> sys 0m0,013s
Ich nutze nicht Proxmox aber XEN, und da habe ich folgende Zeiten mit e64 als paravirtualisiert: real 0m0.020s user 0m0.008s sys 0m0.012s
--
Page 19 of 165 ---- Generated from net(t)forum Gruß Gerd
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance)Hallo Helmut, Posted by Marcus Roeckrath on Sun, 03 Mar 2019 13:46:01 GMT View Forum Message <> Reply to Message Hallo Helmut,
Helmut Backhaus wrote: >> Übrigens wird sich beim nächsten Base-Update bzgl. des DB-Updates >> gravierendes tun, da Daniel das komplett neu geschrieben hat - da ist ein >> Geschwindigkeitszuwachs um mehere Größenordnungen zu erwarten. > > Ist das nur für E-64 oder auch für E-1?
Wieso sollte das nur für eines der beiden Systeme sein? eis1 und eis64 bis auf die "Bittigkeit" der Kompilate sind identisch.
> Ich hab beim ffmpeg wieder Stunden zugebracht, und das gleich 2 mal kurz > hintereinander ...
Es geht zunächst um das Update der Paketdatenbank!
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 13:47:40 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Ich hab beim ffmpeg wieder Stunden zugebracht, und das gleich 2 mal kurz >> hintereinander ... > > also doch auch? ;-)
Dieses Updates müssen viele Abhängigkeiten auflösen und da ist Shell-Code schon nicht optimal.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance)
Page 20 of 165 ---- Generated from net(t)forum Posted by Marcus Roeckrath on Sun, 03 Mar 2019 13:49:50 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Übrigens wird sich beim nächsten Base-Update bzgl. des DB-Updates >> gravierendes tun, da Daniel das komplett neu geschrieben hat - da ist ein >> Geschwindigkeitszuwachs um mehere Größenordnungen zu erwarten. > > Das ist schön zu hören aber die Frage ist ja, wo der auffällige > Unterschied herkommt.
Weg von bash-Skript hinzu awk.
> Ich muss meine Aussage aber etwas Revidieren und das mache ich auch. > Ich habe gerade einen ganz jung freudigen eisfair64 aufgesetzt, > identische VM, nur die neusten Base- und Kernel-Updates, ein bisschen > ssh war noch mit dabei. > Keine weitere Konfiguration, IP bekommt er per DHCP, ssh blieb aus. > > Die Grundlast ist in der Tat bis auf 0,8% gesunken, also völlig > unauffällig.
Ooooh, was ist also an deiner Altinstallation anders?
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Helmut Backhaus on Sun, 03 Mar 2019 13:52:00 GMT View Forum Message <> Reply to Message Am 03.03.19 um 14:39 schrieb Detlef Paschke: > Am 03.03.2019 um 14:25 schrieb Helmut Backhaus: >> Ich hab beim ffmpeg wieder Stunden zugebracht, und das gleich 2 mal kurz >> hintereinander ... > > also doch auch? ;-) >
Na ja, aber das sind KEINE VM's!
-- Gruß, Helmut
Page 21 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 14:14:07 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 14:47 schrieb Marcus Roeckrath: > Dieses Updates müssen viele Abhängigkeiten auflösen und da ist Shell-Code > schon nicht optimal.
Nun, das war dieser Zusammenhang der mir aufgefallen war. Eisman install spam war es bei mir glaube ich was ewig gedauert hatte und wo mir diese Geschichte zuerst aufgefallen ist.
Ich glaube aber auch noch nicht, dass eisman die Bremse ist denn z.B bei der Kernel Installation hat doch eisman nix mehr zu machen und da dauert das "decompress Kernel" (mag sein, dass es anders heißt) und danach das Warten auf die Festplatten-Treiber recht lang. Da macht doch eisman nichts mehr?
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 14:24:47 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 14:49 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Detlef Paschke wrote: > > >> Ich muss meine Aussage aber etwas Revidieren und das mache ich auch. >> Ich habe gerade einen ganz jung freudigen eisfair64 aufgesetzt, >> identische VM, nur die neusten Base- und Kernel-Updates, ein bisschen >> ssh war noch mit dabei. >> Keine weitere Konfiguration, IP bekommt er per DHCP, ssh blieb aus. >> >> Die Grundlast ist in der Tat bis auf 0,8% gesunken, also völlig >> unauffällig. > > Ooooh, was ist also an deiner Altinstallation anders? fast alles installiert was ich auf meinem produktiven Eisfair haben möchte. Samba, BFB, Mail ink. spam, clam, mail-addon, rouncube und allen
Page 22 of 165 ---- Generated from net(t)forum Abhängigkeiten, BfB nimmt soweit ich finden konnte nicht unbescheiden Last. Power-Button zum Runter fahren, Gebe gern eine komplette Liste, sag nur wie am besten erstellen.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 14:29:22 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 14:45 schrieb Gerd Walter:
Hallo Gerd,
> Ich nutze nicht Proxmox aber XEN, und da habe ich folgende Zeiten mit > e64 als paravirtualisiert: > > real 0m0.020s > user 0m0.008s > sys 0m0.012s xen habe ich mir schon auf eine Platte installiert und wollte mal Testen, wie sich die Sache da verhält, kam aber noch nicht dazu.
Nutzt Du das XEN was man bei Citrix laden kann oder sollte ich was anderes nehmen
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Sun, 03 Mar 2019 14:29:23 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 02:13 schrieb Kay Martinen:
> Was ich viel sinnvoller fände wäre ein qemu-guest-agent paket für den > EIS damit der vom Host geregelt runter gefahren werden kann oder
Page 23 of 165 ---- Generated from net(t)forum > Snapshots nicht gelegentlich fehlgehen. Das scheint mir deutlich > wichtiger als "Ausgabe ist zu lahm, muß wohl die Grafik bei Eis-64 sein" > zu rufen.
Leg los: Du brauchst es, Du weisst, was es können muss - Du kennst es erstellen und testen :-)
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Sun, 03 Mar 2019 14:29:54 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 12:16 schrieb Detlef Paschke: > Am 03.03.2019 um 02:13 schrieb Kay Martinen: >> IPMI, SMART und >> irgendwelchen ftp-kram > > da fällt mir noch ein Denkfehler von gestern Abend ein, war auch schon > spät.
Bei mir auch. Vorgreifend sei gesagt das ich auch nur user bin und dir nicht den mut nehmen wollte über Fehler zu berichten. Mir schien nur das dein Fehler nichts gravierendes ist und deine Suchstrategie bestenfalls optimierungswürdig ist. Z.b. statt 3.x mit 4.y besser nur gleiche oder näher beieinander liegende Kernelversionen vergleichen.
> Die Abfragen alle 5 Min. macht Proxmox und gibt sie per ftp weiter an > eisfair. Eisfair empfängt also nur alle 5 Min. die *.txt Dateien per ftp
Das solltest du näher erklären wer da was und wohin macht. Denn mein Proxmox hat einen lokalen daemon der IPMI-Anfragen an den BMC stellt und da wird von haus aus nichts per ftp irgendwohin geschickt. Das muß also m.E. etwas sein das du dir selbst gebastelt hast. Aber was, und warum eigentlich? Und wieviel Last zieht dieses "etwas" allein? Weißt du auch das man bei einem Server mit BMC auch aus der Ferne per IPMI an diese Informationen kommen "kann"?
IPMI, Smart u.a. Sensorwerte auf dem Host zu erheben und sie in eine VM des gleichen Hosts zu senden halte ich mal für sinnfrei. Geht das an einen Echten Eisfair und welche Version läuft da nun drauf?
Wie du schreibst hast du häufiger andere OS installiert, aber es ist (mir) nicht klar ersichtlich welches da grad dein OS-der-Stunde ist. :-)
> und wie ich auch schrob, irgend welche spitzen hatte ich nicht beachtet. > Eisfair macht sonst nichts und läuft mit ca. 20% Grundlast, ein Kubuntu > Desktop mit ca. 2% und gestern mal getestet, ein Ubuntu Server mit um
Page 24 of 165 ---- Generated from net(t)forum > die 0,5% Grundlast.
Das sind alles Virtualisierte Systeme unter Proxmox? Welche Dienste sind denn auf dem Ubuntu-Server aktiv oder sind da überhaupt welche installiert? Das ein Desktop idle weniger Grundlast zieht als ein Server der prinzipiell im Hintergrund mehr jobs laufen lässt wundert mich eigentlich nicht.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 14:31:50 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Ich glaube aber auch noch nicht, dass eisman die Bremse ist denn z.B bei > der Kernel Installation hat doch eisman nix mehr zu machen und da dauert > das "decompress Kernel" (mag sein, dass es anders heißt) und danach das > Warten auf die Festplatten-Treiber recht lang. Da macht doch eisman > nichts mehr? eisman install koordiniert natürlich die Installation - Auspacken, Starten von preinstall, Kopieren der Dateien, Starten von install, Aktualisieren der installed.db - nur so ganz grob.
Das meiste läuft mit bash-Skripten, die ihrerseits Prozesse forken, ...
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 14:34:29 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Ooooh, was ist also an deiner Altinstallation anders? > > fast alles installiert was ich auf meinem produktiven Eisfair haben
Page 25 of 165 ---- Generated from net(t)forum > möchte. Samba, BFB, Mail ink. spam, clam, mail-addon, rouncube und allen > Abhängigkeiten, BfB nimmt soweit ich finden konnte nicht unbescheiden > Last. Power-Button zum Runter fahren,
Wieso nicht mal testweise der Reihe nach Dienste temporär abschalten und danach jedesmal ein eisman update anstoßen, um zu sehen, wann sich eine Performanceänderung ergibt.
> Gebe gern eine komplette Liste, sag nur wie am besten erstellen.
Damit kann ich dann nicht viel anfangen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Sun, 03 Mar 2019 14:45:18 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 13:12 schrieb Detlef Paschke:
> Ich habe auch das Gefühl, dass jede weitere Diskussion darüber wenig > Sinn macht da sie in Richtung "...was willst Du oder erwartest Du denn > eigentlich..." geht.
Nein, das geht sie nicht. Zumindest nicht von meiner Seite.
Aber Du darfst weder Äpfel mit Birnen vergleichen (Desktop-Systeme mit neueren Kernelversionen und Serversysteme mit alten Kernelversionen) noch erwarten, dass eine einfache Meldung zu einer Problembeseitigung führt.
Bitte behalte immer im Kopf: Ich setze weder Xen noch KVM ein. Ich freue mich, dass es inzwischen überhaupt läuft. Es hilft mir überhaupt nicht weiter, dass Du ein Problem hast, welches ich nicht nachvollziehen kann.
Wenn Deine Vermutung in die Richtung einer suboptimalen Kernel-Konfiguration führt:
Installiere Dir eiskernel-dev und wandele die Konfiguration ab, bis sie Deinen Ansprüchen genügt. Führt das zur Beseitigung Deines Problems, lässt es sich damit allgemeingültig lösen und führt das zu keinen Problemen in anderen Bereichen, dann teile mir detailliert mit, was geändert werden sollte.
> Auf der anderen Seite dürfen sich die Entwickler dann aber auch nicht > beschweren, wenn die User Pakete nutzen nach dem Motto "wenn ich nichts > sage schmeckts" und nie eine Rückmeldung abgeben. > Ich erinnere mich da z.B. an die immer noch bestehende Geschichte, als > ein User sich meldete weil sein Samba-Drucker seit einigen Versionen
Page 26 of 165 ---- Generated from net(t)forum > sehr langsam reagiert. Sowohl ich als auch Du nach eigenen Tests haben > das bestätigen können. Ich konnte in der Zwischenzeit feststellen, dass > dies alle Samba-Drucker also auch pdf und fax betrifft und habe es eine > Zeit lang nach jeder neuen Samba-Version getestet und hier die Meldung > abgegeben, dass dieses Problem weiterhin besteht. > Ich glaube, Thomas der ja das Samba-Paket betreut, hat sich kein
> wo könnte die Ursache liegen.
Oha: Ich habe leider nicht die Zeit, jedem einzelnen Problem nachzugehen. Die Verzögerung der Druckdialoge ging mit einem Samba-Versionswechsel einher. Es gab nicht die Alternative, die alte und nicht mehr gewartete Samba-Version für eisfair weiter anzubieten.
Wenn Du mit dem Problem nicht leben kannst (das eigentlich alle Anwender dieser Versions-Linie haben müssten), dann bleibt Dir:
Da Samba im Quellcode vorliegt, lokalisierst Du das Problem und beseitigst es.
Wenn Du das nicht kannst, dann wendest Du Dich an die Samba-Entwickler und machst einen entsprechenden Bug-Report auf.
Du solltest Dir dabei bewusst sein, dass beide Wege viel Zeit und Arbeit erfordern werden.
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 14:49:21 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 15:29 schrieb Kay Martinen:
Hallo Kay,
> Das solltest du näher erklären wer da was und wohin macht. Denn mein > Proxmox hat einen lokalen daemon der IPMI-Anfragen an den BMC stellt und > da wird von haus aus nichts per ftp irgendwohin geschickt. Das muß also > m.E. etwas sein das du dir selbst gebastelt hast. Aber was, und warum > eigentlich? Und wieviel Last zieht dieses "etwas" allein? Weißt du auch > das man bei einem Server mit BMC auch aus der Ferne per IPMI an diese > Informationen kommen "kann"? > > IPMI, Smart u.a. Sensorwerte auf dem Host zu erheben und sie in eine VM > des gleichen Hosts zu senden halte ich mal für sinnfrei. Geht das an > einen Echten Eisfair und welche Version läuft da nun drauf?
Page 27 of 165 ---- Generated from net(t)forum > > Wie du schreibst hast du häufiger andere OS installiert, aber es ist > (mir) nicht klar ersichtlich welches da grad dein OS-der-Stunde ist. :-) also, es ist eine "neue" Maschine, auf die soll eisfair64 da warum 32bit nehmen wenn wir 64bit habe. Einfach weil es geht. Und ja, ich bedienen ihn aus der Ferne, er steht im Heizungskeller, so kann ich bessere Lüfter verbauen. Als VM möchte ich, weil mein derzeitiger HW-Eisfair sichtlich gelangweilt ist und ich für Bastelleinen wenig Sicherheiten hätte oder ihn ausschalten müsste. Beim "neuen" lege ich einfach eine weitere VM an und gut.
IPMI, SMART Geschichte ganz einfach. Die Werte werden von Proxmox per smartd und freeipmi abgefragt in je eine *.txt Datei gesteckt und per ftp auf die VM eisfair gesendet. Grund: Auf dem Eisfair läuft phpSysinfo und ich habe noch keine Möglichkeit gefunden die IPMI und SMART-Werte aus der VM heraus auslesen zu können. Ehrlich gesagt, auch noch gar nicht intensiv gesucht, da erst mal das System stehen muss.
> > Das sind alles Virtualisierte Systeme unter Proxmox? > Welche Dienste sind denn auf dem Ubuntu-Server aktiv oder sind da > überhaupt welche installiert?
Letzter Stand, alles jeweils die letzten Versionen, aktuelles Update und ohne jedes Paket.
> Kay
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 14:58:04 GMT View Forum Message <> Reply to Message Hallo Thomas,
Thomas Bork wrote:
> Ich habe leider nicht die Zeit, jedem einzelnen Problem nachzugehen. Die > Verzögerung der Druckdialoge ging mit einem Samba-Versionswechsel > einher. Es gab nicht die Alternative, die alte und nicht mehr gewartete > Samba-Version für eisfair weiter anzubieten. >
Page 28 of 165 ---- Generated from net(t)forum > Wenn Du mit dem Problem nicht leben kannst (das eigentlich alle Anwender > dieser Versions-Linie haben müssten), dann bleibt Dir:
Ich hatte es auch hier feststellen können, nachdem ich mal testweise über die Sama-Drucker gegangen bin.
Ich sehe es aber für mich nur dann als sinnvoll an, in den Druck noch die Zwischenschicht einzuschieben, wenn man auch die Druckertreiber in Samba verwaltet, was ich nicht tue.
Also warum sollte ich dann noch duch eine zusätzlich Schicht hindurchdrucken sollen?
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 15:01:43 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> also, es ist eine "neue" Maschine, auf die soll eisfair64 da warum 32bit > nehmen wenn wir 64bit habe. Einfach weil es geht.
Spricht ja auch nichts dagegen, ich würde einen neuen eis inzwischen auch nur noch als 64-bit installieren.
Um aber den Performanfresser bei deinem System auszumachen, müsstest du mal alles deaktivieren und der Reihe nach wieder aktivieren.
Wie soll der sonst gefunden werden; niemand anderes kann das bei sich für dich nachstellen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Sun, 03 Mar 2019 15:13:04 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 15:29 schrieb Thomas Bork: > Am 03.03.2019 um 02:13 schrieb Kay Martinen: > >> Was ich viel sinnvoller fände wäre ein qemu-guest-agent paket für den >> EIS damit der vom Host geregelt runter gefahren werden kann oder >> Snapshots nicht gelegentlich fehlgehen. Das scheint mir deutlich
Page 29 of 165 ---- Generated from net(t)forum >> wichtiger als "Ausgabe ist zu lahm, muß wohl die Grafik bei Eis-64 sein" >> zu rufen. > > Leg los: Du brauchst es, Du weisst, was es können muss - Du kennst es > erstellen und testen :-) >
Ja, schon klar. Wer weiß ob ich mich irgendwann mal dran traue.
Eigenartigerweise vergesse ich andauernd das ich "Power-Button" ja in EINER Eisfair-VM schon installiert hatte. Und warum ich das nicht in den anderen längst nachholte will mir auch grad nicht einleuchten.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 15:22:10 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
>> Leg los: Du brauchst es, Du weisst, was es können muss - Du kennst es >> erstellen und testen :-) > > Ja, schon klar. Wer weiß ob ich mich irgendwann mal dran traue.
Das ist eine Frage des Leidensdrucks.
Du wirst keinen hier finden, der das für dich macht, wenn derjenige nicht selbst auch ein persönliches Interesse daran hat.
Ich bin zur Paketentwicklung genau auf diesem Weg gekommen, dass ich etwas "haben" wollte.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 15:35:42 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:01 schrieb Marcus Roeckrath: > Hallo Detlef,
Page 30 of 165 ---- Generated from net(t)forum Hallo Marcus,
> > Detlef Paschke wrote: > >> also, es ist eine "neue" Maschine, auf die soll eisfair64 da warum 32bit >> nehmen wenn wir 64bit habe. Einfach weil es geht. > > Spricht ja auch nichts dagegen, ich würde einen neuen eis inzwischen auch > nur noch als 64-bit installieren. > > Um aber den Performanfresser bei deinem System auszumachen, müsstest du mal > alles deaktivieren und der Reihe nach wieder aktivieren. > > Wie soll der sonst gefunden werden; niemand anderes kann das bei sich für > dich nachstellen. an dieser Stelle ist aber noch nichts installiert und doch ist schon ein in meinen Augen einen doch schon auffälligen Unterschied bei eisman update von ca. 30-40sec. als HM und ca. 3einhalb Minuten als VM zu sehen.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 15:38:34 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:22 schrieb Marcus Roeckrath: > Das ist eine Frage des Leidensdrucks. > > Du wirst keinen hier finden, der das für dich macht, wenn derjenige nicht > selbst auch ein persönliches Interesse daran hat. > > Ich bin zur Paketentwicklung genau auf diesem Weg gekommen, dass ich etwas > "haben" wollte.
Ich kann da nur von mir ausgehen und muss sagen, zu manchen Sachen ist man einfach nicht in der Lage und ist auf die Gnade anderer angewiesen.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209
Page 31 of 165 ---- Generated from net(t)forum Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 15:42:47 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Du wirst keinen hier finden, der das für dich macht, wenn derjenige nicht >> selbst auch ein persönliches Interesse daran hat. >> >> Ich bin zur Paketentwicklung genau auf diesem Weg gekommen, dass ich >> etwas "haben" wollte. > > Ich kann da nur von mir ausgehen und muss sagen, zu manchen Sachen ist > man einfach nicht in der Lage und ist auf die Gnade anderer angewiesen.
Das wird man möglicherweise vergeblich darauf warten, wenn es um eine Spezialität haben möchte, die sonst niemanden interessiert.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Sun, 03 Mar 2019 15:44:38 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 15:14 schrieb Detlef Paschke:
> Ich glaube aber auch noch nicht, dass eisman die Bremse ist denn z.B bei > der Kernel Installation hat doch eisman nix mehr zu machen und da dauert > das "decompress Kernel" (mag sein, dass es anders heißt) und danach das > Warten auf die Festplatten-Treiber recht lang. Da macht doch eisman > nichts mehr?
Das sind auch die Stellen, die auf realer Hardware lange dauern.
Das Warten auf die HDD-Treiber wird durch ein bewusst eingebautes Delay von 10 Sekunden ausgelöst (/bin/sleep 10).
Experimentiere in der initramfs damit und prüfe, wie weit Du das reduzieren kannst (Deine Ergebnisse müssen nicht auf andere zutreffen).
-- der tom [eisfair-team]
Page 32 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 15:44:48 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Wie soll der sonst gefunden werden; niemand anderes kann das bei sich für >> dich nachstellen. > > an dieser Stelle ist aber noch nichts installiert und doch ist schon ein > in meinen Augen einen doch schon auffälligen Unterschied bei eisman > update von ca. 30-40sec. als HM und ca. 3einhalb Minuten als VM zu sehen.
HM (Hardware-Maschine) mit einer VM (virtuelle Maschine) zu vergleichen ist doch unlauter.
Ginbg es nicht mal darum. dass eis1 und eis64 bei dir als vurtualisierte Systeme gravierende Performanceunterschiede zeigen?
Wenn ja, installiere doch nun mal ein rudimentäres eis1 in diese VM und vergleiche.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 15:52:28 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:01 schrieb Marcus Roeckrath: > Um aber den Performanfresser bei deinem System auszumachen, müsstest du mal > alles deaktivieren und der Reihe nach wieder aktivieren.
Habe ich jetzt auf dem (fast) fertigen Eisfair64 gemacht und wie ich schon geahnt hatte nimmt sich bfb ordentlich Leistung. Die Grundlast ist mit bfb, wie schon gesagt, bei ca. 20% ohne bfb geht sie auf ca. 1,5% runter, was ich als völlig normal erachte zumal ja noch einige andere Dienste laufen.
Aber wie schon gesagt, auf einem Jungfreudigen eisfair gibt es noch kein bfb und auch dort dauern die Updates hier ungewöhnlich lang.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Page 33 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 15:56:26 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:44 schrieb Marcus Roeckrath: > HM (Hardware-Maschine) mit einer VM (virtuelle Maschine) zu vergleichen ist > doch unlauter. > > Ginbg es nicht mal darum. dass eis1 und eis64 bei dir als vurtualisierte > Systeme gravierende Performanceunterschiede zeigen? > > Wenn ja, installiere doch nun mal ein rudimentäres eis1 in diese VM und > vergleiche.
Letztendlich ging es um beides bzw. darum, das die VM so viel langsamer ist als die HM. Das in der selben Situation ein 32bit eisfair schneller als ein 64bit eisfair ist fiel mir nur am Rande auf. Ich installiere gleich noch mal ein sauberes eisfair-1.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 15:57:57 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:42 schrieb Marcus Roeckrath: > Das wird man möglicherweise vergeblich darauf warten, wenn es um eine > Spezialität haben möchte, die sonst niemanden interessiert.
Ich sag ja, die Gnade.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 16:04:48 GMT View Forum Message <> Reply to Message
Page 34 of 165 ---- Generated from net(t)forum Hallo Detlef,
Detlef Paschke wrote:
> Letztendlich ging es um beides bzw. darum, das die VM so viel langsamer > ist als die HM.
Meine beiden eisfair auf echter Hardware sind auch massiv unterschiedlich schnell!
Mein eis64 ist halt deutlich neuer und hat einen Core-Prozessor der 2. Generation, mein eis1 einen viel älteren einfacheren Athlon.
Da kommen aber noch weitere Unterschiede hinzu.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 16:08:36 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 16:44 schrieb Thomas Bork: > > Das Warten auf die HDD-Treiber wird durch ein bewusst eingebautes Delay > von 10 Sekunden ausgelöst (/bin/sleep 10). es fiel mir nur in diesem ganzen Zusammenhang auf, dass die Kernelinstallation an diesen Stellen, Entpacken und auf HDD-Treiber warten, in der VM auffällig länger braucht.
In dem Zusammenhang. Ist sleep ein fester Wert also reelle Zeit oder Takte? Könnte man mit z.B. time sleep 10 oder so einen sinnvollen Vergleich anstellen?
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 16:12:14 GMT View Forum Message <> Reply to Message Hallo Detlef,
Page 35 of 165 ---- Generated from net(t)forum Detlef Paschke wrote:
> Aber wie schon gesagt, auf einem Jungfreudigen eisfair gibt es noch kein > bfb und auch dort dauern die Updates hier ungewöhnlich lang.
Die eisfair-immanenten Tools sind in aller Regel Bash-Skripte, die alles andere als performant sind.
Das ist wegen der Wartbarkeit aber bewußt so gewählt, da man sich bei C-Programmen von der Existenz eines C-Spezialisten im Team abhängig macht.
Wie ich schon schrieb, rufen die Skripte weitere Skripte oder Binaries auf, was weitere Prozesse forkt.
Zudem sind manche Bash-internen-Funktionen (insbesondere Stringfunktionen) nicht besonders flott und je nach Prozessor kommt das noch gravierender zum Tragen.
Als eisman neu entwicklet wurde, dauerte alleine der Aufruf der Paketliste der instalierten Pakete auf meinem System rund 2 Minuten. Mit massiven Umstrukturierungen zur Vermeidung von bash-Stringfunktionen konnte ich das hier auf unter 20 Sekunden drücken.
Auf einem flotten neueren System lag zwischen Ursprungs- und optimierter Version gerade mal 2 Sekunden, nämlich 10 zu 8 Sekunden oder ähnliche Werte.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 16:13:12 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> In dem Zusammenhang. Ist sleep ein fester Wert also reelle Zeit oder > Takte? Könnte man mit z.B. time sleep 10 oder so einen sinnvollen > Vergleich anstellen? sleep wartet Sekunden, solange natürlich der Zeitgeber auch richtig läuft.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance)
Page 36 of 165 ---- Generated from net(t)forum Posted by Detlef Paschke on Sun, 03 Mar 2019 16:23:27 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 17:04 schrieb Marcus Roeckrath: > Meine beiden eisfair auf echter Hardware sind auch massiv unterschiedlich > schnell! > > Mein eis64 ist halt deutlich neuer und hat einen Core-Prozessor der 2. > Generation, mein eis1 einen viel älteren einfacheren Athlon. > > Da kommen aber noch weitere Unterschiede hinzu.
Tja, und bei mir war es der deutlich ältere und schwächer der viel schneller war und im verlauf der Suche habe ich wie schon gesagt, eisfair auch direkt auf die Maschine Installiert auf der, so gewünscht, Proxmox laufen soll.
Gut, zugegeben immer noch kein bestechender Vergleich, aber irgend was klemmt doch.?
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 16:33:55 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Letztendlich ging es um beides bzw. darum, das die VM so viel langsamer > ist als die HM.
In der Penne habe ich einen Win7-PC der nur mittels Chrome im Kioskmode, der nur eine Webseite mit den Vertretungsplänen anzeigt, durch einen einen Raspi-3B mit rudimentärem Raspbian ersetzt.
Basis war ein reines Konsolen-Raspbian, dem ich dann noch den lightdm, lxde und natürlich Chrome verpasst habe.
Solange die anzuzeigende Seite nocht scrollen muss, bleibt es bei einer Load von um 0.25 (Temperatur ca. 50°), wenn aber gescrollt werden muss, geht die nicht mehr unter 2 (Temperatur fast 80°)!
Ein einfacher PC mit Linux zeigt weder die große Differenz noch die hohen
Page 37 of 165 ---- Generated from net(t)forum Load-Werte.
Soviel zum Vergleich von Äpfeln und Birnen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 16:46:45 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Tja, und bei mir war es der deutlich ältere und schwächer der viel > schneller war und im verlauf der Suche habe ich wie schon gesagt, > eisfair auch direkt auf die Maschine Installiert auf der, so gewünscht, > Proxmox laufen soll.
Für Kompilieren für ältere CPUs!
Wenn du eine aktuelle Ubuntu in die VM instllierst, könnte das Kompilat wesentlich besser darauf abgestimmt sein.
IMHO verbietet sich hier jeder Vergleich zwischen eisfair und einer beliebigen anderen Distri.
Du kannst - wie auch schon Thomas schrieb - einen ganz speziellen kernel kompilieren, indem alles aktiviert ist, was für deine CPU in der VM wichtig und hilfreich ist und dann auch im Compiler für genau diese CPU optimieren lassen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Sun, 03 Mar 2019 16:53:14 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 17:33 schrieb Marcus Roeckrath:
Hallo Marcus,
> Soviel zum Vergleich von Äpfeln und Birnen. aber irgendwo muss man doch anfangen, oder doch einfach das Maul halten und nehmen was man kriegt?
Page 38 of 165 ---- Generated from net(t)forum Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 17:12:03 GMT View Forum Message <> Reply to Message Hallo,
Marcus Roeckrath wrote:
> Für Kompilieren für ältere CPUs!
Wir ...
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Sun, 03 Mar 2019 17:16:38 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Soviel zum Vergleich von Äpfeln und Birnen. > > aber irgendwo muss man doch anfangen, oder doch einfach das Maul halten > und nehmen was man kriegt?
Was soll ich sagen?
Ich habe keine Idee, weil ich sowas auch nicht nutze.
Mit einem Profiling-Tool könnte man vielleicht feststellen, welche Codeteile wieviel Zeit brauchen und dann mit deinem anderen System vergleichen.
Dann könnte man vielleicht ableiten, wo auf dem einen System mehr Zeit verbraucht wird. Ob die Erkenntnis dann Konsequenzen hat, wage ich zu bezweifeln, denn es wird bestimmt keine optimierten Anwendungen und Kernel für bestimmte CPUs oder Umgebungen geben.
Und ob eine Optimierung nun für ProxMox genau auf diesem System dann zu
Page 39 of 165 ---- Generated from net(t)forum schlechteren Leistung woanders führt, sei auch mal dahingestellt.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Gerd Walter on Sun, 03 Mar 2019 18:08:43 GMT View Forum Message <> Reply to Message Hallo Detlef,
Am 03.03.19 um 15:29 schrieb Detlef Paschke: > Am 03.03.2019 um 14:45 schrieb Gerd Walter:
>> Ich nutze nicht Proxmox aber XEN, und da habe ich folgende Zeiten mit >> e64 als paravirtualisiert:
> Nutzt Du das XEN was man bei Citrix laden kann oder sollte ich was > anderes nehmen
Ich nutze von Debian Buster die XEN 4.11 Installation.
-- Gruß Gerd
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Sun, 03 Mar 2019 19:04:06 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 17:53 schrieb Detlef Paschke: > Am 03.03.2019 um 17:33 schrieb Marcus Roeckrath: > > Hallo Marcus, > >> Soviel zum Vergleich von Äpfeln und Birnen. > > aber irgendwo muss man doch anfangen, oder doch einfach das Maul halten > und nehmen was man kriegt?
Wenn es nicht durch eigene Benchmarks, suche und Vergleiche raus zu finden ist: Ja letzteres.
Aber ich sehe das Problem auch darin das du oft Äpfel und Birnen vergleichst und kaum bis keine Angaben zur Größe und Ausstattung von Äpfeln und Birnen machst. SO kann dir keiner Helfen - der nicht direkt neben dir sitzt.
Vielleicht solltest du mal damit anfangen deine für alle Tests in frage kommende Hardware zu benamen und benennen damit man das hier
Page 40 of 165 ---- Generated from net(t)forum nachvollziehen kann. Dabei könnte 'inxi' helfen das im EIS systeminfos anzeigt. Kann man auch auf der Konsole nutzen auch ohne Farbe (die sieht hier eh keiner). Und bei echter hardware u.a. Distro mit den lstools wie lscpu, lsblk oder schau ob du in deren Repo auch inxi findest.
Als Beispiele.
Mein Haupt-VM Server:
> root@pve:~# inxi -c0 -v 4 -z > System: Host: pve Kernel: 4.15.18-10-pve x86_64 (64 bit gcc: 6.3.0) > Console: tty 0 Distro: Debian GNU/Linux 9 (stretch) > Machine: Device: server System: HP product: ProLiant DL360 G5 > Mobo: N/A model: N/A BIOS: HP v: P58 date: 07/10/2009 > CPU(s): 2 Quad core Intel Xeon E5430s (-HT-MCP-SMP-) cache: 12288 KB > flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 42667 > clock speeds: max: 2000 MHz 1: 2000 MHz 2: 2000 MHz 3: 2000 MHz > 4: 2000 MHz 5: 2000 MHz 6: 2000 MHz 7: 2000 MHz 8: 2000 MHz > Graphics: Card: Advanced Micro Devices [AMD/ATI] ES1000 bus-ID: 01:03.0 > Display Server: N/A driver: N/A > tty size: 80x37 Advanced Data: N/A for root out of X > Network: Card-1: Broadcom Limited NetXtreme II BCM5708 Gigabit Ethernet > driver: bnx2 v: 2.2.6 bus-ID: 03:00.0 > IF: eth1 state: up speed: 1000 Mbps duplex: full mac:
Mein Zweit VM-Server:
> root@pve2:~# inxi -c 0 -v4 -z > System: Host: pve2 Kernel: 4.15.18-10-pve x86_64 (64 bit gcc: 6.3.0) > Console: tty 0 Distro: Debian GNU/Linux 9 (stretch) > Machine: Device: desktop System: HP-Pavilion product: NC108AA-ABD a6724de > Mobo: PEGATRON model: VIOLET v: 3.02 > BIOS: American Megatrends v: 5.03 date: 11/05/2008 > CPU: Quad core AMD Phenom 9650 (-MCP-) cache: 2048 KB > flags: (lm nx sse sse2 sse3 sse4a svm) bmips: 18400 > clock speeds: max: 2300 MHz 1: 2300 MHz 2: 2300 MHz 3: 2300 MHz > 4: 2300 MHz > Graphics: Card: NVIDIA C78 [GeForce 9100] bus-ID: 02:00.0
Page 41 of 165 ---- Generated from net(t)forum > Display Server: N/A driver: N/A > tty size: 80x24 Advanced Data: N/A for root out of X > Network: Card-1: NVIDIA MCP77 Ethernet > driver: forcedeth port: b880 bus-ID: 00:0a.0 > IF: enp0s10 state: up speed: 100 Mbps duplex: full mac:
Und zum Vergleich, eine Eisfair-32bit VM auf dem ersten Host (pve)
> control # inxi -c 0 -v4 -z > System: Host: control Kernel: 3.16.60-eisfair-1-VIRT i686 > bits: 32 gcc: 8.1.1 > Console: tty 0 Distro: eisfair-1 > Machine: Device: qemu-or-kvm System: QEMU product: Standard PC (i440FX + PIIX 1996) v: pc-i440fx-2.12 serial: N/A > Mobo: N/A model: N/A serial: N/A > BIOS: SeaBIOS v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 > CPU: Single core Common 32-bit KVM (-UP-) > arch: Netburst Prescott rev.1 cache: 16384 KB > flags: (pae sse sse2 sse3) bmips: 5333 speed: 2666 MHz (max) > Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 > Display Server: N/A driver: N/A > tty size: 80x24 Advanced Data: N/A for root out of X > Network: Card: Red Hat Virtio network device > driver: virtio-pci port: e040 bus-ID: 00:12.0 > IF: eth0 state: up speed: N/A duplex: N/A mac:
Eine Andere E1-32bit VM auf gleichem Host aber anders konfiguriert:
> hermes # inxi -c 0 -v4 -z
Page 42 of 165 ---- Generated from net(t)forum > System: Host: hermes Kernel: 3.16.58-eisfair-1-VIRT i686 > bits: 32 gcc: 8.1.1 > Console: tty 0 Distro: eisfair-1 > Machine: Device: qemu-or-kvm System: QEMU product: Standard PC (i440FX + PIIX 1996) v: pc-i440fx-2.12 serial: N/A > Mobo: N/A model: N/A serial: N/A > BIOS: SeaBIOS v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 > CPU: Dual core Common 32-bit KVM (-MCP-) > arch: Netburst Prescott rev.1 cache: 16384 KB > flags: (pae sse sse2 sse3) bmips: 10667 > clock speeds: max: 2666 MHz 1: 2666 MHz 2: 2666 MHz > Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 > Display Server: N/A driver: N/A > tty size: 80x24 Advanced Data: N/A for root out of X > Network: Card: Red Hat Virtio network device > driver: virtio-pci port: e040 bus-ID: 00:12.0 > IF: eth0 state: up speed: N/A duplex: N/A mac:
Und eine Ubuntu-Server VM (Teils inaktiviertes Gateway) dazu:
> root@mcp:~# inxi -c 0 -v 4 -z > System: Host: mcp Kernel: 4.15.0-43-generic i686 (32 bit gcc: 7.3.0) > Console: tty 0 Distro: Ubuntu 18.04 bionic > Machine: System: QEMU product: Standard PC (i440FX + PIIX 1996) v: pc-i440fx-2.12 > Mobo: N/A model: N/A > Bios: Sea v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 > CPU: Dual core Common 32-bit KVM (-MCP-) cache: 16384 KB > flags: (pae sse sse2 sse3) bmips: 10667 > clock speeds: max: 2666 MHz 1: 2666 MHz 2: 2666 MHz > Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 > Display Server: N/A driver: N/A > tty size: 80x24 Advanced Data: N/A for root out of X > Network: Card-1: Red Hat Virtio network device > driver: virtio-pci port: e0c0 bus-ID: 00:12.0 > IF: eth0 state: up speed: -1 duplex: unknown mac:
Page 43 of 165 ---- Generated from net(t)forum > driver: virtio-pci port: e120 bus-ID: 00:15.0 > IF: eth3 state: down mac:
Also stelle ich dir mal die Frage, WAS lässt sich besser/überhaupt vergleichen und Bewerten: Das hier oder deine Angaben die leider viel zu viel offen lassen. Wie man sehen kann ist oben vom hostnamen angefangen alles wichtige dabei. Und ich stelle eben selbst überrascht fest das die inxi-version bei Ubuntu älter ist als bei debian und bei EIS höher als alle anderen. :-)
N.B. Bei Debian/Ubuntu kann man die Empfehlungen für mesa und x11 tools einfach weg lassen oder abwählen (mit aptitude) da sie hierfür nicht gebraucht werden aber gern mit installiert werden. Ebenso lm-sensors und hddtemp. Die machen in einer VM eh keinen sinn.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Hilix on Sun, 03 Mar 2019 21:53:38 GMT View Forum Message <> Reply to Message Hallo,
> aber irgendwo muss man doch anfangen, der Meinung bin ich auch. Selbst als reiner Anwender (bzgl. OS-Entwicklung) > oder doch einfach das Maul halten und nehmen was man kriegt? Das ist, meine ich, kein guter Ansatz...
Nur sollten Vergleiche zugegebenermaßen objektiver sein. Ich habe hier auf einem etwas
Page 44 of 165 ---- Generated from net(t)forum schnellerem KVM-Host folgendes (hand-)gemessen:
KVM-Host: i7-6700 (4/8),32G,6G-SSDs,Debian 9, Alle VM's mit 2 vCPU's und 2GB vMem (außer W10 m. 4 VCPU,8G vMem), Anzeige der VM via SPICE-Protokoll unter virt-manager. .. VM-Booten vom OS-Start (ohne Lilo/Grub-Waits) bis zum Login-Prompt: 1. E1 (Basis) : 23 Sek. (vHD m. virtio-scsi) 2. E64 (Basis) : 20 Sek. (vHD m. virtio-scsi) 3. Antergos (Minimal) : 5 Sek. ! (ohne X11/GUI; ist eine ArchLinux basierte Distrib.) 4. Archman : 6 Sek. (inkl. X11, OpenBOX, ArchLinux basiert). 5. Windows 10 Pro : 21 Sek. (bis zum Login-Screen).
Bemerkenswert sind die relativen, nicht die absoluten Zeiten. Beide Eisfair-Bootzeiten sind demnach ungefähr gleich.
Zu Eisfair: Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's gibt es praktisch keine Wartezeiten mehr für die vHD's.
Was mir auch auf dem in einem anderen Beitrag beschriebenen KVM-Host (älterer 2-Core Pentium (U2300/1,2GHz) sowohl bei E1- als auch E64-VM's auffällt, ist die lange Wartezeit (~15+ Sek.) bei der Meldung: "Error: Driver "pcspkr" is already registered, aborting". (2x hintereinander !) Ob das Warten genau wegen dieser Fehlermeldung entsteht oder danach, kann ich nicht sagen.
Grüße. / Hilmar.
Am 03.03.19 um 17:53 schrieb Detlef Paschke: > Am 03.03.2019 um 17:33 schrieb Marcus Roeckrath: > > Hallo Marcus, > >> Soviel zum Vergleich von Äpfeln und Birnen. > > aber irgendwo muss man doch anfangen, oder doch einfach das Maul halten > und nehmen was man kriegt? > > Viele Grüße > Detlef Paschke >
Subject: pcspkr (was: Noch mal Eisfair(64) und Proxmox (Perfomance)) Posted by kay on Sun, 03 Mar 2019 22:23:49 GMT View Forum Message <> Reply to Message
Page 45 of 165 ---- Generated from net(t)forum Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: > Driver "pcspkr" is already registered, aborting"
Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die meldung eigentlich nicht mehr auftauchen.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: pcspkr Posted by Hilix on Sun, 03 Mar 2019 23:41:01 GMT View Forum Message <> Reply to Message Hallo Kay, vielen Dank für den Tipp! :-) Fehlermeldung is weg. (Wieder was gelernt).
Allerdings: Die Wartezeit (in der gleichen Länge) an dieser Stelle bleibt bestehen.
(Bei dem an anderer Stelle beschrieben i7-6700 KVM-Host kommt diese Wartezeit nicht zum Tragen.) Es könnte natürlich auch etwas sein, HW bedingt. Vielleicht weis jemand Rat.
Gruß. / Hilmar. dmesg (Auszug) ------[ 24.886292] scsi1 : ahci [ 24.927142] scsi2 : ahci [ 25.074504] scsi3 : ahci [ 25.508197] scsi4 : ahci [ 25.606127] input: PC Speaker as /devices/platform/pcspkr/input/input4 [ 25.720121] scsi5 : ahci [ 25.772130] scsi6 : ahci [ 25.787157] ata1: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059100 irq 50 [ 25.793600] ata2: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059180 irq 50 [ 25.794840] ata3: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059200 irq 50 [ 25.796083] ata4: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059280 irq 50 [ 25.797064] ata5: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059300 irq 50 [ 25.797991] ata6: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059380 irq 50 [ 26.144561] ata1: SATA link down (SStatus 0 SControl 300) [ 26.324578] ata4: SATA link down (SStatus 0 SControl 300) [ 26.329290] ata3: SATA link down (SStatus 0 SControl 300) [ 26.365567] ata6: SATA link down (SStatus 0 SControl 300)
Page 46 of 165 ---- Generated from net(t)forum [ 26.369663] ata5: SATA link down (SStatus 0 SControl 300) [ 26.429385] ata2: SATA link down (SStatus 0 SControl 300) ====> ~15+ Sek. warten [ 40.005746] udevd[1539]: could not read from '/sys/module/acpi_cpufreq/initstate': No such device [ 47.201684] ppdev: user-space parallel port driver [ 47.297092] sound hdaudioC0D0: autoconfig: line_outs=1 (0x3/0x0/0x0/0x0/0x0) type:line ------
?? CPU Pentium U2300 kann keine CPUfreg ändern ?? Kann man das auch blacklisten?
Am 03.03.19 um 23:23 schrieb Kay Martinen: > Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: >> Driver "pcspkr" is already registered, aborting" > > Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort > 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die > meldung eigentlich nicht mehr auftauchen. > > > Kay >
Subject: Re: pcspkr (et al) Posted by Hilix on Mon, 04 Mar 2019 00:10:41 GMT View Forum Message <> Reply to Message Hallo, mit dem Tipp von Kay (danke) habe ich die Module acpi-cpufreq und ppdev geblacklistet. Die entspr. Meldungen sind weg.
Die Wartezeit allerdings bleibt. Jetzt sehen die dmesg - Meldungen in dieser Gegend so aus: dmesg (Auszug): ------[ 24.955895] ata1: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059100 irq 49 [ 24.956952] ata2: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059180 irq 49 [ 24.970569] ata3: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059200 irq 49 [ 24.973499] ata4: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059280 irq 49 [ 24.975091] ata5: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059300 irq 49 [ 24.975965] ata6: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059380 irq 49 [ 25.175388] snd_hda_intel 0000:00:04.0: irq 50 for MSI/MSI-X [ 25.332232] ata3: SATA link down (SStatus 0 SControl 300) [ 25.347757] ata4: SATA link down (SStatus 0 SControl 300) [ 25.355963] ata5: SATA link down (SStatus 0 SControl 300) [ 25.357494] ata6: SATA link down (SStatus 0 SControl 300) [ 25.434961] ata1: SATA link down (SStatus 0 SControl 300)
Page 47 of 165 ---- Generated from net(t)forum [ 25.450219] ata2: SATA link down (SStatus 0 SControl 300) [ 25.595441] input: PC Speaker as /devices/platform/pcspkr/input/input4 ^^^^^^^^^
Man beachte die Zeitdifferenz in den eckigen Klammern! Da muss noch was anderes passieren?? Vielen Dank für eine Info.
Gruß. / Hilmar.
Am 04.03.19 um 00:41 schrieb Hilmar Böhm: > Hallo Kay, > > vielen Dank für den Tipp! :-) > Fehlermeldung is weg. (Wieder was gelernt). > > Allerdings: Die Wartezeit (in der gleichen Länge) an dieser Stelle bleibt bestehen. > > (Bei dem an anderer Stelle beschrieben i7-6700 KVM-Host kommt diese Wartezeit nicht zum Tragen.) > Es könnte natürlich auch etwas sein, HW bedingt. > Vielleicht weis jemand Rat. > > Gruß. / Hilmar. > > dmesg (Auszug) > ------> [ 24.886292] scsi1 : ahci > [ 24.927142] scsi2 : ahci > [ 25.074504] scsi3 : ahci > [ 25.508197] scsi4 : ahci > [ 25.606127] input: PC Speaker as /devices/platform/pcspkr/input/input4 > [ 25.720121] scsi5 : ahci > [ 25.772130] scsi6 : ahci
Page 48 of 165 ---- Generated from net(t)forum > [ 25.787157] ata1: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059100 irq 50 > [ 25.793600] ata2: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059180 irq 50 > [ 25.794840] ata3: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059200 irq 50 > [ 25.796083] ata4: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059280 irq 50 > [ 25.797064] ata5: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059300 irq 50 > [ 25.797991] ata6: SATA max UDMA/133 abar m4096@0xfc059000 port 0xfc059380 irq 50 > [ 26.144561] ata1: SATA link down (SStatus 0 SControl 300) > [ 26.324578] ata4: SATA link down (SStatus 0 SControl 300) > [ 26.329290] ata3: SATA link down (SStatus 0 SControl 300) > [ 26.365567] ata6: SATA link down (SStatus 0 SControl 300) > [ 26.369663] ata5: SATA link down (SStatus 0 SControl 300) > [ 26.429385] ata2: SATA link down (SStatus 0 SControl 300) > ====> ~15+ Sek. warten > [ 40.005746] udevd[1539]: could not read from '/sys/module/acpi_cpufreq/initstate': No such device > [ 47.201684] ppdev: user-space parallel port driver > [ 47.297092] sound hdaudioC0D0: autoconfig: line_outs=1 (0x3/0x0/0x0/0x0/0x0) type:line > ------> > ?? CPU Pentium U2300 kann keine CPUfreg ändern ?? > Kann man das auch blacklisten? > > > Am 03.03.19 um 23:23 schrieb Kay Martinen: >> Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: >>> Driver "pcspkr" is already registered, aborting" >> >> Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort >> 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die >> meldung eigentlich nicht mehr auftauchen. >> >> >> Kay >>
Subject: Re: pcspkr Posted by kay on Mon, 04 Mar 2019 01:10:40 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 00:41 schrieb Hilmar Böhm: > Fehlermeldung is weg. (Wieder was gelernt). > > Allerdings: Die Wartezeit (in der gleichen Länge) an dieser Stelle
Page 49 of 165 ---- Generated from net(t)forum > bleibt bestehen. > > (Bei dem an anderer Stelle beschrieben i7-6700 KVM-Host kommt diese > Wartezeit nicht zum Tragen.) > Es könnte natürlich auch etwas sein, HW bedingt. > Vielleicht weis jemand Rat.
Hmm, direkt danach werden doch die Dateisysteme gemountet. D.h. da muß die umschaltung von der initramfs auf das root-dateisystem statt finden. Das könnte diese Zeit erklären. Bei KVM-Host meinst du die VMs darin die diese Wartezeit nicht hätten? Bei mir wird da AFAIR auch nur kurz gewartet und auf Echter Hardware länger. Scheint mir logisch. Einen Beweis habe ich aber auch nicht.
> dmesg (Auszug) > ------> [ 26.429385] ata2: SATA link down (SStatus 0 SControl 300) > ====> ~15+ Sek. warten > [ 40.005746] udevd[1539]: could not read from > '/sys/module/acpi_cpufreq/initstate': No such device > > ?? CPU Pentium U2300 kann keine CPUfreg ändern ??
Warum, wenn er es nicht kann sollte das modul auch nicht geladen werden. Es sei denn als Voraussetzung für ein anderes modul.
Die Meldung kommt ja auch von udev und sagt das initstate nicht gelesen werden kann. Hast du den schon blacklistet oder mal versucht den zu laden um zu sehen ob sich die Meldung beim booten ändert?
IMHO gibt es ein cpufreq tool mit dem man den governor umschalten kann, eventuell auch auf "none" oder so. Wäre vielleicht der bessere/korrekte Weg.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 06:23:57 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Was mir auch auf dem in einem anderen Beitrag beschriebenen KVM-Host > (älterer 2-Core Pentium (U2300/1,2GHz) sowohl bei E1- als auch E64-VM's > auffällt, ist die lange Wartezeit (~15+ Sek.) bei der Meldung: "Error:
Page 50 of 165 ---- Generated from net(t)forum > Driver "pcspkr" is already registered, aborting". (2x hintereinander !) Ob > das Warten genau wegen dieser Fehlermeldung entsteht oder danach, kann ich > nicht sagen.
Ich habe den auf meiner realen hardware blacklisted.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 06:36:39 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Bc3b6hm wrote:
> Die Wartezeit allerdings bleibt. Jetzt sehen die dmesg - Meldungen in > dieser Gegend so aus: > > dmesg (Auszug): > ------> [ 25.175388] snd_hda_intel > [ 25.595441] input: PC Speaker as > [ /devices/platform/pcspkr/input/input4 > ^^^^^^^^^ >
Vielleicht beim Laden des ganzen Soundgeraffels?
Da ich Sound auf meinem Server nicht brauche, habe ich das auch blacklited, wobei man da mehr aufwand treiben muss, da sich da sonst immer etwas wegen der Abhängigkeiten lädt: eis # cat /etc/modprobe.d/50-sound-blacklist.conf blacklist snd-wavefront blacklist snd-cs4236 blacklist snd-opl3-lib blacklist snd-hwdep blacklist snd-wss-lib blacklist snd-mpu401-uart blacklist snd-rawmidi blacklist snd-seq-device blacklist snd-pcsp blacklist snd-pcm blacklist snd-timer blacklist snd blacklist soundcore
Page 51 of 165 ---- Generated from net(t)forum install soundcore /bin/false
Welche Module zu blaclklisten sind, hängt natürlich vom eigenen System ab.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Hilix on Mon, 04 Mar 2019 10:56:05 GMT View Forum Message <> Reply to Message Hallo Marcus, vielen Dank für Deine Sound-Blacklist. Sound ist bei mir jetzt auch (entspr.) geblacklistet.
Dennoch, die Wartezeit bleibt! dmesg (Auszug) ------[ 24.992822] ata1: SATA link down (SStatus 0 SControl 300) [ 24.996589] ata2: SATA link down (SStatus 0 SControl 300) [ 25.000544] ata3: SATA link down (SStatus 0 SControl 300) [ 25.043818] ata6: SATA link down (SStatus 0 SControl 300) [ 25.059426] ata5: SATA link down (SStatus 0 SControl 300) [ 25.164534] ata4: SATA link down (SStatus 0 SControl 300)
Jetzt kommen (auf das
Das Wait könnte aber auch auch von Aktionen davor kommen oder von einer Aktion, die gar nicht angezeigt wird (was hätte ich da noch für eine Chance?).
Vielen Dank für eine Info oder Idee. Gruß. / Hilmar.
Am 04.03.19 um 07:36 schrieb Marcus Roeckrath: > Hallo Hilmar, >
Page 52 of 165 ---- Generated from net(t)forum > Hilmar Bc3b6hm wrote: > >> Die Wartezeit allerdings bleibt. Jetzt sehen die dmesg - Meldungen in >> dieser Gegend so aus: >> >> dmesg (Auszug): >> ------>> [ 25.175388] snd_hda_intel >> [ 25.595441] input: PC Speaker as >> [ /devices/platform/pcspkr/input/input4 >> ^^^^^^^^^ >>
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 11:48:44 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
------> [ 24.992822] ata1: SATA link down (SStatus 0 SControl 300)
Page 53 of 165 ---- Generated from net(t)forum > [ 24.996589] ata2: SATA link down (SStatus 0 SControl 300) > [ 25.000544] ata3: SATA link down (SStatus 0 SControl 300) > [ 25.043818] ata6: SATA link down (SStatus 0 SControl 300) > [ 25.059426] ata5: SATA link down (SStatus 0 SControl 300) > [ 25.164534] ata4: SATA link down (SStatus 0 SControl 300) >
Solche Re-Mounts sehe ich nur auf meinem eis64 und dem Schulserver, aber nicht auf meinem privaten eis1-Produktiv-Server.
Könnte mit den Devices zusammenhängen: Letzterer arbeitet noch mit Standard-IDE (hd-Devices) die anderen mit sd-Devices.
Sieht also erstmal normal mit den Remounts aus.
Auf den Systemen mit den Remounts wird zwischen Erst- und RemounT das Netzwerkmodul geladen.
Könnte das nicht so richtig hochkommen?
Wäre es eine Option auch dieses mal Blackzulisten oder verlierst du dann den Zugriff auf die Kiste?
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Mon, 04 Mar 2019 12:26:08 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 20:04 schrieb Kay Martinen:
Hallo Kay,
> Vielleicht solltest du mal damit anfangen deine für alle Tests in frage > kommende Hardware zu benamen und benennen damit man das hier > nachvollziehen kann.
Page 54 of 165 ---- Generated from net(t)forum kein Problem, hatte ich im neuen Thread in der Tat noch nicht präzisiert. Hier noch mal ganz aktuelle Werte, alle aktuellen stabilen Updates gemacht.
Der Proxmox selbst: root@Proxmox:~# inxi -c0 -v 4 -z System: Host: Proxmox Kernel: 4.15.18-11-pve x86_64 (64 bit gcc: 6.3.0) Console: tty 0 Distro: Debian GNU/Linux 9 (stretch) Machine: Device: other-vm? System: Supermicro product: X7DB8 v: 0123456789 Mobo: Supermicro model: X7DB8 v: PCB Version BIOS: Phoenix v: 2.1c date: 07/04/2011 CPU(s): 2 Quad core Intel Xeon X5460s (-HT-MCP-SMP-) cache: 12288 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 50664 clock speeds: max: 3166 MHz 1: 3166 MHz 2: 3166 MHz 3: 3166 MHz 4: 3166 MHz 5: 3166 MHz 6: 3166 MHz 7: 3166 MHz 8: 3166 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] ES1000 bus-ID: 0b:01.0 Display Server: N/A driver: N/A tty size: 237x63 Advanced Data: N/A for root out of X Network: Card-1: Intel 80003ES2LAN Gigabit Ethernet Controller (Copper) driver: e1000e v: 3.4.1.1-NAPI port: 3000 bus-ID: 06:00.0 IF: enp6s0f0 state: up speed: 1000 Mbps duplex: full mac:
Eine frisch aufgesetzte eisfair64 VM ohne Pakete:
Welcome to eisfair! base : 2.8.12
Page 55 of 165 ---- Generated from net(t)forum eiskernel: 3.36.0 (3.16.62-eisfair-64-VIRT) eis64-test # time eisman update (Re)building package database ... [100%] completed! Done! (Re)building outdated database ... please wait! Done! real 3m46.331s user 2m35.168s sys 2m4.640s eis64-test # inxi -c0 -v 4 -z System: Host: eis64-test Kernel: 3.16.62-eisfair-64-VIRT x86_64 bits: 64 gcc: 8.1.1 Console: tty 1 Distro: eisfair-64 Machine: Device: qemu-or-kvm System: QEMU product: Standard PC (i440FX + PIIX 1996) v: pc-i440fx-2.12 serial: N/A Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 CPU: Quad core Common KVM (-MCP-) arch: Netburst Prescott rev.1 cache: 16384 KB flags: (lm nx sse sse2 sse3) bmips: 25333 clock speeds: max: 3166 MHz 1: 3166 MHz 2: 3166 MHz 3: 3166 MHz 4: 3166 MHz Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 Display Server: N/A driver: N/A tty size: 80x24 Advanced Data: N/A for root out of X Network: Card: Red Hat Virtio network device driver: virtio-pci port: e140 bus-ID: 00:12.0 IF: net0 state: up speed: N/A duplex: N/A mac:
Eine frisch aufgesetzte eisfair1 VM ohne Pakete:
Welcome to eisfair! base : 2.8.12 eiskernel: 3.24.0 (3.16.62-eisfair-1-VIRT) eis1-test # time eisman update
Page 56 of 165 ---- Generated from net(t)forum (Re)building package database ... [100%] completed! Done! (Re)building outdated database ... please wait! Done! real 1m51.311s user 0m26.848s sys 0m47.996s eis1-test # inxi -c0 -v 4 -z System: Host: eis1-test Kernel: 3.16.62-eisfair-1-VIRT i686 bits: 32 gcc: 8.1.1 Console: tty 1 Distro: eisfair-1 Machine: Device: qemu-or-kvm System: QEMU product: Standard PC (i440FX + PIIX 1996) v: pc-i440fx-2.12 serial: N/A Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 CPU: Quad core Common KVM (-MCP-) arch: Netburst Prescott rev.1 cache: 16384 KB flags: (lm nx pae sse sse2 sse3) bmips: 25333 clock speeds: max: 3166 MHz 1: 3166 MHz 2: 3166 MHz 3: 3166 MHz 4: 3166 MHz Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 Display Server: N/A driver: N/A tty size: 237x63 Advanced Data: N/A for root out of X Network: Card: Red Hat Virtio network device driver: virtio-pci port: e140 bus-ID: 00:12.0 IF: net0 state: up speed: N/A duplex: N/A mac:
Der ubuntu-server als VM, welcher nach meinem empfinden durchaus normal zu arbeiten scheint. detlef@ubuntu:~$ inxi -c0 -v 4 -z System: Host: ubuntu Kernel: 4.18.0-15-generic x86_64 bits: 64 compiler: gcc v: 8.2.0 Console: tty 0 Distro: Ubuntu 18.10 (Cosmic Cuttlefish) Machine: Type: Kvm System: QEMU product: Standard PC (i440FX + PIIX, 1996) v: pc-i440fx-2.12 serial:
Page 57 of 165 ---- Generated from net(t)forum rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 CPU: Topology: Quad Core model: Common KVM bits: 64 type: MCP arch: Netburst Presler rev: 1 L2 cache: 16.0 MiB flags: lm nx pae sse sse2 sse3 bogomips: 25333 Speed: 3167 MHz min/max: N/A Core speeds (MHz): 1: 3167 2: 3167 3: 3167 4: 3167 Graphics: Device-1: driver: N/A bus ID: 00:02.0 Display: server: No display server data found. Headless machine? tty: 237x63 Message: Advanced graphics data unavailable in console. Try -G --display Network: Device-1: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus v: N/A port: N/A bus ID: 00:01.3 Device-2: Red Hat Virtio network driver: virtio-pci v: N/A port: e140 bus ID: 00:12.0 IF: ens18 state: up speed: -1 duplex: unknown mac:
Zum Vergleich mein derzeitiger eisfair1 auf HW, ja ich weiß, andere Hardware aber schwächer und zudem Dienste ohne Ende. (apache, samba, mail, bfb, clam, fax, antispam.....)
Welcome to eisfair! base : 2.8.12 eiskernel: 3.24.0 (3.16.62-eisfair-1-PAE) eisfair # time eisman update (Re)building package database ... [100%] completed! Done! (Re)building outdated database ... please wait! Done! real 1m5.558s user 0m8.456s sys 0m4.532s eisfair # inxi -c0 -v 4 -z System: Host: eisfair Kernel: 3.16.62-eisfair-1-PAE i686 bits: 32 gcc: 8.1.1 Console: tty 0 Distro: eisfair-1 Machine: Device: other-vm? System: Supermicro product: X6DH8 v:
Page 58 of 165 ---- Generated from net(t)forum 0123456789 serial:
Im direkten Vergleich würde ich Einschätzen, dass die Unterschiede zwischen eis1-HW und eis1-VM zu vernachlässigen sind und als Verlust durch die virtualisierung zu verrechnen wären aber bei eis64-VM erachte ich es schon für auffällig.
Was evtl. noch interessant ist, ich sollte mal Tests mit weniger Kernen/Sockeln machen. Das habe ich jeweils von einem Kern bis vier Kerne in allen Sockel/Kernel konstellationen durchgespielt.
Die jeweilige Performance von eisfair64 hat sich dabei aber wenn überhaupt nur geringfügig geändert. Einzig die Prozessorauslastung in der Proxmox-Konsole hat sich entsprechend verändert.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209
Page 59 of 165 ---- Generated from net(t)forum Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Mon, 04 Mar 2019 13:08:22 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 13:26 schrieb Detlef Paschke: > kein Problem, hatte ich im neuen Thread in der Tat noch nicht > präzisiert. Hier noch mal ganz aktuelle Werte, alle aktuellen stabilen > Updates gemacht.
Als "Nachschlag" evtl. noch die nahezu fertig konfigurierte also benutzbare eisfair64-VM auf der selben Maschine.
Welcome to eisfair! base : 2.8.12 eiskernel: 3.36.0 (3.16.62-eisfair-64-VIRT)
Eisfair64 # time eisman update (Re)building package database ... [100%] completed! Done! (Re)building outdated database ... please wait! Done! real 4m49.558s user 3m19.256s sys 2m43.124s Eisfair64 # inxi -c0 -v 4 -z System: Host: Eisfair64 Kernel: 3.16.62-eisfair-64-VIRT x86_64 bits: 64 gcc: 8.1.1 Console: tty 1 Distro: eisfair-64 Machine: Device: qemu-or-kvm System: Supermicro product: X7DB8 v: 2.00 serial: N/A Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS v: rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org date: 04/01/2014 CPU: Quad core Common KVM (-MCP-) arch: Netburst Prescott rev.1 cache: 16384 KB flags: (lm nx sse sse2 sse3) bmips: 25333 clock speeds: max: 3166 MHz 1: 3166 MHz 2: 3166 MHz 3: 3166 MHz 4: 3166 MHz Graphics: Card: Device 1234:1111 bus-ID: 00:02.0 Display Server: N/A driver: N/A tty size: 237x63 Advanced Data: N/A for root out of X Network: Card: Red Hat Virtio network device driver: virtio-pci port: e140 bus-ID: 00:12.0 IF: net0 state: up speed: N/A duplex: N/A mac:
Page 60 of 165 ---- Generated from net(t)forum Drives: HDD Total Size: 1014.8GB (0.6% used) ID-1: /dev/sdb model: QEMU_HARDDISK size: 73.2GB ID-2: /dev/sdc model: QEMU_HARDDISK size: 300.0GB ID-3: /dev/sdd model: QEMU_HARDDISK size: 300.0GB ID-4: /dev/sde model: QEMU_HARDDISK size: 147.1GB ID-5: /dev/sdf model: QEMU_HARDDISK size: 160.0GB ID-6: /dev/sda model: QEMU_HARDDISK size: 34.4GB ID-7: /dev/hdc model: QEMU DVD-ROM size: 0.1GB Partition: ID-1: / size: 32G used: 1.2G (5%) fs: ext4 dev: /dev/sda3 ID-2: /boot size: 43M used: 12M (30%) fs: ext4 dev: /dev/sda1 ID-3: swap-1 size: 0.13GB used: 0.00GB (0%) fs: swap dev: /dev/sda2 Info: Processes: 121 Uptime: 0:24 Memory: 924.3/7979.5MB Init: SysVinit runlevel: 2 Gcc sys: N/A Client: Shell (bash 4.4.231) inxi: 2.3.56 Eisfair64 #
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 13:26:47 GMT View Forum Message <> Reply to Message Hallo Detlef,
>> Soviel zum Vergleich von Äpfeln und Birnen. > > aber irgendwo muss man doch anfangen, oder doch einfach das Maul halten > und nehmen was man kriegt? ich habe diesen Riesen-Fred zwar nur zu Teil gelesen, aber ich kenne diese (vermeintlich) träge Verhalten auch.
Tue Dir (und den anderen Protagonisten) einmal den Gefallen und führe die Tests nicht per Proxmox-Konsole durch, sondern logge Dich per ssh ein und arbeite die Versuche nochmals ab.
Gruß Heinz-Peter
Subject: Re: pcspkr (et al) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 13:32:36 GMT
Page 61 of 165 ---- Generated from net(t)forum View Forum Message <> Reply to Message Hallo Marcus,
> ------>> [ 24.992822] ata1: SATA link down (SStatus 0 SControl 300) >> [ 24.996589] ata2: SATA link down (SStatus 0 SControl 300) >> [ 25.000544] ata3: SATA link down (SStatus 0 SControl 300) >> [ 25.043818] ata6: SATA link down (SStatus 0 SControl 300) >> [ 25.059426] ata5: SATA link down (SStatus 0 SControl 300) >> [ 25.164534] ata4: SATA link down (SStatus 0 SControl 300) >>
EXT3-fs (hda3): error: couldn't mount because of unsupported optional features (2c0)
Ist auch nicht weiter verwunderlich, schließlich handelt es sich um ein ext4-FS. ;)
Könnte das die Unterschiede bei Dir erklären? Ist die heimische Produktivmaschine schon länger im Einsatz und noch auf ext3?
Page 62 of 165 ---- Generated from net(t)forum Gruß Heinz-Peter
Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 13:35:23 GMT View Forum Message <> Reply to Message Hallo Kay,
>> Driver "pcspkr" is already registered, aborting" > > Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort > 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die > meldung eigentlich nicht mehr auftauchen. bei mir taucht sie trotzdem auf. ;( Das ist umso erstaunlicher, als es sich um eine VM handelt, der ich beim Start gar keine Soundmaschinerie mit auf den Weg gebe.
Gruß Heinz-Peter
Subject: Re: pcspkr Posted by Marcus Roeckrath on Mon, 04 Mar 2019 13:42:27 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>>> Driver "pcspkr" is already registered, aborting" >> >> Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort >> 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die >> meldung eigentlich nicht mehr auftauchen. > > bei mir taucht sie trotzdem auf. ;( > Das ist umso erstaunlicher, als es sich um eine VM handelt, der ich beim > Start gar keine Soundmaschinerie mit auf den Weg gebe.
IMHO hat das nichts mit Soundhardware zu tun, sondern ist der "Mainboard-Piepser".
-- Gruss Marcus
Page 63 of 165 ---- Generated from net(t)forum Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 13:53:03 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Solche Re-Mounts sehe ich nur auf meinem eis64 und dem Schulserver, aber >> nicht auf meinem privaten eis1-Produktiv-Server. >> >> Könnte mit den Devices zusammenhängen: Letzterer arbeitet noch mit >> Standard-IDE (hd-Devices) die anderen mit sd-Devices. >> >> Sieht also erstmal normal mit den Remounts aus. >> >> Auf den Systemen mit den Remounts wird zwischen Erst- und RemounT das >> Netzwerkmodul geladen. >> >> Könnte das nicht so richtig hochkommen? >> >> Wäre es eine Option auch dieses mal Blackzulisten oder verlierst du dann >> den Zugriff auf die Kiste? > > solche remounts habe ich auch, aber das hat nichts mit der Netzanbindung > zu tun. Vorher gibt es solche Zeilen:
Das ist klar, mir ging es nur darum zu sehen, was alles zwischen dem Erst- und diesem Remount noch so passiert.
In etwa folgendes wird an dieser Stelle im Initprozess gestartet: udev swap checkfs mountfs
Das Netzwerkmodul wird von udev geladen, daher meine Idee, das Netzwerkmodul zu blacklisten, wenn man sich dadurch nicht von der VM aussperrt.
Oder macht der einen Filesystemncheck (checkfs)?
Man könnte natprlich auch mal in die Startskripte an dieser Stelle echos einfügen, um zu sehen, welches hier aufhält.
Die Reihenfolge findet man in /etc/rc2.d und beginnt mit S03udev.
Die Skripte liegen selbst in /etc/init.d; vor Änderungen sichern.
> EXT3-fs (hda3): error: couldn't mount because of unsupported optional > features (2c0) >
Page 64 of 165 ---- Generated from net(t)forum > Ist auch nicht weiter verwunderlich, schließlich handelt es sich um ein > ext4-FS. ;)
Ja, das ist das Probing des Dateisystems durch den Kernel - völlig normal.
> Könnte das die Unterschiede bei Dir erklären? Ist die heimische > Produktivmaschine schon länger im Einsatz und noch auf ext3?
Ja, das auch, die Kiste ist Uralt; nicht die Hardware selbst, die ist zwar auch schon gut 10 Jahre abgehangen, die Installation selbst hat aber mehr als 15 Jahre auf dem Buckel - und rennt.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Mon, 04 Mar 2019 14:07:22 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 14:26 schrieb Heinz-Peter Faasen: > Hallo Detlef,
Hallo Heinz-Peter,
> > ich habe diesen Riesen-Fred zwar nur zu Teil gelesen, aber ich kenne > diese (vermeintlich) träge Verhalten auch. das ist schon der zweite und schon wieder solch ein Monster geworden.
> Tue Dir (und den anderen Protagonisten) einmal den Gefallen und führe > die Tests nicht per Proxmox-Konsole durch, sondern logge Dich per ssh > ein und arbeite die Versuche nochmals ab.
Das ist alles schon erledigt. Auf der Proxmox noVNC ist die Ausgabe bei Eisfair von Hause aus extrem langsam. Das haben mir auch andere Proxmox-User bestätigt. Das auffällig langsame Update der DB und träge Installationen scheinen damit aber nicht zusammen zu hängen. Das ist auch per ssh so.
> Gruß > Heinz-Peter >
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf
Page 65 of 165 ---- Generated from net(t)forum http://www.schabau.goip.de
Subject: Re: pcspkr (et al) Posted by Hilix on Mon, 04 Mar 2019 14:47:23 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 04.03.19 um 12:48 schrieb Marcus Roeckrath: > Solche Re-Mounts sehe ich nur auf meinem eis64 und dem Schulserver, aber > nicht auf meinem privaten eis1-Produktiv-Server. > > Könnte mit den Devices zusammenhängen: Letzterer arbeitet noch mit > Standard-IDE (hd-Devices) die anderen mit sd-Devices. das habe ich nicht verstanden... Btw. der Host läuft auf einer SSD (3G-SATA, aber wahrscheinlich doch schneller als eine herkömmliche HD).
Die Bildschirm-Meldungen beim Booten selbst und die Meldungen des "dmesg" unterscheiden sich. Ich habe mal die Meldungen beim Booten abgetippt (Gibt es eigentlich kein gpm o.ä.?):
------.... Adding 131068k swap on /dev/sda2. Priority:-1 ectents:1 across:131068k FS * Mounting root file system in read-only mode EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro * Checking file Systems... fsck from util-linux 2.28 /dev/sda3: clean, 30572/644640 files, 207092/2573563 blocks /dev/sda1: clean, 20/12288 files, 22649/49152 blocks * Remounting root file system on read-write mode... EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro * Mounting remaining file systems... / : ignored EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: errors=remount-ro /boot : successfully mounted none : ignored /proc : already mounted /media/floppy : ignored /media/cdrom : ignored /dev/pts : successfully mounted /sys : already mounted /run/shm : successfully mounted /run : already mounted /dev : already mounted EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,acl,user_xattr * Setting console mode to Unicode (UTS-8)......
Page 66 of 165 ---- Generated from net(t)forum ------
Wie man sieht, wird (zumind.) das Root-FS fsck'ed und davor ro und danch wieder rw gemounted.
Normalerweise geht das mounten eines sauberen (clean) FS auch bei einem langsamen System (wie hier) schnell. Wenn es länger dauert, könnte das darauf hindeuten, dass das FS beim vorherigen Shutdown nicht sauber dismounted wurde(?). Ich habe mal testweise die vHD dieses Systems als sdb an eine andere Eisfair-VM am gleichen Host gehängt und ein
# time fsck -y -f /dev/sdb3 durchgeführt: ------real 0m1.404s user 0m0.564s sys 0m0.608s ------Das sieht gut aus und es kann die lange Wartezeit nicht erklären.
Wo könnte ich noch suchen?
Grüße. / Hilmar.
Subject: Re: pcspkr (et al) Posted by Hilix on Mon, 04 Mar 2019 14:57:27 GMT View Forum Message <> Reply to Message ....
Am 04.03.19 um 12:48 schrieb Marcus Roeckrath: > Auf den Systemen mit den Remounts wird zwischen Erst- und RemounT das > Netzwerkmodul geladen. > > Könnte das nicht so richtig hochkommen? > > Wäre es eine Option auch dieses mal Blackzulisten oder verlierst du dann den > Zugriff auf die Kiste? > das habe ich, glaub ich, vergessen zu erwähnen: virtio-net geblacklistet. Keine Veränderung der Wartezeit! Gruß./Hilmar.
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 15:03:22 GMT View Forum Message <> Reply to Message
Page 67 of 165 ---- Generated from net(t)forum Halo Hilmar,
Hilmar Böhm wrote:
>> Solche Re-Mounts sehe ich nur auf meinem eis64 und dem Schulserver, aber >> nicht auf meinem privaten eis1-Produktiv-Server. >> >> Könnte mit den Devices zusammenhängen: Letzterer arbeitet noch mit >> Standard-IDE (hd-Devices) die anderen mit sd-Devices. > > das habe ich nicht verstanden...
Ich habe nur versucht, auf meinen Systemen auch den Bereich in der dmesg-Ausgabe zu identifizieren, in denen es bei dir so lange hängt - wegen der fehlenden Remounts ging das auf meinem Produktivsystem nicht - um mehr ging es nicht.
> Btw. der Host läuft auf einer SSD (3G-SATA, aber wahrscheinlich doch > schneller als eine herkömmliche HD).
Irgendwelche HD-Vorgänge - außer einem echten Check - sollten kaum für 22 Sekunden Zeitverschwendung verantwortlich sein.
> Die Bildschirm-Meldungen beim Booten selbst und die Meldungen des "dmesg" > unterscheiden sich. Ich habe mal die Meldungen beim Booten abgetippt (Gibt > es eigentlich kein gpm o.ä.?):
Und zwischen welchen Meldungen ist hier die lange Pause?
> fsck from util-linux 2.28 > /dev/sda3: clean, 30572/644640 files, 207092/2573563 blocks > /dev/sda1: clean, 20/12288 files, 22649/49152 blocks > > Wie man sieht, wird (zumind.) das Root-FS fsck'ed und davor ro und danch > wieder rw gemounted.
Die werden dann aber sofort als clean erkannt, also findet kein echter Check statt.
> Wo könnte ich noch suchen?
Ich würde vermutlich doch mal in alle Startskripte ab S03udev bis S25ip-eth in den jeweiligen Start-Zweig zu Beginn ein echo $(date) "Start startskriptname" und am Ende des SAtart-Zweiges echo $(date) "Ende startskriptname" reinsetzen.
Page 68 of 165 ---- Generated from net(t)forum Bitte die entsprechenden Startskripte vorher sichern.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 15:04:26 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
>> Auf den Systemen mit den Remounts wird zwischen Erst- und RemounT das >> Netzwerkmodul geladen. >> >> Könnte das nicht so richtig hochkommen? >> >> Wäre es eine Option auch dieses mal Blackzulisten oder verlierst du dann >> den Zugriff auf die Kiste? >> > das habe ich, glaub ich, vergessen zu erwähnen: virtio-net geblacklistet. > Keine Veränderung der Wartezeit!
Ok, das wäre somit auch ausgeschlossen.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Hilix on Mon, 04 Mar 2019 15:24:27 GMT View Forum Message <> Reply to Message ....habe auch mal virtio-net geblacklistet und dann mit
# modprobe virtio-net # /etc/init.d/ip-eth start das Netzwerk händisch geladen.
Danach war - ohne Verzögerung, sofort - das Netzwerkdevice inkl. IP-Adresse vom DHCP-Server vorhanden (ip a).
Das kann es also wirklich nicht gewesen sein. Ich werde jetzt mal Deinen Vorschlag mit den Startup-Skripts verfolgen.
Gruß. / Hilmar.
Page 69 of 165 ---- Generated from net(t)forum Am 04.03.19 um 16:04 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >>> Auf den Systemen mit den Remounts wird zwischen Erst- und RemounT das >>> Netzwerkmodul geladen. >>> >>> Könnte das nicht so richtig hochkommen? >>> >>> Wäre es eine Option auch dieses mal Blackzulisten oder verlierst du dann >>> den Zugriff auf die Kiste? >>> >> das habe ich, glaub ich, vergessen zu erwähnen: virtio-net geblacklistet. >> Keine Veränderung der Wartezeit! > > Ok, das wäre somit auch ausgeschlossen. >
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 16:07:43 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> ...habe auch mal virtio-net geblacklistet und dann mit > > # modprobe virtio-net > # /etc/init.d/ip-eth start > > das Netzwerk händisch geladen. > > Danach war - ohne Verzögerung, sofort - das Netzwerkdevice inkl. > IP-Adresse vom DHCP-Server vorhanden (ip a).
Ok.
> Das kann es also wirklich nicht gewesen sein. Ich werde jetzt mal Deinen > Vorschlag mit den Startup-Skripts verfolgen.
Alles andere wäre weiter stochern im Nebel. Vielleicht bringen uns die Start-End-Zeiten der Initskripte der Ursache näher.
-- Gruss Marcus
Page 70 of 165 ---- Generated from net(t)forum Subject: Re: pcspkr (et al) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 16:28:09 GMT View Forum Message <> Reply to Message Hallo Marcus,
>> solche remounts habe ich auch, aber das hat nichts mit der Netzanbindung >> zu tun. Vorher gibt es solche Zeilen: > Das ist klar, mir ging es nur darum zu sehen, was alles zwischen dem Erst- > und diesem Remount noch so passiert. der remount hält den boot-Prozess nicht wesentlich auf. Nur vor dem gescheiterten ext3-Versuch gibt es die 10s Wartezeit, von denen hier schon mal gesprochen wurde:
[ 14.915268] hid-generic 0003:80EE:0021.0001: input: USB HID v1.10 Mouse [VirtualBox USB Tablet] on usb-0000:00:06.0-1/input0 [ 25.452234] EXT3-fs (hda3): error: couldn't mount because of unsupported optional features (2c0) [ 25.527814] EXT2-fs (hda3): error: couldn't mount because of unsupported optional features (2c4)
Ist aber bei einem Server eigentlich nicht wirklich schlimm. ;)
Gruß Heinz-Peter
Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 16:33:23 GMT View Forum Message <> Reply to Message Hi Marcus,
>>> Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort >>> 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die >>> meldung eigentlich nicht mehr auftauchen. >> >> bei mir taucht sie trotzdem auf. ;( >> Das ist umso erstaunlicher, als es sich um eine VM handelt, der ich beim >> Start gar keine Soundmaschinerie mit auf den Weg gebe. > > IMHO hat das nichts mit Soundhardware zu tun, sondern ist der > "Mainboard-Piepser". schon klar. Ich wollte nur deutlich machen, dass auch aus der "Ecke" nichts kommen kann. ;)
Ich habe in der base bzgl. des Moduls
1 pcspkr no
Page 71 of 165 ---- Generated from net(t)forum gesetzt, das bringt aber nichts. Auch das Anlegen einer Datei in modprobe.d mit dem Inhalt "blacklist pcspkr" hilft nicht. Es kommt immer das:
[ 28.861158] input: PC Speaker as /devices/platform/pcspkr/input/input7 [ 29.165404] Error: Driver 'pcspkr' is already registered, aborting... [ 29.231689] Error: Driver 'pcspkr' is already registered, aborting...
Ok, stört nicht wirklich, ist nur auffällig und unerklärlich.
Gruß Heinz-Peter
Subject: Re: pcspkr Posted by Holger Bruenjes on Mon, 04 Mar 2019 16:40:00 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter
Am 04/03/2019 um 17.33 schrieb Heinz-Peter Faasen:
> Ich habe in der base bzgl. des Moduls > > 1 > pcspkr > no hmm
MODULE_1_NAME='pcspkr' MODULE_1_ACTIVE='yes' # active 'yes' or 'no' MODULE_1_ACTION='blacklist' # action to apply to this module MODULE_1_STRING='' dann wird das automatisch geschrieben
-> 50-eis-blacklist.conf blacklist pcspkr
Holger
Subject: Re: pcspkr Posted by Marcus Roeckrath on Mon, 04 Mar 2019 16:42:59 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
Page 72 of 165 ---- Generated from net(t)forum > 1 > pcspkr > no und
MODULE_1_ACTION='blacklist'?
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 16:46:05 GMT View Forum Message <> Reply to Message Hallo Detlef,
>> ich habe diesen Riesen-Fred zwar nur zu Teil gelesen, aber ich kenne >> diese (vermeintlich) träge Verhalten auch. > > das ist schon der zweite und schon wieder solch ein Monster geworden.
:D
>> Tue Dir (und den anderen Protagonisten) einmal den Gefallen und führe >> die Tests nicht per Proxmox-Konsole durch, sondern logge Dich per ssh >> ein und arbeite die Versuche nochmals ab. > > Das ist alles schon erledigt. > Auf der Proxmox noVNC ist die Ausgabe bei Eisfair von Hause aus extrem > langsam. Das haben mir auch andere Proxmox-User bestätigt.
Bei mir läuft der eis unter xen und VirtualBox. In beiden Fällen ist es so, dass ich Konsole die Ausgabe von dmesg fast mitlesen kann, während sie über ssh sofort "durchrauscht". In Zahlen sieht das so aus: real 0m0.003s user 0m0.000s sys 0m0.000s real 0m26.454s user 0m0.000s sys 0m26.364s
> Das auffällig langsame Update der DB und träge Installationen scheinen > damit aber nicht zusammen zu hängen. Das ist auch per ssh so.
Page 73 of 165 ---- Generated from net(t)forum Nun gut, das hat Marcus ja schon erklärt. Wobei auch da die Konsole das Ganze etwas ausbremst, wenn auch nicht so stark: 20s gegenüber 30s.
Gruß Heinz-Peter
Subject: Re: pcspkr Posted by kay on Mon, 04 Mar 2019 16:51:21 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 17:33 schrieb Heinz-Peter Faasen: > Hi Marcus, > >>>> Setup-Basiskonfiguration, nach ganz unten scrollen zu modules und dort >>>> 'pcspkr' als blacklisted eintragen. Beim nächsten boot sollte die >>>> meldung eigentlich nicht mehr auftauchen. >>> >>> bei mir taucht sie trotzdem auf. ;( >>> Das ist umso erstaunlicher, als es sich um eine VM handelt, der ich beim >>> Start gar keine Soundmaschinerie mit auf den Weg gebe. >> >> IMHO hat das nichts mit Soundhardware zu tun, sondern ist der >> "Mainboard-Piepser". > schon klar. Ich wollte nur deutlich machen, dass auch aus der "Ecke" > nichts kommen kann. ;) > > Ich habe in der base bzgl. des Moduls > > 1 > pcspkr > no
Nimm statt no mal Blacklist... > > gesetzt, das bringt aber nichts. Auch das Anlegen einer Datei in > modprobe.d mit dem Inhalt "blacklist pcspkr" hilft nicht. > Es kommt immer das:
.... und starte neu. > > [ 28.861158] input: PC Speaker as /devices/platform/pcspkr/input/input7 > [ 29.165404] Error: Driver 'pcspkr' is already registered, aborting... > [ 29.231689] Error: Driver 'pcspkr' is already registered, aborting... > > Ok, stört nicht wirklich, ist nur auffällig und unerklärlich. >
Mit Blacklist und neustart immer noch?
Page 74 of 165 ---- Generated from net(t)forum Kay
-- Sent via SN (Eisfair-1)
Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 16:56:59 GMT View Forum Message <> Reply to Message Hallo Holger,
>> Ich habe in der base bzgl. des Moduls >> >> 1 >> pcspkr >> no > > hmm > > MODULE_1_NAME='pcspkr' > MODULE_1_ACTIVE='yes' # active 'yes' or 'no' > MODULE_1_ACTION='blacklist' # action to apply to this module > MODULE_1_STRING='' danke für den Hinweis, da hatte ich wohl was falsch verstanden.
> dann wird das automatisch geschrieben > > -> 50-eis-blacklist.conf > blacklist pcspkr
Der Inhalt ist identisch, aber ich hatte beim manuellen Anlegen der Datei einen Typo in der Extension. Ist erstaunlicherweise relevant. :D
Greets Heinz-Peter
Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 17:01:49 GMT View Forum Message <> Reply to Message Hallo Marcus,
>> 1 >> pcspkr >> no > > und >
Page 75 of 165 ---- Generated from net(t)forum > MODULE_1_ACTION='blacklist'? offenbar hatte ich den Funktionszusammenhang nicht richtig verstanden - Asche auf mein Haupt! *grummel*
Sorry, war ein Schnellschuss, weil's mich nie wirklich gestört und ich mich deshalb auch nicht fundamental eingearbeitet hatte!
Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 17:03:02 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Das auffällig langsame Update der DB und träge Installationen scheinen >> damit aber nicht zusammen zu hängen. Das ist auch per ssh so. > > Nun gut, das hat Marcus ja schon erklärt.
Ich habe doch nur erklärt, dass die Bash-Skripte keine Vollblut-Rennpferde sind, den Performanceunterschied zwischen eis1 und eis64 unter ProxMox erklärt das dann aber nicht.
-- Gruss Marcus
Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 17:04:06 GMT View Forum Message <> Reply to Message Hallo Kay,
> Nimm statt no mal Blacklist... >> gesetzt, das bringt aber nichts. Auch das Anlegen einer Datei in >> modprobe.d mit dem Inhalt "blacklist pcspkr" hilft nicht. >> Es kommt immer das: > ... und starte neu. >> [ 28.861158] input: PC Speaker as /devices/platform/pcspkr/input/input7 >> [ 29.165404] Error: Driver 'pcspkr' is already registered, aborting... >> [ 29.231689] Error: Driver 'pcspkr' is already registered, aborting... >> >> Ok, stört nicht wirklich, ist nur auffällig und unerklärlich. >> > Mit Blacklist und neustart immer noch?
Page 76 of 165 ---- Generated from net(t)forum nee, denn kaum macht man's richtig, klappt die Sache. Siehe meine Antworten an Holger und Marcus. War halt doof, dass in beiden Wegen ein kleiner Fehler steckte. ;)
Gruß Heinz-Peter
Subject: Re: pcspkr Posted by Marcus Roeckrath on Mon, 04 Mar 2019 17:04:53 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>>> 1 >>> pcspkr >>> no >> >> hmm >> >> MODULE_1_NAME='pcspkr' >> MODULE_1_ACTIVE='yes' # active 'yes' or 'no' >> MODULE_1_ACTION='blacklist' # action to apply to this module >> MODULE_1_STRING='' > > danke für den Hinweis, da hatte ich wohl was falsch verstanden.
Joo, das ACTIVE sagt nur, ob dieser Konfigurationseintrag überhaupt beachtet werden soll.
Sonst müsste man bei Experimenten ständig einen solchen Eintrag wieder komplett entfernen.
> Der Inhalt ist identisch, aber ich hatte beim manuellen Anlegen der > Datei einen Typo in der Extension. Ist erstaunlicherweise relevant. :D
Hier ja, inb der Schule nicht so sehr.
-- Gruss Marcus
Subject: Re: pcspkr Posted by Marcus Roeckrath on Mon, 04 Mar 2019 17:12:17 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
Page 77 of 165 ---- Generated from net(t)forum >>> 1 >>> pcspkr >>> no >> >> und >> >> MODULE_1_ACTION='blacklist'? > > offenbar hatte ich den Funktionszusammenhang nicht richtig verstanden - > Asche auf mein Haupt! *grummel*
Macht nichts.
> Sorry, war ein Schnellschuss, weil's mich nie wirklich gestört und ich > mich deshalb auch nicht fundamental eingearbeitet hatte!
Nun weißt du, wie dieser Konfigurationsabschnitt gemeint ist, denn vielleicht bruahcst du es ja mal zukünftig.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 17:18:54 GMT View Forum Message <> Reply to Message Hallo Detlef, eine kleine Ergänzung noch:
>> Das auffällig langsame Update der DB und träge Installationen scheinen >> damit aber nicht zusammen zu hängen. Das ist auch per ssh so. > > Nun gut, das hat Marcus ja schon erklärt. > Wobei auch da die Konsole das Ganze etwas ausbremst, wenn auch nicht so > stark: 20s gegenüber 30s.
Die von Dir beobachteten GRAVIERENDEN Unterschiede zw. Eis-1 und Eis-64 kann ich nicht feststellen.
Eis-64: real 0m18.487s user 0m1.808s sys 0m1.240s
Eis-1: real 0m17.133s
Page 78 of 165 ---- Generated from net(t)forum user 0m2.412s sys 0m1.040s
Gruß Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Mon, 04 Mar 2019 17:28:44 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 18:03 schrieb Marcus Roeckrath: > > Ich habe doch nur erklärt, dass die Bash-Skripte keine Vollblut-Rennpferde > sind, den Performanceunterschied zwischen eis1 und eis64 unter ProxMox > erklärt das dann aber nicht.
Kann es sein das in diesen Scripten binär-programme oder Bibliotheken/??? aufgerufen werden die
- evtl. noch debug code enthalten - 32bittig arbeiten und bei 64-bit langsamer - durch 64bittiges kompilieren träger wurden
?
Die Weisheit mag ja eine Binse sein aber es ist doch oft wirklich so das die Doppelte Bitbreite dinge nicht nur verbreitert, sondern auch verlangsamen kann.
Und wenn beim updaten diverse tools oft genug aufgerufen werden mag sich das ja aufsummieren.
Das soll die Leistung des Teams jetzt nicht schmälern, aber mir ist oft aufgefallen das bei einem Debian/Ubuntu ein 'apt update' oder ein 'aptitude' Start deutlich schneller sind. Und da sind es regelmäßig die Infos für Zig-Tausende Installierbare Pakete die einerseits aktualisiert und andererseits gelesen werden müssen.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 17:29:42 GMT View Forum Message <> Reply to Message Hi Marcus,
Page 79 of 165 ---- Generated from net(t)forum >>> Das auffällig langsame Update der DB und träge Installationen scheinen >>> damit aber nicht zusammen zu hängen. Das ist auch per ssh so. >> >> Nun gut, das hat Marcus ja schon erklärt. > > Ich habe doch nur erklärt, dass die Bash-Skripte keine Vollblut-Rennpferde > sind, genau darauf hatte ich mich bezogen. ;)
> den Performanceunterschied zwischen eis1 und eis64 unter ProxMox > erklärt das dann aber nicht.
Tja, unter XEN und VirtualBox kann ich den nicht erkennen.
Auf der Host-Konsole gibt es manchmal etwas auffälligere Abweichungen, das ist aber nicht eindeutig reproduzierbar. Per ssh hingegen verhalten sie sich aber praktisch völlig gleich.
Was mir gerade einfällt: Die Eis-1-Installationen haben den VIRT-Kernel. Ich weiß jetzt nicht, wie das bei Detlef ist, könnte aber ein Unterschied sein.
Gruß Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 17:36:48 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
> Was mir gerade einfällt: Die Eis-1-Installationen haben den VIRT-Kernel. > Ich weiß jetzt nicht, wie das bei Detlef ist, könnte aber ein > Unterschied sein.
Unter eis64 gibt es sowieso nur noch einen nämlich den Virt-Kernel.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 17:44:09 GMT View Forum Message <> Reply to Message Hallo Kay,
Page 80 of 165 ---- Generated from net(t)forum Kay Martinen wrote:
> Kann es sein das in diesen Scripten binär-programme oder > Bibliotheken/??? aufgerufen werden die
Natürlich werden da auch weitere Binärprogramme aufgerufen.
> - evtl. noch debug code enthalten > - 32bittig arbeiten und bei 64-bit langsamer
Nein, unter eis64 sind auch alle Programme 64bittig.
> - durch 64bittiges kompilieren träger wurden
Signifikante sind nicht zu erwarten; zudem laufen unter eis1 und eis64 native Anwendungen, meint, Syste und Anwendungen sind gleichbittig.
Zudem wird ja von anderen Anwender kein gravierender Unterschied zwischen eis1 und eis64 in einer VM berichtet.
> Die Weisheit mag ja eine Binse sein aber es ist doch oft wirklich so das > die Doppelte Bitbreite dinge nicht nur verbreitert, sondern auch > verlangsamen kann.
64bit-Programme sind etwas größer, aber sie werden auf einem 64bit-Prozessor ausgeführt, so dass da auch keine Klimmzüge notwendig sind.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 19:15:44 GMT View Forum Message <> Reply to Message Hi Marcus,
>> Was mir gerade einfällt: Die Eis-1-Installationen haben den VIRT-Kernel. >> Ich weiß jetzt nicht, wie das bei Detlef ist, könnte aber ein >> Unterschied sein. > > Unter eis64 gibt es sowieso nur noch einen nämlich den Virt-Kernel. klar - aber Detlef könnte bei der 32-bit-Variante z.B. den PAE verwenden. Wahrscheinlich hat er das irgendwo gesagt, aber ich mag nicht suchen. ;)
Gruß Heinz-Peter
Page 81 of 165 ---- Generated from net(t)forum Subject: Re: pcspkr Posted by Heinz-Peter Faasen on Mon, 04 Mar 2019 19:27:18 GMT View Forum Message <> Reply to Message Hi Marcus,
>> offenbar hatte ich den Funktionszusammenhang nicht richtig verstanden - >> Asche auf mein Haupt! *grummel* > > Macht nichts. danke für die Nachsicht. ;)
>> Sorry, war ein Schnellschuss, weil's mich nie wirklich gestört und ich >> mich deshalb auch nicht fundamental eingearbeitet hatte! > > Nun weißt du, wie dieser Konfigurationsabschnitt gemeint ist, denn > vielleicht bruahcst du es ja mal zukünftig.
Wieder was gelernt. Und ja, würde mich nicht wundern, wenn es mir irgendwann zupass käme.
Schönen Abend! Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Mon, 04 Mar 2019 19:36:11 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>>> Was mir gerade einfällt: Die Eis-1-Installationen haben den VIRT-Kernel. >>> Ich weiß jetzt nicht, wie das bei Detlef ist, könnte aber ein >>> Unterschied sein. >> >> Unter eis64 gibt es sowieso nur noch einen nämlich den Virt-Kernel. > > klar - aber Detlef könnte bei der 32-bit-Variante z.B. den PAE verwenden. > Wahrscheinlich hat er das irgendwo gesagt, aber ich mag nicht suchen. ;)
Laut seinem Posting:
System: Host: eis1-test Kernel: 3.16.62-eisfair-1-VIRT i686
-- Gruss Marcus
Page 82 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Mon, 04 Mar 2019 21:33:06 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 22:53 schrieb Hilmar Böhm:
> Zu Eisfair: > Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" die > Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's gibt es > praktisch keine Wartezeiten mehr für die vHD's.
Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat niemand mehr getestet, ob mit neuerem Kernel mit kürzeren Denkpausen noch alles funktioniert.
Auszug aus dem Kernel-Install-Skript (Funktion zur Erzeugung der initramfs):
if [ -n "$new_scsi_drivers" ] then new_scsi_drivers="scsi_mod sd_mod $new_scsi_drivers" message="New complete SCSI/SATA/PATA and dependend module(s) for initramfs:" echo "$message" echo "$message" >>"$klogfile"
for mod in $new_scsi_drivers do mecho --info " $mod" echo "$mod" >>"$klogfile"
driver_with_path_relative=`grep "/$mod.ko:" /lib/modules/$kernel/modules.dep | cut -d: -f1` driver_with_path="/lib/modules/$kernel/$driver_with_path_relative" echo " Copying $driver_with_path to $initrd_mount/lib/modules/$kernel." >>"$klogfile" cp $driver_with_path $initrd_mount/lib/modules/$kernel echo " Writing \"/sbin/insmod /lib/modules/$kernel/$mod.ko\" to $initrd_mount/init." >>"$klogfile" echo "/sbin/insmod /lib/modules/$kernel/$mod.ko" >>$initrd_mount/init
if [ "$mod" = "usb-storage" ] then # delay_use von usb-storage ist 5 sec, warte insges. 6 sec auf das Device { echo '/bin/sleep 2' echo '/bin/echo -e "\033[32m\033[49mWaiting for usb-storage device coming up ...\033[0m"' echo '/bin/sleep 4' } >>$initrd_mount/init
Page 83 of 165 ---- Generated from net(t)forum fi done
# always waiting for devices coming up { echo '/bin/echo -e "\033[32m\033[49mWaiting for SCSI/SATA/PATA devices coming up ...\033[0m"' echo '/bin/sleep 10' } >>$initrd_mount/init fi
Hier wird bei Verwendung von usb-storage (also z.B. bei Installation auf einen USB-Stick) nach Laden des Moduls 6 Sekunden gewartet. Wie man dem Kommentar entnehmen kann, war damals der Zeitraum, den der Kernel dem Modul einräumt, bevor angeschlossene Medien bereit sind, 5 Sekunden lang. Das ist inzwischen nicht mehr so: modprobe usb-storage pvscsi # cat /sys/module/usb_storage/parameters/delay_use 1
Inzwischen gibt der Kernel dem Modul nur noch 1 Sekunde Zeit, Medien zu finden.
Das Delay unten von 10 Sekunden habe ich damals durch Ausprobieren bestimmt. Damit lief dann in _jedem Fall_ alles fehlerfrei.
Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen Installationen mit einem kürzeren Delay durchzutesten (Installation und darauf folgenden Boot von und auf einen langsamen USB-1-Stick, Installation auf ein gemischtes Array aus IDE-, SCSI- und SATA-Platten, die an verschiedenen Controllern unterschiedlich lange benötigen, um alle bereit zu sein usw.) und das alles auf Hardware, die nicht aus den letzten 5 Jahren stammt:
Dann können wir das gerne mal ändern.
Wer macht es? Du?
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Mon, 04 Mar 2019 22:40:06 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 22:33 schrieb Thomas Bork: > Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: >
Page 84 of 165 ---- Generated from net(t)forum >> Zu Eisfair: >> Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" >> die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's gibt >> es praktisch keine Wartezeiten mehr für die vHD's. > > Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat > niemand mehr getestet, ob mit neuerem Kernel mit kürzeren Denkpausen > noch alles funktioniert. > ... > Das Delay unten von 10 Sekunden habe ich damals durch Ausprobieren > bestimmt. Damit lief dann in _jedem Fall_ alles fehlerfrei.
Fehlerfrei (naja: Fehler vermeiden) ist ja für einen Server auch wichtiger als ein paar sekunden beim Boot zu sparen. Ich meine: Mein Proliant braucht locker mehr als 2 Minuten um überhaupt durch seinen POST (inkl. Raid-detect) zu kommen. Das OS ist in der halben Zeit geladen. Und der hat nur 4 Platten. Mein Alter Fileserver (ein G4) braucht locker 5 minuten, hat dafür aber auch 20 Platten die er alle einzeln durchtestet. Das OS ist aber ebenso fix da wie beim neuen.
> Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen > Installationen mit einem kürzeren Delay durchzutesten (Installation und > darauf folgenden Boot von und auf einen langsamen USB-1-Stick, > Installation auf ein gemischtes Array aus IDE-, SCSI- und SATA-Platten, > die an verschiedenen Controllern unterschiedlich lange benötigen, um > alle bereit zu sein usw.) und das alles auf Hardware, die nicht aus den > letzten 5 Jahren stammt:
Also abgesehen von USB-1 Sticks hätte ich noch genügend Abgehangene HW vom 80386DX/SX über P-ATA, SCSI-1 bis U320 und S-ATA Platten und PIII bis zum Dualcore PC hier...
> Dann können wir das gerne mal ändern.
.... aber wegen eines 10 Sekunden-Delay das mich nicht - und vermutlich nur einen oder wenig andere stört...
> Wer macht es? Du?
.... ist das alles durch zu Testen definitiv viel zu viel Aufwand!
Zumal man einen Server idealerweise einmal Bootet (mit oder Ohne Delay= egal) und ihn dann laufen lässt - bis es zwingend nötig ist ihn neu zu starten. Sorgen wegen dieses Boot-Delay ist m.E. Jammern auf Hohem Niveau.
Interessante fände ich da eher wie schnell der neue Eisman; oder die angedeutete Beschleunigung sein wird da das im Laufenden Betrieb eher regelmäßig vorkommt.
Und ein kleiner Test eben war schon erstaunlich.
Page 85 of 165 ---- Generated from net(t)forum Ein 'time eisman update' in einer VM brauchte beim 2. Versuch noch real 2m0.718s user 0m6.224s sys 0m8.632s
Ein 'time apt update' in einer Ubuntu 16 VM auf dem gleichen Proxmox/Proliant Server dagegen grade mal 17 sekunden (mit ca. 5 aktualisierten Dateien und der Ansage das es zwei Update-bare Pakete gäbe. Und dabei zog der Eisfair das auch noch über einen lokalen Proxy, Ubuntu aber direkt aus dem Inet.
Selbst wenn das eisman update noch eine Minute dauern würde wäre das eine Verdopplung des Tempos hier. Aber da er das ja inzwischen per crontab automatisch machen kann auch nicht wirklich ein Problem.
Man ist halt manchmal ungeduldig und dann wieder nicht. ;-)
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Hilix on Tue, 05 Mar 2019 00:09:23 GMT View Forum Message <> Reply to Message Am 04.03.19 um 22:33 schrieb Thomas Bork: > Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: > >> Zu Eisfair: >> Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei >> Eisfair-VM's gibt es praktisch keine Wartezeiten mehr für die vHD's. > > Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat niemand mehr getestet, ob mit neuerem Kernel mit kürzeren > Denkpausen noch alles funktioniert. > > Auszug aus dem Kernel-Install-Skript (Funktion zur Erzeugung der initramfs): > ... > ... > > # always waiting for devices coming up > { > echo '/bin/echo -e "\033[32m\033[49mWaiting for SCSI/SATA/PATA devices coming up ...\033[0m"' > echo '/bin/sleep 10' > } >>$initrd_mount/init
Page 86 of 165 ---- Generated from net(t)forum > fi > > Hier wird bei Verwendung von usb-storage (also z.B. bei Installation auf einen USB-Stick) nach Laden des Moduls 6 Sekunden > gewartet. Wie man dem Kommentar entnehmen kann, war damals der Zeitraum, den der Kernel dem Modul einräumt, bevor angeschlossene > Medien bereit sind, 5 Sekunden lang. Das ist inzwischen nicht mehr so: > > modprobe usb-storage > pvscsi # cat /sys/module/usb_storage/parameters/delay_use > 1 > > Inzwischen gibt der Kernel dem Modul nur noch 1 Sekunde Zeit, Medien zu finden. > > Das Delay unten von 10 Sekunden habe ich damals durch Ausprobieren bestimmt. Damit lief dann in _jedem Fall_ alles fehlerfrei. > > Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen Installationen mit einem kürzeren Delay durchzutesten > (Installation und darauf folgenden Boot von und auf einen langsamen USB-1-Stick, Installation auf ein gemischtes Array aus IDE-, > SCSI- und SATA-Platten, die an verschiedenen Controllern unterschiedlich lange benötigen, um alle bereit zu sein usw.) und das > alles auf Hardware, die nicht aus den letzten 5 Jahren stammt: > > Dann können wir das gerne mal ändern. > > Wer macht es? Du? > Wenn Du mich meinst: Nein! (Keine Zeit, bin (in diesem Fall) nur Anwender.)
USB-Storage verwende ich nicht für VM's.
Zu dem Block " #always waiting for devices coming up" kann ich nur sagen, dass eine VM auf einem Host läuft, der i.d.R. einen virt. Spreicher (vHD) für die VM bereits zur Verfügung hat, wenn die VM auf ihm gestartet wird. Also keine Wartezeiten erforderlich. Warum nicht einfach diese 10 Sek. sleep weglassen?
Andere (Server-)Systeme anderer Distributionen stellen heutzutage fest, ob ihr Kernel in einer VM läuft. Es gibt genügend freie Software - sicherlich auch für BASH/SH-Scripte, die diese Information liefern kann. In diesen Falle sind solche langen Wartezeiten nicht notwendig.
Beispiele (aus VM'S):
1. Debian 9: Journalmeldungen (Auszug): Mär 04 09:33:13 kmrzmp kernel: Booting paravirtualized kernel on KVM ... Mär 04 09:33:13 kmrzmp systemd[1]: Detected virtualization qemu.
Page 87 of 165 ---- Generated from net(t)forum (Stör Dich nicht an systemd, die obere Meldung stammt vom Kernel)
2. Antergos_Minimal (ArchLinux basiert): Journalmeldungen (Auszug): Mär 04 23:46:28 antimin kernel: Booting paravirtualized kernel on KVM ... Mär 04 23:46:29 antimin systemd[1]: Detected virtualization kvm. Mär 04 23:46:29 antimin systemd[1]: Detected architecture x86-64. (Das ist das System das auf meinem Debian KVM-Host in 6 Sekunden auf 100 ist! :-)
3. Alpine Linux, Virt-Kernel, V3.9.2 Keine entsprechende Meldung in 'messages'/dmesg, Aber vHD (sda, virtio-scsi) wird sehr schnell, ohne Wartezeiten gemountet.
Wollte nur zeigen, dass es geht. Aber wenn ich der einzige bin, dem das aufstößt und wenn das bei einem Server keine Rolle spielt (oder ich nur "auf hohem Niveau jammere"), dann lassen wir es halt so. wie ist...
/ Hilmar.
Subject: Re: pcspkr (et al) Posted by Hilix on Tue, 05 Mar 2019 00:46:11 GMT View Forum Message <> Reply to Message Hallo Marcus, habe mir mit dem Test den halben Tag um die Ohren geschlagen. (...und das in Köln, heute :-) )
Es gibt keine Erkenntnisse, die mich der Ursache näher bringen. Habe die Echos für Start- und Stop-Zeiten in die Startskripts eingetragen, und zwar in die start() - Blöcke, soweit vorhanden. Die werden vermutlich beim Systemstart durchlaufen ?!
Hier die Zeiten, die ich in eine Log-Datei schreiben ließ: ------Mon Mar 4 23:07:15 CET 2019 = Stop in S07mountfs Mon Mar 4 23:07:15 CET 2019 = Start in S08base Mon Mar 4 23:07:15 CET 2019 = Stop in S08base Mon Mar 4 23:07:16 CET 2019 = Start in S08environment Mon Mar 4 23:07:16 CET 2019 = Stop in S08environment Mon Mar 4 23:07:16 CET 2019 = Start in S08mtab Mon Mar 4 23:07:16 CET 2019 = Stop in S08mtab Mon Mar 4 23:07:16 CET 2019 = Start in S08rtc Mon Mar 4 23:07:16 CET 2019 = Stop in S08rtc Mon Mar 4 23:07:17 CET 2019 = Start in S09console Mon Mar 4 23:07:21 CET 2019 = Stop in S09console Mon Mar 4 23:07:21 CET 2019 = Start in S09hostname Mon Mar 4 23:07:21 CET 2019 = Stop in S09hostname Mon Mar 4 23:07:22 CET 2019 = Start in S11ide Mon Mar 4 23:07:22 CET 2019 = Stop in S11ide
Page 88 of 165 ---- Generated from net(t)forum Mon Mar 4 23:07:22 CET 2019 = Start in S12lo Mon Mar 4 23:07:22 CET 2019 = Stop in S12lo Mon Mar 4 23:07:22 CET 2019 = Start in S14usb Mon Mar 4 23:07:23 CET 2019 = Stop in S14usb Mon Mar 4 23:07:23 CET 2019 = Start in S25ip-eth Mon Mar 4 23:07:23 CET 2019 = Stop in S25ip-eth ------
Da kann man keine Laufzeiten > 5 Sek. sehen (evtl. in S09console). Was auffällt, dass die Anzeige der eingebauten Echos erst mit S07mountfs beginnt. Ich habe sie auch in alle Skripts davor eingebaut (auch in die S01/s02xxx -Skripte).
Habe ich was falsch gemacht? Habe ich etwas übersehen? Hast Du evtl. noch eine Idee?
Viele Grüße. / Hilmar.
P.S. Habe mir vorher von /etc/rc2.d und /etc/init.d tar-files erzeugt. Kann ich die einfach wieder restoren (wg. der Logical Links)? Wenn nicht, ist auch nicht schlimm, habe ja noch den rsnapshot vom Vortag... (Dieses Rsnapshot-Teil ist einfach genial, hat mir schon einige Male den Arsch gerettet... :-) )
Am 04.03.19 um 17:07 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >> ...habe auch mal virtio-net geblacklistet und dann mit >> >> # modprobe virtio-net >> # /etc/init.d/ip-eth start >> >> das Netzwerk händisch geladen. >> >> Danach war - ohne Verzögerung, sofort - das Netzwerkdevice inkl. >> IP-Adresse vom DHCP-Server vorhanden (ip a). > > Ok. > >> Das kann es also wirklich nicht gewesen sein. Ich werde jetzt mal Deinen >> Vorschlag mit den Startup-Skripts verfolgen. > > Alles andere wäre weiter stochern im Nebel. Vielleicht bringen uns die > Start-End-Zeiten der Initskripte der Ursache näher. >
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 06:34:21 GMT
Page 89 of 165 ---- Generated from net(t)forum View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
> ... aber wegen eines 10 Sekunden-Delay das mich nicht - und vermutlich > nur einen oder wenig andere stört... > > Zumal man einen Server idealerweise einmal Bootet (mit oder Ohne Delay= > egal) und ihn dann laufen lässt - bis es zwingend nötig ist ihn neu zu > starten. Sorgen wegen dieses Boot-Delay ist m.E. Jammern auf Hohem Niveau.
Da gebe ich dir recht; Booten kommt beoi meinem Servern auch nur dann vor, wenn es erzwungen ist (Stromausfall, Urlaub, Kernelupdate) - das ist eine übersichtliche Anzahl.
Intern hat Thomas mal einen Testkernel mit reduziertem Delay gemacht, der auf all meiner realen Hardware sauber durchbootete.
> Interessante fände ich da eher wie schnell der neue Eisman; oder die > angedeutete Beschleunigung sein wird da das im Laufenden Betrieb eher > regelmäßig vorkommt.
Es geht zunächst nur um eisman update; ich habe alle meine Kisten schon auf die neue Beta der Base gehoben, so dass ich nun keine direkten Vergleiche von alt und neu machen kann.
Nur so grob aus meiner Erinnerung: Vorher ging der Prozentzähler so etwa einmal jede Sekunde (vielleicht waren es sogar fast 2 Sekunden) weiter, nun rauscht das inerhalb von 4 Sekunden durch. Bis der Zähler aber läuft, werden noch einige Vorarbeiten ohne Fortschrittsanzeige gemacht. eis # time eisman update (Re)building package database ... [100%] completed! Done! (Re)building outdated database ... please wait! Done! real 0m27.963s user 0m25.096s sys 0m0.836s
> Man ist halt manchmal ungeduldig und dann wieder nicht. ;-)
Wenn es - wie üblich - als Cronjob im Hintergrund läuft, stört es nicht, aber wenn man mal schnell manuell die DB aktualisieren will, wartet man ungeduldig.
--
Page 90 of 165 ---- Generated from net(t)forum Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 07:08:20 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> habe mir mit dem Test den halben Tag um die Ohren geschlagen. (...und das > in Köln, heute :-) )
Man muss auch mal Prioritäten setzen. :-) Für die Leber ist eisfair bestimmt gesünder.
Und das sagt ein geborener Düsseldorfer einem Kölner.
> Es gibt keine Erkenntnisse, die mich der Ursache näher bringen. Habe die > Echos für Start- und Stop-Zeiten in die Startskripts eingetragen, und zwar > in die start() - Blöcke, soweit vorhanden. Die werden vermutlich beim > Systemstart durchlaufen ?!
Ja genau da, das sieht etwa so aus: case ...
start)
;; stop)
;; esac
> Hier die Zeiten, die ich in eine Log-Datei schreiben ließ: > ------> Mon Mar 4 23:07:15 CET 2019 = Stop in S07mountfs > Mon Mar 4 23:07:15 CET 2019 = Start in S08base > Mon Mar 4 23:07:15 CET 2019 = Stop in S08base > Mon Mar 4 23:07:16 CET 2019 = Start in S08environment > Mon Mar 4 23:07:16 CET 2019 = Stop in S08environment > Mon Mar 4 23:07:16 CET 2019 = Start in S08mtab > Mon Mar 4 23:07:16 CET 2019 = Stop in S08mtab > Mon Mar 4 23:07:16 CET 2019 = Start in S08rtc > Mon Mar 4 23:07:16 CET 2019 = Stop in S08rtc > Mon Mar 4 23:07:17 CET 2019 = Start in S09console > Mon Mar 4 23:07:21 CET 2019 = Stop in S09console
Page 91 of 165 ---- Generated from net(t)forum > Mon Mar 4 23:07:21 CET 2019 = Start in S09hostname > Mon Mar 4 23:07:21 CET 2019 = Stop in S09hostname > Mon Mar 4 23:07:22 CET 2019 = Start in S11ide > Mon Mar 4 23:07:22 CET 2019 = Stop in S11ide > Mon Mar 4 23:07:22 CET 2019 = Start in S12lo > Mon Mar 4 23:07:22 CET 2019 = Stop in S12lo > Mon Mar 4 23:07:22 CET 2019 = Start in S14usb > Mon Mar 4 23:07:23 CET 2019 = Stop in S14usb > Mon Mar 4 23:07:23 CET 2019 = Start in S25ip-eth > Mon Mar 4 23:07:23 CET 2019 = Stop in S25ip-eth > ------> > Da kann man keine Laufzeiten > 5 Sek. sehen (evtl. in S09console).
Geht ja auch mehr darum, dass in der dmesg 22 Sekunden fehlen.
Auch am Bildschirm muss man doch irgendwann diese lange Pause beobachten. War die noch vor den obigen Echos?
> Was auffällt, dass die Anzeige der eingebauten Echos erst mit S07mountfs > beginnt. Ich habe sie auch in alle Skripts davor eingebaut (auch in die > S01/s02xxx -Skripte). Übrigens beginnt sie auch mit dem Stop im mountfs.
Das verstehe ich derzeit auch noch nicht, denn auch diese Skripte erzeugen ja ihrerseits Ausgaben.
Denkbar wäre allerdings, dass das echo nicht funktioniert ohne einen Fehler rauszuschmeißen. Ich denke, der $(date) Befehl steht noch nicht zur Verfügung, da date ein externen Kommando ist.
Lass also mal $(date) bei den früheren und in mountfs bei "Start in" weg und beobachte augenscheinlich die Abstände der Meldungen.
Es bleibt bei der Frage, wo sich die Pause in dmesg wiederfinden läßt.
Insbesondere ab udev hätte mich interessiert, da dieses vor der Pause in dmesg gestartet wird. War die Pause im Bootvorgang jetzt vor
> Habe ich was falsch gemacht? Habe ich etwas übersehen? Hast Du evtl. noch > eine Idee?
Ich denke nicht.
> P.S. Habe mir vorher von /etc/rc2.d und /etc/init.d tar-files erzeugt. > Kann ich die einfach wieder restoren (wg. der Logical Links)?
Du brauchtest nur die echten Dateien in /etc/init.d zu sichern und auch nur dort die temporär veränderten wieder restaurieren, den Links passiert dabei garnichts.
> Wenn nicht, > ist auch nicht schlimm, habe ja noch den rsnapshot vom Vortag... (Dieses
Page 92 of 165 ---- Generated from net(t)forum > Rsnapshot-Teil ist einfach genial, hat mir schon einige Male den Arsch > gerettet... :-) )
Es ist die Aufgabe von Backups, Ärsche zu retten. Auch wenn ich es bislang noch nicht als Rettungsanker brauchte, setze ich rsnapshot in der Penne ein (7 tage, 4 Wochen, 24 Monate).
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 09:51:49 GMT View Forum Message <> Reply to Message Am 04.03.2019 um 18:18 schrieb Heinz-Peter Faasen: > Hallo Detlef,
Hallo Heinz-Peter,
> Die von Dir beobachteten GRAVIERENDEN Unterschiede zw. Eis-1 und Eis-64 > kann ich nicht feststellen. tja das lässt sich einfach nicht erklären. Das ist so eine verzwickte Sache wo man denkt, "alles ist in Ordnung, alles Funktioniert normal, es müsste eigentlich gehen... Warum macht es das dann aber nicht?"
Hat auch keinen Sinn mehr hier noch lange weiter zu machen. Dieses Monster hier ist auch gar mittlerweile nicht mehr lesbar. Ich werde das so hinnehmen müssen. Den "neuen" Eisfair will ich sowieso eine Zeit lang parallel zum bisherigen laufen lassen und dann werde ich mal beobachten, ob der neue in der täglichen Arbeit auffällig langsamer läuft oder ob es sich in der Tat nur auf das einspielen von Updates beschränkt. Damit kann ich dann leben und die langsame Proxmox-Konsole ist mir sowieso Scheiß egal gewesen. Die brauche ich so gut wie nie.
Proxmox an sich möchte ich auf jeden Fall erst mal weiter nutzen. Es Bringt gleich alles mit was man braucht, für mich als Virtualisierungs-Neueinsteiger ist es intuitiv zu nutzen, ist gut beschrieben und was ich als Eisfair User wichtig finde und was leider nicht mehr selbstverständlich ist, im Proxmox Forum herrscht ein vernünftiger Umgangston.
Also, für jeden der mal in die Virtualisierung rein riechen möchte kann ich Proxmox empfehlen und wenn man dann nicht so bekloppt wie ich ist und mit der Standartpartitionierung zufrieden ist, installiert man von der iso und hat in knapp vier Minuten das fertige System inkl. Web-Konfigurationsschicht mit allem drum und dran. (Die Debian-Installation ist bei Proxmox aber auch gut beschrieben und schnell gemacht.)
Page 93 of 165 ---- Generated from net(t)forum > Gruß > Heinz-Peter
Viele Grüße Detlef Paschke
Ps. da sehe ich gerade, ich sollte wohl mal meine Signatur ändern. "registered Fli4l-User" gibt es doch schon ewig nicht mehr, oder? -- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 10:09:11 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> was ich als Eisfair User wichtig finde und was leider > nicht mehr selbstverständlich ist, im Proxmox Forum herrscht ein > vernünftiger Umgangston.
Ich kenne das Proxmox-Forum nicht und kann daher den dortigen Umgangston nicht beurteilen.
Ich kann aber hier durchaus nicht erkennen, dass hier ein rauher und harscher Umgangston herrscht - ich nehme mich mal raus, da man sich selbst nicht beurteilen kann/soll.
Natürlich wird zu Recht mal klar nachgefragt, wenn die gelieferten Infos zu dürftig, aber das hier auch nur der Anflug von Abkanzeln usw. gang und gäbe ist, möchte ich mal in Abrede stellen.
Das finde ich heutzutage in der ct-Newsgroup oder auch oft in den OpenSuSE-Nesgroups, in denen ich mich früher regelmäßig getummelt habe.
> Ps. da sehe ich gerade, ich sollte wohl mal meine Signatur ändern. > "registered Fli4l-User" gibt es doch schon ewig nicht mehr, oder?
Keine Ahnung. -- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Tue, 05 Mar 2019 10:35:48 GMT
Page 94 of 165 ---- Generated from net(t)forum View Forum Message <> Reply to Message Hi Marcus,
> Ich kann aber hier durchaus nicht erkennen, dass hier ein rauher und > harscher Umgangston herrscht - ich nehme mich mal raus, da man sich selbst > nicht beurteilen kann/soll. ich wage mal zu behaupten, dass Du Detlef da gründlichst missverstanden hast. ;)
Gruß Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 10:44:47 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Ich kann aber hier durchaus nicht erkennen, dass hier ein rauher und >> harscher Umgangston herrscht - ich nehme mich mal raus, da man sich >> selbst nicht beurteilen kann/soll. > > ich wage mal zu behaupten, dass Du Detlef da gründlichst missverstanden > hast. ;)
Ich weiß nicht, da er den Umgangston hier mit dem vom ihm geschätzten Umgangston im Proxmox-Forum vergleicht.
Wenn bei ihm da aus irgendeinem Grund dieser Eindruck entstanden ist, sollte man darüber reden.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 11:15:50 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 11:09 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Ich kenne das Proxmox-Forum nicht und kann daher den dortigen Umgangston > nicht beurteilen.
Page 95 of 165 ---- Generated from net(t)forum > > Ich kann aber hier durchaus nicht erkennen, dass hier ein rauher und > harscher Umgangston herrscht - ich nehme mich mal raus, da man sich selbst > nicht beurteilen kann/soll. > > Natürlich wird zu Recht mal klar nachgefragt, wenn die gelieferten Infos zu > dürftig, aber das hier auch nur der Anflug von Abkanzeln usw. gang und gäbe > ist, möchte ich mal in Abrede stellen. > > Das finde ich heutzutage in der ct-Newsgroup oder auch oft in den > OpenSuSE-Nesgroups, in denen ich mich früher regelmäßig getummelt habe. neeeiiin, da hast Du mich jetzt falsch verstanden. Ich als alter Eisfair User, zu denen ich mich als einer der User der ersten Stunde zähle, halte den Umgangston hier unter uns als Vorbildlich und Beispiel für viele andere Gruppen in die man so rein gelesen hat.
Was in manchen Gruppen so abgeht ist nicht mehr Normal, da sind Beschimpfungen nach einfachen Fragen fast die Tagesordnung.
So meine ich. Sorry wenn es falsch rüber kam.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 11:36:02 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> neeeiiin, da hast Du mich jetzt falsch verstanden.
Danke, dann wäre das geklärt.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Heinz-Peter Faasen on Tue, 05 Mar 2019 12:21:22 GMT View Forum Message <> Reply to Message
Page 96 of 165 ---- Generated from net(t)forum Hallo Marcus,
>>> Ich kann aber hier durchaus nicht erkennen, dass hier ein rauher und >>> harscher Umgangston herrscht - ich nehme mich mal raus, da man sich >>> selbst nicht beurteilen kann/soll. >> >> ich wage mal zu behaupten, dass Du Detlef da gründlichst missverstanden >> hast. ;) > > Ich weiß nicht, da er den Umgangston hier mit dem vom ihm geschätzten > Umgangston im Proxmox-Forum vergleicht. na, ich würde eher sagen, ihm gefällt das Proxmox-Forum, weil es ihn bzgl. der Umgangsformen sehr an Eisfair erinnert. ;)
> Wenn bei ihm da aus irgendeinem Grund dieser Eindruck entstanden ist, sollte > man darüber reden.
Sehe ich auch so. Probleme und Missstimmungen zwar in freundlichem Ton, aber eben offen ansprechen, damit die Dinge aus der Welt geschafft werden können. Nichts ist schlimmer, als sich im Stile von "Political correctness" um alles herum zu lavieren und damit nichts i.O. zu bringen.
Gruß Heinz-Peter
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 12:32:19 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 12:36 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> > Detlef Paschke wrote: > >> neeeiiin, da hast Du mich jetzt falsch verstanden. > > Danke, dann wäre das geklärt. >
So, und da dass hier nun sowieso ein Monster geworden ist lege ich nochmal nach, für das Archiv. Ein Haus, ein Baum, ein Kind und ein Vermächtnis im Archiv. ;-)
Page 97 of 165 ---- Generated from net(t)forum Der Umgang hier ist in keinster Weise zu bemängeln, ganz im Gegenteil. Der Ton hier müsste sogar im Portfolio von Eisfair mit aufgenommen werden da Service und Unterstützung ein wesentlicher Bestandteil einer guten Software ist oder sein sollte. Jeder der irgend eine Frage zu Eisfair hat, oder wie in diesem Fall eine Frage welche evtl. nur am Rande oder evtl. sogar gar nicht mit Eisfair zu Tun hat, kann sie hier getrost stellen und wird, sobald auch nur irgend jemand einen Ansatz hat, Hilfestellung erhalten. Beschimpfungen für die "Dummheit" gibt es hier nicht, niemand weiß alles. Im Verlauf der Beiträge tauchen dann manchmal noch andere Sachen auf wie, "Gut wäre ein qemu-guest-agent paket damit der vom Host geregelt runter gefahren werden kann" oder "was auffällt, ist die lange Wartezeit bei pcspkr" und Ruck Zuck kommt von einer Seite "installiere ganz einfach das power-button-packet, denn Proxmox macht auch nix anderes als "auf den Knopp zu drücken"" oder "Du brauchst nur das Modul pcspkr blacklisten" und schon kommt ein, "Mensch danke, dass wusste ich noch gar nicht". Sicherlich wird man evtl. auch mal etwas "lauter" wenn der Gegenüber wieder nicht die Info drei Beiträge vorher gelesen hat, nicht Versteht worum es eigentlich geht und man schon völlig Entnerven vor einem Problem sitzt was sich einfach nicht lösen lässt, wir sind alle nur Menschen, aber trotzdem gehen wir hier alle respektvoll miteinander um.
Ich bin der festen Überzeugung, dass etwas anderes hier auch nicht akzeptiert würde und sehe dass als einen ganz großen Vorteil des gesamten Eisfair-Projekt.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 12:35:47 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
> na, ich würde eher sagen, ihm gefällt das Proxmox-Forum, weil es ihn > bzgl. der Umgangsformen sehr an Eisfair erinnert. ;)
Hat sich durch die Mail von Detlef ja auch so bestätigt.
>> Wenn bei ihm da aus irgendeinem Grund dieser Eindruck entstanden ist, >> sollte man darüber reden.
Page 98 of 165 ---- Generated from net(t)forum > > Sehe ich auch so. Probleme und Missstimmungen zwar in freundlichem Ton, > aber eben offen ansprechen, damit die Dinge aus der Welt geschafft > werden können.
Eben weil es bei non-verbaler Kommunikation viel schneller Missverständnisse geben kann, die sich durch Maillaufzeiten auch nicht "augenblicklich" klären lassen.
> Nichts ist schlimmer, als sich im Stile von "Political correctness" um > alles herum zu lavieren und damit nichts i.O. zu bringen.
Gott bewahre, man muss auch mal etwas klar und deutlich sagen können und dürfen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 12:59:34 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Der Umgang hier ist in keinster Weise zu bemängeln, ganz im Gegenteil. > Der Ton hier müsste sogar im Portfolio von Eisfair mit aufgenommen > werden da Service und Unterstützung ein wesentlicher Bestandteil einer > guten Software ist oder sein sollte.
Danke für deine Lobesworte, die tun dem ganzen Team gut.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 13:12:35 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Habe ich was falsch gemacht? Habe ich etwas übersehen? Hast Du evtl. noch > eine Idee?
Bitte schau dir einen Bootvorgang auch mal in der /var/log/messages an, da müsste doch auch dieser "Pausenbereich" zu finden sein.
Page 99 of 165 ---- Generated from net(t)forum Du darfst mir auch gerne eine messages per PM zukommen lassen - am besten gezipped oder so.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 13:44:05 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 13:59 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> > Detlef Paschke wrote: > >> Der Umgang hier ist in keinster Weise zu bemängeln, ganz im Gegenteil. >> Der Ton hier müsste sogar im Portfolio von Eisfair mit aufgenommen >> werden da Service und Unterstützung ein wesentlicher Bestandteil einer >> guten Software ist oder sein sollte. > > Danke für deine Lobesworte, die tun dem ganzen Team gut. > und, das ist jetzt wieder nicht bös sondern als großer Pluspunkt gemeint, dass beziehe ich nicht nur auf das Team allein sondern die gesamte Nutzergemeinde denn jeder der hier einen Tipp geben kann, und sei es auch nur eine kleine Erfahrung die er mal gemacht hat, gibt sie hier weiter wenn es Nötig wird.
Oh Gott. schaut euch mal die ms. Gruppen an. Da führt persönliches Ansprechen bereits zu Beleidigungen. Und, auch die Linux-Gruppen werden immer schlimmer. Das waren mal hochanständige Gruppen. Verrückte Zeit.
Nö nö, ich bleibe mal schön bei Eisfair, ich erinnere mich, allein par2cmdline hat damals jemand nur gebaut weil ich hier danach gefragt habe und auch andere Probleme werden früher oder später gelöst.
Ich mache meinen Eisfair64-VM auf Proxmox jetzt fertig, lasse ihn eine Zeit lang parallel zum eisfair1-HM laufen und wenn alles gut ist schließe ich die Umstellung ab und werde noch mal berichten. Evtl. gibt es bis dahin den neuen Eisman der dieses Problem vielleicht sogar gelöst hat.
Viele Grüße Detlef Paschke
Page 100 of 165 ---- Generated from net(t)forum -- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 14:02:01 GMT View Forum Message <> Reply to Message Hallo Dtlef,
Detlef Paschke wrote:
> und, das ist jetzt wieder nicht bös sondern als großer Pluspunkt > gemeint, dass beziehe ich nicht nur auf das Team allein sondern die > gesamte Nutzergemeinde denn jeder der hier einen Tipp geben kann, und > sei es auch nur eine kleine Erfahrung die er mal gemacht hat, gibt sie > hier weiter wenn es Nötig wird.
Ohne die Anwender wäre das mit dem kleinen Kernteam (wenn ich nicht verzählt habe) 7 Leuten kaum machbar.
Opensource und damit auch eisfair ist zwar kostenlos aber nicht umsonst - es erfordert mindestens das Lesen der Dokumentation.
Opensource ist aber auch die aktive Teilhabe aller, was nicht meint, dass jeder aktiv am Paketbau etc. teilhaben muss, aber Hilfe in Form von Bugberichten, Hilfestellungen, Tests, ... einbringen kann und sollte.
Vielleicht nun genug der "Lobhudelei", kommen wir wieder zur Technik.
> Ich mache meinen Eisfair64-VM auf Proxmox jetzt fertig, lasse ihn eine > Zeit lang parallel zum eisfair1-HM laufen und wenn alles gut ist > schließe ich die Umstellung ab und werde noch mal berichten. > Evtl. gibt es bis dahin den neuen Eisman der dieses Problem vielleicht > sogar gelöst hat.
Wenn eisman update rasant beschleunigt ist, wird automatisch auch die Diskrepanz zwischen eis1 und eis64 bei dir kleiner werden, wo sie aber auf deinem System überhaupt herkommt, erschließt sich mir nicht.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 15:06:50 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 15:02 schrieb Marcus Roeckrath:
Page 101 of 165 ---- Generated from net(t)forum > Hallo Dtlef,
Hallo Marcus,
> Wenn eisman update rasant beschleunigt ist, wird automatisch auch die > Diskrepanz zwischen eis1 und eis64 bei dir kleiner werden, wo sie aber auf > deinem System überhaupt herkommt, erschließt sich mir nicht. das ist wieder so ein... eigentlich müsste es, keiner weiß warum. Hin und wieder zeigt es sich mal bei anderen, dann wieder gar nicht...??? Wird keinen Sinn haben hier lange weiter zu grübeln.
Ich werde jetzt eis64 für meinen neuen eisfair einsetzen. Ich glaube Du sagtest es, wenn ein neues System, warum dann nicht gleich eisfair64 einsetzen und genau so sehe ich es auch. Eisfair2 und Eisfair-NG hatte ja nicht so geklappt, bei mir mangels Hardware. Bei eis64 könnte ich mir durchaus vorstellen, dass es irgend wann eine eisfair x86_x64 iso gibt und Pakete beide Plattformen bedienen. Sicher, auf unserer Fahne steht, eisfair ist ein Server auch für ältere Hardware aber was vor zwölf Jahren ältere Hardware war hat heute sicher keiner mehr im Keller zu stehen. Und ich sehe mich da schon als ewig gestriger. Evtl. mal ein Aufruf hier um zu sehen, was überhaupt noch muss?
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 15:22:19 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
> Ich werde jetzt eis64 für meinen neuen eisfair einsetzen. Ich glaube Du > sagtest es, wenn ein neues System, warum dann nicht gleich eisfair64 > einsetzen und genau so sehe ich es auch.
Schau einfach nach, ob es essentielle Pakete gibt, die noch nicht füpr eisfair-64 zur Verfügung stehen - das sollten wenige sein. eisgraph ist so ein Kandidat, die Hintergründe hierzu sind hinlänglich bekannt, technisch gibt es da keine Gründe.
> Eisfair2 und Eisfair-NG hatte ja nicht so geklappt,
Page 102 of 165 ---- Generated from net(t)forum Das kann man nicht vergleichen. eisfair-1 und eisfair-64 basieren auf der gleichen "Ideologie", es musste nur alles neu übersetzt werden, die ganze Konfigurationsschicht ist davon unberührt.
> bei mir mangels Hardware. Bei eis64 könnte ich mir > durchaus vorstellen, dass es irgend wann eine eisfair x86_x64 iso gibt > und Pakete beide Plattformen bedienen.
Das verstehe ich jetzt nicht?
Es gibt Installer für eis64 und eis1, welchen Vorteil bringt ein gemeinsamer Installer?
Die meisten Pakete gibt es inzwischen als eis1- und eis64-Pakete oder eben als auf beiden Systemen einsetzbare noarch-Pakete.
> Sicher, auf unserer Fahne steht, > eisfair ist ein Server auch für ältere Hardware aber was vor zwölf > Jahren ältere Hardware war hat heute sicher keiner mehr im Keller zu > stehen.
Die wird nach und nach sterben, aber mein eis1 läuft noch mit einem Asus P4P800, BIOS 080009 08/20/2003; mal sehen, ob er noch die Volljährigkeit erreicht.
> Und ich sehe mich da schon als ewig gestriger. > Evtl. mal ein Aufruf hier um zu sehen, was überhaupt noch muss?
Für mich muss alles, was noch nicht definitiv Schrott ist. Besonders alte Hardware scheint da auch besonders robust zu sein - eben Wertarbeit.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Tue, 05 Mar 2019 15:31:24 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 01:09 schrieb Hilmar Böhm: > Am 04.03.19 um 22:33 schrieb Thomas Bork: >> Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: >> >>> Zu Eisfair: >>> Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" >>> die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's >>> gibt es praktisch keine Wartezeiten mehr für die vHD's. >> >> Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat >> niemand mehr getestet, ob mit neuerem Kernel mit kürzeren Denkpausen
Page 103 of 165 ---- Generated from net(t)forum >> noch alles funktioniert. >> >> Auszug aus dem Kernel-Install-Skript (Funktion zur Erzeugung der >> initramfs): >> ... >> ... >> >> # always waiting for devices coming up >> { >> echo '/bin/echo -e "\033[32m\033[49mWaiting for SCSI/SATA/PATA >> devices coming up ...\033[0m"' >> echo '/bin/sleep 10' >> } >>$initrd_mount/init >> fi >> >> >> Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen >> Installationen mit einem kürzeren Delay durchzutesten (Installation >> und darauf folgenden Boot von und auf einen langsamen USB-1-Stick, >> Installation auf ein gemischtes Array aus IDE-, SCSI- und >> SATA-Platten, die an verschiedenen Controllern unterschiedlich lange >> benötigen, um alle bereit zu sein usw.) und das alles auf Hardware, >> die nicht aus den letzten 5 Jahren stammt: >> Dann können wir das gerne mal ändern. >> Wer macht es? Du? >> > Wenn Du mich meinst: Nein! > (Keine Zeit, bin (in diesem Fall) nur Anwender.)
Na und, Ich auch. Aber vielleicht war das ein Angebot von Thomas die einen kernel mit kürzerem Delay zu schicken. Du must ihn dann bei dir allerdings installieren, aktivieren, booten und sehen ob wirklich alles immer gefunden und eingebunden wird.
> Zu dem Block " #always waiting for devices coming up" > kann ich nur sagen, dass eine VM auf einem Host läuft, der i.d.R. einen > virt. Spreicher (vHD) für die VM bereits zur Verfügung hat, wenn die VM > auf ihm gestartet wird. Also keine Wartezeiten erforderlich. Warum nicht > einfach diese 10 Sek. sleep weglassen?
Du verstehst da glaube ich noch etwas nicht richtig. Das wäre eine Optimierung hin zu VM-Betrieb. Und weil der kernel nicht nur für VMs taugt, sondern insbesondere auch für Reale ältere HW mit realen Verzögerungen beim Hochfahren. So kann es dir z.B. passieren das dein root-dev auf einer IDE oder S-ATA Platte noch schnell gefunden würde, wenn du aber einen SCSI-Controller hast und der kein RAID macht, die Platten aber an einer SCA-Backplane hängen und auf Soft-start eingestellt sind... dann mußt du dich drauf verlassen das keiner den Controller in seinem Setup umstellte. Denn dann ist DER es der jeder einzelnen Platte erst ein Start Signal schicken muß. Bis die Hochgelaufen sind kann das etliche Sekunden dauern. Üblicherweise macht der das Sequenziell, aber die PlattenID kann er m.E. auch vorher schon
Page 104 of 165 ---- Generated from net(t)forum lesen. Die Platten sind also evtl. noch am Hochdrehen, der Controller durch damit und das OS startet.... und findet diese nicht weil sie noch nicht Ready sind. Und dann könnte es auch sein das man keine U320 Disk hat, sondern eine SCSI-1 (oder emulator) die evtl. grad mal 5 MB/sek liefern kann. Dann kann es noch länger dauern.
Ich habe damals z.b. eine SyQuest Wechselplatte mit 66 MB als Bootmedium ausprobiert. Die hing an einem einfachen FAST-SCSI Kontroller und war dennoch schnarchlangsam. Das war allerdings noch DOS. Ich zweifele Ernsthaft ob die von einem EIS beim Boot überhaupt gefunden werden würde. Die Braucht nach einlegen und aktivieren ca. 20 Sekunden bis sie überhaupt brauchbar ist. Und, je nach Konfig kann man so was als Wechsellaufwerk(=Floppy) oder als Festes Laufwerk(=Disk) betreiben. Bei letzterem könnte sie nicht fest gemountet werden wenn sie nicht bereit ist.
> Andere (Server-)Systeme anderer Distributionen stellen heutzutage fest, > ob ihr Kernel in einer VM läuft. > Wollte nur zeigen, dass es geht.
Brauchst du nicht zeigen, ist bekannt.
Das kann der Kernel selbst am besten und ganz allein feststellen. Aber der Nebeneffekt eines Verkürzten Delays könnte sein das der kernel auf Echter HW nicht mehr Jedes Laufwerk findet und das noch mehr Ärger Produziert. Und das nur weil du ein Problem mit 10 Sekunden Warten hast. Nee, danke. Da erWARTEst du etwas zu viel für meinen Geschmack.
> Aber wenn ich der einzige bin, dem das > aufstößt und wenn das bei einem Server keine Rolle spielt (oder ich nur > "auf hohem Niveau jammere"), dann lassen wir es halt so. wie ist...
Damit hätte ich kein Problem. :-)
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: pcspkr (et al) Posted by kay on Tue, 05 Mar 2019 15:47:35 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 08:08 schrieb Marcus Roeckrath: > > Hilmar Böhm wrote: > >> Es gibt keine Erkenntnisse, die mich der Ursache näher bringen. Habe die >> Echos für Start- und Stop-Zeiten in die Startskripts eingetragen, und zwar >> in die start() - Blöcke, soweit vorhanden. Die werden vermutlich beim
Page 105 of 165 ---- Generated from net(t)forum >> Systemstart durchlaufen ?! > >> Hier die Zeiten, die ich in eine Log-Datei schreiben ließ: >> ------>> Mon Mar 4 23:07:15 CET 2019 = Stop in S07mountfs
!!!
>> Was auffällt, dass die Anzeige der eingebauten Echos erst mit S07mountfs >> beginnt. Ich habe sie auch in alle Skripts davor eingebaut (auch in die >> S01/s02xxx -Skripte). Übrigens beginnt sie auch mit dem Stop im mountfs. > > Das verstehe ich derzeit auch noch nicht, denn auch diese Skripte erzeugen > ja ihrerseits Ausgaben.
Im syslog? Im logpuffer des kernels (dmesg)?
> Denkbar wäre allerdings, dass das echo nicht funktioniert ohne einen Fehler > rauszuschmeißen. Ich denke, der $(date) Befehl steht noch nicht zur > Verfügung, da date ein externen Kommando ist.
Mit mountfs werden doch sicherlich erst die Dateisysteme RW Gemountet. Wo sollen davor also die Logausgaben hin geschrieben werden wenn noch nichts gemountet ist. In die initramfs?
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 15:59:43 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 16:22 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Detlef Paschke wrote: > >> Ich werde jetzt eis64 für meinen neuen eisfair einsetzen. Ich glaube Du >> sagtest es, wenn ein neues System, warum dann nicht gleich eisfair64 >> einsetzen und genau so sehe ich es auch. > > Schau einfach nach, ob es essentielle Pakete gibt, die noch nicht füpr > eisfair-64 zur Verfügung stehen - das sollten wenige sein.
Page 106 of 165 ---- Generated from net(t)forum ich habe extra im Vorfeld nachgefragt und gewartet bis für eis64 alles da ist was ich brauche. :-)
> Das kann man nicht vergleichen. eisfair-1 und eisfair-64 basieren auf der > gleichen "Ideologie", es musste nur alles neu übersetzt werden, die ganze > Konfigurationsschicht ist davon unberührt. > >> bei mir mangels Hardware. Bei eis64 könnte ich mir >> durchaus vorstellen, dass es irgend wann eine eisfair x86_x64 iso gibt >> und Pakete beide Plattformen bedienen. > > Das verstehe ich jetzt nicht? > > Es gibt Installer für eis64 und eis1, welchen Vorteil bringt ein gemeinsamer > Installer?
Ich könnte mir vorstellen, dass es doch weniger Arbeit ist, wenn man nur ein System pflegen muss was für x86 und 64 funktioniert. Bei den Paketen doch genauso oder? Jetzt, in der Umstellungsphase haben wir da noch zwei Reiter auf Packeis aber dann? Ist es nicht einfacher ein Paket was bei beiden Funktioniert?
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 16:04:31 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
>> Denkbar wäre allerdings, dass das echo nicht funktioniert ohne einen >> Fehler rauszuschmeißen. Ich denke, der $(date) Befehl steht noch nicht >> zur Verfügung, da date ein externen Kommando ist. > > Mit mountfs werden doch sicherlich erst die Dateisysteme RW Gemountet. > Wo sollen davor also die Logausgaben hin geschrieben werden wenn noch > nichts gemountet ist. In die initramfs?
Di echos schreiben auf die Konsole, ich habe bewußt nicht in eine Datei schreiben lassen, da zum fraglichen Zeitpunkt nicht gewährleistet ist, dass da etwas schreibbar gemountet ist.
Page 107 of 165 ---- Generated from net(t)forum -- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 16:07:09 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Es gibt Installer für eis64 und eis1, welchen Vorteil bringt ein >> gemeinsamer Installer? > > Ich könnte mir vorstellen, dass es doch weniger Arbeit ist, wenn man nur > ein System pflegen muss was für x86 und 64 funktioniert. Bei den Paketen > doch genauso oder? Jetzt, in der Umstellungsphase haben wir da noch zwei > Reiter auf Packeis aber dann? Ist es nicht einfacher ein Paket was bei > beiden Funktioniert?
Wir müssen doch sowieso alles zweimal durch den Compiler schieben.
Die Pakete sind für eis1 und eis64 bis auf die Binaries identisch.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Tue, 05 Mar 2019 16:13:10 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 16:59 schrieb Detlef Paschke: > Am 05.03.2019 um 16:22 schrieb Marcus Roeckrath: > >> Das kann man nicht vergleichen. eisfair-1 und eisfair-64 basieren auf der >> gleichen "Ideologie", es musste nur alles neu übersetzt werden, die ganze >> Konfigurationsschicht ist davon unberührt. >> >> Es gibt Installer für eis64 und eis1, welchen Vorteil bringt ein gemeinsamer >> Installer? > > Ich könnte mir vorstellen, dass es doch weniger Arbeit ist, wenn man nur > ein System pflegen muss was für x86 und 64 funktioniert. Bei den Paketen > doch genauso oder? Jetzt, in der Umstellungsphase haben wir da noch zwei > Reiter auf Packeis aber dann? Ist es nicht einfacher ein Paket was bei > beiden Funktioniert?
Die Großen Distributionen machen es auch so. Sie haben einen 32-bit Ast (den sie gern absägen möchten) einen 64-bit Ast und einen NoArch-Bereich
Page 108 of 165 ---- Generated from net(t)forum in dem nur sachen drin stecken die nicht von der Bitbreite des Systems abhängig sind.
Eisfair soll aber ja explizit auch ältere (nur 32bit) taugliche HW bedienen können (jedenfalls auf Absehbare Zeit, denke ich noch) und daher gibt es eben die 32-bit Pakete UND die 64-Bit Pakete - die eben quasi nur die für 64-bit neu übersetzten 32-bit Programme sind. Das zusammenfassen zu wollen wäre in etwa so wie die Universal-APPS für Windows. So lange es nicht mehr Arbeit macht als ein automatisiertes neu übersetzen mit einem 64-bit Schalter ist das wohl überschaubar wenig Aufwand. Und eine Änderung nicht nötig.
Und alles an scripten o.ä. das selbst keine binärprogramme enthielte ist eh davon unabhängig, also NoArch (svw. NotArchitecture-dependent)
Du kannst also z.b. durchaus ein 32-bit 'ls' in einem NoArch Paket benutzen. Oder auch ein 64-bit 'ls' weil es dann halt auch NUR 'ls' heißt.
Anders ist es beim Netzwerk. Da gibt es z.B. die Unterscheidung zwischen 'ping' und 'ping6' für das IPv6. Dennoch können die beteiligten Programme entweder für 32-bit oder für 64-bit übersetzt sein.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 16:21:51 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 17:07 schrieb Marcus Roeckrath: > Hallo Detlef,
Hallo Marcus,
> Wir müssen doch sowieso alles zweimal durch den Compiler schieben. > > Die Pakete sind für eis1 und eis64 bis auf die Binaries identisch. ich dachte an die Übersicht auf der Webseite von eisfair aber evtl. täuscht mich mein Eindruck auch.
Was mich aber sicher nicht täuscht, dieses Ding hier ist sicher nicht mehr lesbar. Geschnatter gibt es nicht mehr, lass uns ein neues Thema aufmachen wenn Bedarf zum quatschen über Eisfair im allgemeinen und besonderen ist. Zwei Bier finden sich. :-)
Viele Grüße Detlef Paschke
Page 109 of 165 ---- Generated from net(t)forum -- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 16:32:07 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 17:13 schrieb Kay Martinen:
Hallo Kay,
> Eisfair soll aber ja explizit auch ältere (nur 32bit) taugliche HW > bedienen können (jedenfalls auf Absehbare Zeit, denke ich noch) und > daher gibt es eben die 32-bit Pakete UND die 64-Bit Pakete - die eben > quasi nur die für 64-bit neu übersetzten 32-bit Programme sind. Das > zusammenfassen zu wollen wäre in etwa so wie die Universal-APPS für > Windows. So lange es nicht mehr Arbeit macht als ein automatisiertes neu > übersetzen mit einem 64-bit Schalter ist das wohl überschaubar wenig > Aufwand. Und eine Änderung nicht nötig. ja natürlich, ich bin ja selbst drauf angewiesen. Ich kann mir keinen i7 in den Keller stellen der hier meine Freizeitbeschäftigung und mein Homeserver ist. Ich habe mir das vermutlich wieder alles viel zu einfach vorgestellt.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 16:34:28 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
> Die Großen Distributionen machen es auch so. Sie haben einen 32-bit Ast > (den sie gern absägen möchten) einen 64-bit Ast und einen NoArch-Bereich > in dem nur sachen drin stecken die nicht von der Bitbreite des Systems > abhängig sind.
Page 110 of 165 ---- Generated from net(t)forum Exakt so ist es auch bei eisfair; auch bei SuSE gibt es ein Paket als 32- und 64-bit-Paket erkennbar an einem Teil des Paketdateinamens x86 vs. x86_64.
> Eisfair soll aber ja explizit auch ältere (nur 32bit) taugliche HW > bedienen können (jedenfalls auf Absehbare Zeit, denke ich noch) und > daher gibt es eben die 32-bit Pakete UND die 64-Bit Pakete - die eben > quasi nur die für 64-bit neu übersetzten 32-bit Programme sind.
Genauer: Eine Source, die grundsätzlich beliebig bittig ist, wird mal mit dem Kompilerschalter für 32bit und dann noch mit dem für 64bit übersetzt.
> Das > zusammenfassen zu wollen wäre in etwa so wie die Universal-APPS für > Windows.
Mir sind unter Linux noch keine solchem Kombi-Kompilate untergekommen - die wären/sind natürlich auch aufgebläht.
> Und alles an scripten o.ä. das selbst keine binärprogramme enthielte ist > eh davon unabhängig, also NoArch (svw. NotArchitecture-dependent) > > Du kannst also z.b. durchaus ein 32-bit 'ls' in einem NoArch Paket > benutzen. Oder auch ein 64-bit 'ls' weil es dann halt auch NUR 'ls' heißt.
Wenn man in Skripten etwas Binäres aufrufen will, braucht man sich darüber überhaupt keinen Kopf machen, nun das richtig bittige Programm aufzurufen.
Solange alle notwendigen Libraries auf eis64 auch zusätzlich als 32-bit-Variante vorliegen, laufen auch 32-bittig kompilierte Programme.
Es gibt auf eis64 auch alle Libs zusätzlich als 32-bit, die dann als Paket libXYZ-32bit heißen.
Für Programmpakete haben wir uns allerdings entschieden, diese als echte 64-bit-Pakete zu machen.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 16:36:53 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
>> Wir müssen doch sowieso alles zweimal durch den Compiler schieben. >>
Page 111 of 165 ---- Generated from net(t)forum >> Die Pakete sind für eis1 und eis64 bis auf die Binaries identisch. > > ich dachte an die Übersicht auf der Webseite von eisfair aber evtl. > täuscht mich mein Eindruck auch.
Noch sind die Listen nicht identisch, so kann man nun leichter nachsehen, was es für eis64 gibt.
> Was mich aber sicher nicht täuscht, dieses Ding hier ist sicher nicht > mehr lesbar. Geschnatter gibt es nicht mehr, lass uns ein neues Thema > aufmachen wenn Bedarf zum quatschen über Eisfair im allgemeinen und > besonderen ist. Zwei Bier finden sich. :-)
Hast recht, das schweift ja nun auch immer weiter vom eigentlichen Problem ab.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Hilix on Tue, 05 Mar 2019 16:39:25 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 05.03.19 um 17:04 schrieb Marcus Roeckrath: > ich habe bewußt nicht in eine Datei > schreiben lassen, da zum fraglichen Zeitpunkt nicht gewährleistet ist, dass > da etwas schreibbar gemountet ist. ich hab's verstanden! :) Werde als nächstes die "Log"-Datei wieder aus den echos rausschmeisen... Gruß. / Hilmar.
....meine Frage nach gpm o.ä. blieb bislang unbeantwortet; es wäre (nicht nur in diesem Fall) nützlich. Ich werde nicht noch mal den Bildschirm abtippen, wie beim letzten mal. Habe aber noch eine andere Idee...
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 16:46:56 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
>> ich habe bewußt nicht in eine Datei
Page 112 of 165 ---- Generated from net(t)forum >> schreiben lassen, da zum fraglichen Zeitpunkt nicht gewährleistet ist, >> dass da etwas schreibbar gemountet ist. > > ich hab's verstanden! :) > Werde als nächstes die "Log"-Datei wieder aus den echos rausschmeisen...
Du hast meinen Vorschlag in etwa so abgewandelt? echo irgendwas >> irgendeinedatei
Das geht natürlich erst nach dem Read-Mounten der Partitionen.
> ...meine Frage nach gpm o.ä. blieb bislang unbeantwortet; es wäre (nicht > nur in diesem Fall) nützlich. Ich werde nicht noch mal den Bildschirm > abtippen, wie beim letzten mal. Habe aber noch eine andere Idee...
Film mit Smartphone machen, falls das nicht die Bildwiederholfrequenz des Filmes "überlastet" und es dann doch nicht gescheit lesbar ist.
Die Echos waren auch nicht dazu gedacht, dass du nun das uns wortgetreu präsentierst, sondern uns mitteilen kannst, welcher davon lange braucht oder ob zwischen zwei aufeinanderfolgenden davon eine lange Pause ist.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 17:22:20 GMT View Forum Message <> Reply to Message Hallo,
Marcus Roeckrath wrote:
> Du hast meinen Vorschlag in etwa so abgewandelt? > > echo irgendwas >> irgendeinedatei > > Das geht natürlich erst nach dem Read-Mounten der Partitionen.
ReadWrite-Mounten!!!!
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Tue, 05 Mar 2019 18:30:27 GMT View Forum Message <> Reply to Message
Page 113 of 165 ---- Generated from net(t)forum Am 05.03.2019 um 17:21 schrieb Detlef Paschke: > Am 05.03.2019 um 17:07 schrieb Marcus Roeckrath: >> Hallo Detlef, > > Hallo Marcus, > >> Wir müssen doch sowieso alles zweimal durch den Compiler schieben. >> >> Die Pakete sind für eis1 und eis64 bis auf die Binaries identisch. > > ich dachte an die Übersicht auf der Webseite von eisfair aber evtl. > täuscht mich mein Eindruck auch. > > Was mich aber sicher nicht täuscht, dieses Ding hier ist sicher nicht > mehr lesbar.
Ich hab da wohl eine höhere Toleranzschwelle, nach einem wahren Monsterthread in einer Linux-gruppe der vor Wochen schon die 700 Posts-Marke knackte, und vermutlich immer noch läuft. Dürften inzwischen die 1000 Erreichen. Und in d.a.f.c. sind längere Threads die mal vom Thema abrutschen auch nicht selten.
Lesbarkeit ist dabei eher eine Sache des Fokus. Und wie man den NUA bedient.
Bezüglich E-64 und Proxmox mag hierzuthread in der Tat kein Fortschritt mehr zustande kommen. Dennoch möchte ich noch mal anmerken das EIS bei mir unter Proxmox gut läuft und das auch als Simple Installation (ohne Virt-schnick-schnack) ich für den E-64 aber bisher hier noch keinen Vorteil sehe, da der Host eh nur 12 GB hat. Mehr RAM könnte aber auch ein 32-bittiger EIS nutzen und die Absolute Spitzenperformance strebe ich eh nicht an.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: pcspkr (et al) Posted by kay on Tue, 05 Mar 2019 18:34:55 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 18:22 schrieb Marcus Roeckrath: > Hallo, > > Marcus Roeckrath wrote: > >> Du hast meinen Vorschlag in etwa so abgewandelt? >> >> echo irgendwas >> irgendeinedatei >>
Page 114 of 165 ---- Generated from net(t)forum Das war auch gleich mein Verdacht da logdatei und ...
>> Das geht natürlich erst nach dem Read-Mounten der Partitionen. > > ReadWrite-Mounten!!!! >
Ich dachte schon...
Aber ROM (ReadOnlyMemory) Beschreiben... das hätte doch was. ;-) Panic: Bootloader not found, overwritten. :-))
(JFTR: Keine Angst, war nur Spaß. So was geht nicht einfach so!)
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 18:59:09 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
> ich für den E-64 aber bisher hier noch keinen > Vorteil sehe, da der Host eh nur 12 GB hat. Mehr RAM könnte aber auch > ein 32-bittiger EIS nutzen und die Absolute Spitzenperformance strebe > ich eh nicht an.
Bei Neuinstallationen würde ich aus folgenden Gründen immer für eis64 plädieren:
1. 32-bit-eisfair kann zwar mit dem PAE-Kernel mehr als 4 GB Speicher nutzen, aber nur mit technischen "Krücken" die Performance kosten (Mapping) und jeder einzelnen Anwendung steht niemals mehr als 4GB Speicher zur Verfügung.
2. eisfair-64 und 64bit-Anwendungen können linear Speichermengen über 4 GB bis zu einem für Normalanwender nicht finanziell leistbaren Bereich nutzen.
3. Ein 64-Bit-Prozessor arbeitet IMHO mit nativer 64-bit-Software effektiver.
4. Es gibt Anwendungen, die 64bit erfordern und das wird irgendwann auch bestimmt auf eis so sein.
Page 115 of 165 ---- Generated from net(t)forum Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die Hardware 64bit kann.
-- Gruss Marcus
Subject: E-64 (was: Noch mal Eisfair(64) und Proxmox (Perfomance)) Posted by kay on Tue, 05 Mar 2019 20:07:39 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 19:59 schrieb Marcus Roeckrath: > Hallo Kay, > > Kay Martinen wrote: > >> ich für den E-64 aber bisher hier noch keinen >> Vorteil sehe, da der Host eh nur 12 GB hat. Mehr RAM könnte aber auch >> ein 32-bittiger EIS nutzen und die Absolute Spitzenperformance strebe >> ich eh nicht an. > > Bei Neuinstallationen würde ich aus folgenden Gründen immer für eis64 > plädieren: > > 1. 32-bit-eisfair kann zwar mit dem PAE-Kernel mehr als 4 GB Speicher > nutzen, aber nur mit technischen "Krücken" die Performance kosten (Mapping) > und jeder einzelnen Anwendung steht niemals mehr als 4GB Speicher zur > Verfügung.
Keine meiner E1 VMs braucht so viel RAM, und ich auch nicht. Noch nicht. DIE "Killer-App" dazu sehe ich noch nicht.
> 2. eisfair-64 und 64bit-Anwendungen können linear Speichermengen über 4 GB > bis zu einem für Normalanwender nicht finanziell leistbaren Bereich nutzen.
Du meinst die Speicherpreise jenseits von xx GB? Das ändert sich vielleicht, vielleicht auch nicht. Derzeit brauch ich auch das nicht.
> 3. Ein 64-Bit-Prozessor arbeitet IMHO mit nativer 64-bit-Software > effektiver.
Guter Punkt wenn er stimmt. Ich hab das nie nachgeprüft. Nur kürzlich gelesen das Spectre und Meltdown Patches viel Leistung kosteten und dies im neuen Kernel 5.0 zu einem gewissen Teil wieder kompensiert wird.
An nach wie vor eigentlich Defekten CPUs ändert das kein bisschen und wann EIS kernel 5.0 bekommt... oder überhaupt mal... ???
Page 116 of 165 ---- Generated from net(t)forum > 4. Es gibt Anwendungen, die 64bit erfordern und das wird irgendwann auch > bestimmt auf eis so sein.
Das wird bei EIS dann wohl den Einstieg vom Ausstieg auf der 32-bit Schiene einläuten. Und damit all meine Alt-HW die nur 32Bit kann obsolet machen - für EIS.
> Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die Hardware > 64bit kann.
Ja, WENN sie es kann. Noch lebt sie!
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Detlef Paschke on Tue, 05 Mar 2019 20:14:36 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 19:30 schrieb Kay Martinen:
Hallo Kay,
> Lesbarkeit ist dabei eher eine Sache des Fokus. Und wie man den NUA bedient. ich sehe dass eher für die Allgemeinheit und weiß auch, wie sich solche Threads im Archiv lesen, wenn man in Jahren mal etwas sucht.
> Bezüglich E-64 und Proxmox mag hierzuthread in der Tat kein Fortschritt > mehr zustande kommen. Dennoch möchte ich noch mal anmerken das EIS bei > mir unter Proxmox gut läuft und das auch als Simple Installation (ohne > Virt-schnick-schnack) ich für den E-64 aber bisher hier noch keinen > Vorteil sehe, da der Host eh nur 12 GB hat. Mehr RAM könnte aber auch > ein 32-bittiger EIS nutzen und die Absolute Spitzenperformance strebe > ich eh nicht an.
Wie schon erwähnt, ich baue mir nun nach wirklich vielen Jahren einen völlig neuen Eisfair auf und da mir eis64 im Gegensatz zu den von Anfang an schwächelnden eisfair2 und eisfair-ng als der nächste bleibende Schritt erscheint, habe ich mich für Eisfair64 entschieden.
Die VM-Geschichte hatte ich schon mal angesprochen. Vor ca. zehn Jahren durfte ich mal im Rahmen eines "Projekt für behinderte Menschen" (nicht lachen) einige Zeit im hiesigen Klinikum in die Serverräume und wurde etwas mit Servervirtualisierung vertraut gemacht. Von da an war ich eigentlich infiziert, hatte nur nicht die geeignete Hardware zur Verfügung um selbst in Servervirtualisierung einzusteigen.
Page 117 of 165 ---- Generated from net(t)forum Mein derzeitiger eisfair hat über die Jahre schon einiges an Veränderungen erlebt und da sind sicher noch etliche Sachen drauf die längst keiner mehr Braucht. Viele Sachen hat man früher Kompiliert, die es jetzt als Pakete gibt, ganz schnell fällt mir da scannbuttond ein. Und ein (neuer) virtualisierter Server kann natürlich schnell mal neu zum basteln aufgesetzt werden.
> Kay
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: E-64 (was: Noch mal Eisfair(64) und Proxmox (Perfomance)) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 20:26:23 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
>> 3. Ein 64-Bit-Prozessor arbeitet IMHO mit nativer 64-bit-Software >> effektiver. > > Guter Punkt wenn er stimmt. Ich hab das nie nachgeprüft. Nur kürzlich > gelesen das Spectre und Meltdown Patches viel Leistung kosteten und dies > im neuen Kernel 5.0 zu einem gewissen Teil wieder kompensiert wird.
Uns fehlt noch der gcc mit retpoline-Patch, was deutlich weniger (wenn überhaupt) Leistung bei der Verhinderung von Spectre/Meltdown kostet, als die massnahmen auf Microcode-Ebene.
> An nach wie vor eigentlich Defekten CPUs ändert das kein bisschen und > wann EIS kernel 5.0 bekommt... oder überhaupt mal... ???
IMHO gibt es noch keine CPU, die die Macken nicht hat; kapuut bei Design, sagen machen.
>> 4. Es gibt Anwendungen, die 64bit erfordern und das wird irgendwann auch >> bestimmt auf eis so sein. > > Das wird bei EIS dann wohl den Einstieg vom Ausstieg auf der 32-bit > Schiene einläuten.
Standardsoftware wird man noch lange auch in 32bit übersetzen können.
Page 118 of 165 ---- Generated from net(t)forum Ohne das nun aktuell für eisfair in Spiel bringen zu wollen, geht z. B. Docker wohl nur als 64-bit.
> Und damit all meine Alt-HW die nur 32Bit kann obsolet > machen - für EIS.
Solange man dann irgendwann nicht 64bit-Spezialitäten nutzen will, kann das bis zum Hardwaretod weiterlaufen.
>> Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die >> Hardware 64bit kann. > > Ja, WENN sie es kann. Noch lebt sie!
Deswegen sagte ich ja auch, Neuinstallation auf 64bit-Hatrdware, von der Umstellung bestehnder Installationne sprach ich nicht.
Wer jetzt neu installiert und passende Hardware hat, ist zukunftssicherer mit eisfair-64 aufgestellt.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Hilix on Tue, 05 Mar 2019 20:42:06 GMT View Forum Message <> Reply to Message Hallo Marcus.
Oh Mannn! Ich hab's verstanden! (Ich sitze hier mit gerötetem Kopf! Es ist mir peinlich, ein solchen Fehler gemacht zu haben!)
Filmen ist nicht nötig. Die virt-manager-Konsole kann Snapshots der Bildschirmausgabe machen. Von den 14 Start-Scripts fallen 2 aus der Reihe; die Laufzeiten der restlichen liegen bei max. 1 Sek. (wahrscheinlich deutlich darunter).
S09console braucht ~ 4 Sek. S03udev braucht ~27 Sek. !! ------Das lange Wait ist zwischen der letzte Ausgabe aus S03udev und dem S03udev-Ende. Zwischen den einzelnen Scripts gibt es keine erkennbaren Pausen.
[Insgesamt braucht die E64-VM (Basic!) auf diesem System ~69 Sek. bis zum Login. Das ist deutlich über einer Minute! (Zum Vergleich: Auf dem gleichen System braucht (unter gleichen Bedingungen) die
Page 119 of 165 ---- Generated from net(t)forum Antergos-Minimal-VM (auch ohne GUI) ~25 Sek. bis zum Login.)]
Jetzt müsste man sich fragen, was die ungewöhnlich lange Laufzeit des udev-Startscripts verursacht. Da muss ich aber passen. Ich kann Dir gerne die scrennshot.png's per PM zusenden, wenn's interessiert.
Sag mir bitte, wie's (wenn's) weiter gehen soll. Helfe gerne, wenn ich kann.
Gruß. / Hilmar.
Am 05.03.19 um 17:46 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >>> ich habe bewußt nicht in eine Datei >>> schreiben lassen, da zum fraglichen Zeitpunkt nicht gewährleistet ist, >>> dass da etwas schreibbar gemountet ist. >> >> ich hab's verstanden! :) >> Werde als nächstes die "Log"-Datei wieder aus den echos rausschmeisen... > > Du hast meinen Vorschlag in etwa so abgewandelt? > > echo irgendwas >> irgendeinedatei > > Das geht natürlich erst nach dem Read-Mounten der Partitionen. > >> ...meine Frage nach gpm o.ä. blieb bislang unbeantwortet; es wäre (nicht >> nur in diesem Fall) nützlich. Ich werde nicht noch mal den Bildschirm >> abtippen, wie beim letzten mal. Habe aber noch eine andere Idee... > > Film mit Smartphone machen, falls das nicht die Bildwiederholfrequenz des > Filmes "überlastet" und es dann doch nicht gescheit lesbar ist. > > Die Echos waren auch nicht dazu gedacht, dass du nun das uns wortgetreu > präsentierst, sondern uns mitteilen kannst, welcher davon lange braucht > oder ob zwischen zwei aufeinanderfolgenden davon eine lange Pause ist. >
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Hilix on Tue, 05 Mar 2019 20:49:00 GMT View Forum Message <> Reply to Message Hallo Kay,
Sei mir bitte nicht böse, aber ich glaube, Du hast mit nicht verstanden.
Page 120 of 165 ---- Generated from net(t)forum Gruß. / Hilmar.
Am 05.03.19 um 16:31 schrieb Kay Martinen: > Am 05.03.2019 um 01:09 schrieb Hilmar Böhm: >> Am 04.03.19 um 22:33 schrieb Thomas Bork: >>> Am 03.03.2019 um 22:53 schrieb Hilmar Böhm: >>> >>>> Zu Eisfair: >>>> Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up" >>>> die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's >>>> gibt es praktisch keine Wartezeiten mehr für die vHD's. >>> >>> Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat >>> niemand mehr getestet, ob mit neuerem Kernel mit kürzeren Denkpausen >>> noch alles funktioniert. >>> >>> Auszug aus dem Kernel-Install-Skript (Funktion zur Erzeugung der >>> initramfs): >>> ... >>> ... >>> >>> # always waiting for devices coming up >>> { >>> echo '/bin/echo -e "\033[32m\033[49mWaiting for SCSI/SATA/PATA >>> devices coming up ...\033[0m"' >>> echo '/bin/sleep 10' >>> } >>$initrd_mount/init >>> fi >>> >>> >>> Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen >>> Installationen mit einem kürzeren Delay durchzutesten (Installation >>> und darauf folgenden Boot von und auf einen langsamen USB-1-Stick, >>> Installation auf ein gemischtes Array aus IDE-, SCSI- und >>> SATA-Platten, die an verschiedenen Controllern unterschiedlich lange >>> benötigen, um alle bereit zu sein usw.) und das alles auf Hardware, >>> die nicht aus den letzten 5 Jahren stammt: >>> Dann können wir das gerne mal ändern. >>> Wer macht es? Du? >>> >> Wenn Du mich meinst: Nein! >> (Keine Zeit, bin (in diesem Fall) nur Anwender.) > > Na und, Ich auch. Aber vielleicht war das ein Angebot von Thomas die > einen kernel mit kürzerem Delay zu schicken. Du must ihn dann bei dir > allerdings installieren, aktivieren, booten und sehen ob wirklich alles > immer gefunden und eingebunden wird. > >> Zu dem Block " #always waiting for devices coming up" >> kann ich nur sagen, dass eine VM auf einem Host läuft, der i.d.R. einen
Page 121 of 165 ---- Generated from net(t)forum >> virt. Spreicher (vHD) für die VM bereits zur Verfügung hat, wenn die VM >> auf ihm gestartet wird. Also keine Wartezeiten erforderlich. Warum nicht >> einfach diese 10 Sek. sleep weglassen? > > Du verstehst da glaube ich noch etwas nicht richtig. Das wäre eine > Optimierung hin zu VM-Betrieb. Und weil der kernel nicht nur für VMs > taugt, sondern insbesondere auch für Reale ältere HW mit realen > Verzögerungen beim Hochfahren. So kann es dir z.B. passieren das dein > root-dev auf einer IDE oder S-ATA Platte noch schnell gefunden würde, > wenn du aber einen SCSI-Controller hast und der kein RAID macht, die > Platten aber an einer SCA-Backplane hängen und auf Soft-start > eingestellt sind... dann mußt du dich drauf verlassen das keiner den > Controller in seinem Setup umstellte. Denn dann ist DER es der jeder > einzelnen Platte erst ein Start Signal schicken muß. Bis die > Hochgelaufen sind kann das etliche Sekunden dauern. Üblicherweise macht > der das Sequenziell, aber die PlattenID kann er m.E. auch vorher schon > lesen. Die Platten sind also evtl. noch am Hochdrehen, der Controller > durch damit und das OS startet.... und findet diese nicht weil sie noch > nicht Ready sind. Und dann könnte es auch sein das man keine U320 Disk > hat, sondern eine SCSI-1 (oder emulator) die evtl. grad mal 5 MB/sek > liefern kann. Dann kann es noch länger dauern. > > Ich habe damals z.b. eine SyQuest Wechselplatte mit 66 MB als Bootmedium > ausprobiert. Die hing an einem einfachen FAST-SCSI Kontroller und war > dennoch schnarchlangsam. Das war allerdings noch DOS. Ich zweifele > Ernsthaft ob die von einem EIS beim Boot überhaupt gefunden werden > würde. Die Braucht nach einlegen und aktivieren ca. 20 Sekunden bis sie > überhaupt brauchbar ist. Und, je nach Konfig kann man so was als > Wechsellaufwerk(=Floppy) oder als Festes Laufwerk(=Disk) betreiben. Bei > letzterem könnte sie nicht fest gemountet werden wenn sie nicht bereit ist. > >> Andere (Server-)Systeme anderer Distributionen stellen heutzutage fest, >> ob ihr Kernel in einer VM läuft. >> Wollte nur zeigen, dass es geht. > > Brauchst du nicht zeigen, ist bekannt. > > Das kann der Kernel selbst am besten und ganz allein feststellen. > Aber der Nebeneffekt eines Verkürzten Delays könnte sein das der kernel > auf Echter HW nicht mehr Jedes Laufwerk findet und das noch mehr Ärger > Produziert. Und das nur weil du ein Problem mit 10 Sekunden Warten hast. > Nee, danke. Da erWARTEst du etwas zu viel für meinen Geschmack. > > >> Aber wenn ich der einzige bin, dem das >> aufstößt und wenn das bei einem Server keine Rolle spielt (oder ich nur >> "auf hohem Niveau jammere"), dann lassen wir es halt so. wie ist... > > Damit hätte ich kein Problem. :-) > > Kay >
Page 122 of 165 ---- Generated from net(t)forum Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 20:59:22 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Oh Mannn! Ich hab's verstanden! > (Ich sitze hier mit gerötetem Kopf! Es ist mir peinlich, ein solchen > Fehler gemacht zu haben!)
Ehrlich gesagt, hatte ich auch erst vor, dir einen Vorschlag mit Schreiben in eine datei zu machen, bis ... ja, bis mir siedend heiß einfiel, dass das erst ab einem bestimmten zeitpunkt geht.
Ales gut.
> Von den 14 Start-Scripts fallen 2 aus der Reihe; die Laufzeiten der > restlichen liegen bei max. 1 Sek. (wahrscheinlich deutlich darunter). > > S09console braucht ~ 4 Sek. > S03udev braucht ~27 Sek. !! > ------> Das lange Wait ist zwischen der letzte Ausgabe aus S03udev und dem > S03udev-Ende. Zwischen den einzelnen Scripts gibt es keine erkennbaren > Pausen.
Kannst du mir mal den Screenshot der gesamten ausgaben von udev per PM schicken, also der, wo von "Start von udev" ... bis "Ende von udev", also den von dir hinzugefügten echos alles zu sehen ist.
Eventuell überlege ich mal, mit welchen weiteren Ausgaben wir dem Startscript entlocken können, ob es was tut oder auf irgendwas wartet.
> Jetzt müsste man sich fragen, was die ungewöhnlich lange Laufzeit des > udev-Startscripts verursacht. Da muss ich aber passen. Ich kann Dir gerne > die scrennshot.png's per PM zusenden, wenn's interessiert.
Ja, gerne auch alle.
> Sag mir bitte, wie's (wenn's) weiter gehen soll. Helfe gerne, wenn ich > kann.
Wir sehen weiter, wenn ich eine Idee habe, wie es weiter gehen könnte.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance)
Page 123 of 165 ---- Generated from net(t)forum Posted by Uwe Kunze on Tue, 05 Mar 2019 21:04:16 GMT View Forum Message <> Reply to Message > Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die Hardware > 64bit kann.
Klar ... aber ich möchte daran erinnern, dass der eisfair mal ausdrücklich auch für "ältere Hardware" gedacht war (so stand es früher mal auf der eisfair-Seite, wenn ich mich recht erinnere). Im Moment heißt es dort "Die Anforderungen an die Hardware sind dabei gering."
Ein eis-1 läuft bei mir noch auf einem Pentium 200 MMX mit 64 MB RAM ! Meltdown und Spectre können mich mal ...
:-)
Gruß Uwe
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Uwe Kunze on Tue, 05 Mar 2019 21:12:31 GMT View Forum Message <> Reply to Message >> Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die >> Hardware 64bit kann.
> Klar ... aber ich möchte daran erinnern, dass der eisfair mal > ausdrücklich auch für "ältere Hardware" gedacht war (so stand es früher > mal auf der eisfair-Seite, wenn ich mich recht erinnere).
Habs wiedergefunden :-)
> Hardwarevoraussetzungen > > CPU: Pentium 66 > Hauptspeicher: 32 MB, besser 64 > Massenspeicher: mindestens 120 MB Festplatte, später auch CompactFlashTM > Sonstiges: Netzwerkkarte zum Anschluss an LAN > Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL > > Die genannten Hardwaredaten sind als absolutes Minimum zu betrachten. Viele Pakete, (z.B. Datenbanken) benötigen je nach Einsatz zum sinvollen Arbeiten eher Hardware-Ausstattungen, die um ein vielfaches darüber liegen.
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 21:13:16 GMT View Forum Message <> Reply to Message Hallo Uwe,
Page 124 of 165 ---- Generated from net(t)forum Uwe Kunze wrote:
>> Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die >> Hardware 64bit kann. > > Klar ... aber ich möchte daran erinnern, dass der eisfair mal > ausdrücklich auch für "ältere Hardware" gedacht war
Und daran ändert sich doch auch durch meine Aussage nichts.
-- Gruss Marcus
Subject: Re: pcspkr (et al) Posted by Hilix on Tue, 05 Mar 2019 21:23:30 GMT View Forum Message <> Reply to Message Hallo Marcus,
Danke. PM geht raus.
Grüße. / Hilmar.
Am 05.03.19 um 21:59 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >> Oh Mannn! Ich hab's verstanden! >> (Ich sitze hier mit gerötetem Kopf! Es ist mir peinlich, ein solchen >> Fehler gemacht zu haben!) > > Ehrlich gesagt, hatte ich auch erst vor, dir einen Vorschlag mit Schreiben > in eine datei zu machen, bis ... ja, bis mir siedend heiß einfiel, dass das > erst ab einem bestimmten zeitpunkt geht. > > Ales gut. > >> Von den 14 Start-Scripts fallen 2 aus der Reihe; die Laufzeiten der >> restlichen liegen bei max. 1 Sek. (wahrscheinlich deutlich darunter). >> >> S09console braucht ~ 4 Sek. >> S03udev braucht ~27 Sek. !! >> ------>> Das lange Wait ist zwischen der letzte Ausgabe aus S03udev und dem >> S03udev-Ende. Zwischen den einzelnen Scripts gibt es keine erkennbaren >> Pausen. > > Kannst du mir mal den Screenshot der gesamten ausgaben von udev per PM
Page 125 of 165 ---- Generated from net(t)forum > schicken, also der, wo von "Start von udev" ... bis "Ende von udev", also > den von dir hinzugefügten echos alles zu sehen ist. > > Eventuell überlege ich mal, mit welchen weiteren Ausgaben wir dem > Startscript entlocken können, ob es was tut oder auf irgendwas wartet. > >> Jetzt müsste man sich fragen, was die ungewöhnlich lange Laufzeit des >> udev-Startscripts verursacht. Da muss ich aber passen. Ich kann Dir gerne >> die scrennshot.png's per PM zusenden, wenn's interessiert. > > Ja, gerne auch alle. > >> Sag mir bitte, wie's (wenn's) weiter gehen soll. Helfe gerne, wenn ich >> kann. > > Wir sehen weiter, wenn ich eine Idee habe, wie es weiter gehen könnte. >
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Tue, 05 Mar 2019 21:27:17 GMT View Forum Message <> Reply to Message Hallo Uwe,
Uwe Kunze wrote:
>>> Also warum bei Neuinstallationen noch auf 32-bit setzen, wenn die >>> Hardware 64bit kann. > >> Klar ... aber ich möchte daran erinnern, dass der eisfair mal >> ausdrücklich auch für "ältere Hardware" gedacht war (so stand es früher >> mal auf der eisfair-Seite, wenn ich mich recht erinnere). > > Habs wiedergefunden :-) > >> Hardwarevoraussetzungen >> >> CPU: Pentium 66 >> Hauptspeicher: 32 MB, besser 64 >> Massenspeicher: mindestens 120 MB Festplatte, später auch >> CompactFlashTM Sonstiges: Netzwerkkarte zum Anschluss an LAN >> Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL >> >> Die genannten Hardwaredaten sind als absolutes Minimum zu betrachten. >> Viele Pakete, (z.B. Datenbanken) benötigen je nach Einsatz zum sinvollen >> Arbeiten eher Hardware-Ausstattungen, die um ein vielfaches darüber >> liegen.
Ich wäre ja gespannt darauf, wenn man nun einem aktuellen Installer das nochmal auf sowas versucht zu installieren.
Page 126 of 165 ---- Generated from net(t)forum Wenn man also noch sowas nutzen will, nimmt man natürlich eisfair-1, was anderes geht auch nicht.
Aber wer 64bit-Hardware hat, braucht doch nicht die Hälfte davon "brach liegen lassen", indem er den 32bit-eis installiert.
Wäre so, als würde jemand bei seinem brandneuen BMW ein Rad abmontieren läßt, weil er bislang die Isetta gefahren ist.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Tue, 05 Mar 2019 22:13:45 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 21:49 schrieb Hilmar Böhm: > > Sei mir bitte nicht böse, aber ich glaube, Du hast mit nicht verstanden. >
Da ich im folgenden Vollqoute keinen Hinweis von dir fand was du meinst, erkläre bitte mal genauer WAS ich deiner Meinung nach nicht verstanden hätte?
Dir ging es im Kern um die Verkürzung der Wartezeit beim einbinden der Dateisysteme zur Bootzeit. Da ist nun erstmal egal ob es um einen EIS in Virtuell in Echt oder in 32/64 Bit geht. Die müssen bei allen gemountet werden. Und ich versuchte dir mit (zugegebenermaßen) weit ausgeholten Beispielen zu vermitteln warum ich das nicht für gut halte.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Wed, 06 Mar 2019 06:55:16 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Danke. PM geht raus.
Mehr als das, was du bezüglich udev festgestellt hast, sehe ich auch nicht.
Page 127 of 165 ---- Generated from net(t)forum Lass uns mal das Initskript von udev mit weiteren echos pflastern, die anderen Initskripte kannst du wieder in den Originalzustand versetzen.
Im udev Initskript gibts es den Block, den ich um einige echo erweitert habe:
echo $(date) "Starte udev daemon" /sbin/udevd --daemon echo $(date) "Gestartet udev daemon"
# Now traverse /sys in order to "coldplug" devices that have # already been discovered echo $(date) "Trigger subsystems add" /sbin/udevadm trigger --action=add --type=subsystems echo $(date) "Trigger devices add" /sbin/udevadm trigger --action=add --type=devices echo $(date) "Trigger devices change" /sbin/udevadm trigger --action=change --type=devices echo $(date) "End Trigger"
# Now wait for udevd to process the uevents we triggered if ! is_true "$OMIT_UDEV_SETTLE" then echo $(date) "Start Settle" /sbin/udevadm settle echo $(date) "End Settle" fi
# If any LVM based partitions are on the system, ensure they # are activated so they can be used. if [ -x /sbin/vgchange ] then echo $(date) "Start vgchange" /sbin/vgchange -a y >/dev/null echo $(date) "End vgchange" fi
Sieht ziemlich rustikal aus, aber manchmal muss der Holzhammer sein. Wir sollten nun herausbekommen, welches der ausgeführten Kommandos so lange braucht.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Wed, 06 Mar 2019 08:23:11 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 22:27 schrieb Marcus Roeckrath: >>
Page 128 of 165 ---- Generated from net(t)forum >>> Hardwarevoraussetzungen >>> >>> CPU: Pentium 66 >>> Hauptspeicher: 32 MB, besser 64 >>> Massenspeicher: mindestens 120 MB Festplatte, später auch >>> CompactFlashTM Sonstiges: Netzwerkkarte zum Anschluss an LAN >>> Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL >>> > > Ich wäre ja gespannt darauf, wenn man nun einem aktuellen Installer das > nochmal auf sowas versucht zu installieren.
Der; lange nicht in Betrieb befindliche; hier ist "nur etwas" schneller aber wenn du es brauchst, die Komponenten sind alle da. P1 mit 66 . 75 MHZ, 32 o. 64 MB RAM, P-ATA um die xxx MB und 10 Mbit LAN.
Möchtest du denn etwas bestimmtes wissen?
Ich hab so einen (ein Compaq Prolinea) einige Zeit für FLI4L benutzt.
Kay
-- Sent via SN (Eisfair-1)
Subject: Aw: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Wed, 06 Mar 2019 09:46:49 GMT View Forum Message <> Reply to Message Hallo Kay, kay schrieb am Wed, 06 March 2019 09:23Am 05.03.2019 um 22:27 schrieb Marcus Roeckrath: >> >>> Hardwarevoraussetzungen >>> >>> CPU: Pentium 66 >>> Hauptspeicher: 32 MB, besser 64 >>> Massenspeicher: mindestens 120 MB Festplatte, später auch >>> CompactFlashTM Sonstiges: Netzwerkkarte zum Anschluss an LAN >>> Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL >>> > > Ich wäre ja gespannt darauf, wenn man nun einem aktuellen Installer das > nochmal auf sowas versucht zu installieren.
Der; lange nicht in Betrieb befindliche; hier ist "nur etwas" schneller aber wenn du es brauchst, die Komponenten sind alle da. P1 mit 66 . 75 MHZ, 32 o. 64 MB RAM, P-ATA um die xxx MB und 10 Mbit LAN.
Page 129 of 165 ---- Generated from net(t)forum Möchtest du denn etwas bestimmtes wissen? Pures Interesse, ob sich ein aktueller eisfair wirklich noch auf einem solchen Dinosaurier installieren läßt, oder ob wir die Mindestvorausetzungen doch mal anpassen sollten.
Subject: Re: pcspkr (et al) Posted by Hilix on Wed, 06 Mar 2019 16:08:34 GMT View Forum Message <> Reply to Message Hi Marcus, Ergebnisse kommen noch heute Abend. Muss noch'n paar Sachen dazwischen erledigen. Grüße. / Hilmar.
Am 06.03.19 um 07:55 schrieb Marcus Roeckrath: ...... > > Sieht ziemlich rustikal aus, aber manchmal muss der Holzhammer sein. Wir > sollten nun herausbekommen, welches der ausgeführten Kommandos so lange > braucht. >
Subject: Re: pcspkr (et al) Posted by Marcus Roeckrath on Wed, 06 Mar 2019 16:17:30 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Ergebnisse kommen noch heute Abend. Muss noch'n paar Sachen dazwischen > erledigen.
Kein Problem, wir sind hier auf der "Arbeit" und nicht auf der Flucht.
Bitte aber hierhin posten und zwar nur die Echos aus dem udev-Initskript.
-- Gruss Marcus
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Wed, 06 Mar 2019 20:21:04 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 01:09 schrieb Hilmar Böhm:
>> Wer macht es? Du?
Page 130 of 165 ---- Generated from net(t)forum > Wenn Du mich meinst: Nein! > (Keine Zeit, bin (in diesem Fall) nur Anwender.)
Dachte ich mir.
-- der tom [eisfair-team]
Subject: Re: E-64 Posted by Thomas Bork on Wed, 06 Mar 2019 20:26:01 GMT View Forum Message <> Reply to Message Am 05.03.2019 um 21:26 schrieb Marcus Roeckrath:
> Uns fehlt noch der gcc mit retpoline-Patch, was deutlich weniger (wenn > überhaupt) Leistung bei der Verhinderung von Spectre/Meltdown kostet, als > die massnahmen auf Microcode-Ebene.
Falsch, den haben wir doch inzwischen und der Kernel ist auch damit gebaut.
-- der tom [eisfair-team]
Subject: Re: E-64 Posted by Marcus Roeckrath on Wed, 06 Mar 2019 20:34:06 GMT View Forum Message <> Reply to Message Hallo Thomas,
Thomas Bork wrote:
>> Uns fehlt noch der gcc mit retpoline-Patch, was deutlich weniger (wenn >> überhaupt) Leistung bei der Verhinderung von Spectre/Meltdown kostet, als >> die massnahmen auf Microcode-Ebene. > > Falsch, den haben wir doch inzwischen und der Kernel ist auch damit > gebaut.
Gut dass du mich erinnerst, ich wollte dich schon fragen, nachdem ich in dmesg gestern aus anderen Gründen etas suchte und dann auf dieses hier zufällig stieß:
Spectre V2 : Mitigation: Full generic retpoline
-- Gruss Marcus
Page 131 of 165 ---- Generated from net(t)forum Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Thomas Bork on Wed, 06 Mar 2019 20:39:15 GMT View Forum Message <> Reply to Message Am 03.03.2019 um 17:46 schrieb Marcus Roeckrath:
> Für Kompilieren für ältere CPUs!
Bei e64 für alle 64-Bit-CPUs. Aber ich optimiere immer noch auf Grösse und nicht auf Performance...
-- der tom [eisfair-team]
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by kay on Wed, 06 Mar 2019 21:22:57 GMT View Forum Message <> Reply to Message Am 06.03.2019 um 10:46 schrieb Marcus Roeckrath: > Hallo Kay, > > kay schrieb am Wed, 06 March 2019 09:23 >> Am 05.03.2019 um 22:27 schrieb Marcus Roeckrath: >>>> >>>> > Hardwarevoraussetzungen >>>> > >>>> > CPU: Pentium 66 >>>> > Hauptspeicher: 32 MB, besser 64 >>>> > Massenspeicher: mindestens 120 MB Festplatte, später auch >>>> > CompactFlashTM Sonstiges: Netzwerkkarte zum Anschluss an >> LAN >>>> > Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an >> xDSL >>>> > >>> >>> Ich wäre ja gespannt darauf, wenn man nun einem aktuellen >>> Installer das >>> nochmal auf sowas versucht zu installieren. >> >> Der; lange nicht in Betrieb befindliche; hier ist "nur etwas" >> schneller >> aber wenn du es brauchst, die Komponenten sind alle da. P1 mit 66 . >> 75 >> MHZ, 32 o. 64 MB RAM, P-ATA um die xxx MB und 10 Mbit LAN. >> >> Möchtest du denn etwas bestimmtes wissen? > > Pures Interesse, ob sich ein aktueller eisfair wirklich noch auf einem > solchen Dinosaurier installieren läßt, oder ob wir die > Mindestvorausetzungen doch mal anpassen sollten.
Page 132 of 165 ---- Generated from net(t)forum >
Okay. Also wenn ich diesen Compaq Prolinea 575 (IMHO) mal wieder auf den Tisch gewuppt bekomme dann werde ich das mal mit einer Eisfair-CD probieren. So weit ich erinnere hat der eine 75 MHz Pentium CPU, 32-48 MB RAM, Legacy IO (Par, Ser, PS/2) und es dürfte noch mindestens eine SMC ULtra Combo NIC drin stecken. Die HDD hatte irgendwas zwischen 100 und 300 MB und ist Parallel-ATA.
Würde EIS-1 auf einem 386 o. 486 DX eigentlich überhaupt noch laufen?
Kay
-- Sent via SN (Eisfair-1)
Subject: Eisfair Starup Waits und VM (was: Re: pcspkr (et al)) Posted by Hilix on Wed, 06 Mar 2019 21:41:17 GMT View Forum Message <> Reply to Message Hallo Marcus,
Habe die Tests gemacht. Danke für den fertigen Echo-Block (ist ja ein Service! :-) )
Ergebnisse:
Wed Mar 5 09:43.31 CET 2919 Getartet udev daemon
Wed Mar 6 09:43.31 CET 2919 Trigger subsystems add Wed Mar 6 09:43.31 CET 2919 Trigger devices add Wed Mar 6 09:43.31 CET 2919 Trigger devices change Wed Mar 6 09:43.33 CET 2919 Trigger devices change Wed Mar 6 09:43.35 CET 2919 End Trigger
Wed Mar 5 09:43.36 CET 2919 Start Settle Wed Mar 5 09:43.58 CET 2919 End Settle <--- 22s
------
> ...und zwar nur die Echos aus dem udev-Initskript. Das würde Dir so passen :-) Ich habe noch ein paar Anmerkungen:
Der Übeltäter ist das "udevadm settle". Settle bedeutet meist
Die udevadm-ManPage sagt: ------udevadm settle [options]
Page 133 of 165 ---- Generated from net(t)forum Watches the udev event queue, and exits if all current events are handled.
-t, --timeout=SECONDS Maximum number of seconds to wait for the event queue to become empty. The default value is 120 seconds. A value of 0 will check if the queue is empty and always return immediately. ------
Da eine VM in der Regel bereits (durch den Host) verfügbaren Speicher nutzt, entstehen keine langen Event-Queues, behaupte ich mal. Ich habe es mit dem angehängten Parameter "-t 0" probiert und es funktioniert - ohne Waits! - einwandfrei!
Wenn man die 5s von udev-Start bis zu "Settle" und die 22s der "Settle"-Aktion zusammen zählt, kommt auf die 27 Sekunden, die ich bereits a.a.O. berichtet habe.
Und wenn man jetzt auch noch die 10s Sleep (im Rahmen des "Waiting for SCSI/SATA/PATA devices coming up") beseitigt, von der Thomas Bork berichtet hat (s. https://web.nettworks.org/forum/index.php?t=msg&goto=69927&& srch=%2Fbin%2Fsleep#msg_69927) und die in einer virtualiserten Umgebung m.E. unnötig sind, gewinnt man über ein halbe Minute beim Booten - vor allem auf langsameren Hosts. Das ist doch schon was!!
Zudem: Der Eisfair-Kernel der VM weiss ja bereits, dass es auf einem KVM-Hypervisor läuft. Siehe: /var/log/messages: "... eis klogd: Hypervisor detected: KVM". (Der Kernel müsste diese Info "exportieren", somehow). In den Startup-Scripts gibt es auch Möglichkeiten festzustellen, ob die das System auf einem Hypervisor läuft (z.B. "dmidecode", ist im Basis-Eisfair vorhanden). In diesem Falle, werden die beiden Befehle _nicht_ aufgeführt.
Falls Eisfair "bare metal" läuft, werden die Waits beibehalten. Alles bleibt beim alten. Keine weitere Änderung erforderlich.
Ich denke, das sollte ohne großen Aufwand möglich sein.
In der Hoffnung, mich nicht zu weit aus dem Fenster gelehnt zu haben, :) viele Grüße. / Hilmar.
Btw., Marcus: Hast Du in S03udev diese Variable "OMIT_UDEV_SETTLE" im if Statement gesehen, in der das "udevadm settle" eingebettet ist? Wo wird diese Variable gesetzt und unter welchen Bedingungen?
Am 06.03.19 um 07:55 schrieb Marcus Roeckrath: > Im udev Initskript gibts es den Block, den ich um einige echo erweitert
Page 134 of 165 ---- Generated from net(t)forum > habe: > > echo $(date) "Starte udev daemon" > /sbin/udevd --daemon > echo $(date) "Gestartet udev daemon" > > # Now traverse /sys in order to "coldplug" devices that have > # already been discovered > echo $(date) "Trigger subsystems add" > /sbin/udevadm trigger --action=add --type=subsystems > echo $(date) "Trigger devices add" > /sbin/udevadm trigger --action=add --type=devices > echo $(date) "Trigger devices change" > /sbin/udevadm trigger --action=change --type=devices > echo $(date) "End Trigger" > > # Now wait for udevd to process the uevents we triggered > if ! is_true "$OMIT_UDEV_SETTLE" > then > echo $(date) "Start Settle" > /sbin/udevadm settle > echo $(date) "End Settle" > fi > > # If any LVM based partitions are on the system, ensure they > # are activated so they can be used. > if [ -x /sbin/vgchange ] > then > echo $(date) "Start vgchange" > /sbin/vgchange -a y >/dev/null > echo $(date) "End vgchange" > fi > > Sieht ziemlich rustikal aus, aber manchmal muss der Holzhammer sein. Wir > sollten nun herausbekommen, welches der ausgeführten Kommandos so lange > braucht. >
Subject: Re: Noch mal Eisfair(64) und Proxmox (Perfomance) Posted by Marcus Roeckrath on Wed, 06 Mar 2019 22:04:18 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
>> Pures Interesse, ob sich ein aktueller eisfair wirklich noch auf einem >> solchen Dinosaurier installieren läßt, oder ob wir die >> Mindestvorausetzungen doch mal anpassen sollten. >
Page 135 of 165 ---- Generated from net(t)forum > Okay. Also wenn ich diesen Compaq Prolinea 575 (IMHO) mal wieder auf den > Tisch gewuppt bekomme dann werde ich das mal mit einer Eisfair-CD > probieren.
Keine Hektik; ist doch nur ein Spaßexperiment.
> So weit ich erinnere hat der eine 75 MHz Pentium CPU, 32-48 > MB RAM, Legacy IO (Par, Ser, PS/2) und es dürfte noch mindestens eine > SMC ULtra Combo NIC drin stecken. Die HDD hatte irgendwas zwischen 100 > und 300 MB und ist Parallel-ATA. > > Würde EIS-1 auf einem 386 o. 486 DX eigentlich überhaupt noch laufen?
Ich denke 486 ja, aber auf einem 386er???
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM (was: Re: pcspkr (et al)) Posted by Marcus Roeckrath on Wed, 06 Mar 2019 22:15:11 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Ergebnisse: > > Wed Mar 5 09:43.31 CET 2919 Getartet udev daemon > > Wed Mar 6 09:43.31 CET 2919 Trigger subsystems add > Wed Mar 6 09:43.31 CET 2919 Trigger devices add > Wed Mar 6 09:43.31 CET 2919 Trigger devices change > Wed Mar 6 09:43.33 CET 2919 Trigger devices change > Wed Mar 6 09:43.35 CET 2919 End Trigger > > Wed Mar 5 09:43.36 CET 2919 Start Settle > Wed Mar 5 09:43.58 CET 2919 End Settle <--- 22s > > ------> >> ...und zwar nur die Echos aus dem udev-Initskript. > Das würde Dir so passen :-) > Ich habe noch ein paar Anmerkungen:
Das wollte ich auch nicht ausschliessen; nur andere Teile vom Bootbildschirm waren jetzt nicht mehr nötig.
> Der Übeltäter ist das "udevadm settle".
Page 136 of 165 ---- Generated from net(t)forum Hatte auch genau das in Verdacht.
> Settle bedeutet meist
Auf echter Hardware scheint das ja viel schneller zum Ende zu kommen, denn prinzipiell ist es ja schon sinnvoll, dass auf die vorher getriggerten Events gewartet wird.
Andere beobachten das Verhalten ja bei sich in der VM nicht.
Mir stellen sich da folgende Fragen:
Werden dabei Events getriggert, die dann nicht bearbeitet werden?
Ist deine VM so konfiguriert, dass hier sehr viele Events getriggert werden.
Leider hat der settle keine Verbose-Option.
Muss da mal - heute abend nicht mehr - Tante Google befragen.
> Der Eisfair-Kernel der VM weiss ja bereits, dass es auf einem > KVM-Hypervisor läuft. Siehe: /var/log/messages: "... eis klogd: Hypervisor > detected: KVM". (Der Kernel müsste diese Info "exportieren", somehow). > In den Startup-Scripts gibt es auch Möglichkeiten festzustellen, ob die > das System auf einem Hypervisor läuft (z.B. "dmidecode", ist im > Basis-Eisfair vorhanden). In diesem Falle, werden die beiden Befehle > _nicht_ aufgeführt. > > Falls Eisfair "bare metal" läuft, werden die Waits beibehalten. Alles > bleibt beim alten. Keine weitere Änderung erforderlich. > > Ich denke, das sollte ohne großen Aufwand möglich sein.
Es geht nicht um den Aufwand; für mich sind da einfach noch offene Fragen.
> Btw., Marcus: Hast Du in S03udev diese Variable "OMIT_UDEV_SETTLE" im if > Statement gesehen, in der das "udevadm settle" eingebettet ist? Wo wird > diese Variable gesetzt und unter welchen Bedingungen?
Das habe ich mich auch gefragt und keine Antwort gefunden. Eventuell wird die von den trigger-Zeilen gesetzt, wenn diese Events triggern.
Das wird man aber auch in der Doku zu udev finden können.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Thu, 07 Mar 2019 01:12:16 GMT
Page 137 of 165 ---- Generated from net(t)forum View Forum Message <> Reply to Message Hallo Marcus, vielen Dank für Deine späte Nachricht.
Ich habe mir die E64-VM mal von dem langsamen "Server/Host" auf eine schnelleres System kopiert, um da mal die fraglichen Phänomene zu testen.
Zu den beiden Systemen: das Langsamere ist das Ältere: Zotac (2010), CPU: Pentium U2300 / 2 Kerne / 1.2 GHZ, aktuelle 500G SATAII-SSD, wird aber wahrscheinlich als 3G-SATA SSD genutzt(HW-bedingt) / 8GB Mem./ OS: akt. Arch Linux (orig., kein Derivat, keine GUI), Virtualisierung: QEMU 3.1.0-2 + Libvirt 5.1.0-1 (KVM)
TUXEDO (2016), ASRock Z170M-ITX/ac, CPU: i7-6700 4/8, max 4GHz, SSD-Drives (Samsung_SSD_850) / 32GB Mem, /OS: Debian 9 (GUI: KDE), Virtualisierung: QEMU-KVM 2.8, Libvirt 3.0.0/stable, virt-manager 1.4.0-5
Die E64-VM: 2vCPU's, 2G Mem, 10G vHD virtio-scsi-Anbindung.
Die gleiche e64-VM braucht auf dem Zotac-System zum Booten: 69s Die gleiche e64-VM braucht auf dem TUXEDO/Debian System: 19s (beide Systeme original, also ungehackt)
Das gesamte S03udev Init-Script (inkl. Settle) braucht auf dem Debian-System: <= 1s ! also keine Verzögerung
Wenn ich das "sleep 10" ("Waiting for SCSI/SATA/PATA devices...") im initramfs/init ausknipse, braucht der ganze Bootvorgang: _9s_!! Das ist schon ganz ordentlich!
Ich vermute, dass auf dem schnelleren System die Event-Queue beim "udevadm settle" klein oder gar nicht existent ist. Auf dem langsameren System wirkt sich vermutlich der schwache Prozessor, der langsamere Speiche und die langsamere SSD-Anbindung aus. Es könnten natürlich auch andere HW-bedingte Gründe geben, ich nicht kenne und bisher auch noch nicht in Betracht gezogen habe.
Damit ist wahrscheinlich die Sache gestorben... ? :-( (Wenn es nicht noch eine Idee gibt.)
Grüße. / Hilmar.
Am 06.03.19 um 23:15 schrieb Marcus Roeckrath:
Page 138 of 165 ---- Generated from net(t)forum > Hallo Hilmar, > > Hilmar Böhm wrote: > >> Ergebnisse: >> >> Wed Mar 5 09:43.31 CET 2919 Getartet udev daemon >> >> Wed Mar 6 09:43.31 CET 2919 Trigger subsystems add >> Wed Mar 6 09:43.31 CET 2919 Trigger devices add >> Wed Mar 6 09:43.31 CET 2919 Trigger devices change >> Wed Mar 6 09:43.33 CET 2919 Trigger devices change >> Wed Mar 6 09:43.35 CET 2919 End Trigger >> >> Wed Mar 5 09:43.36 CET 2919 Start Settle >> Wed Mar 5 09:43.58 CET 2919 End Settle <--- 22s >> >> ------>> >>> ...und zwar nur die Echos aus dem udev-Initskript. >> Das würde Dir so passen :-) >> Ich habe noch ein paar Anmerkungen: > > Das wollte ich auch nicht ausschliessen; nur andere Teile vom Bootbildschirm > waren jetzt nicht mehr nötig. > >> Der Übeltäter ist das "udevadm settle". > > Hatte auch genau das in Verdacht. > >> Settle bedeutet meist
Page 139 of 165 ---- Generated from net(t)forum >> In den Startup-Scripts gibt es auch Möglichkeiten festzustellen, ob die >> das System auf einem Hypervisor läuft (z.B. "dmidecode", ist im >> Basis-Eisfair vorhanden). In diesem Falle, werden die beiden Befehle >> _nicht_ aufgeführt. >> >> Falls Eisfair "bare metal" läuft, werden die Waits beibehalten. Alles >> bleibt beim alten. Keine weitere Änderung erforderlich. >> >> Ich denke, das sollte ohne großen Aufwand möglich sein. > > Es geht nicht um den Aufwand; für mich sind da einfach noch offene Fragen. > >> Btw., Marcus: Hast Du in S03udev diese Variable "OMIT_UDEV_SETTLE" im if >> Statement gesehen, in der das "udevadm settle" eingebettet ist? Wo wird >> diese Variable gesetzt und unter welchen Bedingungen? > > Das habe ich mich auch gefragt und keine Antwort gefunden. Eventuell wird > die von den trigger-Zeilen gesetzt, wenn diese Events triggern. > > Das wird man aber auch in der Doku zu udev finden können. >
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Thu, 07 Mar 2019 06:27:49 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Die E64-VM: 2vCPU's, 2G Mem, 10G vHD virtio-scsi-Anbindung. > > Die gleiche e64-VM braucht auf dem Zotac-System zum Booten: 69s > Die gleiche e64-VM braucht auf dem TUXEDO/Debian System: 19s > (beide Systeme original, also ungehackt) > > Das gesamte S03udev Init-Script (inkl. Settle) braucht auf dem > Debian-System: <= 1s ! also keine Verzögerung > > Damit ist wahrscheinlich die Sache gestorben... ? :-( > (Wenn es nicht noch eine Idee gibt.)
IMHO ja, denn das settle wird durchaus Sinn machen und wenn das eine System eine schlechte Performance hat, kann man das nicht dadurch verbessern, dass man alles "ausschaltet", was Zeit frisst.
-- Gruss Marcus
Page 140 of 165 ---- Generated from net(t)forum Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Thu, 07 Mar 2019 10:12:23 GMT View Forum Message <> Reply to Message Hallo Marcus, vielen Dank für Deine Einschätzung.
"Schlechte Performance" find' ich gut :-) Rast ein Porschefahrer auf der Autobahn mit seinem 911er mit 300 km/h an einem VW Käfer mit 110 vorbei und murmelt nur kopfschüttelnd sich in den Bart: Schlechte Performance!... :-)
Die Performance-Unterschiede zwischen der Eisfair-64- und der Antergos-Minimal-VM beim Booten (30+ Sek.) sind damit aber nicht wegdiskutiert.
Ich bin aber nach wie vor der Meinung, dass man bei einer VM nicht 10 Sekunden auf langsame SCSI/SATA/PATA-Platten warten muss!
Viele Grüße. / Hilmar Böhm.
P.S.: Habe zum Modifizieren des initramfs/init-Scripts Deinen Howto-Artikel ("Bearbeiten der initramfs (ab Kernel 3.18.0)") verwendet. (Um zu sehen, wie man das initramfs aus und wieder einpackt.) Kurz und knackig! Bin mir aber unsicher, ob der Punkt 5 bei einem aktuellen E64-System noch erforderlich ist?
Am 07.03.19 um 07:27 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >> Die E64-VM: 2vCPU's, 2G Mem, 10G vHD virtio-scsi-Anbindung. >> >> Die gleiche e64-VM braucht auf dem Zotac-System zum Booten: 69s >> Die gleiche e64-VM braucht auf dem TUXEDO/Debian System: 19s >> (beide Systeme original, also ungehackt) >> >> Das gesamte S03udev Init-Script (inkl. Settle) braucht auf dem >> Debian-System: <= 1s ! also keine Verzögerung >> >> Damit ist wahrscheinlich die Sache gestorben... ? :-( >> (Wenn es nicht noch eine Idee gibt.) > > IMHO ja, denn das settle wird durchaus Sinn machen und wenn das eine System > eine schlechte Performance hat, kann man das nicht dadurch verbessern, dass > man alles "ausschaltet", was Zeit frisst. >
Page 141 of 165 ---- Generated from net(t)forum Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Thu, 07 Mar 2019 11:04:25 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Die Performance-Unterschiede zwischen der Eisfair-64- und der > Antergos-Minimal-VM beim Booten (30+ Sek.) sind damit aber nicht > wegdiskutiert.
Treten diese Geschwindigkeitsunterschiede auch zwischen eisfair-1 und eisfair-64 auf?
> Ich bin aber nach wie vor der Meinung, dass man bei einer VM nicht 10 > Sekunden auf langsame SCSI/SATA/PATA-Platten warten muss!
Das ist Sache von Thomas.
> P.S.: Habe zum Modifizieren des initramfs/init-Scripts Deinen > Howto-Artikel ("Bearbeiten der initramfs (ab Kernel 3.18.0)") verwendet. > (Um zu sehen, wie man das initramfs aus und wieder einpackt.) Kurz und > knackig! Bin mir aber unsicher, ob der Punkt 5 bei einem aktuellen > E64-System noch erforderlich ist?
Du willst doch, dass nach dem Bearbeiten der initramfs auch die für deinen Prozessor passenden Microcodes wieder eingebunden werden, zumindest auf realer Hardware.
Auf VM macht das keinen Sinn, da dort Microcodes nicht in den Prozessor geladen werden können, das ist Sache des Hostsystems; da müsste die /var/install/initrd/ucode.img beim Kernelupdate aber auch leer sein.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Fri, 08 Mar 2019 01:09:02 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 07.03.19 um 12:04 schrieb Marcus Roeckrath: > Hallo Hilmar, > > Hilmar Böhm wrote: > >> Die Performance-Unterschiede zwischen der Eisfair-64- und der >> Antergos-Minimal-VM beim Booten (30+ Sek.) sind damit aber nicht >> wegdiskutiert.
Page 142 of 165 ---- Generated from net(t)forum > > Treten diese Geschwindigkeitsunterschiede auch zwischen eisfair-1 und > eisfair-64 auf? JA!
Habe eine aktuelle Eisfair-1 VM auf das Zotac ZBox-System übernommen. Diese VM bootet unter vergleichbarer KVM-Konfig: (2G vMem, 10G vHD virtio-scsi, virtio-net, 2 vCPU's) in 52 Sek.
Das ist 17s schneller als die Eisfair-64 VM, von der ich berichtet habe. (Auch der Console-Output wirkt sichtlich agiler.)
"S03udev" benötigt insgesamt 5s! Davon "udevadm settle" _4s_! (Kann die beiden Screenshots gerne zur Verfügung stellen.)
Das ist gegenüber den 27s/22s der Eisfair-64 VM deutlich schneller, bei gleicher Host-HW und gleicher virtueller Umgebung.
Ich glaube inzwischen doch, das die Eisfair-64 VM auf diesem Host-System ein Problem hat, das von der Eisfairseite verursacht wird!
(Btw. ein aktuelles Alpine Linux (V3.9.2-Virt) benötigt auf diesem Host 24s bis zum Login-Prompt.)
....
>> P.S.: Habe zum Modifizieren des initramfs/init-Scripts Deinen >> Howto-Artikel ("Bearbeiten der initramfs (ab Kernel 3.18.0)") verwendet. >> (Um zu sehen, wie man das initramfs aus und wieder einpackt.) Kurz und >> knackig! Bin mir aber unsicher, ob der Punkt 5 bei einem aktuellen >> E64-System noch erforderlich ist? > > Du willst doch, dass nach dem Bearbeiten der initramfs auch die für deinen > Prozessor passenden Microcodes wieder eingebunden werden, zumindest auf > realer Hardware. > > Auf VM macht das keinen Sinn, da dort Microcodes nicht in den Prozessor > geladen werden können, das ist Sache des Hostsystems; da müsste > die /var/install/initrd/ucode.img beim Kernelupdate aber auch leer sein. > Vielen Dank für die Info. Das muss ich mir noch mal anschauen.
Grüße. / Hilmar.
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 06:47:12 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Page 143 of 165 ---- Generated from net(t)forum Hilmar Böhm wrote:
>> Treten diese Geschwindigkeitsunterschiede auch zwischen eisfair-1 und >> eisfair-64 auf? > JA!
Ich bin bei meiner Frage in diesem Monsterthread bei der Zuordnung Person-Problem durcheinandergekommen.
> Habe eine aktuelle Eisfair-1 VM auf das Zotac ZBox-System übernommen. > Diese VM bootet unter vergleichbarer KVM-Konfig: (2G vMem, 10G vHD > virtio-scsi, virtio-net, 2 vCPU's) in 52 Sek. > > Das ist 17s schneller als die Eisfair-64 VM, von der ich berichtet habe. > (Auch der Console-Output wirkt sichtlich agiler.) > > "S03udev" benötigt insgesamt 5s! Davon "udevadm settle" _4s_! > (Kann die beiden Screenshots gerne zur Verfügung stellen.) > > Das ist gegenüber den 27s/22s der Eisfair-64 VM deutlich schneller, bei > gleicher Host-HW und gleicher virtueller Umgebung.
Und dann sehen wir auch, woher der Geschwindigkeitsunterscheid genau herkommt, nämlich von udevadm settle. udevadm settle braucht rund 20 Sekunden länger.
Einfach udevadm settle totzulegen ist auch keine Option:
"After the kernel boots, udevd is used to create device nodes for all detected devices. That is a relatively time consuming task that has to be completed for the boot process to continue, otherwise there is a risk of services failing due to missing device nodes. udevadm settle waits for udevd to process the device creation events for all hardware devices, thus ensuring that any device nodes have been created successfully before proceeding."
Mit settle wird nun auf den Abschluss der vorher getriggerten Events gewartet.
Du könntest die vorstehenden trigger-Zeilen mal um --verbose ergänzen, damit wir sehen, welche Events getriggert werden.
Du könntest nach Boot mal schauen, ob in /dev andere oder mehr Devices beim Boot mir eis64 oder eis1 existieren. z. B. nach Boot so: ls -1 /dev > /tmp/devs_in_eis1 oder
Page 144 of 165 ---- Generated from net(t)forum ls -1 /dev > /tmp/devs_in_eis64 und dann mit diff /tmp/devs_in_eis1 /tmp/devs_in_eis64 vergleichen.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Detlef Paschke on Fri, 08 Mar 2019 09:13:59 GMT View Forum Message <> Reply to Message Am 08.03.2019 um 07:47 schrieb Marcus Roeckrath:
Hallo Marcus,
> Du könntest nach Boot mal schauen, ob in /dev andere oder mehr Devices beim > Boot mir eis64 oder eis1 existieren. > > z. B. nach Boot so: > > ls -1 /dev > /tmp/devs_in_eis1 > > oder > > ls -1 /dev > /tmp/devs_in_eis64 das habe ich gemacht wenn ich mich hier mal rein hängen darf. Bei mir sind beide Dateien absolut identisch.
Viele Grüße Detlef Paschke
-- registered Fli4l-User #00000209 Das "Zitat des Augenblicks" gibt es nur auf http://www.schabau.goip.de
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 09:38:10 GMT View Forum Message <> Reply to Message Hallo Detlef,
Detlef Paschke wrote:
Page 145 of 165 ---- Generated from net(t)forum >> z. B. nach Boot so: >> >> ls -1 /dev > /tmp/devs_in_eis1 >> >> oder >> >> ls -1 /dev > /tmp/devs_in_eis64 > > das habe ich gemacht wenn ich mich hier mal rein hängen darf. > Bei mir sind beide Dateien absolut identisch.
Unnötig, wenn die identisch sind.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Fri, 08 Mar 2019 11:47:20 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 08.03.19 um 07:47 schrieb Marcus Roeckrath: > Du könntest die vorstehenden trigger-Zeilen mal um --verbose ergänzen, damit > wir sehen, welche Events getriggert werden. >
Habe ich gemacht. Aber die Listen für --action=add und --action=change devices sind eeeeendloooos (und scrollen oben aus der virt-manager Konsole raus; rückwärtsblättern mit
Früher in den "Eisen"zeiten hätte ich mich mit Kermit über eine serielle Leitung an die Kiste gehängt und den Output mitgeloggt. Ein serielles Interface in der VM aufzusetzen und sich irgendwie dran zuklemmen ist auch nicht gerade trivial.
Ich habe "less" in die initrd.gz (initramfs) eingebaut/kopiert (da nicht in der busybox enthalten). Dann kann man mit: udevadm trigger --action=add --type=devices --verbose | less udevadm trigger --action=change --type=devices --verbose | less den Output anhalten und darin blättern. Wenn man noch ein "grep" (ist in der busybox enthalten) vor das less setzt, kann man den Output auch noch filtern.
Aber ich glaube, es bringt nicht viel, weil man die udev-event Liste nicht anzeigen lassen kann, auf die das "udevadm settle" -
Page 146 of 165 ---- Generated from net(t)forum Kommando wartet, bis sie abgearbeitet ist. Diese Event-Liste scheint bei E1- und E64-VM's unterschiedlich lange zu sein.
Ich weiss nicht, wo die ata[1..6] Devices herkommen. Habe mal die IDE-CDROM aus der VM-Konfig raus geschmissen; die ata Devices sind aber immer noch da: ata[1..6]: SATA max UDMA/133 abar ... irq 49 und ata[1..6]: SATA link down (SStaus 0 SControl 300)
Ich könnte mir denken, dass der Kernel irgendwie noch ATA-Devices sieht, aber dann das udev diese testet, keine Verbindung bekommt ("link down") und sie dann wieder raus wirft. Das kostet u.U. Zeit (22s). Aber warum dauert das bei der E64-VM so lange? (retorische Frage :-) )
Man kriegt leider die Event-Liste nicht zu sehen.... Jetzt hilft eigentlich nur noch ein Blick in die Sourcen. Die Optionen des "udevadm settle" Kommandos sind leider ziemlich mager!
Viele Grüße. / Hilmar.
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 12:22:44 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Habe ich gemacht. Aber die Listen für --action=add und --action=change > devices sind eeeeendloooos (und scrollen oben aus der virt-manager Konsole > raus; rückwärtsblättern mit
Was ist mit der ersten trigger Zeile, kommt da wenig oder nichts?
> den Output anhalten und darin blättern. Wenn man noch ein "grep" (ist in > der busybox enthalten) vor das less setzt, kann man den Output auch noch > filtern. > > Aber ich glaube, es bringt nicht viel, weil man die udev-event Liste nicht > anzeigen lassen kann, auf die das "udevadm settle" - Kommando wartet, bis > sie abgearbeitet ist. Diese Event-Liste scheint bei E1- und E64-VM's > unterschiedlich lange zu sein.
Page 147 of 165 ---- Generated from net(t)forum Man müsste überlegen, wie man nun die Eventlisten sichern und vergleichen kann, also die Frage beantworten, warum die Liste unter eis64 länger ist.
> Ich weiss nicht, wo die ata[1..6] Devices herkommen. Habe mal die > IDE-CDROM aus der VM-Konfig raus geschmissen; die ata Devices sind aber > immer noch da: > > ata[1..6]: SATA max UDMA/133 abar ... irq 49 > und > ata[1..6]: SATA link down (SStaus 0 SControl 300) > > Ich könnte mir denken, dass der Kernel irgendwie noch ATA-Devices sieht, > aber dann das udev diese testet, keine Verbindung bekommt ("link down") > und sie dann wieder raus wirft. Das kostet u.U. Zeit (22s). Aber warum > dauert das bei der E64-VM so lange? (retorische Frage :-) )
IMHO ist der StandardIDE-Treiber im Kernel drin, so dass auch die notwendigen Devices erzeugt werden müssen - mehr kann wahrscheinlich Thomas sagen.
Das dürfte aber für eis1 und eis64 identisch sein.
Es geht aber um die Unterschiede.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 12:29:50 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Böhm wrote:
> Aber ich glaube, es bringt nicht viel, weil man die udev-event Liste nicht > anzeigen lassen kann, auf die das "udevadm settle" - Kommando wartet, bis > sie abgearbeitet ist. Diese Event-Liste scheint bei E1- und E64-VM's > unterschiedlich lange zu sein.
Nach https://www.williamfeely.info/lfs-multilib/chapter07/usage.html Abschnitt 7.6.8 kannst du in /etc/sysconfig eine Datei rc.site anlegen und darin
# Speed up boot without waiting for settle in udev OMIT_UDEV_SETTLE=y schreiben, was das Settle verhindert.
Page 148 of 165 ---- Generated from net(t)forum Keine Ahnung welche Nebeneffekte das hat.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Fri, 08 Mar 2019 14:27:57 GMT View Forum Message <> Reply to Message Hallo Marcus,
Am 08.03.19 um 13:29 schrieb Marcus Roeckrath:
> > Nach https://www.williamfeely.info/lfs-multilib/chapter07/usage.html > Abschnitt 7.6.8 kannst du in /etc/sysconfig eine Datei rc.site anlegen und > darin > > # Speed up boot without waiting for settle in udev > OMIT_UDEV_SETTLE=y > > schreiben, was das Settle verhindert. /etc/sysconfig gibt es in Eisfair nicht. Selbst wenn man das Verzeichnis anlegt mit der rc.site darin und dem betreffenden Inhalt, wird das Settle dennoch ausgeführt. rc.site wird also nicht beachtet. Dafür könnte man im Initscript die entsprechenden Zeilen auskommentieren - und das wirkt!
> > Keine Ahnung welche Nebeneffekte das hat. > Das sehe ich auch so. Habe u.a. schon bemerkt, dass dann das Netzwerk-Device nicht gesehen/nicht aktiviert wurde oder es doppelt bzw. als schon vorhanden gesehen wurde. Also besser SETTLE/n lassen...
Ich habe auch noch mal eine E64-VM neu aufgesetzt, um auszuschließen, dass es sich um einen Einmaleffekt bei den aufgetretenen Problemen handelt.Es verhielt sich aber alles gleich vor vorher.
Das bedeutet, dass ich auf diesen Host-System zumind. kein Eisfair-64 mehr verwenden werde - wahrscheinlich überhaupt kein Eisfair mehr darauf.
Ich bin jetzt mit meinem Latein am Ende. Vieeelen Dank für Deinen Support und Deine Geduld.
Grüße. / Hilmar.
Page 149 of 165 ---- Generated from net(t)forum Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 14:40:06 GMT View Forum Message <> Reply to Message Hallo Hilmar,
Hilmar Bc3b6hm wrote:
>> Nach https://www.williamfeely.info/lfs-multilib/chapter07/usage.html >> Abschnitt 7.6.8 kannst du in /etc/sysconfig eine Datei rc.site anlegen >> und darin >> >> # Speed up boot without waiting for settle in udev >> OMIT_UDEV_SETTLE=y >> >> schreiben, was das Settle verhindert. > > /etc/sysconfig gibt es in Eisfair nicht.
Es gibt Pakete, die dort Sachen ablegen wie lm_sensors. Wenn es nicht da ist, muss man es eben anlegen.
> Selbst wenn man das Verzeichnis > anlegt mit der rc.site darin und dem betreffenden Inhalt, wird das Settle > dennoch ausgeführt. rc.site wird also nicht beachtet. Dafür könnte man im > Initscript die entsprechenden Zeilen auskommentieren - und das wirkt!
Dann so, wenn das andere nicht geht. Wenn ein Update das Init-Skript updaten sollte, ist dann die Änderung wieder futsch.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by kay on Fri, 08 Mar 2019 14:57:23 GMT View Forum Message <> Reply to Message Am 08.03.2019 um 07:47 schrieb Marcus Roeckrath: > Und dann sehen wir auch, woher der Geschwindigkeitsunterscheid genau > herkommt, nämlich von udevadm settle. > > udevadm settle braucht rund 20 Sekunden länger. > > Einfach udevadm settle totzulegen ist auch keine Option: > > "After the kernel boots, udevd is used to create device nodes for all > detected devices. That is a relatively time consuming task that has to be > completed for the boot process to continue, otherwise there is a risk of > services failing due to missing device nodes. > > udevadm settle waits for udevd to process the device creation events for all
Page 150 of 165 ---- Generated from net(t)forum > hardware devices, thus ensuring that any device nodes have been created > successfully before proceeding." > > Mit settle wird nun auf den Abschluss der vorher getriggerten Events > gewartet.
Ich will ja wirklich nicht sagen "Ich habs ja gesagt" aber Tatsache ist leider das ich schon als ich (Hilmar/Detlef?) versuchte zu erklären das und warum der Timeout sinn macht daran dachte das da etwas im Hintergrund noch nach etwas sucht weshalb es erst danach weiter gehen kann. Leider kam ich auch nicht direkt auf udev obwohl das logischerweise so sein muß.
Gab/gibt es nicht einen kernel logger/debugger (kmesg?!) den man beim Eisfair evtl. aktivieren kann? Evtl. zeigt der mehr an, macht es vermutlich nicht einfacher.
Falls es aber zwecks gegenprüfung hilft kann ich auf meinem Proliant und/oder dem AMD Phenom (beide Proxmox) gern noch weitere Tests mit einem Dummy- Eisfair in 32/64 Bit machen. Bitte mailen was ich probieren sollte oder... hier schreiben?
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 15:20:40 GMT View Forum Message <> Reply to Message Hallo Kay,
Kay Martinen wrote:
> Falls es aber zwecks gegenprüfung hilft kann ich auf meinem Proliant > und/oder dem AMD Phenom (beide Proxmox) gern noch weitere Tests mit > einem Dummy- Eisfair in 32/64 Bit machen. Bitte mailen was ich probieren > sollte oder... hier schreiben?
Keine Ahnung, ob es was bringt.
Da ist das Problem, dass man zu diesem Bootzeitpunkt noch keine schreibfähige Partition hat, und alles abschreiben, wird nicht gelingen.
Wäre auch die Frage, ob auch auf deinem System die Liste der getriggerten Events unter eis1 und eis64 unterschiedlichlang ist und dadurch auch unterschiedlich lange Bootzeiten festzustellen sind.
--
Page 151 of 165 ---- Generated from net(t)forum Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Fri, 08 Mar 2019 16:17:08 GMT View Forum Message <> Reply to Message Hallo Marcus,
> Da ist das Problem, dass man zu diesem Bootzeitpunkt noch keine > schreibfähige Partition hat, und alles abschreiben, wird nicht gelingen. > > Wäre auch die Frage, ob auch auf deinem System die Liste der getriggerten > Events unter eis1 und eis64 unterschiedlichlang ist und dadurch auch > unterschiedlich lange Bootzeiten festzustellen sind. so langsam geht hier wirklich alles durcheinander bzw. werdn die unterschiedlichsten Themen hier hineingepackt, bloß weil es am Anfang um Virtualisierung ging.
Aufhänger war doch mal, dass sich speziell eis64 unter Proxmox relativ träge verhält. Das zu hinterfragen ist ja auch sehr legitim, denn die Performance ist schon eine wichtige Größe für die Bewertung eines Servers. Allerdings habe ich bislang nichts zu den wirklich wichtigen Daten gelesen, etwa bei der Übertragung größerer Datenmengen. Ob ein Update etwas länger läuft oder gar ein Bootvorgang ist dagegen eigentlich eher akademisch.
Zudem müsste man, bevor man den eis zerlegt, erst einmal schauen, ob das Problem nicht auf Seiten des Hosts liegt. Und da kommt einerseits die Distro (Proxmox) in Betracht, aber auch die verwendete Virtualisierungslösung (m.W. KVM). Es wäre, wenn jemand da wirklich Forscherdrang hat, sehr sinnvoll, mal einen Debian mit KVM aufzusetzen und zu schauen, was dort mit dem eis als VM passiert.
Gruß Heinz-Peter
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Fri, 08 Mar 2019 16:37:00 GMT View Forum Message <> Reply to Message Hallo Heinz,
Heinz-Peter Faasen wrote:
> so langsam geht hier wirklich alles durcheinander bzw. werdn die > unterschiedlichsten Themen hier hineingepackt, bloß weil es am Anfang um > Virtualisierung ging.
Page 152 of 165 ---- Generated from net(t)forum > > Aufhänger war doch mal, dass sich speziell eis64 unter Proxmox relativ > träge verhält. Das zu hinterfragen ist ja auch sehr legitim, denn die > Performance ist schon eine wichtige Größe für die Bewertung eines Servers. > Allerdings habe ich bislang nichts zu den wirklich wichtigen Daten > gelesen, etwa bei der Übertragung größerer Datenmengen. Ob ein Update > etwas länger läuft oder gar ein Bootvorgang ist dagegen eigentlich eher > akademisch.
Für ein Dauerläufersystem, wie es ein Server in aller Regel ist, spielt die Bootzeit erstmal eine untergeordnete Rolle.
Erstaunlich finde ich dennoch, dass das im Vergleich von eis1 und eis64 unter ProxMox bei letzterem über 20 Sekunden länger dauert, weil das udev-Skript viel länger braucht, um die getriggerten Events abzuarbeiten.
Bei gleicher Hardware frage ich mich dabei, woher die höhere Zahl von getriggerten Events kommt.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Hilix on Fri, 08 Mar 2019 16:45:38 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Am 08.03.19 um 17:17 schrieb Heinz-Peter Faasen: > Allerdings habe ich bislang nichts zu den wirklich wichtigen Daten gelesen, etwa bei der Übertragung größerer Datenmengen. Ob > ein Update etwas länger läuft oder gar ein Bootvorgang ist dagegen eigentlich eher akademisch. Systemoptimierungen sind an allen Teilen eines Server m.E. wichtig, auch beim Bootvorgang. Ich habe nicht gezählt, wie oft ich Eisfair-VM's während meiner Tests jüngstgebootet habe, jedes mal mit einer guten Minute Wartezeit. Akademisch ist das sicherlich nicht.
> > Zudem müsste man, bevor man den eis zerlegt, erst einmal schauen, ob das Problem nicht auf Seiten des Hosts liegt. Und da kommt > einerseits die Distro (Proxmox) in Betracht, aber auch die verwendete Virtualisierungslösung (m.W. KVM). > Es wäre, wenn jemand da wirklich Forscherdrang hat, sehr sinnvoll, mal einen Debian mit KVM aufzusetzen und zu schauen, was dort > mit dem eis als VM passiert. Das habe ich ja in einen anderen Beitrag bereits berichtet (Debian-KVM-Host und E1/64-VM)! Naja, die 3 Threads, die sich mit dieser Problematik beschäftigen, sind inzwischen wirklich umfangreich :-)
Page 153 of 165 ---- Generated from net(t)forum Probleme mit der Übertragung größerer Datenmengen lassen sich durch schnelle Schnittstellen und Datenträger, geeignete Protokolle und ausreichend Memory lösen bzw. positiv beeinflussen. Da sehe ich bei Eisfair kein Problem.
Grüße. / Hilmar.
Subject: Re: Eisfair Starup Waits und VM Posted by Thomas Zweifel on Fri, 08 Mar 2019 17:05:21 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter
Am 08.03.2019 um 17:17 schrieb Heinz-Peter Faasen: > Zudem müsste man, bevor man den eis zerlegt, erst einmal schauen, ob das > Problem nicht auf Seiten des Hosts liegt. Und da kommt einerseits die > Distro (Proxmox) in Betracht, aber auch die verwendete > Virtualisierungslösung (m.W. KVM). > Es wäre, wenn jemand da wirklich Forscherdrang hat, sehr sinnvoll, mal > einen Debian mit KVM aufzusetzen und zu schauen, was dort mit dem eis > als VM passiert.
Mit einer CentOS/KVM VM sehe ich da keinen grossen Unterschied zur Hardware, die 10sek Wartezeit für die Laufwerke und die Mountzeit (journal einlesen) ergeben eine grössere Lücke:
[ 21.665133] sda: sda1 sda2 sda3 [ 21.792174] sd 0:0:0:0: [sda] Attached SCSI disk [ 21.805147] usb 1-1: New USB device found, idVendor=0627, idProduct=0001 [ 21.805151] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [ 21.805154] usb 1-1: Product: QEMU USB Tablet [ 21.805157] usb 1-1: Manufacturer: QEMU [ 21.805159] usb 1-1: SerialNumber: 42 [ 22.556883] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:05.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/in put/input4 [ 22.813692] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Pointer [QEMU QEMU USB Tablet] on usb-0000:00:05.7-1/input0 [ 23.095648] libata version 3.00 loaded. [ 35.795726] EXT3-fs (sda3): error: couldn't mount because of unsupported optional features (2c0) [ 36.025267] EXT2-fs (sda3): error: couldn't mount because of unsupported optional features (2c0) [ 36.316934] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 39.001918] udevd[1365]: starting version 3.2.1 [ 39.124876] random: udevd: uninitialized urandom read (16 bytes read, 115 bits of entropy available)
Page 154 of 165 ---- Generated from net(t)forum [ 39.374804] random: udevd: uninitialized urandom read (16 bytes read, 120 bits of entropy available) [ 39.651252] random: udevd: uninitialized urandom read (16 bytes read, 123 bits of entropy available) [ 39.907822] random: udevd: uninitialized urandom read (16 bytes read, 123 bits of entropy available) [ 40.161192] random: udevd: uninitialized urandom read (16 bytes read, 123 bits of entropy available) [ 40.440369] random: nonblocking pool is initialized [ 40.610454] udevd[1366]: starting eudev-3.2.1 [ 40.860882] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0 [ 41.045390] ide-cd driver 5.00
Gruss Thomas
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Sun, 10 Mar 2019 09:38:06 GMT View Forum Message <> Reply to Message Hallo Marcus,
> Für ein Dauerläufersystem, wie es ein Server in aller Regel ist, spielt die > Bootzeit erstmal eine untergeordnete Rolle. eben. Und selbst wenn es sich um eine Maschine handelt, die nachts abgeschaltet wird (bspw. in einer Büroumgebung), ist die Bootzeit am Morgen i.d.R. vernachlässigbar. Die Kaffeemaschine ist praktisch immer langsamer. :D
> Erstaunlich finde ich dennoch, dass das im Vergleich von eis1 und eis64 > unter ProxMox bei letzterem über 20 Sekunden länger dauert, weil das > udev-Skript viel länger braucht, um die getriggerten Events abzuarbeiten. > > Bei gleicher Hardware frage ich mich dabei, woher die höhere Zahl von > getriggerten Events kommt.
Ein Kollege hat gestern mal eine Proxmox-Umgebung aufgebaut und festgestellt, dass es sehr viele Konfigurationsmöglichkeiten gibt. Ihm ist es nicht leicht gefallen, eine VM vernünftig zur Mitarbeit zu bewegen. Von daher denke ich, dass der Fehler irgendwo dort zu suchen ist. Allerdings ist Proxmox nach seinen Erfahrungen für mich eh keine Option mehr, weil es schon nach dem Systemstart und ohne irgendwelche Aktivitäten etwa 800 MB RAM belegte. Wenn er auch bei anderen Dingen so verschwenderisch mit den Ressourcen umgeht....
Page 155 of 165 ---- Generated from net(t)forum Ich habe noch mal eine eis1- und eine eis64-VM ohne irgendwelche Zusatzpakete unter VirtualBox installiert. Beide brauchen praktisch auf die Sekunde genau die gleiche Zeit bis zum Login-Prompt: 35s. Es gibt zwei größere Wartezeiten: Zum einen der schon diskutierte Delay vor dem Mount, aber vorher schon mal ~10s für "Calibrating delay loop (skipped) preset value..", was aber der virtuellen Umgebung geschuldet sein dürfte und auf realer HW nicht auftreten sollte.
"time eisman update" liefert reproduzierbar folgende Ergebnisse: eis-1: real 0m16.033s user 0m1.948s sys 0m1.016s eis64: real 0m18.137s user 0m1.752s sys 0m1.236s
Ich vermute die Ursache darin, dass auf dem eis64 ein zusätzliches Paket installiert ist, dass die 32bit-SW aussortiert. Dies dürfte das Skript zusätzlich belasten.
Gruß Heinz-Peter
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Sun, 10 Mar 2019 09:50:34 GMT View Forum Message <> Reply to Message Hallo Thomas,
>> Es wäre, wenn jemand da wirklich Forscherdrang hat, sehr sinnvoll, mal >> einen Debian mit KVM aufzusetzen und zu schauen, was dort mit dem eis >> als VM passiert. > > Mit einer CentOS/KVM VM sehe ich da keinen grossen Unterschied zur > Hardware, die 10sek Wartezeit für die Laufwerke und die Mountzeit > (journal einlesen) ergeben eine grössere Lücke: danke für Deinen Erfahrungsbericht.
Hast Du auch mal die Möglichkeit, eis-1- und eis64-VMs zu vergleichen?
Gruß Heinz-Peter
Page 156 of 165 ---- Generated from net(t)forum Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Sun, 10 Mar 2019 09:51:07 GMT View Forum Message <> Reply to Message Hallo Heinz-Pater,
Heinz-Peter Faasen wrote:
>> Für ein Dauerläufersystem, wie es ein Server in aller Regel ist, spielt >> die Bootzeit erstmal eine untergeordnete Rolle. > > eben. > Und selbst wenn es sich um eine Maschine handelt, die nachts > abgeschaltet wird (bspw. in einer Büroumgebung),
Mein Schulserver läuft auch 24/7, denn nachts werden Backups und andere Aufgaben erledigt.
Abgesehen davon gibt es auch Kollegen (z. B. die Vertretungsplaner, ich als Admin), die sich auch abens noch ins Netz verbinden, um zu arbeiten.
> Ich habe noch mal eine eis1- und eine eis64-VM ohne irgendwelche > Zusatzpakete unter VirtualBox installiert. Beide brauchen praktisch auf > die Sekunde genau die gleiche Zeit bis zum Login-Prompt: 35s.
Möglicherweise muss man in ProxMox spezielle Optionen setzen, je nachdem ob man einen 32- oder 64bit-Client betreibt.
Danke für deine Tests.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by Thomas Zweifel on Sun, 10 Mar 2019 11:46:05 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter
Am 10.03.2019 um 10:50 schrieb Heinz-Peter Faasen: >>> Es wäre, wenn jemand da wirklich Forscherdrang hat, sehr sinnvoll, mal >>> einen Debian mit KVM aufzusetzen und zu schauen, was dort mit dem eis >>> als VM passiert. >> >> Mit einer CentOS/KVM VM sehe ich da keinen grossen Unterschied zur >> Hardware, die 10sek Wartezeit für die Laufwerke und die Mountzeit >> (journal einlesen) ergeben eine grössere Lücke: > > danke für Deinen Erfahrungsbericht. > > Hast Du auch mal die Möglichkeit, eis-1- und eis64-VMs zu vergleichen?
Page 157 of 165 ---- Generated from net(t)forum Aber Klar --> Ist hier etwa gleichauf mit dem E64:
[ 22.249810] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 22.508217] sd 0:0:0:1: [sdb] Write Protect is off [ 22.508222] sd 0:0:0:1: [sdb] Mode Sense: 63 00 00 08 [ 22.643444] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 22.937264] sdb: unknown partition table [ 23.080429] sd 0:0:0:1: [sdb] Attached SCSI disk [ 23.219226] sda: sda1 sda2 sda3 [ 23.360386] sd 0:0:0:0: [sda] Attached SCSI disk [ 36.114423] EXT3-fs (sda3): error: couldn't mount because of unsupported optional features (2c0) [ 36.355869] EXT2-fs (sda3): error: couldn't mount because of unsupported optional features (2c0) [ 36.601052] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 38.867337] apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) [ 38.989218] apm: overridden by ACPI. [ 39.292635] random: nonblocking pool is initialized [ 39.422174] udevd[1381]: starting version 3.2.1 [ 39.561101] udevd[1382]: starting eudev-3.2.1 [ 39.796205] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0 [ 39.950651] input: PC Speaker as /devices/platform/pcspkr/input/input4 [ 40.070036] virtio-pci 0000:00:03.0: irq 46 for MSI/MSI-X [ 40.070091] virtio-pci 0000:00:03.0: irq 47 for MSI/MSI-X [ 40.070144] virtio-pci 0000:00:03.0: irq 48 for MSI/MSI-X [ 40.081386] ide-cd driver 5.00 [ 40.569705] ide-cd: hda: ATAPI 4X DVD-ROM drive, 512kB Cache [ 40.676936] cdrom: Uniform CD-ROM driver Revision: 3.20
Beim eisman update dasselbe nochmal: eistest # time eisman update real 0m55.499s user 0m7.604s sys 0m7.140s eisfair64 # time eisman update real 0m53.946s user 0m6.540s sys 0m7.124s
Genau so wie ein eistest # time echo "scale=5000; 4*a(1)" | bc -l real 1m8.496s
Page 158 of 165 ---- Generated from net(t)forum user 1m8.480s sys 0m0.004s eisfair64 # time echo "scale=5000; 4*a(1)" | bc -l real 0m56.016s user 0m55.912s sys 0m0.000s nichts unerwartetes ans Tageslicht bringt.
Gruss Thomas
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Sun, 10 Mar 2019 12:16:18 GMT View Forum Message <> Reply to Message Hallo Thomas,
>> Hast Du auch mal die Möglichkeit, eis-1- und eis64-VMs zu vergleichen? > > Aber Klar --> Ist hier etwa gleichauf mit dem E64: > > [ 22.249810] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 22.508217] sd 0:0:0:1: [sdb] Write Protect is off > [ 22.508222] sd 0:0:0:1: [sdb] Mode Sense: 63 00 00 08 > [ 22.643444] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 22.937264] sdb: unknown partition table > [ 23.080429] sd 0:0:0:1: [sdb] Attached SCSI disk > [ 23.219226] sda: sda1 sda2 sda3 > [ 23.360386] sd 0:0:0:0: [sda] Attached SCSI disk > [ 36.114423] EXT3-fs (sda3): error: couldn't mount because of > unsupported optional features (2c0) > [ 36.355869] EXT2-fs (sda3): error: couldn't mount because of > unsupported optional features (2c0) > [ 36.601052] EXT4-fs (sda3): mounted filesystem with ordered data > mode. Opts: (null) > [ 38.867337] apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) > [ 38.989218] apm: overridden by ACPI. > [ 39.292635] random: nonblocking pool is initialized > [ 39.422174] udevd[1381]: starting version 3.2.1 > [ 39.561101] udevd[1382]: starting eudev-3.2.1 > [ 39.796205] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, > revision 0 > [ 39.950651] input: PC Speaker as /devices/platform/pcspkr/input/input4 > [ 40.070036] virtio-pci 0000:00:03.0: irq 46 for MSI/MSI-X
Page 159 of 165 ---- Generated from net(t)forum > [ 40.070091] virtio-pci 0000:00:03.0: irq 47 for MSI/MSI-X > [ 40.070144] virtio-pci 0000:00:03.0: irq 48 for MSI/MSI-X > [ 40.081386] ide-cd driver 5.00 > [ 40.569705] ide-cd: hda: ATAPI 4X DVD-ROM drive, 512kB Cache > [ 40.676936] cdrom: Uniform CD-ROM driver Revision: 3.20 > > > Beim eisman update dasselbe nochmal: > > eistest # time eisman update > real 0m55.499s > user 0m7.604s > sys 0m7.140s > > eisfair64 # time eisman update > real 0m53.946s > user 0m6.540s > sys 0m7.124s > > > Genau so wie ein > > eistest # time echo "scale=5000; 4*a(1)" | bc -l > real 1m8.496s > user 1m8.480s > sys 0m0.004s > > eisfair64 # time echo "scale=5000; 4*a(1)" | bc -l > real 0m56.016s > user 0m55.912s > sys 0m0.000s > > nichts unerwartetes ans Tageslicht bringt. vielen Dank für Deine Tests! Sie bestätigen, was ich mit Xen und VirtualBox erlebe.
Als Fazit bleibt damit, dass das Problem im Proxmox steckt oder in der von den Nutzern gewählten Konfiguration. Da Proxmox auch noch weitere Nachteile hat, ist es für mich uninteressant und ich werde mich nicht weiter mit dem System beschäftigen.
Gruß Heinz-Peter
Subject: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Sun, 10 Mar 2019 12:22:32 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Page 160 of 165 ---- Generated from net(t)forum Heinz-Peter Faasen wrote:
>> nichts unerwartetes ans Tageslicht bringt. > > vielen Dank für Deine Tests! > Sie bestätigen, was ich mit Xen und VirtualBox erlebe. > > Als Fazit bleibt damit, dass das Problem im Proxmox steckt oder in der > von den Nutzern gewählten Konfiguration. > Da Proxmox auch noch weitere Nachteile hat, ist es für mich > uninteressant und ich werde mich nicht weiter mit dem System beschäftigen.
Euch danke für die Tests, die zeigen, dass wir vermutlich kein grundsätzliches Problem im eisfair-64 haben.
-- Gruss Marcus
Subject: Re: Eisfair Starup Waits und VM Posted by kay on Sun, 10 Mar 2019 14:42:50 GMT View Forum Message <> Reply to Message Am 10.03.2019 um 10:51 schrieb Marcus Roeckrath: > Hallo Heinz-Pater, > > Heinz-Peter Faasen wrote: > >> Ein Kollege hat gestern mal eine Proxmox-Umgebung aufgebaut und >> festgestellt, dass es sehr viele Konfigurationsmöglichkeiten gibt. >> Ihm ist es nicht leicht gefallen, eine VM vernünftig zur Mitarbeit zu >> bewegen.
Das würde ich hier so nicht behaupten wollen. Beim Einrichten einer VM braucht man eigentlich nur RAM-Menge, Diskgröße und Installations-image angeben. Meist wird man zusätzlich noch den Typ der Virtuellen Netzwerkkarte (Default: e1000) und evtl. den zu emulierenden Prozessor (Default: kvm64) angeben und evtl. noch ob man für das RAM Ballooning nutzen will. Dazu eine ID-Nr (100-xxx) und das war's eigentlich schon. Aber man KANN natürlich viel mehr Einstellungen machen - muß es aber nicht!
> > Möglicherweise muss man in ProxMox spezielle Optionen setzen, je > nachdem ob man einen 32- oder 64bit-Client betreibt.
Ich setzte die CPU in den 32-bit Eisfairs immer auf kvm32 und hab dies nur beim Test Eisfair64 auf dem Default (kvm64) gelassen. Hab aber nicht probiert ob dies einen Unterschied macht.
Page 161 of 165 ---- Generated from net(t)forum Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Mon, 11 Mar 2019 09:48:35 GMT View Forum Message <> Reply to Message Hallo Kay,
>>> Ein Kollege hat gestern mal eine Proxmox-Umgebung aufgebaut und >>> festgestellt, dass es sehr viele Konfigurationsmöglichkeiten gibt. >>> Ihm ist es nicht leicht gefallen, eine VM vernünftig zur Mitarbeit zu >>> bewegen. > > Das würde ich hier so nicht behaupten wollen. Beim Einrichten einer VM > braucht man eigentlich nur RAM-Menge, Diskgröße und Installations-image > angeben. Meist wird man zusätzlich noch den Typ der Virtuellen > Netzwerkkarte (Default: e1000) und evtl. den zu emulierenden Prozessor > (Default: kvm64) angeben und evtl. noch ob man für das RAM Ballooning > nutzen will. Dazu eine ID-Nr (100-xxx) und das war's eigentlich schon. > Aber man KANN natürlich viel mehr Einstellungen machen - muß es aber nicht! ich habe keine Ahnung, was da bei ihm schief gelaufen ist. Mir fehlen aber die Zeit und der Antrieb, mich in ein System einzuarbeiten, dass nur geringe Vorteile, aber offenbar doch deutliche Nachteile gegenüber den bisher von mir verwendeten Lösungen hat.
Versteh mich bitte richtig: Ich will weder Dir noch jemand anderem Proxmox madig machen, es ist eben einfach für MICH nicht die beste Wahl.
>> Möglicherweise muss man in ProxMox spezielle Optionen setzen, je >> nachdem ob man einen 32- oder 64bit-Client betreibt. > > Ich setzte die CPU in den 32-bit Eisfairs immer auf kvm32 und hab dies > nur beim Test Eisfair64 auf dem Default (kvm64) gelassen. Hab aber nicht > probiert ob dies einen Unterschied macht.
Das ist natürlich denkbar. Allerdings könntest Du ja nur den eis-1 auf kvm64 installieren. Und damit dürfte es nicht besser werden.
Hast Du eigentlich auch so einen hohen RAM-Verbrauch für den Host?
Gruß Heinz-Peter
Page 162 of 165 ---- Generated from net(t)forum Subject: Aw: Re: Eisfair Starup Waits und VM Posted by Marcus Roeckrath on Mon, 11 Mar 2019 10:10:39 GMT View Forum Message <> Reply to Message Hallo Heinz-Peter,
Heinz-Peter Faasen schrieb am Mon, 11 March 2019 10:48 Versteh mich bitte richtig: Ich will weder Dir noch jemand anderem Proxmox madig machen, es ist eben einfach für MICH nicht die beste Wahl.
Und das ist auch gut so; jedem scvmeckt es anderes am besten, sei es auf dem Desktop, dem Server oder als Virtualisierungslösung.
Subject: Re: Eisfair Starup Waits und VM Posted by kay on Mon, 11 Mar 2019 16:10:43 GMT View Forum Message <> Reply to Message Am 11.03.2019 um 10:48 schrieb Heinz-Peter Faasen: > >>>> Ihm ist es nicht leicht gefallen, eine VM vernünftig zur Mitarbeit zu >>>> bewegen. >> >> Das würde ich hier so nicht behaupten wollen. Beim Einrichten einer VM >> braucht man eigentlich nur RAM-Menge, Diskgröße und Installations-image > > Mir fehlen aber die Zeit und der Antrieb, mich in ein System > einzuarbeiten, dass nur geringe Vorteile, aber offenbar doch deutliche > Nachteile gegenüber den bisher von mir verwendeten Lösungen hat.
Das ist natürlich deine Sache. Mit VMware habe ich angefangen aber lange nicht damit gespielt weil ich Virtualbox praktischer finde - auf dem Desktop um was aus zu probieren. Und Proxmox hab ich auf den zwei Hosts, einer in der Wohnung mit Router und den anderen im Keller für Serverjobs. Ich hab mich halt nur gewundert wie man da nicht sofort mit klar kommen kann. esxi 3/4 mit seinem Windows-client fand ich dagegen Raketenwissenschaft. :-)
> Versteh mich bitte richtig: Ich will weder Dir noch jemand anderem > Proxmox madig machen, es ist eben einfach für MICH nicht die beste Wahl.
Jedem das seine, ist schon klar.
>> Ich setzte die CPU in den 32-bit Eisfairs immer auf kvm32 und hab dies >> nur beim Test Eisfair64 auf dem Default (kvm64) gelassen. Hab aber nicht >> probiert ob dies einen Unterschied macht. > > Das ist natürlich denkbar. Allerdings könntest Du ja nur den eis-1 auf > kvm64 installieren. Und damit dürfte es nicht besser werden.
Das könnte ich mal probieren wenn es noch niemand versuchte. Umgekehrt (Eis64 auf kvm32) macht es ja Definitiv keinen Sinn.
Page 163 of 165 ---- Generated from net(t)forum > Hast Du eigentlich auch so einen hohen RAM-Verbrauch für den Host?
IMHO nein, nicht die 800 MB von denen du schriebst. Ist hier nur schwierig zu ermitteln weil die dauernd laufen und gebraucht werden. Der/Die Server im Keller um diesen Artikel zu posten und die Router-VM hier um den (und alles andere) an meinen Hauptrouter durch zu stellen.
Heißt: Die VMs sind auch auf Autostart gesetzt und fahren sofort mit hoch wenn der host startet. Ich versuche beim nächsten geplanten reboot mal dran zu denken Autostart aus zu schalten und dann sehe ich ja wieviel RAM er idle braucht. Hier läuft allerdings kein corosync oder Clusterzeugs was RAM und eine Extra NIC brauchen könnte.
Kay
-- Sent via SN (Eisfair-1)
Subject: Re: Eisfair Starup Waits und VM Posted by Heinz-Peter Faasen on Mon, 11 Mar 2019 16:41:25 GMT View Forum Message <> Reply to Message Hallo Kay,
> Das ist natürlich deine Sache. Mit VMware habe ich angefangen aber lange > nicht damit gespielt weil ich Virtualbox praktischer finde - auf dem > Desktop um was aus zu probieren. sehe ich auch so.
> Und Proxmox hab ich auf den zwei Hosts, > einer in der Wohnung mit Router und den anderen im Keller für > Serverjobs. Ich hab mich halt nur gewundert wie man da nicht sofort mit > klar kommen kann.
Kann ich im Moment nichts zu sagen, habe es halt selbst nicht probiert.
> esxi 3/4 mit seinem Windows-client fand ich dagegen > Raketenwissenschaft. :-)
Ich will weder einen M$-Client noch ein kostenpflichtiges Verwaltungstool wie vCenter. Vor allem aber gefällt mir, dass Xen inzw. unter dem Dach der Linux-Foundation gelandet ist.
>> Das ist natürlich denkbar. Allerdings könntest Du ja nur den eis-1 auf >> kvm64 installieren. Und damit dürfte es nicht besser werden. >
Page 164 of 165 ---- Generated from net(t)forum > Das könnte ich mal probieren wenn es noch niemand versuchte. Umgekehrt > (Eis64 auf kvm32) macht es ja Definitiv keinen Sinn.
Ebent! ;)
>> Hast Du eigentlich auch so einen hohen RAM-Verbrauch für den Host? > > IMHO nein, nicht die 800 MB von denen du schriebst. Ist hier nur > schwierig zu ermitteln weil die dauernd laufen und gebraucht werden. > Der/Die Server im Keller um diesen Artikel zu posten und die Router-VM > hier um den (und alles andere) an meinen Hauptrouter durch zu stellen. > > Heißt: Die VMs sind auch auf Autostart gesetzt und fahren sofort mit > hoch wenn der host startet. Ich versuche beim nächsten geplanten reboot > mal dran zu denken Autostart aus zu schalten und dann sehe ich ja > wieviel RAM er idle braucht.
Wäre mal interessant.
> Hier läuft allerdings kein corosync oder > Clusterzeugs was RAM und eine Extra NIC brauchen könnte.
Das war wohl auch nur eine einfache Basisinstallation direkt vom ISO.
Gruß Heinz-Peter
Page 165 of 165 ---- Generated from net(t)forum