Brauche Empfehlung für Rootserver

[Prolamer]

Hallo,
ich brauche eine Empfehlung für einen Freund, der einen Server braucht.

Hier seine Ansprüche:

Besucher: ~10.000/Tag und steigend
Projekt: Webshop inkl. Direktversand von Produkten. Es wird hier mit einigen Befehlen alle 20 Minuten auf eine Große Datenbank zugegriffen, die einige aushalten muss.
Aktuell hat er einen Server bei isgenug.de aber den kann man in die Tonne kloppen, da der für die Anfrage über 20 Minuten braucht!
Am besten einen Anbieter, die eine Anständige Anbindung hat, Guten Support bietet und auch ein anständiges Image von Anfang an dabei hat, wo man nur noch einige einstellen braucht.
Traffic: ~100-200GB/Monat, jedoch etwas mehr Traffic-Absicherung nach oben bis 500GB, wenn der Shop weiter wächst.

Welchen Shop bzw. Anbieter könnt Ihr empfehlen?

EDIT:
Wen ich nicht haben möchte als ANbieter: S4U, OVH/ISGENUG, Hetzner, Strato, 1&1.

 

[svenr]

Ich hab deine Anforderungen mal überflogen und kam zu der Frage....
was ist ein anständiges Image in deinen Augen (mir sind die OVH Images bekannt und diese sind doch sehr weitläufig, wenige Anbieter haben solch eine Palette) Es wäre gut wenn Du hier konkreter werden könntest.
Desweiteren, die Anzahl der Besucher ist eine Sache....
wenn Du schreibst das euer script 20 min zur Abarbeitung braucht, wären auch hier etwas mehr Infos nötig, was dieses eigentlich macht, welcher isgenug Server eigentlich im Einsatz ist usw....

Gruß Sven

 

[Prolamer]

Ich hab deine Anforderungen mal überflogen und kam zu der Frage....
was ist ein anständiges Image in deinen Augen (mir sind die OVH Images bekannt und diese sind doch sehr weitläufig, wenige Anbieter haben solch eine Palette) Es wäre gut wenn Du hier konkreter werden könntest.
Desweiteren, die Anzahl der Besucher ist eine Sache....
wenn Du schreibst das euer script 20 min zur Abarbeitung braucht, wären auch hier etwas mehr Infos nötig, was dieses eigentlich macht, welcher isgenug Server eigentlich im Einsatz ist usw....

Gruß Sven

Hi Sven,

wir haben das Script sowohl als auch auf dem Großen:
http://www.ovh.de/rootserver/eg_best_of.xml

Als auch auf dem 2. Isgenug Server ausprobiert.
Das Script ruf Kundendaten ab.
Es vergleicht diese und greift dabei auf mehrere Tabellen zu in der Datenbank.
Es guckt halt, ob jemand gezahlt hat, wenn ja, wie viel Sachen hat er in seiner Bestellung. Ab einer bestimmten Anzahl wird nicht automatisch versendet.
Auch wenn man den Befehl manuell eingibt in der SQL DB, um mehrere Sachen abzufragen, kommt der Server schon ins stottern. Was nicht an der Hardware liegt, sondern an der Software.
Wir sind ratlos - OVH meint es sei alles in Ordnung, dass sie keinen Fehler finden konnten.
Wie gesagt wir haben es auf 2 OVH Server getestet, nach einer Standard-Installation - DB war extrem langsam bzw. die Anfrage dauerte ewig.
Bei anderen Anbietern war diese Anfrage relativ flott fertig.

Es liegt definitiv an einer Einstellung im OVH Image, dass der Server ~10-15 Minuten braucht um die Anfrage komplett zu bearbeiten...

hier mal ein Ausschnitt der DB Abfrage (Die DB selber hat ca. 30k-50k Einträge):

orderq = Db::getInstance()->executeQuery("SELECT a.firstname, a.lastname, a.email, a.id_customer, e.id_order, e.id_customer, (SELECT sign FROM currency WHERE currency = e.currency) AS currency, e.total_paid, e.date_add FROM customer a JOIN (SELECT o.id_order, o.id_customer, o.id_currency, o.total_paid, o.date_add FROM _orders o JOIN (SELECT order FROM order_history WHERE date_add IN (SELECT MAX(date_add) FROM order_history GROUP BY id_order) AND id_order_state IN (12,2)) h ON o.id_order = h.id_order) e ON a.id_customer = e.id_customer WHERE DATE_SUB(NOW(),INTERVAL (SELECT tage FROM xxxx LIMIT 0,1) SECOND) <= e.date_add");

 

[svenr]

Ich bin verwundert da auch ovh nur die Standartpakete der jeweiligen Distri nutzt. Welches Image nutzt ihr genau?
Ist der sql Server entsprechend eingestellt und optimiert von euch?
Liegen irgendwelche Daten auf anderen Servern so das evtl ein Problem mit der Anbindung vorliegen könnte?

