Quante selezioni al secondo può eseguire un server mysql?

19

Sto scrivendo un piano aziendale e devo simulare il costo quando il mio sito web sarà raggiunto da 500.000 visitatori unici.

visitatori: 500.000
visualizzazioni di pagina: 1.500.000
visualizzazioni di pagina di ragno: 500.000
visualizzazioni di pagina totali: 2.000.000

Ogni pagina fa 50 query + -

query al giorno: 100 milioni
all'ora: 4 milioni
al minuto: 70.000
al secondo: 1.200
picco: 3.000

Per fare questo calcolo ho bisogno di 3.000 query al secondo ... che tipo di server può gestirlo?

Il problema è: in realtà il mio sito sta facendo 2.000 visite al giorno e avendo - + 150/200 query / secondo ... a partire da questo punto mi aspetto 50.000 query / secondo.

Di quanti server ho bisogno nel cluster o nella replica gestiscono questo lavoro?

mysql linux

— Ripristina Monica
fonte

5

Che tipo di sito 8k + richiede una visita?

— Ignacio Vazquez-Abrams,

5

È necessaria una revisione della progettazione del sistema immediatamente.

— Chopper3,

1

In nessun posto informazioni sufficienti, perché non ci hai detto nulla di ciò che conta davvero: le domande stesse. Né ci devi dire della macchina che stai utilizzando. È un 486? L'ultimo e il più grande supercomputer o qualcosa in mezzo? Tutti quei numeri che hai elencato sono irrilevanti per la domanda. Si prega di fornire informazioni RILEVANTI.

— John Gardeniers,

> Che tipo di sito 8k + richiede una visita? Ricevo 2000 visitatori unici ma ogni visitatore apre molte pagine, + ho molti ragni all'interno. 2000 utenti unici stanno generando 6000 ips unici aprendo più di 120.000 pagine aperte ogni giorno. grazie

22

Lavoravo per una società di e-commerce con un sito Web che aveva diversi milioni di pagine al giorno. Avevamo un singolo DELL PE 1750 con 2 CPU single core e 2 GB di RAM, dimensioni del database circa. 4GB. Nelle ore di punta questo server ha gestito fino a 50k + query al secondo.

Detto questo: il database era ben strutturato, tutte le query sono state ottimizzate (avevamo sessioni settimanali che analizzavano i log delle query lente e correggevano query e indici) e anche la configurazione del server era stata perfezionata. La memorizzazione nella cache è sicuramente una buona idea, ma MySQL lo fa comunque, devi solo analizzare le prestazioni e quindi ottimizzare il modo in cui viene utilizzata la tua memoria (cache delle query rispetto ad altre opzioni).

Da quell'esperienza posso dirti che l'impatto maggiore è causato da indici mancanti, indici errati e cattiva progettazione del database (ad es. Campi stringa lunghi come chiavi primarie e assurdità simili).

— wolfgangsz
fonte

8

Tutto dipende dalla complessità della query, dalla quantità di memoria dei server e dalla velocità dei dischi.

Se le query sono molto semplici o ottimizzate, un singolo server di database di grandi dimensioni può gestirlo. Se tuttavia le query sono molto complesse (o semplici ma mal sintonizzate), avrai bisogno di diversi server.

— mrdenny
fonte

O alcune serie modifiche dello schema e reindicizzazione ...

— Massimo,

3

L'ottimizzazione è SEMPRE preferita rispetto all'aggiunta di altro hardware. L'aggiunta di altro hardware maschera solo il problema fino a quando il problema non sarà molto più difficile da risolvere.

— mrdenny,

Grazie per la risposta, quindi penso che 2 server in parallelo + 1 passivo per ridondanza dovrebbero essere ok, giusto? Sto parlando di 2x server quad core con 32 g di RAM e unità veloci. ho ragione? ricorda che ho bisogno di spettacoli!

1

tutto è ottimizzato e indicizzato, ho 1 o 2 query lente a settimana (e il tempo di query lento è di soli 2 secondi) comunque sto scrivendo un business plan e mi piacerebbe sapere che tipo di pool di server può gestire 12.000.000 di pagine aperte quotidianamente generando con 8000 query / secondo

8000 query al secondo non sono poi così tante. Un singolo server 16 core probabilmente farà il trucco. 64 concerti di RAM (o più o meno a seconda della dimensione del database e della quantità di dati che devono essere conservati nella cache in qualsiasi momento) dovrebbero fare il trucco. Il mio DB (concesso il suo SQL Server) è 1 TB su un server a 16 core da 64 Gig di RAM con 40-50k utenti che lo colpiscono ogni giorno fino a diverse volte al minuto (ciascuno) per tutto il giorno.

— mrdenny,

3

Questo non può davvero essere stimato senza sapere nulla delle query specifiche che stai eseguendo, dello schema del database e delle sue dimensioni.

