Wie viele Auswahlen pro Sekunde kann ein MySQL-Server ausführen?

19

Ich schreibe einen Geschäftsplan und muss die Kosten simulieren, wenn meine Website von 500.000 einzelnen Besuchern erreicht wird.

Besucher: 500.000
Seitenaufrufe: 1.500.000
Spinnen-Seitenaufrufe: 500.000
Gesamtseitenaufrufe: 2.000.000

Jede Seite führt 50 Abfragen aus + -

Anfragen pro Tag: 100 Millionen
pro Stunde: 4 Millionen
pro Minute: 70.000
pro Sekunde: 1.200
Höchststand: 3.000

Für diese Berechnung benötige ich 3.000 Abfragen pro Sekunde. Welche Art von Server kann damit umgehen?

Das Problem ist, dass meine Website 2.000 Besuche pro Tag durchführt und - + 150/200 Abfragen pro Sekunde hat. Ab diesem Zeitpunkt erwarte ich 50.000 Abfragen pro Sekunde.

Wie viele Server im Cluster oder in der Replikation werden für diesen Job benötigt?

mysql linux

— Setzen Sie Monica wieder ein
quelle

5

Welche Art von Website fragt 8k + einen Besuch ab?

— Ignacio Vazquez-Abrams

5

Sie benötigen sofort eine Überprüfung des Systemdesigns.

— Chopper3

1

Nicht annähernd genug Informationen, weil Sie uns nichts darüber gesagt haben, worauf es wirklich ankommt - die Abfragen selbst. Sie müssen uns auch nichts über die Maschine erzählen, auf der Sie arbeiten. Ist das ein 486? Der neueste und beste Supercomputer oder etwas dazwischen? Alle diese Zahlen, die Sie aufgelistet haben, sind für die Frage irrelevant. Bitte geben Sie RELEVANTE Informationen an.

— John Gardeniers

> Welche Art von Website fragt 8k + einen Besuch ab? Ich erhalte 2000 eindeutige Besucher, aber jeder Besucher öffnet viele Seiten, und ich habe viele Spinnen im Inneren. 2.000 Unique User generieren 6.000 Unique IPS und öffnen täglich mehr als 120.000 Seiten. danke

22

Ich habe für ein E-Commerce-Unternehmen mit einer Website gearbeitet, die mehrere Millionen Seitenaufrufe pro Tag hatte. Wir hatten einen einzelnen DELL PE 1750 mit 2 Single-Core-CPUs und 2 GB RAM, Datenbankgröße ca. 4GB. Zu Spitzenzeiten wurden auf diesem Server bis zu 50.000 Abfragen pro Sekunde verarbeitet.

Trotzdem: Die Datenbank war gut strukturiert, alle Abfragen wurden optimiert (wir hatten wöchentliche Sitzungen, in denen die langsamen Abfrageprotokolle analysiert und Abfragen und Indizes repariert wurden) und die Serverkonfiguration wurde ebenfalls optimiert. Zwischenspeichern ist auf jeden Fall eine gute Idee, aber MySQL tut dies trotzdem. Sie müssen nur die Leistung analysieren und dann die Speicherauslastung genau einstellen (Abfragecache im Vergleich zu anderen Optionen).

Aus dieser Erfahrung kann ich Ihnen sagen, dass die größte Auswirkung auf fehlende Indizes, falsche Indizes und ein schlechtes Datenbankdesign (z. B. lange Zeichenfolgenfelder als Primärschlüssel und ähnlicher Unsinn) zurückzuführen ist.

— wolfgangsz
quelle

8

Alles hängt davon ab, wie komplex die Abfrage ist, wie viel Arbeitsspeicher die Server haben und wie schnell die Festplatten sind.

Wenn die Abfragen sehr einfach oder sehr gut abgestimmt sind, kann ein einzelner großer Datenbankserver dies erledigen. Wenn die Abfragen jedoch sehr komplex (oder einfach, aber schlecht abgestimmt) sind, benötigen Sie mehrere Server.