Gruß Sven

 

[Prolamer]

Ich bin verwundert da auch ovh nur die Standartpakete der jeweiligen Distri nutzt. Welches Image nutzt ihr genau?
Ist der sql Server entsprechend eingestellt und optimiert von euch?
Liegen irgendwelche Daten auf anderen Servern so das evtl ein Problem mit der Anbindung vorliegen könnte?

Gruß Sven

Anbindungsproblem liegt definitiv nicht vor.
Als Image/OS:
Betriebssystem Ispconfig 3.0.3.3 (Debian 6.0 Squeeze)

Der Server lahmt total bzw. man kann ihn vergessen, sobald das script ausgeführt wird!
Das ist Frustration³

my.cnf von mysql:

user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
read_buffer_size = 32M
tmp_table_size = 128M
max_heap_table_size = 128M
join_buffer_size = 16M
table_cache = 2048


#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 16M
max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit	= 1M
query_cache_size        = 16M

passt also...

 

[d4f]

Was sagt tuning_primer?
Wie siehts mit der Systembelastung aus wenn das Script lauft (insbesonder Festplatte, RAM, Swap, ...) => atop

Wenn dir genug RAM uebrig bleibt, koenntest du versuchen eine 2. MySQL-Instanz als read-only Slave auf einer tmpfs laufen zu lassen und die SELECT-Queries auf diesen zu leiten.

 

[Prolamer]

tuning-primer natürlich auch schon ausgeführt.
Darum habe ich teils utopische Werte gesetzt, denn die Werte lagne zuvor teilweise bei 128kb o.ä.

Hier mal ein Paar interessante Einträge (RAM liegt bei insgesamt 16GB!)

Habe mal noch screens von atop angehangen.

MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 4
Historic max_used_connections = 9
The number of used connections is 5% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

QUERY CACHE
Query cache is enabled
Current query_cache_size = 16 M
Current query_cache_used = 1 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 11.35 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere

TEMP TABLES
Current max_heap_table_size = 128 M
Current tmp_table_size = 128 M
Of 969 temp tables, 32% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 32 M
Current table scan ratio = 2228 : 1
read_buffer_size is over 8 MB there is probably no need for such a large read_bu                                                                                                                                                             ffer

TABLE LOCKING
Current Lock Wait ratio = 1 : 4332
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

 

[d4f]

Verbindet sich dein Skript per Unix-Socket oder TCP-Socket an MySQL?
(Ersteres ist vor zu ziehen!)
Was sagt die Mysql Error-Log?

 

[Prolamer]

Verbindet sich dein Skript per Unix-Socket oder TCP-Socket an MySQL?
(Ersteres ist vor zu ziehen!)
Was sagt die Mysql Error-Log?

Das Script greift auf die SQL Daten des Shops zu in der config Datei.
Und verbindet sich dann mit den Daten.
MySQL Error log habe ich keinen bisher erstellen lassen.

 

[proman]

Volle Leistung kannst Du haben.

Also Hallo erst mal...

Da ich aus der Branche komme, mag ich hier keine Eigenwerbung machen.Das Problem liegt wohl an der geringen CPU Belastungsgrenze.
ISPCP hat schon alleine einen hohen Stellenwert bei der CPU Belastung.

Wenn Du nun einen Server belegen magst der die Leistung bringt musst Du aber etwas tiefer in die Tasche greifen.
Ich selbst biete folgende v-Server an und kann Dir einen Testaccount einrichten.
Unser Support ist (Eigenlob stinkt) großartig 24/7 und unsere Domainpreise sind totel niedrig ( 29 Cent für eine de Domain... Dauerhafter Preis )

OK mehr kann ich hier nicht schreiben...

Merkmal
Premium-Server
Hostsystem-Prozessor
Intel® Core™ i7-920 Quad-Core

Arbeitsspeicher je Hostsystem
12 bis 24 GB DDR3 Ram
Raidsystem
Hardware Raid 5, mindestens 4 Festplatten

Hostsystem-Netzwerkinterface
1000-Mbit-Interface

Server-Hardware
Optimiert auf hohe Verfügbarkeit und Stabilität

Serverstandort
Deutschland

Tägliches Backup Ihrer Daten
enthalten

Erstreaktion im Fehlerfall
Innerhalb von 4 Stunden garantiert

Netzwerkverfügbarkeit im Jahresmittel
Mindestens 99,5% im Jahresmittel

Traffic
Im Angebot inbegriffen (fair use policy)

 

[Otzelott]

Betriebssystem Ispconfig 3.0.3.3 (Debian 6.0 Squeeze)

