Performance Strato vServer

ThomasChr

Active Member
Hallo zusammen,

ich besitze einen Strato V-Server Linux Level 2.
Mit -theoretisch- 4 vCores, 8GB Ram und SSD Platte sollte das Ding ja durchaus für ein paar simple Datenbankabfragen ausreichen.
(zumal ich denke das Virtuozzo als Virtualisierungsplattform auch recht performant sein sollte)

Jetzt finde ich aber das hier in meinem MariaDB SlowQuery Log:
Code:
# Time: 140911 16:26:44
# User@Host: servermonitoring[servermonitoring] @ localhost []
# Thread_id: 519  Schema: servermonitoring  QC_hit: No
# Query_time: 84.331559  Lock_time: 0.000106  Rows_sent: 0  Rows_examined: 0
use servermonitoring;
SET timestamp=1410445604;
INSERT INTO monitorstates(monitorid, state, ipv4used) VALUES (6, 1, '123.123.123.123');

Jetzt bin ich ja schon geschockt gewesen dass manche Querys mal bis zu 10 Sekunden brauchen, aber das habe ich auf Longtext Spalten geschoben.
In diesem Fall ists aber folgende Tabellenstruktur:
Code:
CREATE TABLE IF NOT EXISTS `monitorstates` (
  `statetime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `monitorid` int(11) NOT NULL,
  `state` int(11) NOT NULL,
  `ipv4used` varchar(15) NOT NULL,
  PRIMARY KEY (`statetime`,`monitorid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Sorry aber 84 Sekunden für einen INSERT ???
(die Tabelle hat gerade mal 350 Rows!)
Ich persönlich finde jede Datenbankabfrage über einer Sekunde bedenklich.

Besteht die Möglichkeit dass ich da irgendeinen wirklich doofen Fehler gemacht habe oder kann tatsächlich das Wirtssystem bei Strato so ausgelastet sein dass es mal 84 Sekunden für nen simplen Insert braucht?

Hab ich ne Möglichkeit um Irgendwie einen Vergleich zwischen WallClock Time und CPU Time zu ziehen (das simple time-Commando hat da nichts sinnvolles gebracht bislang) um zu merken wenn die CPUs einfach mal gerade 'nicht da' sind?

Andere Vorschläge außer den Strato Support vollzujammern?

Mfg,

Thomas
 
Last edited by a moderator:
Na sowohl der top als auch sysbench bewegen sich in den Bereichen 'alles super, alles fein'.

Hier mal top:
Code:
top - 09:36:33 up 13:09,  2 users,  load average: 0,16, 0,07, 0,02
Tasks:  65 total,   1 running,  64 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  0,0 sy,  0,0 ni,100,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:  16777216 total,   420948 used, 16356268 free,        0 buffers
KiB Swap:        0 total,        0 used,        0 free.   191552 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    1 root      20   0   33200   2568   1452 S   0,0  0,0   0:00.20 init
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd/2+
    3 root      20   0       0      0      0 S   0,0  0,0   0:00.00 khelper/23+
    4 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rpciod/233+
    5 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rpciod/233+
    6 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rpciod/233+
    7 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rpciod/233+
    8 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rpciod/233+

Hier mal sysbench (sysbench --test=cpu --cpu-max-prime=20000 run):
Code:
Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          28.7221s
    total number of events:              10000
    total time taken by event execution: 28.7209
    per-request statistics:
         min:                                  2.58ms
         avg:                                  2.87ms
         max:                                  4.15ms
         approx.  95 percentile:               3.16ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   28.7209/0.00

Das Problem ist ja irgendwie dass die CPUs (und auch die Platten!) nicht langsam sind. Sie sind nur manchmal einfach nicht da :-)

Man bräuchte irgendwie eine Möglichkeit auf Langzeit zu messen was die 'response Time' der CPU ist. Denke ich...

Aber so ganz sicher bin ich mir eben nicht. Bei ner physikalischen Maschine ist die CPU entweder gerade im Kernelland, Userland, Waiting for I/O oder in der Idleloop. Bei der Virtzuozzo VM scheint es noch den Status 'gerade in einer anderen VM. ÄTSCH' zu geben...