— mrdenny
quelle

Oder einige gravierende Schemaänderungen und Neuindizierung ...

— Massimo

3

Die Optimierung wird IMMER der Hinzufügung weiterer Hardware vorgezogen. Das Hinzufügen weiterer Hardware überdeckt das Problem nur so lange, bis es viel schwerer zu lösen ist.

— Mrdenny

Danke für die Antwort, also denke ich, dass 2 Server gleichzeitig + 1 passiver Server für die Redoundierung in Ordnung sein sollten, oder? Ich spreche von 2x Quad-Cores-Servern mit 32 g RAM und schnellen Laufwerken. habe ich recht? Denken Sie daran, dass ich Auftritte brauchen!

1

Alles ist gut abgestimmt und indiziert. Ich habe 1 oder 2 langsame Abfragen pro Woche (und die Zeit für langsame Abfragen beträgt nur 2 Sekunden). Ich schreibe einen Geschäftsplan und möchte wissen, welche Art von Serverpool dies kann Täglich geöffnete 12.000.000 Seiten mit 8.000 Abfragen pro Sekunde verwalten

8000 Abfragen pro Sekunde sind gar nicht so viel. Ein einzelner 16-Kern-Server wird wahrscheinlich den Trick tun. 64 GB RAM (oder mehr oder weniger, je nachdem, wie groß die Datenbank ist und wie viele Daten gleichzeitig im Cache gespeichert werden müssen) sollten dies tun. Meine Datenbank (mit SQL Server) hat eine Kapazität von 1 TB auf einem 64-Gig-RAM-Server mit 16 Kernen und 40-50.000 Benutzern, die sie täglich mehrmals pro Minute (jeweils) im Laufe des Tages bearbeiten.

— Mrdenny

3

Dies kann wirklich nicht geschätzt werden, ohne etwas über die spezifischen Abfragen zu wissen, die Sie ausführen, das Datenbankschema und seine Größe.

Ein einfaches SELECT für eine indizierte Spalte ist ein ganz anderes Biest als ein paar JOINs, die auf nicht indizierten basieren ... und natürlich ändern sich die Dinge sehr, wenn die beteiligten Tabellen 1K-Datensätze oder 1M enthalten.

Ebenfalls:

Wie ist Ihre aktuelle Hardwarekonfiguration?
Wie viel Energie (CPU, RAM, Festplatten-E / A) verbraucht Ihr Server unter der aktuellen Last?

— Massimo
quelle

Eigentlich habe ich einen Server mit 2x Quad Core mit 8 GB RAM. Ich verwende die volle RAM und 100% des Prozessors (es scheint , i 800% verwenden können, finden Sie hier:) CPU: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ download2p.png disk: img213.imageshack.us/i/download1x.png danke

Basierend auf diesen Diagrammen verwenden Sie nur einen (oder höchstens zwei) Ihrer CPU-Kerne. Ihre Anwendung ist also definitiv nicht CPU-gebunden ... oder es ist, aber es ist nicht möglich, die Vorteile mehrerer CPUs zu nutzen. Außerdem wird der gesamte für "Cache" verwendete Speicher von niemandem benötigt , sondern nur vom Betriebssystem ausgenutzt, da "er vorhanden" ist.

— Massimo

Wie finde ich Informationen zur Verwendung aller CPU-Kerne? Ich benutze Lampe ...

Zunächst sollten Sie prüfen, ob Sie sie nicht verwenden, weil sie nicht benötigt werden (= geringe Last), weil Ihre Vorgänge nicht ordnungsgemäß parallelisiert werden können oder weil MySQL und / oder Apache nicht dafür konfiguriert sind benutze sie. Und da diese beiden Programme normalerweise standardmäßig Multithread-fähig sind, würde ich einen Blick auf Ihre Serverauslastung und Ihre SQL-Abfragen werfen ...

— Massimo,

