ThomasChr Tut man das nicht sonst auch?
Eigentlich schon. Aber bei schönem Wetter hab ich immer ein schlechtes Gewissen dabei!
Beiträge von ThomasChr
-
-
Generell finde ich Regen aber cool. Das kann noch ein paar Tage weiterregnen. Die Landwirte habens nötig.
Endlich ohne schlechtes Gewissen Zeit am Computer verbringen
-
Ich bin jetzt vom Cluster wieder weg. Eine einzelne Kiste mit ZFS und Dedup reicht mir, da ich fast nur noch lxc Container betreibe.
Kannst das ein bisschen ausführen? Warum LXC und kein Docker, und wie managed du es?
Proxmox?
-
Ich nehme einfach mal an dass die Erfahrung zeigt dass soviele Kerne sowieso selten bis nie ausgenutzt werden. Wäre also noch mehr CPUs die rumstehen und nicht genutzt werden.
Um das auszugleichen müsste man wahrscheinlich deutlich teurer sein.
Wenn ich drank denke was ich an Test und Standby RS-Servern habe die ihre CPUs quasi nie benutzen...
Naja, die genau Kalkulation könnte dir hier sicherlich nur netcup sagen, aber es wird sich halt ned lohnen. In dem Preissegment kann ich mir dann schon einen physikalischen Root-Server mieten.
-
Weil der RS die CPUs dediziert hat. Das heißt du musst -und wir gehen jetzt mal davon aus dass netcup das auch exakt so macht- für jeden RS-Server auf dem Host alle seine CPUs jederzeit verfügbar haben. (selbst wenn er ausgeschaltet ist!)
Und das obwohl mindestens die Hälfte der RS-Server ihre CPU sowieso nicht nutzen!
Bei den VPS kannst du besser wirtschaften und Host-CPUs doppelt und dreifach vergeben, je nachdem wieviel CPUs eben von allen VPS-Servern auf dem Host auch wirklich gerade verwendet werden!
-
Auf einem RS G8 war es nicht möglich laggfrei einen CS.GO Server laufen zu lassen. Das sieht beim RS G9 bedeutend anders aus!
Wäre jetzt echt interessant hier zu forschen warum das so ist. CPU Latency? Network Latency?
-
Dachte ich zuerst auch, aber afaik muss zuerst die Partition vergrößert werden. Dann erst bringt der resize2fs was...
-
Leider schon etwas umständlich, dafür dass es sonst sehr einfach ist über das CCP einen größeren Servertarif zu buchen.Nix für ungut, aber dass wird von einem Server-Admin halt nunmal erwartet!
Man sollte eher sagen "das installieren eines Linux Images ist bei Netcup viel zu einfach, so dass es sogar Leute machen können die keine Ahnung von Partitionen haben"...
Wie gesagt, nix für ungut, ist nicht böse gemeint!
-
Kann nicht mit Hassbotschaften dienen, aber die Frage auf welchem Netcup System das Ding läuft würde mich interessieren...
Aber bitte jetzt keinen Benchmark machen, da sind die Forumsteilnehmer gerade empfindlich
-
Nur zum Verständnis: netcup kümmert sich hier um die Absicherung des Systems, das aktualisieren und das Monitoring. Um das einrichten von deinen Websites kümmern die sich nicht. Auch Support leisten sie hier nur bedingt!
Und das soll definitiv kein Support Bashing sein, denn ein Managed Server bedeutet eigentlich nur dass du ein Webhosting für dich alleine hast.
Es heißt also nicht dass der Support dir viel mehr hilft als beim normalen Webhosting, oder dass er dir alle Wünsche auf deinem Server erfüllt!
-
Wobei ich mal ganz frech behaupten würde dass eine Kombination aus RS 2000 G9 + Plesk Lizenz nicht nur deutlich mehr Speicherplatz hat, sondern auch nochmal so fast 20 € günstiger ist.
Einziger Unterschied: Man muss sich regelmäßig einloggen um im Plesk irgendwo auf Update klicken. Sicherlich kein Hexenwerk.
Naja, bis was kaputt geht. Dann muss man halt schnell lernen ums repariert zu kriegen
-
Kompromiss ist wahrscheinlich ein Verwaltungsterminal wie Plesk (kostet) und Keyhelp (kostet nix).
Besser ist es aber wohl das von Hand zu machen, da lernt man ne Menge und eigentlich ists nicht wirklich schwierig.
Wenn du magst könnten wir da einen Beitrag im Forum machen und gemeinsam deinen Server einrichten?
-
Mit den heutigen Methoden zwecks Query Performance Forschung gehe ich schon davon aus dass die meißten Mainstream Applikationen ihre DB-Querys optimiert haben.
Aber klar, so ein paar miese Plugins könnte es natürlich schon geben. Wer weiß das schon...
Nur beim Shared Webhosting kann man da halt ned mal schnell auf den DB-Server schauen und prüfen
-
Gibt's irgendwas spezielles, was man überprüfen sollte, sobald die Root-Partition kurzzeitig (ca. 2 Stunden) voll war? /var, /home und /tmp waren nicht betroffen. Alle Dienste sind normal weitergelaufen und auch im syslog finde ich nichts auffälliges, dennoch frag ich lieber mal hier nach bevor ich was übersehe
afaik steckt der Pinguin das problemlos weg!
-
Wäre schon wenn netcup sich hier mal äußern würde...
Bin sehr zufrieden mit netcup (hab allerdings nur Server) und möchte nicht dass andere solche Probleme haben.
-
Wenn die Platte vom neuen System größer als die vom alten ist:
Beide Systeme ins Rescue fahren und auf dem Quellsystem mit folgendem Befehl die Platte rüberkopieren:
Codedd if=/dev/sda bs=32M status=progress | ssh root@IP_ZIELSYSTEM dd of=/dev/sda bs=32MDanach im Zielsystem booten und die Platte/Partition vergrößern. Das geht dann problemlos im laufenden Betrieb.
Mit Glück war es das und IP und Hostname muss nicht angepasst werden.
PS: Diese Möglichkeit ist natürlich die beste, egal was alle anderen sagen
-
Ich persönlich finds irritierend dass man so eine Kleinigkeit gleich an die Beschwerdestelle senden muss. Wurde denn davor versucht es dem Supportmitarbeiter zu erklären?
-
Genauigkeit GPS Geschwindigkeit:
Zitat
~ 0.2 - 0.5 km/h
Quelle: Drei verschiedene gegoogelte Websites mit "gps speed accuracy". -
Hier mal zwei kurze Tests mit Virtualbox.
runqlat Host idle:
/usr/share/bcc/tools/runqlat 10 1
Code
Alles anzeigenusecs : count distribution 0 -> 1 : 366 |*********** | 2 -> 3 : 56 |* | 4 -> 7 : 89 |** | 8 -> 15 : 53 |* | 16 -> 31 : 6 | | 32 -> 63 : 6 | | 64 -> 127 : 5 | | 128 -> 255 : 2 | | 256 -> 511 : 3 | | 512 -> 1023 : 0 | | 1024 -> 2047 : 3 | | 2048 -> 4095 : 1235 |****************************************| 4096 -> 8191 : 1017 |******************************** | 8192 -> 16383 : 34 |* |runqlat Host CPU unter load (stress -c 12):
/usr/share/bcc/tools/runqlat 10 1
Code
Alles anzeigenusecs : count distribution 0 -> 1 : 97 |**** | 2 -> 3 : 203 |********* | 4 -> 7 : 76 |*** | 8 -> 15 : 57 |** | 16 -> 31 : 5 | | 32 -> 63 : 8 | | 64 -> 127 : 5 | | 128 -> 255 : 6 | | 256 -> 511 : 0 | | 512 -> 1023 : 2 | | 1024 -> 2047 : 0 | | 2048 -> 4095 : 659 |******************************* | 4096 -> 8191 : 826 |****************************************| 8192 -> 16383 : 213 |********** | 16384 -> 32767 : 5 | |biolatency Host idle:
/usr/share/bcc/tools/biolatency 10 1
Code
Alles anzeigenusecs : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 0 | | 32 -> 63 : 0 | | 64 -> 127 : 0 | | 128 -> 255 : 0 | | 256 -> 511 : 3 | | 512 -> 1023 : 3 | | 1024 -> 2047 : 2 | | 2048 -> 4095 : 8 | | 4096 -> 8191 : 8 | | 8192 -> 16383 : 16 | | 16384 -> 32767 : 25 | | 32768 -> 65535 : 313 |********** | 65536 -> 131071 : 1173 |****************************************| 131072 -> 262143 : 360 |************ |biolatency Host Platte aktiv (stress -d 12):
/usr/share/bcc/tools/biolatency 10 1
Code
Alles anzeigenusecs : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 0 | | 32 -> 63 : 0 | | 64 -> 127 : 0 | | 128 -> 255 : 0 | | 256 -> 511 : 4 | | 512 -> 1023 : 2 | | 1024 -> 2047 : 2 | | 2048 -> 4095 : 9 |* | 4096 -> 8191 : 14 |* | 8192 -> 16383 : 9 |* | 16384 -> 32767 : 1 | | 32768 -> 65535 : 21 |** | 65536 -> 131071 : 118 |************** | 131072 -> 262143 : 335 |****************************************| 262144 -> 524287 : 218 |************************** | 524288 -> 1048575 : 7 | | -
Jeder Tacho geht vor. Teilweise auch von verschiedenstem (Radgröße?) abhängig. Fakt ist dass ein Tacho niemals zu wenig anzeigen darf. Gerne aber zuviel.
Somit keine außergewöhnliche Entdeckung. GPS (Dopplerffekt) sollte da deutlich genauer sein wenn euch das interessiert.
Wann ein Blitzer auslößt ist übrigens auch einstellbar...
Ich wünsche euch viel Spaß bei euren wissenschaftlichen Forschungen
