Warum mietet er das dann nicht bei einer Gameserverbude…?
Posts by frostschutz
-
-
Kann ich die zur Verfügung gestellten CD-ROM-/DVD-Images wie
z.B. "Ubuntu 14.04 Server 64 Bit" nur auf einem "Root-Server L Generation
6" oder auch auf einem "Root-Server M Generation 6" nutzen?Du installierst dir einen Bootloader auf die Festplatte. Wenn du nicht weißt wie das geht, machst du halt zuerst irgendeine Image-Installation.
Dann lädst du dir Kernel und Initrd von hier: Index of /ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64
Und dann bootest du das und installierst wie gewohnt. Die Pakete werden dann nicht von CD sondern übers Internet geladen, ansonsten dürfte es gleich sein...
Oder aber du freundest dich mit debootstrap an.
-
Du brauchst ein besseres Mikrofon (oder ich bessere Ohren) oder einen anderen Audio-Codec. Selbst ein 0815 USB-Mikrofon um 10-20€ sollte das besser hinbekommen. Deine Aufnahme klingt nach Onboard-Mikrofoneingang ohne Mic-Boost...
Um herauszufinden was beim Befolgen der Wiki-Anleitung nicht geklappt hat, wäre es interessant den ganzen Vorgang im Terminal mal festzuhalten (per 'script' o.ä.). fdisk könnte Probleme machen, es gibt inzwischen ja auch zig verschiedene fdisk-Versionen (mit und ohne GPT-Unterstützung, mit und ohne automatisches Partitions-Alignment, ...), da muss man sich eben anpassen. Das Rettungssystem macht Anfängern vielleicht auch Probleme, weil man hier erstmal selbst sich drum kümmern muss daß es überhaupt bootet (Network steht nicht automatisch in der Liste und schon gar nicht an 1. Stelle - bei dir auch nur auf Platz #2).
-
Nicht das was ich gemeint habe ... ich kenne FreeBSD nicht, Google meint was von /etc/wall_cmos_clock
Eine Stunde daneben klingt halt stark danach, daß die "Systemuhr" falsch interpretiert wird (local statt UTC oder andersrum).
-
Gibts da auch ne Einstellung der Systemuhr utc vs. local?
-
Du brauchst den VirtIO Treiber Windows7Install - KVM
Oder Netcup überreden dich von VirtIO auf normales SATA umzustellen, aus Performanzgründen aber normalerweise nicht empfehlenswert.
-
parted nimmt leider schräge Einheiten beim print, die es falsch aussehen lassen obwohl es richtig ist.
Wenn du Partitionsalignment mit parted anschauen willst, nimm lieber:
Wenn du glatte MiB siehst bzw. Sektoren vielfache von 2048, dann passt es. Falls es eine erweiterte oder bios_boot Partition gibt: Es zählt nur primary und logical.
Edit: Ups, ich hab dich glaub eh falsch verstanden, dir gings nicht ums Alignment... sorry
Wenn es VirtIO ist (/dev/vda) dann kannst du problemlos im Betrieb neue Partitionen hinzufügen, der Kernel sieht diese sofort. Einzig bei /dev/sda mag er das lieber nicht so ohne Reboot dazwischen solange das Gerät in Gebrauch ist. Du kannst auch die bestehende Partition vergrößern und dann mit resize2fs das ext4-Dateisystem erweitern.
-
Bug Report ist hier: Bug 91691 – Extremely slow disk I/O, high iowait in 3.16 and newer kernels, unless blktrace is running
VIel herausgekommen ist dabei bis jetzt noch nicht. Wenn man blktrace laufen läßt ist die Performanz auf einmal besser. Aber das kanns ja auch nicht sein.
Gerade habe ich mal testweise Debian Jessie-rc1 installiert. Das kommt mit einem 3.16er Kernel. Da sieht es dann so aus:
Code# dd if=/dev/vda of=/dev/null bs=1M count=512 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 1640.51 s, 327 kB/s
Mir bleibt also nichts übrig, als bei einem alten Kernel zu bleiben. Anders läuft auf der Kiste nichts.
Vor ein paar Jahren hatte ich schonmal einen Kernel-Bug, mit einem Firewire-Gehäuse das der Linux-Treiber nicht erkennen wollte. Da habe ich dem Kernelentwickler Root-Zugriff auf die Kiste gegeben und der hat das direkt am System debuggt und behoben. Das gleiche habe ich hier auch angeboten (Root-Zugang zum VServer), der Entwickler ist darauf leider nicht eingegangen. Ich weiß auch nicht mal, ob der Bisect überhaupt die richtige Stelle gefunden hat...
felix, wenn das Problem auf Netcup-Seite reproduzierbar ist, bist du wohl in der besseren Position diesem Kernel-Bug auf die Schliche zu kommen. Ich bin hier mit meinem Latein am Ende.
-
Danke für die Antwort. Ich werde das dann nachher mal auf den Kernel-Bugtracker werfen.
-
Vielleicht ist die Seite etwas unter Last weil die Produkte alle 0€ kosten?
-
Ich habe mir Anfang Januar einen Root Server M zugelegt (das 5.49€-Angebot, Root-Server M v5a1 24M). Leider scheint das Gerät allergisch gegen Kernel neuer als 3.15 zu sein. Der Server bleibt oft stundenlang mit 100% IO-Wait hängen.
Mir ist es relativ egal, ob ein vServer langsam ist. Ich habe keine Gameserver und auch kein Gentoo drauf, meine Ansprüche sind niedrig. Aber ich möchte doch dann und wann mal ein Systemupdate machen oder einen Tarball entpacken können ohne daß sich der Server stundenlang verabschiedet. Und ich verschenke ungerne >90% der möglichen Performanz unnötig an einen Kernel-Bug, und bei einer alten Kernel-Version bleiben ist auf lange Sicht für mich auch keine Option.
Mein Test sieht folgendermaßen aus:
1) Image übers Controlpanel installieren. Distribution egal (Debian, Ubuntu, Archlinux). Minimale Partitionierung. Ggf. Pakete aktualisieren.
2) Mit parted (o.ä.) im unpartitionierten Speicher eine 512MiB große vda4-Partition erstellen (mit MiB-Alignment).
3) 512MiB Datei im RAM erstellen und auf die Partition schreiben.Codetruncate -s 512M /dev/shm/foobar shred -n 1 /dev/shm/foobar dd bs=1M if=/dev/shm/foobar of=/dev/vda4
Ab Kernel 3.2.x (Rescuesystem) bis einschließlich Kernel 3.14/3.15 bekomme ich bei diesem Test 30-50MiB/s. Ab Kernel 3.16 aufwärts (einschließlich 3.19-rc4) sind es 2-3MiB/s und das System kommt dabei fast zum Stillstand. Dabei ist es egal zu welcher Tageszeit der Test durchgeführt wird, ob die Kernel selbst compiliert sind oder z.B. aus dem Ubuntu Kernel Mainline Repository stammen.
Das sind jetzt lineare Writes und damit relativ harmlos. Aber sobald die Zugriffe zufälliger werden (z.B. ein kernel.tar.xz entpacken) kann man erstmal ins Elsaß fahren und einen Flammkuchen essen gehen. Da geht dann praktisch gar nichts mehr.
Ein git bisect hat mich zu diesem Commit geschickt: blk-mq: split make request handler for multi and single queue · 07068d5 · torvalds/linux · GitHub
Das muss aber nicht unbedingt stimmen da die bisect-Zwischenstände ihre ganz eigenen Krankheiten haben (Kernel Panics usw.). Und für einen einfachen git revert gibt es ein paar Konflikte. Ich komme da auch nicht wirklich weiter - bin halt weiters kein Kernel-Entwickler. Auf der LKML habe ich nur eine Problembeschreibung gefunden die meiner ähnelt - aber die dort angegebene Kernel-Version passt nicht: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1
Bevor ich mir jetzt einen armen unschuldigen Kernel-Entwickler schnappe und diesem auf die Nerven gehe, wollte ich mal fragen, ob das Problem auch bei anderen (M v5a1) auftritt oder nicht?
Bei meinem Root Server S ist es z.B. nicht der Fall, da läuft alles wunderbar (>50MiB/s)... lokal in einer eigenen KVM-Instanz kann ich das Problem auch nicht reproduzieren, dazu müsste man wohl im Detail wissen, wie der Netcup-Host aufgebaut ist.
-
Ich steige im Moment selbst von einem Root Server S auf Root Server M um. Übertragen habe ich ganz normal mit SSH/rsync.
Sorgen bereitet mir der hohe IO-wait. Beim entpacken eines Linux-Kernel-Tarballs bleibt die Kiste praktisch stehe.
Überschreiben einer 512MB-Partition mit Zufallsdaten:
Code# truncate -s 512M /dev/shm/foobar # shred -n 1 /dev/shm/foobar # dd bs=1M if=/dev/shm/foobar of=/dev/vda4 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 164.985 s, 3.3 MB/s
Das gleiche im Rettungssystem:
Coderescue:~# truncate -s 512M /dev/shm/foobar rescue:~# shred -n 1 /dev/shm/foobar rescue:~# dd bs=1M if=/dev/shm/foobar of=/dev/vda4 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 12.7916 s, 42.0 MB/s
Es liegt also allem Anschein nach am Kernel. Das Rettungssystem ist 3.2.63 - das ist mir etwas zu stabil
-, im installierten System habe ich 3.18.1 und 3.17.7 probiert.
Auf der LKML habe ich noch jemanden mit IO-wait-Problemen bei aktuellem Kernel gefunden: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1
Ich versuche es als nächstes mit 3.14, das läuft auf meinem Root Server S...
Edit: Und siehe da, mit 3.14.2 und ansonsten ident. Konfiguration (make oldconfig) klappts auf einmal wunderbar:
Code# truncate -s 512M /dev/shm/foobar # shred -n 1 /dev/shm/foobar # dd bs=1M if=/dev/shm/foobar of=/dev/vda4 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 11.8879 s, 45.2 MB/s
Fröhliches Kernel-Bug-Hunting...
-
Das ist ja noch gruseliger als vorher...
jetzt wird da schon stillschweigend irgendwelcher Krempel nachinstalliert, also wirklich
-
Abgesehen davon daß das eine ziemlich gruselige Art ist, etwas zu partitionieren, fehlt da schlicht der Befehl der das Dateisystem selbst vergrößert (resize2fs odgl).
Und wenn du das nicht im Rettungssystem machst wo das Dateisystem nicht gemountet ist, wird das System die Partitionstabelle nach einem fdisk nicht aktualisieren (weil in Benutzung) und resize2fs somit auch nichts machen.
-
Was geht denn nicht?
Du hast LVM.
-
Du versuchst da, fsck auf ein LVM PV anzuwenden, statt auf ein wie auch immer geartetes Logical Volume (LV). Da kannst du froh sein wenn es mit einer Fehlermeldung aussteigt. fsck mit -y und -f ist nicht selten eine tödliche Kombi.
-
Mein Firefox (30.0 Linux) weigert sich warum auch immer das Textfeld per Mittlere-Mausklick-Paste zu befüllen. Ich hab das gleiche Problem allerdings auch phpMyAdmin (im Queryeditor) und noch nicht die Ursache gefunden. Ohne JS gehts.
Kann das jemand nachvollziehen oder ist das eine Eigenart meines Systems?
-
Je mehr Server du hast, desto mehr Administrationsaufwand bringt das auch mit sich.
Webserver und Datenbank zu trennen bringt dir erstmal Performanzeinbußen. Weil dann eben der ganze DB-Traffic übers Netz gehen muss. Lokal ist es einfach viel schneller.
Wer das machen muss weil die Kiste einfach brennt, der setzt für die Web<->DB Verbindung meistens eine eigene Leitung ein. Und die Webanwendung selbst wird dann auch daraufhin optimiert, wirklich nur das nötige von der DB abzufragen; wogegen du lokal bzw. in 0815 PHP-Scripts eher ein SELECT * FROM findest auch wenn von den hundert Spalten nur zwei oder drei tatsächlich gebraucht werden. Lokal ist das nicht so wahnsinnig schlimm, aber wenn es Netzwerktraffic verzehnfacht merkst du es sofort... besonders lustig wird es dann wenn der Webserver versucht vom DB-Server ein Backup zu ziehen (weil die PHP-Software im Administrationspanel das so anbietet). Da schickst du dann auf einmal mehrere Gigabyte über die Leitung... für Nichts
-
-
Wenn ich sowas sehe frage ich mich immer, interessierst du dich jetzt tatsächlich für die Benchmarks, oder willst du einfach wissen wieviel Chancen ein Linux Virus heutzutage so hat? Denn jeder, der das so ausführt, hat dann womöglich einen. Du weißt bei dem Befehl ja nicht, was in dem Script dringestanden hat. Wenn du es dir vorher oder nachher nochmal runterlädst, mußt du ja nicht das gleiche Script bekommen. Das kann der Webserver ja bei jedem Request aufs neue entscheiden, was er diesmal ausliefert.
Ist auch der Grund warum ich den Calibre-Installer nicht mag ( calibre - Download for linux ) der macht das gleiche mit Python und sudo... und Calibre hatte schonmal einen eingebauten local root exploit.
Meine Ergebnisse (Root Server S)
Code
Display MoreENSKY MEDIA Benchmark v2.1 visit: www.ensky-media.net Allgemeine Informationen CPU : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz Anzahl der Kerne : 1 CPU Taktfrequenz : 2393.996 MHz Arbeitsspeicher : 998 MB SWAP : 639 MB Uptime : 22 days, 22:47, Netzwerk Benchmark Download Geschwindigkeit: ENSKY MEDIA (DE, Frankfurt am Main): 22.0MB/s Download Geschwindigkeit: Colo Bunker (DE, Bonn): 48.2MB/s Download Geschwindigkeit: Thinkboard (DE): 10.2MB/s Download Geschwindigkeit: QSC (DE): 14.2MB/s Festplatten Benchmark I/O Geschwindigkeit : 236 MB/s