3

Wie Ignacio bemerkte, sollten Sie sich mit Caching befassen. In den Zentimetern oder vielleicht sogar vor dem Stapel. Über 50 Abfragen für jede (jede!) Seite sind wirklich eine Menge.

— Joris
quelle

ja das ist eine komplexe website, es ist eine community, ich kann nichts cachen, es ändert sich jede sekunde. Ich habe versucht, Seiten zwischenzuspeichern, aber die Cache-Hitrate war fast 0, da jedes Mal, wenn ich eine Seite zwischenzuspeichern, sie nie wieder gelesen oder geändert werden kann, bevor sie wieder geöffnet wird. danke

4

Es gibt nur sehr wenige nicht zwischenspeicherbare Sites. Wenn es sich nur jede Sekunde ändert, können Sie immer noch eine ganze Sekunde zwischenspeichern, wie z. B. 10 Seitenaufrufe. Sie könnten außerhalb der Datenbank, auf gemeinsam genutzten Speichersegmenten, Dateisystemen, zwischengespeichert. In einer solchen Situation kann ESI auch nützlich sein

— Joris

0

Gemessen an Ihren Kommentaren ist der größte Faktor die Größe Ihres Datensatzes oder zumindest die Größe des "heißen" Datensatzes. 3.000 oder sogar 8.000 Qps auf einem 16-Core-Server sind überhaupt kein Problem, solange der Server selten auf die Festplatte muss, um die Abfrage zu erfüllen. Sobald der aktive Datensatz die Menge an Speicher überschreitet, die InnoDB zum Zwischenspeichern verwendet, sinkt Ihre Leistung rapide.

— Elliott
quelle

0

Für große "Hot" -Datensätze lohnt sich wahrscheinlich die Investition in die Umstellung auf ein "Big Data" -Schema. Wenn Sie beispielsweise eine große Datenmenge abrufen müssen, aber nie neu schreiben, sondern nur neue Daten anhängen, sehen Sie sich Apache Hive an. Stöbern Sie herum, es ist normalerweise eine Variante, die Sie leicht genug mit vorhandenem Code verknüpfen können, um zu verhindern, dass das Sodbrennen den Cache-Speicherplatz erschöpft.

— BHGalyean
quelle

0

Es gibt zu viele Dinge, die Ihre Anfragen pro Sekunde beeinflussen können. Vertrauen Sie meinen Daten nicht, ohne sich selbst zu testen. Ich poste hier mein Geschwindigkeitstestergebnis, um jemandem zu helfen, das QPS mit der aktuellen (2018-09) MySQL-Datenbank und dem aktuellen Computer abzuschätzen. In meinem Test ist die Datengröße geringer als der Serverspeicher (was die E / A-Leistung drastisch reduziert und die Leistung erheblich verbessert).

Ich benutze eine CPU 3,75 GB Speicher, 100 GB SSD, GCP Cloud MySQL Server Instanz und bekomme:

1 Klient, ein Quadratmeter, eine Zeile gelesen: 799 Quadratmeter / Sekunde.
50 Kunden, ein Quadratmeter in einer Zeile: 6403 Quadratmeter / Sekunde.
50 Clients, eine SQL, eine Zeile schreiben: 4341 Zeilen geschrieben, qps. 4341 m² / Sekunde.
1 Client, 30.000 Zeilen pro SQL schreiben: 92.109 geschriebene Zeilen / s.

— Bronzemann
quelle

Schreibe qps Testergebnis (2018-11) gcp mysql 2cpu 7.5GB Speicher 150GB SSD Serialisierung Schreibe 10 Threads, 30k Zeilen Schreibe pro SQL, 7.0566GB Tabelle, die Datenschlüssellänge beträgt 45 Bytes und die Wertelänge 9 Bytes, bekomme 154KB geschriebene Zeilen pro sekunde schreiben 97,1% der cpu qps 1406 / s in die gcp-konsole.

— Bronzemann