Ein dramatischer Titel, aber ich kann gerade nicht anders als es so auszukotzen!  Ich habe seit Anfang November 2009 einen V-PowerServer-L von Strato, und hatte bislang nur ein paar kleine Anwendungen darauf laufen: einige WordPress Seiten… und das ging so.  Nun wollte ich vor ein Paar Tagen eine Magento Shop zur Demo aufsetzen, aber es ging nicht: der Installation vom Datenbank ist nach 45 Minuten immer noch nicht zu ende gekommen… zur Vergleich, auf meinen Desktop geht das in ~25 Sekunden!  Erst dachte ich das ich bei der MySQL Server was falsch eingestellt hatte… habe gesucht, optimiert, aber kein Ervolg… Auch merkwürdig das es zwar ewig lange brauchte, aber CPU last und Hauptspeicherverbrauch kaum nennenswert waren.   Dann kam bonnie++ zur Hilfe – da habe ich ein paar Tests gefahren, und plötzlich blöste sich der Ursache: Dateizugriffszeiten für Erstellung/Löschen sind horend langsam.  Hier ein Beispiel:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
h1652797.strato 12G   289  66 40647  14 21138   7   683  45 50521   7 136.6   3
Latency               700ms   36604ms    8855ms     449ms    2776ms    1791ms
Version  1.96       ------Sequential Create------ --------Random Create--------
h1652797.stratoserv -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   753   2 +++++ +++   900   2  1978   5 +++++ +++  2059   5
Latency               445ms    2346us   15866us    3986us    1653us   55366us

Ich habe das natürlich auch mit dem Rescue boot gemacht um sicher zu stellen das keine meine Dienste irgendwie dazwischen pfuschen oder irgendwelche Einstellungen von mir da negativ mitwirken.

Zum Vergleich, sieht das auf mein Desktop so aus:

Version 1.03c        ------Sequential Output------ --Sequential Input-  --Random-
                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--- --Seeks---
Machine        Size K/sec %CP K/sec  %CP K/sec %CP K/sec %CP K/sec  %CP  /sec  %CP
rcl-desktop   16G   68441  98 137016  29 40956   6 50718  76 226049  17  265.8   0
Version 1.03c       ------Sequential Create------ --------Random Create--------
rcl-desktop         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 50 66904  98 +++++ +++ 95599  98 70748  99 +++++ +++ 92337 100

Wer das nicht lesen kann oder mag: der Strato V-PowerServer-L kann nur EIN HUNDERSTEL (oder schlechter) so viel/schnell Daten erstellen/lesen wie mein Desktop.  Ich weiss das Virtuelle Server nicht der Leistung haben von “echte” hardware, aber ich bin auch selber erfahren genug mit VMWare und co. zu wissen das das nicht im Rahmen das Zumutbare ist, und vor allem im Kombination mit 2CPU’s (Opteron(tm) Processor 2347 HE) und 6GB RAM ein Witz ist.  Ich habe sogar mein altes mini-PC mit bonnie++ gemessen.  Der hat ein AMD Geode 500MHz CPU, und ein älteres 2,5 Zoll ATA Festplatte… sogar der schneidet ab mit 10x schneller als mein Strato V-PowerServer:

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
coconut          1G  3804  95 30923  43 12903  18  4405  97 34627  28 114.8   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  7265  98 +++++ +++ 13685  99  7003  93 +++++ +++ 13330  99

Da habe ich Strato ausfürlich und mit den Testdaten ein Nachricht geschickt, ob die die unterliegende Systemprobleme bitte beheben könnten.  Die antworteten:

Den Sachverhalt haben wir ebenfalls erneut für Sie geprüft, konnten jedoch keine Beeinträchtigungen feststellen. Zur Prüfung haben wir die hostende Hardware Ihres V-Servers überprüft, die eine normale Lastverteilung aufzeigte.

Bitte beachten Sie, dass die Ressourcen der Hardware auf mehrere V-Server geteilt werden und sich somit je nach Lastverteilung unterschiedliche Performance-Werte ergeben können. In Ihrem Fall empfehlen wir Ihnen einen Wechsel auf einen der angebotenen dedizierten Root-Server, dessen Ressourcen ausschließlich Ihrem System zur Verfügung gestellt werden.

Ach so… der Performance (für dem ich übrigens 29,90EUR/Monat bezahle) ist 1/10 wie der Popeligste Rechner den ich finden könnte, und wenn ich was besseres will, soll ich was anderes Bestellen.

Ich dachte mir das kann doch nicht seien… wenn ich mit einen Menschen Rede wird er merken das was übersehen wurde und das Regeln können… und habe deshalb noch für weitere 3EUR auf deren Kostenpflichtige Technische Hotline angerufen um erst mit Herr Matt, und dann der Teamleader Herr Schumann zu sprechen.  Die sagten das die Tests bestätigen das es keine Probleme vorliegen, und das (wörtlich!)

das Performance das Sie gemessen haben ist was man bie dieser Produkt zu erwarten hat.

Wow… Ich staune!  Was haben die denn für Standards?  Wenn es ein Test gibt, stelle ich mir als erfahrener Ingineur vor, dann muss es auch ein Standard geben, was für Auslastung bzw. Zugriffszeiten zulässig sind.  Nein sagten die Herren: bei Strato gibt es Tests, aber keine Werte für Bestung diese Tests.