ISPCP hat schon alleine einen hohen Stellenwert bei der CPU Belastung.

ISPCP und Ispconfig sind zwei unterschiedliche Projekte

 

[skydrak]

Ich glaube kaum, dass ein vServer mehr Leistung bringt, als der oben genannte Root-Server...

Und irgendwie habe ich Bauchschmerzen, wenn ich höre, dass du aus der Branche kommst und ich deine anderen beiden Beiträge hier lese...

 

[Prolamer]

Zumal der Server von der Anfrage auch in die "Knie" gezwungen wurde:

Intel Xeon i7 W3520
4x2(HT)x2.66+ GHz
Arbeitsspeicher 24 GB DDR3

Also liegt es definitiv an einer Einstellung - bloß an welcher ist mir noch nicht ganz schlüssig.

 

[d4f]

Das Script greift auf die SQL Daten des Shops zu in der config Datei.
Und verbindet sich dann mit den Daten.

War das jetzt eine ehrliche Antwort auf meine Frage
[Ironie] Ich ging davon aus dass dein Skript die Zugangsdaten per random() generiert und solange ausprobiert bis es reinkommt - was die Verzoegerung erklaert. [/Ironie]

Die Frage steht somit. Wenn du nicht weisst was ich meine; Mysql kann ueber UNIX-Sockets (spezielle Dateien welche bidirektionale Kommunikation zwischen Prozessen ermoeglichen) oder ueber TCP (Port 3389) angesprochen werden. Wenn du 'localhost' als Mysql-Host benutzt, geht es in aller Regel ueber Unix-Sockets - bei '127.0.0.1' hingegen ueber TCP.
TCP erursacht groesseren Overhead ("teurer") und kann durch iptables (un)gewollt beeinflusst werden.

Uebrigens: "Of 969 temp tables, 32% were created on disk"

Die Mysql-Errorlog waere eventuell ganz interessant

Ich behaupte einfach mal rundweg raus dass dein SQL nicht optimal ist und somit bei einer so grossen Datenbank viele temporaere Tabellen erzeugt werden muessen. Dein mehrfach gejointer und mit Sub-Queries versehener Query ist zwar bei mir noch nicht ganz verdaut, aber ich wuerde sagen dass eine zusaetzliche Tabelle in welcher festgehalten wird welche noch offen stehen und ob diese automatisch bearbeitet werden duerfen (was einfach beim Insert berechnet respektiv aktualisiert werden kann) um einiges optimaler waere.

Bist du sicher dass die atop-Screenshots waehrend einer Query durchgefuehrt wurden? Das System liegt naemlich scheinbar da am Schlafen - zumindest die Festplatte sollte sich da aber schon abrackern...

Du kannst auch mal versuchen einen Mysql Read-only Replication slave in eine tmpfs-Partition zu legen; fuehrt er da die Queries bedeutend schneller durch?

@ProMan: deine Ausdrucksweise klingt sehr... jugendlich... und deine Vorschlaege paradox (Nur ein dicker Root schafft es, unser vServer auch) sowie deine Angebote uebertrieben beworben (3,48Eur/Jahr ist KEIN Niedrigpreis)

 

[fx123]

Ich hab den Thread jetzt nur überflogen, aber jede Wette, das ganz einfach das Datenbankschema schlecht ist und Indexe entweder nicht vorhanden sind oder nicht genutzt werden (z.B. wegen der SubSelects).
Als ersten Schritt sollte man hier das MySQL-Slow-Query-Log auswerten und sich anschließend die Queries mit EXPLAIN anschaun.

Wenn du dich selbst nicht damit auskennst, hol dir einen Datenbankexperten. Mit Hardware dagegenzuhalten ist total Quatsch...

 

[virtual2]

Was sagt denn iostat?

Möglicherweise sind deine Platten am abschmiergeln

 

[Joe User]

Ich hab den Thread jetzt nur überflogen,

Steht auch nur unrelevanter Mist drin...

aber jede Wette, das ganz einfach das Datenbankschema schlecht ist und Indexe entweder nicht vorhanden sind oder nicht genutzt werden (z.B. wegen der SubSelects).

Full-Table-Scans, SubSelects, JOINs und ungünstiges DB-Design, wobei letzteres durch seine Shopsoftware vorgegeben ist.

Als ersten Schritt sollte man hier das MySQL-Slow-Query-Log auswerten und sich anschließend die Queries mit EXPLAIN anschaun.

Slow-Query-Log bringt nix, da es nur ein einziger Query ist, der den MySQLd auslastet. Das EXPLAIN habe ich schon vor Tagen in seinem anderen Thread angefordert, aber noch nicht erhalten.

Wenn du dich selbst nicht damit auskennst, hol dir einen Datenbankexperten. Mit Hardware dagegenzuhalten ist total Quatsch...

Fullack!