Sieht man das eventuell in der 'st' Column von vmstat?
Die Erklärung aus 'High Performance Mysql' liest sich so:
Code:
A possible fifth column (st) shows the percent “stolen” from a virtual machine if you’re using virtualization. This refers to the time during which something was runnable on the virtual machine, but the hypervisor chose to run something else instead.
Klingt als wäre das das gesuchte. Aber ob das auch bei Virtuozzo funktioniert? Denke ja das ist eher so eine Sache die nur bei KVM richtig gehen wird.

Thomas
 
Die Ausgabe von ' cat /proc/cpuinfo | grep MHz' ist auch ganz interessant:
Code:
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941

Und so sehen die Teile aus wenn ich sie mit 10 mal 'yes' belaste:
Code:
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 239.941
cpu MHz         : 559.863
cpu MHz         : 559.863
cpu MHz         : 239.941
cpu MHz         : 239.941
Zwei Stück haben sich gemächlich auf 560 MHz hochgeschraubt .. naja...
 
Strato vServer haben häufig ein völlig überlastetes I/O System. Da können die theoretischen Angaben noch so prima klingen, das hilft dir alles nicht, wenn die Festplatten keine Daten rausrücken wollen. Das sieht mir ein wenig danach aus...
 
Hmmm... Sysbench kommt eher selten über 150 ms Maximale Response-Time.
Aber gut, kann ja sein dass momentan da I/O System sich langweilt:
Code:
Operations performed:  154560 Read, 103040 Write, 329619 Other = 587219 Total
Read 2.3584Gb  Written 1.5723Gb  Total transferred 3.9307Gb  (13.417Mb/sec)
  858.66 Requests/sec executed

Test execution summary:
    total time:                          300.0019s
    total number of events:              257600
    total time taken by event execution: 2.6253
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.01ms
         max:                                 93.82ms
         approx.  95 percentile:               0.02ms

Threads fairness:
    events (avg/stddev):           257600.0000/0.00
    execution time (avg/stddev):   2.6253/0.00
 
Hmmm, wenn man mit allen 8 Cores I/O machen will dann wartet man auch mal 3 Sekunden auf ne Festplatte...
Code:
Operations performed:  248944 Read, 165970 Write, 165970 Other = 580884 Total
Read 3.7986Gb  Written 2.5325Gb  Total transferred 6.3311Gb  (21.602Mb/sec)
 1382.51 Requests/sec executed

Test execution summary:
    total time:                          300.1155s
    total number of events:              414914
    total time taken by event execution: 2400.6253
    per-request statistics:
         min:                                  0.00ms
         avg:                                  5.79ms
         max:                               3109.31ms
         approx.  95 percentile:              25.33ms

Threads fairness:
    events (avg/stddev):           51864.2500/298.57
    execution time (avg/stddev):   300.0782/0.03
 
Hmmm, wenn man mit allen 8 Cores I/O machen will dann wartet man auch mal 3 Sekunden auf ne Festplatte...

Drei Sekunden - oder auch mal 76 (hier Level 1):

Code:
root@XXX:/var/www/XXX# date && ls -al && date
Sat Oct  4 19:16:13 CEST 2014
total 28
drwx------  4 www-data-XXX www-data-XXX 4096 Oct  4 17:46 .
drwxr-xr-x 10 root           root           4096 Oct  2 13:05 ..
(...)
Sat Oct  4 19:17:29 CEST 2014
root@XXX:/var/www/XXX#

Bin gerade darauf gestoßen - da kommt dann nach dem ls -al erstmal ne ganze Zeit lang nix. Klingt schon ein bisschen anders als der Marketingtext zum Storage auf https://www.strato.de/linux-vserver/ ;-)

Gruß, Phil
 
Last edited by a moderator:
Unabhängig davon, dass deren Monitoring bei solch astronomischer I/O-Last eigentlich schon auf Weihnachtsbaum-Niveau leuchten müsste: Einfach mal den Support kontaktieren? :) Immerhin wird hier nicht ansatzweise das eingehalten, was man eigentlich gebucht hat - nämlich superschnellen SSD-Speed. Da ein solches System de facto nicht mehr vernünftig operabel ist, erfüllt Strato hier seine Leistung aus meiner Sicht nicht ausreichend.
 