Fazit: Mit CPU und RAM protzen die V-PowerServe gross, aber sind trotzdem nutzlos weil die keine Anwendungen die ein Bischen Festplattenperformance brauchen (sprich alles ausser der Webseite deiner Oma!) unterstützen.

Ich werde bald möglichst meinen Anbieter wechseln (ärgerlich ist das ich erst 4 von ein 12-Monate Vertrag hinter mich habe…), und veröffentliche hiermit ein Beispiel der Standard der laut der Strato Technischer Support  bei den Strato V-PowerServer reihe zu erwarten ist, damit hoffentlich andere auch erfahren was bei Strato der Standard ist bevor die ein Vertrag abschliesen.

Ich rate die Finger von diesen Produkten zu lassen!

A couple of days ago, Amazon released their RDS service.  Being a MySQL fan, I had to have a try!

The cool stuff:

• It is well documented, and pretty easy to set up an instance.
• You can dynamically change the class (CPU power and Memory) of a database instance – this means you can give it more power without shutting it down, and easily scale it without having to do complex MySQL proxy configuration and synchronisation.

What’s still missing:

• Not available in EU yet (it should be soon) – I set up a few instances in the US, but can’t really test what the performance is in the EU between EC2 instances and RDS instances, and that’s what I’m really interested in…
• I takes a long time for the instance to become available!  I was waiting between 5 and 30 minutes.  I guess that’s not such an issue if you are just creating it once and leaving it running as the data hub for an application, but it’s annoyingly slow for testing/playing.  At least they don’t seem to start billing for time until it is online.

Other interesting notes

• If you start the instance without any parameters, it will have a typical configuration for the machine used (memory allocation spread between InnoDB and MyISAM).  It is however possible to specify parameters when the instance is started, or even during run time – this gives a lot of room for optimisation: it’s not just a dumb service, you can tune it to your requirements.
• Just for kicks and giggles, I tried scaling a small instance to a large instance, without any custom parameters: the only change was allocating all the additional memory to innodb_buffer_pool_size.  I guess that’s what most people want…

MySQL User Groups

Most operating systems have a user privilege granting system where privileges are given to groups, and users are asigned to groups, thereby inheriting all the privileges of this group. Unfortunately this is not currently (using MySQL server version 5.1) natively possible: the privileges must be defined for every user. Managing a MySQL installation with many users can become a very laborious, and non transparent process, and many admins opt to have fewer MySQL users, with many real users using one MySQL user with the desired privileges. This increases difficulty in managing the server, because you never have just the right set of privileges for a given person, nor can you quickly determine which processes are being carried out by which person.

Following is a work around to implement a kind of group privilege management in MySQL.

Setup

See attached procedure and creates to set it up the tables on your system.

Two additional tables must be defined to hold the groups.  These are created in a new `mysql_meta` database (must be created first). The first table contains a list of the users which should be managed, and the groups which they are in. The second table contains a list of the privileges given for each group.

After entering the users, groups, the procedure updateMysqlUserPrivileges when called will first revoke all privileges from all users listed, and then proceed to grant the privileges anew. This is not very elegant… but if it was, I wouldn’t call it a workaround!

It should be noted at this point that every user listed will be processed. That means that if a user is defined, but he has no group, or no privileges defined, all his privileges will be revoked, and he will be left with nothing but USAGE on the server.

Adding users

Users must be defined manually before adding them to the mysql_meta tables:

CREATE USER newuser@localhost IDENTIFIED BY 'password';

You can then add your user to the mysql_meta.user_groups table. If the user should belong to multiple groups, make multiple entries in this table, one for each group.

In the mysql_meta.user_group_privileges you can now define the privileges which should be given to each group. Please note that I have simplified by using one column `schema` to contain the database/table definition. As a result, it is not currently possible to grant permissions to specific columns. For example:

INSERT INTO `mysql_meta`.`user_groups` (`user`,`host`,`user_group`)
   VALUES( 'newuser','localhost','newgroup');
INSERT INTO `mysql_meta`.`user_group_privileges`
  (`user_group`,`schema`,`privilege_type`,`isa`)
  VALUES ( 'newgroup','mydb.*' ,'SELECT','TABLE'),
  ('newgroup','mydb.*','UPDATE'),
  ('newgroup','mydb.*','INSERT','TABLE'),
  ('newgroup','mydb.fancyProcedure','EXECUTE','PROCEDURE');

Would be equivalent to:

GRANT UPDATE, INSERT, SELECT ON mydb.* TO newuser@localhost;
GRANT EXECUTE PROCEDURE ON mydb.fancyProcedure TO newuser@localhost

Committing new privileges

Once the new privilege tables are completed, simply call the procedure to update:

CALL mysql_meta.updateMysqlUserPrivileges;

And here we stumble on another shortcoming of MySQL: there is no real way to do error handling in procedures or functions… I have opted to return a row with two columns: “Errors” and “Warnings”. If any users are defined in the user_groups table, but are not yet created as MySQL users, these will be listed as Errors, and if there are users which are defined, but which have no privileges, they will be listed in the Warnings column.