Posts by Exmember01

    Hecke29 : Ich nehme mal an, dass wir hier den gleichen Provider meinen. Denn der hatte ja im letzten Monat aufgrund seines 20 jährigen Bestehens bis Ende des letzten Monats für bestimmte dedizierte Server die Setup-Gebühr erlassen. Dieses Angebot habe ich auch wahrgenommen und hatte dann schon nach ca. 15 Tagen Testphase für mich aufgrund der extrem guten Performance entschieden, dass unter anderem auch die Root-Server RS 6000 und RS 3000 bei netcup auf diesem dedizierten Server als virtuelle Standby-Server umgezogen werden. Dadurch spare ich jetzt nicht nur unterm Strich ca. 20 Euro pro Monat, sondern habe dadurch auch die Performance in Bezug des IO´s deutlich verbessert.

    //Edit: Server a, der von einem Konkurrenten (mit dem netcup meines Wissens nach eine gemeinsame Vergangenheit hat oder auch noch heute zusammen arbeitet) stammt, weist seineszeichen als dedizierter Server im gleichen Preissegment bessere Performance auf:

    [Blocked Image: https://image.ibb.co/d44sda/diskstats_latency_week.png]

    Eine Anmerkung von mir: Bei einem dedizierten Server (kein Root-Server, der virtualisiert ist), dessen Ressourcen man exklusive nutzt, sind solche Werte auch kein Problem zu erreichen. Selbst wenn er nur 1GB RAM und einen CPU-Kern hätte.

    Halte uns dann bitte auf dem Laufenden, wie es weiterging.


    Vielen Dank für deinen Tipp.


    Gestern habe ich dann doch mal testweise den Root-Server RS 6000 SAS G7 und auch noch einen weiteren Root-Server in den Rettungsmodus gestartet gehabt und mußte dann danach leider feststellen, dass der massive Performance-Einbruch bei beiden Root-Servern durch mein in die Jahre stetig gewachsenes System verursacht wird. Denn das System auf dem Root-Server RS 6000 SAS G7 bei netcup wird zuerst auf einen dedizierten Entwicklerserver bei einem Fremdanbieter als Uhrsystem weiterentwickelt und optimiert und danach nach eingehenden Tests auf diesen Root-Server dann 1:1 nachgezogen.


    Leider habe ich bisher dabei übersehen, dass ich den dedizierten Server beim Fremdanbieter, der als Wirt-System für die Entwicklungsumgebung und dem System dient, gegenüber dem Wirt-System von netcup, auf dem dieser Root-Server installiert ist, exklusiv nutze und ich während meiner Tests diesen Performance-Einbruch auf meinem Entwicklerserver von daher auch nicht mitbekommen habe.


    Aufgrund dieser Erkenntnisse habe ich nun für mich entschieden, mich diesbezüglich nicht mehr an den Support zu wenden, sondern habe dieses System gestern noch auf schon einen vorhandenen dedizierten Server bei einem Fremdanbieter umgezogen, worauf es jetzt wie von mir gewünscht auch läuft.

    Da kann was nicht stimmen. Ich würde das im Testsystem noch mal wiederholen und mich dann an den Support wenden.

    Da eventuell meine Systemkonfiguration in Frage gestellt wird, habe ich auf einem Spiegel-Server beim Fremdanbieter, dessen Konfiguration bis auf die Festplattenart (SATA) und der Plattengröße mit der des Root-Servers RS 6000 SAS G7 identisch ist, diesen Vorgang noch mal wiederholt, der da dann wie folgt aussieht:


    df -h .

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    /dev/meine-SATA-Festplatte 493G 80G 388G 18% /


    dd if=/dev/zero bs=1M count=20000 of=output

    20971520000 Bytes (21 GB) kopiert, 23,0002 s, 912 MB/s


    Diese Messung zeigt sehr deutlich, dass der RAM-Durchsatz für diese Schreibleistung von 912 MB/s verantwortlich ist.

    Soeben habe ich mal auf meinem Root-Server RS 6000 SAS 7 folgende Befehle ausgeführt:


    df -h .

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    /dev/meine-SAS-Festplatte 1,4T 208G 1,1T 17% /


    dd if=/dev/zero bs=1M count=20000 of=output

    20971520000 Bytes (21 GB) kopiert, 1311,9 s, 16,0 MB/s


    Persönlich hätte ich ein besseres Ergebnis erwartet.


    Eventuell ist derzeit das Host-System extremst ausgelastet, so dass RAM-Durchsatzt und CPU-Leistung dabei auf der Strecke bleiben.

    Patrick Hofmann wrote:

    Das stimmt so nicht. Auch bei solchen Dingen sollte man Support geben.

    Meines Wissens gibt Netcup auf so ein Problem tatsächlich Support. Halt aber dann nur kostenpflichtig, da es sich hier nicht um eine Störung handelt, die Netcup zu vertreten hätte.

    147852369 wrote:

    Wie update ich auf PHP7 am sichersten, ohne dass laufende Applikationen (z.B. Nextcloud) gestört werden?

    An deiner Stelle hätte ich die neue Version vorerst nur dazu installiert und die einzelnen Webseiten sukzessive von der älteren auf die neue Version umgestellt.

    Würde mich über Erfahrung mit eurer Virtualisierung freuen.

    Meine Erfahrungen zur Virtualisierung sehen wie folgt aus:

    Auf einem dedizierten Server beim Fremdanbieter verwende ich schon seit über zwei Jahren unter CentOS 7 zur Vollvirtualisierung die Vollvirtualisierungstechnologie KVM.


    Von dieser Vollvirtualisierungstechnologie bin ich mehr als begeistert, weil unter dieser Vollvirtualisierungstechnologie VM´s zum einen, wenn dass Host-System nicht überbucht wird, extrem performant laufen oder auch dann noch angenehm performant laufen, wenn bei Bedarf das Host-System gewollt mit Fingerspitzengefühl überbucht wird.


    Als Beispiel mal zwei Extremfälle:

    Ein echter CPU-Thread (1 CPU-Kern entspricht 2 CPU-Threads) des Host-Systems kann einer VM fest zugewiesen werden, dessen Thread aber noch mal in 160 vCores gespalten wird ohne dass sie bezogen auf den individuellen Anwendungsfall, wie z.B. einem Webserver mit einer sehr geringen Anzahl an statischen Seiten, an Performance verliert.


    Oder das Host-System hat real nur 2 GB RAM und es wird z.B. einer VM trotzdem 128 GB RAM zugewiesen, die sie dann auch noch tatsächlich nutzen kann. Denn die Voraussetzung dafür ist nur, dass der SWAP des Host-Systems mindestens 128 GB groß sein muß, damit diese VM ihren vRAM dann auch tatsächlich nutzen kann und zudem das Wirt-System diesen Prozeß (die VM) auch noch stabil am Laufen halten kann.

    i hat einen viel höheren iowait-Wert und Disk Latency als g und k bei vergleichbarem Durchsatz. Ich finde keine Erklärung dafür. Alle Server sind einzig und alleine dafür da, dem ceph-Cluster als OSD bereit zu stehen; es laufen keine sonstigen Anwendungen darauf, die nicht für den Betrieb notwenig sind (und selbst dann laufen sie auf allen drei Servern).


    Übersehe ich etwas? Woran kann es liegen? Hat jemand vielleicht ähnliche Probleme oder Ideen wie ich dem Ganzen auf die Spur kommen kann?


    Du übersiehst eventuell, dass du dir das Hostsystem, auf dem unter anderem auch einer deiner virtuellen Maschinen S 8000 G7 installiert ist, noch mit weiteren Kunden teilst und du somit nicht exklusiv die Leistung des Hostsystem nutzen kannst. Von daher auch diese unterschiedlichen Ergebnisse der einzelnen VM´s S 8000 G7.

    du benutzt also eine extra beschränkte vm auf einem rootserver bei einem andren provider als backup ziel!?


    Nein, auf einen großen Root-Server (RS 6000 G7 SE) bei Netcup als Gateway-Server. Denn auf den dedizierten Server mit dedizierter Gigabit-Leitung beim Fremdanbieter brauche ich die Bandbreite nicht künstlich zu drosseln.

    das wäre ja ok.aber - woher hast du das mit den 4,5MB/s?

    Das habe ich mit Hilfe des SFTP-Client von beiden Servern aus zum Zielserver in Berlin gemessen. Denn wenn du eine Datei auf einem Zielserver damit überträgst, bekommst du nicht nur den aktuellen Fortschritt angezeigt, sondern auch die derzeit aktuelle Bandbreite mit der die Datei gerade übertragen wird.


    ich habe nicht nur einen server.

    Damit man dein Problem besser eingrenzen kann, meinte ich mit der Frage "Welchen Server - genaue Produktbezeichnung - hast du denn?" deinen Problemserver.


    am meisten wäre mir mit einer methode geholfen, mit der ich den durchschnitt unter 80Mb/s halten könnte.


    Wenn ich mich richtig daran erinnern kann, wurde in diesem Forum schon mal das Tool TC, welches ich aber auch nicht nutze, zur Bandbreitenbegrenzung vorgeschlagen.


    Ich persönlich regle die Bandbreitenbegrenzung über einen meiner vielen OpenVZ 7 Container unter OpenVZ 7 auf einen großen Root-Server.

    Dessen Bandbreite wird präzise auf 9 MB/s (9 MB/s entspricht 72 Mbit/s) begrenzt.

    jay , 80 Mbit/s entspricht umgerechnet 10 MB/s.

    Da du mit der Bandbreite der Gegenstelle aus Berlin mit ca. 4,5 MB/s noch weit darunter liegst, wird mit höchster Wahrscheinlichkeit Netcup dir die Bandbreite auch nicht drosseln.


    Welchen Server - genaue Produktbezeichnung - hast du denn?

    Über einen Root-Server bei Netcup und einen dedizierten Server mit dedizierter Gigabit-Leitung direkt in Frankfurt/Main bei einem Fremdanbieter kam ich auf nur einer Übertragungsrate von ca. 4,5 MB/s zur virtuellen Festplatte beim Provider aus Berlin. Also würde ich eher mal das Problem beim Provider aus Berlin suchen.

    Auf einen meiner großen Server mit 12 Kernen und installiertem OpenVZ 7 habe ich mal auf einen Test-Container mit 12 GB RAM und 4 vCores und installiertem CentOS 7 einen Benchtest laufen lassen. Dessen Werte über UnixBench sehen wie folgt aus:


    BYTE UNIX Benchmarks (Version 5.1.3)

    System: psip01: GNU/Linux

    OS: GNU/Linux -- 3.10.0-514.16.1.vz7.30.15 -- #1 SMP Wed Jun 21 14:23:18 MSK 2017

    Machine: x86_64 (x86_64)

    Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")

    CPU 0: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4794.4 bogomips)

    Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

    CPU 1: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4794.4 bogomips)

    Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

    CPU 2: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4794.4 bogomips)

    Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

    CPU 3: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4794.4 bogomips)

    Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET

    14:51:05 up 1 min, 1 user, load average: 0.15, 0.07, 0.03; runlevel 5


    ------------------------------------------------------------------------


    Benchmark Run: So Jul 30 2017 14:51:05 - 15:20:44

    4 CPUs in system; running 1 parallel copy of tests


    Dhrystone 2 using register variables 46166375.8 lps (10.0 s, 7 samples)

    Double-Precision Whetstone 2772.0 MWIPS (19.4 s, 7 samples)

    Execl Throughput 3280.6 lps (29.8 s, 2 samples)

    File Copy 1024 bufsize 2000 maxblocks 1300396.3 KBps (30.0 s, 2 samples)

    File Copy 256 bufsize 500 maxblocks 345317.3 KBps (30.0 s, 2 samples)

    File Copy 4096 bufsize 8000 maxblocks 2988268.9 KBps (30.0 s, 2 samples)

    Pipe Throughput 2287730.4 lps (10.0 s, 7 samples)

    Pipe-based Context Switching 126570.5 lps (10.0 s, 7 samples)

    Process Creation 10946.3 lps (30.0 s, 2 samples)

    Shell Scripts (1 concurrent) 8499.1 lpm (60.0 s, 2 samples)

    Shell Scripts (8 concurrent) 2740.7 lpm (60.0 s, 2 samples)

    System Call Overhead 4560819.5 lps (10.0 s, 7 samples)


    System Benchmarks Index Values BASELINE RESULT INDEX

    Dhrystone 2 using register variables 116700.0 46166375.8 3956.0

    Double-Precision Whetstone 55.0 2772.0 504.0

    Execl Throughput 43.0 3280.6 762.9

    File Copy 1024 bufsize 2000 maxblocks 3960.0 1300396.3 3283.8

    File Copy 256 bufsize 500 maxblocks 1655.0 345317.3 2086.5

    File Copy 4096 bufsize 8000 maxblocks 5800.0 2988268.9 5152.2

    Pipe Throughput 12440.0 2287730.4 1839.0

    Pipe-based Context Switching 4000.0 126570.5 316.4

    Process Creation 126.0 10946.3 868.8

    Shell Scripts (1 concurrent) 42.4 8499.1 2004.5

    Shell Scripts (8 concurrent) 6.0 2740.7 4567.8

    System Call Overhead 15000.0 4560819.5 3040.5

    ========

    System Benchmarks Index Score 1737.3


    ------------------------------------------------------------------------


    Benchmark Run: So Jul 30 2017 15:20:44 - 15:49:58

    4 CPUs in system; running 4 parallel copies of tests


    Dhrystone 2 using register variables 175625693.6 lps (10.0 s, 7 samples)

    Double-Precision Whetstone 12244.6 MWIPS (16.9 s, 7 samples)

    Execl Throughput 16799.3 lps (30.0 s, 2 samples)

    File Copy 1024 bufsize 2000 maxblocks 1418395.5 KBps (30.0 s, 2 samples)

    File Copy 256 bufsize 500 maxblocks 372089.0 KBps (30.0 s, 2 samples)

    File Copy 4096 bufsize 8000 maxblocks 4282925.1 KBps (30.0 s, 2 samples)

    Pipe Throughput 8704495.6 lps (10.0 s, 7 samples)

    Pipe-based Context Switching 1330676.4 lps (10.0 s, 7 samples)

    Process Creation 35984.9 lps (30.0 s, 2 samples)

    Shell Scripts (1 concurrent) 23977.4 lpm (60.0 s, 2 samples)

    Shell Scripts (8 concurrent) 3555.6 lpm (60.0 s, 2 samples)

    System Call Overhead 11779097.0 lps (10.0 s, 7 samples)


    System Benchmarks Index Values BASELINE RESULT INDEX

    Dhrystone 2 using register variables 116700.0 175625693.6 15049.3

    Double-Precision Whetstone 55.0 12244.6 2226.3

    Execl Throughput 43.0 16799.3 3906.8

    File Copy 1024 bufsize 2000 maxblocks 3960.0 1418395.5 3581.8

    File Copy 256 bufsize 500 maxblocks 1655.0 372089.0 2248.3

    File Copy 4096 bufsize 8000 maxblocks 5800.0 4282925.1 7384.4

    Pipe Throughput 12440.0 8704495.6 6997.2

    Pipe-based Context Switching 4000.0 1330676.4 3326.7

    Process Creation 126.0 35984.9 2855.9

    Shell Scripts (1 concurrent) 42.4 23977.4 5655.1

    Shell Scripts (8 concurrent) 6.0 3555.6 5926.0

    System Call Overhead 15000.0 11779097.0 7852.7

    ========

    System Benchmarks Index Score 4762.6

    Hallo, ist bei KVM/QEMU von Haus aus eine dynamische Speicherzuordnung (RAM) aktiviert?

    Ja. Denn du erkennst es nach der Standardinstallation von KVM und einer darauf installierten VM daran, dass nach Eingabe des Befehls "lsmod | grep virt" in der VM unter anderem auch der Treiber "virtio_balloon" mit angezeigt wird. Denn KVM ist dafür gedacht, Server besser auszulasten.


    Zum Beispiel sieht die Ausgabe auf einem Root-Server von Netcup wie folgt aus:


    lsmod | grep virt

    virtio_balloon 13834 0

    virtio_scsi 18400 5

    virtio_net 28024 0

    virtio_pci 22913 0

    virtio_ring 21524 4 virtio_net,virtio_pci,virtio_balloon,virtio_scsi

    virtio 15008 4 virtio_net,virtio_pci,virtio_balloon,virtio_scsi


    Alles was man hier sieht, sind Module bzw. Treiber, die auf dem Root-Server vom Betriebssystem zur Startzeit geladen wurden. Ohne diese Module / Treiber würde der Root-Server nicht stabil laufen.


    Eine Seite, die das bessere Auslasten eines Servers sehr gut beschreibt, findest du hier mit der Überschrift Overcommitting mit KVM.

    Hoffe nur das netcup das Problem im Griff bekommt, da der alte zum 01.08 gekündigt ist und sonst ein komplettes Jahr verlängert wird.

    Da man im ersten Monat seinen neuen Root-Server wegen der Unzufriedenheitsgarantie wieder kündigen kann, würde ich an deiner Stelle den jetzigen neuen Root-Server wieder kündigen - sofern Dieser auch eine Laufzeit von 12 Monaten hat - und einen neuen Root-Server mit einer Laufzeit von einem Monat neu bestellen. Da der Preisunterschied pro Monat nur 2 Euro beträgt.

    Nur ein Vorschlag: Den alten Server würde ich an deiner Stelle noch solange produktiv nutzen, bis der neue Server so läuft wie gewünscht. Denn der Vorteil ist der, dass du dann deinen neuen Server viel entspannter bzw. schmerzfreier testen kannst und du dadurch nicht so unter einem hohen Zeitdruck stehst.