Un semplice SELECT su una colonna indicizzata è piuttosto diverso da un paio di JOIN basati su quelli non indicizzati ... e ovviamente le cose cambiano molto se le tabelle coinvolte contengono record 1K o 1M.

Anche:

Qual è la tua attuale configurazione hardware?
Quanto della sua potenza (CPU, RAM, I / O del disco) sta usando il tuo server sotto il carico attuale?

— Massimo
fonte

in realtà ho un server con 2x quad core con 8 GB di RAM. sto usando il ram completo e il 100% del processore (sembra che io possa usare l'800%, vedi qui :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ disco download2p.png : img213.imageshack.us/i/download1x.png grazie

Sulla base di questi grafici, stai usando solo uno (o al massimo due) dei tuoi core della CPU; quindi la tua applicazione non è sicuramente legata alla CPU ... o lo è, ma non è in grado di sfruttare più CPU. Inoltre, tutta quella memoria utilizzata per "cache" non è realmente necessaria da nessuno, è solo il sistema operativo che ne approfitta perché "è lì".

— Massimo

come posso trovare informazioni sull'uso di tutti i core della cpu? sto usando la lampada ...

Prima di tutto, dovresti controllare se non li stai usando perché non ce n'è bisogno (= carico ridotto), perché le tue operazioni non possono essere adeguatamente parallelizzate o perché MySQL e / o Apache non sono configurati per usali. E, dal momento che questi due programmi di solito sono multithread per impostazione predefinita, darei un'occhiata al carico del tuo server e alle tue query SQL ...

— Massimo

3

Come ha osservato Ignacio, potresti voler esaminare la memorizzazione nella cache. Nel cms o forse anche davanti alla pila. Più di 50 domande per ogni (ogni!) Pagina sono davvero molte.

— Joris
fonte

sì, questo è un sito web complesso, è una comunità, non posso memorizzare nulla nella cache, cambia ogni secondo. ho provato a memorizzare nella cache le pagine, ma l'hitrate della cache era quasi 0, poiché ogni volta che memorizzo nella cache una pagina, non può più essere letta o può cambiare prima che venga riaperta. grazie

4

Ci sono pochissimi siti inaccessibili; se cambia solo ogni secondo è ancora possibile memorizzare nella cache per un intero secondo, ad esempio 10 visualizzazioni di pagina ;-) Hai considerato di non memorizzare nella cache interamente le pagine, ma piuttosto blocchi o valori specifici ecc.? È possibile memorizzare nella cache all'esterno del database, su segmenti di memoria condivisa, filesystem, memcached. Inoltre, in genere in una situazione del genere l'ESI potrebbe essere utile

— Joris il

0

A giudicare dai tuoi commenti, il fattore più importante sarà la dimensione del tuo set di dati, o almeno la dimensione del set di dati "caldo". 3.000qps o persino 8.000qps su un server a 16 core non sono affatto un problema, a condizione che il server raramente debba andare sul disco per soddisfare la query. Quando il set di dati attivo supera la quantità di memoria utilizzata da InnoDB per memorizzarlo nella cache, le prestazioni diminuiranno rapidamente.

— Elliott
fonte

0

Per grandi set di dati "caldi", probabilmente vale la pena investire in tempo per convertirsi in uno schema di "big data", è quello che fanno. Ad esempio, se hai una grande quantità di dati da recuperare, ma non riscrivi mai, ma aggiungi solo nuovi dati, guarda Apache Hive. Dai un'occhiata in giro, di solito è un sapore che puoi interfacciare abbastanza facilmente al codice esistente, che impedirà anche al bruciore di stomaco di rimanere senza spazio nella cache.

— BHGalyean
fonte

0

Ci sono troppe cose che possono influire sulle tue query al secondo, per favore non fidarti dei miei dati senza testarti. Pubblico qui il mio risultato del test di velocità per aiutare qualcuno a stimare il qps con il database e la macchina mysql (2018-09) correnti. Nel mio test la dimensione dei dati è inferiore alla memoria del server (che riduce drasticamente l'I / O e migliora le prestazioni).

Uso una memoria da 3,75 GB cpu, 100 GB ssd, istanza del server mysql gcp cloud e ottengo:

1 client, uno sql una riga letta: 799 sql / secondo.
50 client, uno sql una riga letta: 6403 sql / secondo.
50 client, uno sql una riga scrivono: 4341 righe scritte, qps. 4341 sql / secondo.
1 client, 30k righe di scrittura per sql: 92109 righe / s scritte.

— uomo di bronzo
fonte

scrivi risultato del test qps (2018-11) gcp mysql 2cpu 7,5 GB di memoria 150 GB di serializzazione ssd scrivi 10 thread, 30k righe di scrittura per sql, 7,0566 GB di tabella, la lunghezza della chiave dei dati è 45 byte e la lunghezza del valore è 9 byte, ottieni 154 KB di righe scritte al secondo, cpu 97,1% scrive qps 1406 / s nella console gcp.

— uomo di bronzo,