Hallo,

gab es hier jetzt schon was Neues von Seiten Strato oder konntest du das Problem besser lokalisieren?

Ich selbst habe aktuell ein älteres Produkt V-PowerServer XL (v5.3)
Linux 2.6.32-042stab092.3 (xxxxx.stratoserver.net) _i686_ (4 CPU)

und seit ca. 2 Wochen läuft der Server sehr langsam.

Gruß Berker
 
Ich hatte gestern abend erhebliche Probleme mit dem I/O-System während ein paar größere doxygen Abläufe liefen. Sowohl ls, vi oder Webseitenaufruf haben minutenlang gehangen. Hab mich jetzt mal beim Support (nochmals) wegen der schlechten Performance beschwert, mal sehen...

Gemessen hab ich diesmal aber nix da ich das Zeug durchbringen wollte.
Also "High Performance" ist bei Strato vServer Linux (mittlerweile Level 3 bei mir) tatsächlich nicht :-(

Der große Vorteil von Strato sind imho die 10 automatischen Backups die die vorhalten, hab aber gesehen dass das Hosteurope auch macht ...

Thomas
 
Naja ganz einfach: Die 10 automatischen Backups bietet nicht jeder und... ... ich bin zu faul alles wieder neu einzurichten :-)

Thomas
 
Der Strato Support hat mir nun aufgrund meines Tickes mitgeteilt dass das I/O-System auf dem entsprechenden Host optimiert wurde und ich nun keine Einschränkungen mehr bemerken sollte.

Na mal sehen :-)
 
So, und um den Thread hier zu einem Abschluß zu bringen:
Ich bin kein Kunde mehr von Strato.

Nachdem mein Server plötzlich mal für einen Tag ohne erkennbaren Grund weg war (und sich auch nicht ins Rescue booten lies) - und der Support erst nach eineindhalb Tagen sich gemeldet hat mit einem "Momentan ist ihr Server erreichbar, kein Problem feststellbar" wurdes mir doch zu bunt.

Ich hab meinen Vertrag da gekündigt und als Kulanz (danke, das hatte ich nicht erwartet!) hat Strato meinen 6 monatigen Vertrag schon nach einem Monat kündigen lassen.

Der vServer läuft nun auf einem dedizierten Hetzner Server den ich selber betreibe und alle Probleme die ich hatte sind verschwunden.

Sollte es mal wieder ein vServer werden, so hab ich festgestellt dass mir die netcup vServer am meisten zusagen.

Der große Nachteil aber:
Strato hatte halt für 10 Tage alle Daten vollautomatisch gesichert (und das bei einer 600GB Festplatte). So etwas bekommt man wohl nur bei Providern die nicht mit KVM virtualisieren.
Jetzt muss ich meine Backups selber machen :-(
 
Ich habe ebenfalls einen Strato Vserver 10 und bin masslos ernüchtert. Von den maximal 100 Mbit Anbindung habe ich bei sftp maximal 20Mbit, oft noch weniger.
Von der Gesamt-Cpuleistung habe ich nur wenige Prozente (Plesk stellt hier ein Monitor - Programm mit 8 Fenstern zur Verfügung, ohne das man die Kommandozeile bemühen muss), und der Aufbau ist dementsprechend langsam. Das Ram ist auch ganz schnell ausgelastet. Eine Webseite mit Datenbank ist - auch dank Nginx - bei über 90 Pagespeed. Bei großen Benutzerzahlen bleibt nur der File-Cache.

Zugegebenermassen sind 8GBRam und 300 GB SSD zusammen mit Plesk (und Backup) extrem günstig.
Virtuozzo emuliert 64 Software-Kerne, die aber wohl auf 100 User verteilt werden. Die Anbindung des einzelnen Servers ist dann ausgelastet.
Es gibt bei Strato daher wohl einen Grund, warum man den 3mal teureren Vserver 40 bewirbt.
 
Wow, fast 8 Jahre nach dem ...........
Aber nun gut, schön zu wissen das sich in den letzten 8 Jahren bei Strate anscheinend nichts verändert hat ;)
 
Back
Top