Bir mysql sunucusu saniyede kaç seçim çalıştırabilir?

19

Bir iş planı yazıyorum ve web sitemin 500.000 tekil ziyaretçiden ulaşacağı maliyeti simüle etmeliyim.

ziyaretçi: 500.000
sayfa görüntüleme sayısı: 1.500.000
örümcek sayfa görüntüleme sayısı: 500.000
toplam sayfa görüntüleme sayısı: 2.000.000

Her sayfada 50 sorgu + -

günlük sorgu sayısı: 100 Milyon
saatte: 4 Milyon
dakikada: 70.000
Saniyede: 1.200
tepe noktası: 3.000

Bu hesaplamayı yaparken 3.000 sorguya ihtiyacım var ... ne tür bir sunucu işleyebilir?

Sorun şu ki, aslında sitem 2.000 ziyaret günü yapıyor ve - + 150/200 sorgu / saniye ... bu noktadan başlayarak 50.000 sorgu / saniye bekliyorum.

Küme veya çoğaltmada kaç sunucuya ihtiyacım var bu işi yönetiyor?

mysql linux

— Monica'yı eski durumuna getir
kaynak

5

8k + ne tür bir siteyi ziyaret eder?

— Ignacio Vazquez-Abrams

5

Hemen bir sistem tasarımı incelemesine ihtiyacınız var.

— Chopper3

1

Yeterince yakın bilgi yok, çünkü bize gerçekten önemli olan hiçbir şey söylemediniz - sorguların kendisi. Bize koştuğunuz makineden bahsetmemize gerek yok. Bu bir 486 mı? En son ve en büyük süper bilgisayar veya arada bir şey? Listelediğiniz tüm bu sayılar soru ile alakasız. Lütfen İLGİLİ bilgiler veriniz.

— John Gardeniers

> 8k + ne tür bir siteyi ziyaret eder? 2000 benzersiz ziyaretçi alıyorum ama her ziyaretçi birçok sayfa açıyor, + içinde çok fazla örümcek var. 2000 benzersiz kullanıcı, günde 120.000'den fazla sayfa açan 6000 benzersiz ips üretiyor. teşekkürler

22

Günde birkaç milyon sayfa ziyaret eden bir web sitesine sahip bir e-ticaret şirketinde çalışıyordum. Biz 2 tek çekirdekli CPU ve 2 GB RAM ile tek bir DELL PE 1750 vardı, veritabanı boyutu yaklaşık. 4 CİGABAYT. Yoğun zamanlarda bu sunucu saniyede 50k + sorguyu işledi.

Bunu söyledikten sonra: veritabanı iyi yapılandırılmış, tüm sorgular ince ayarlanmış (yavaş sorgu günlüklerini analiz eden ve sorguları ve dizinleri düzelten haftalık oturumlarımız vardı) ve sunucu kurulumu da ince ayarlandı. Önbellekleme kesinlikle iyi bir fikirdir, ancak MySQL yine de bunu yapar, sadece performansı analiz etmeniz ve ardından belleğinizin nasıl kullanıldığına ince ayar yapmanız gerekir (önbellek diğer seçeneklere karşı sorgulama).

Bu deneyime göre, en yüksek etkinin eksik dizinler, yanlış dizinler ve kötü veritabanı tasarımından kaynaklandığını söyleyebilirim (örneğin, birincil anahtarlar ve benzer saçmalıklar gibi uzun dize alanları).

— wolfgangsz
kaynak

8

Her şey sorgunun ne kadar karmaşık olduğuna ve sunucuların ne kadar belleğe ve disklerin ne kadar hızlı olduğuna bağlıdır.

Sorgular çok basit veya çok iyi ayarlanmışsa, tek bir büyük veritabanı sunucusu bunu işleyebilir. Ancak sorgular çok karmaşıksa (veya basit ama kötü ayarlanmışsa), birkaç sunucuya ihtiyacınız olacaktır.

— mrdenny
kaynak

Veya bazı ciddi şema değişiklikleri ve yeniden endeksleme ...

— Massimo

3

Tuning, her zaman daha fazla donanım eklemek yerine tercih edilir. Daha fazla donanım eklemek, sorunu çözmek çok daha zor olduğu zamana kadar sorunu maskeler.

— mrdenny

Cevabınız için teşekkürler, bu yüzden yedekleme için paralel + 1 pasif 2 sunucunun tamam olması gerektiğini düşünüyorum, değil mi? 32 g koç ve hızlı sürücüler ile 2x dört çekirdekli sunucular hakkında konuşuyorum. haklı mıyım performanslara ihtiyacım olduğunu hatırla!

1

her şey iyi ayarlanmış ve endeksli, ben haftada 1 veya 2 yavaş sorgu var (ve yavaş sorgu süresi sadece 2 saniye) neyse ben bir iş planı yazıyorum ve ne tür bir sunucu havuzu olabilir bilmek istiyorum Günlük açılan 12.000.000 sayfayı 8000 sorgu / saniye ile yönetme

Saniyede 8000 sorgu o kadar da değil. 16 çekirdekli tek bir sunucu muhtemelen işe yarayacaktır. 64 Gig RAM (veya veritabanının ne kadar büyük olduğuna ve herhangi bir zamanda önbellekte ne kadar verinin tutulması gerektiğine bağlı olarak daha fazla veya daha az) hile yapmalıdır. My DB (SQL Server'ı verildi) 16 çekirdekli 64 Gig RAM sunucusunda 1 TB olup, 40-50k kullanıcısı günlük olarak günde birkaç kez (her biri) güne kadar vurur.

— mrdenny

3

Bu, çalıştırdığınız sorgular, veritabanı şeması ve boyutu hakkında hiçbir şey bilmeden gerçekten tahmin edilemez.

İndekslenmiş bir sütundaki basit bir SELECT, endekslenmemiş olanlara dayanan birkaç JOIN'den oldukça farklı bir canavardır ... ve elbette ilgili tablolar 1K kayıtları veya 1M içeriyorsa işler çok değişir.

Ayrıca:

Mevcut donanım yapılandırmanız nedir?
Sunucunuzun gücü ne kadar (CPU, RAM, Disk G / Ç) mevcut yük altında kullanılıyor?

— Massimo
kaynak

Aslında ben 8 GB ram ile 2x dört çekirdekli bir sunucu var. İşlemcinin tam ramını ve% 100'ünü kullanıyorum (% 800 kullanabileceğim görünüyor, buraya bakın :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ download2p.png disk: img213.imageshack.us/i/download1x.png teşekkürler

Bu grafiklere dayanarak, CPU çekirdeklerinizden yalnızca birini (veya en fazla iki) kullanıyorsunuz; yani uygulamanız kesinlikle CPU'ya bağlı değil ... ya da birden fazla CPU'dan yararlanamaz. Ayrıca, "önbellek" için kullanılan bu belleğin hiçbirine gerçekte ihtiyaç duyulmaz , sadece işletim sisteminden faydalanır çünkü "orada" dır .

— Massimo

tüm işlemci çekirdeklerini kullanma hakkında nasıl bilgi bulabilirim? lamba kullanıyorum ...

Her şeyden önce, onları kullanmadığınızı kontrol etmelisiniz, çünkü bunlara hiç gerek yok (= düşük yük), çünkü işlemleriniz düzgün bir şekilde paralelleştirilemiyor veya MySQL ve / veya Apache'niz onları kullan. Ve bu iki program genellikle varsayılan olarak çok iş parçacıklı olduğundan, sunucu yükünüze ve SQL sorgularınıza bir göz atacağım ...

— Massimo

3

Ignacio'nun belirttiği gibi, önbelleğe almak isteyebilirsiniz. CM'lerde veya belki de yığının önünde. Her (her!) Sayfa için 50'den fazla sorgu gerçekten çok fazla.

— Joris
kaynak

evet bu karmaşık bir web sitesi, bir topluluk, hiçbir şey önbelleğe alamıyorum, her saniye değişiyor. sayfaları önbelleğe almaya çalıştım, ama önbellek hitrate neredeyse 0 oldu, çünkü bir sayfayı her önbelleğe aldığımda, bir daha asla okunamaz ya da tekrar açılmadan önce değişebilir. teşekkürler

4

Çok az erişilemeyen site vardır; yalnızca her saniyede bir değişiklik yaparsa, 10 sayfa görüntüleme gibi tam bir saniye önbellekleme yapabilirsiniz ;-) Sayfaları tamamen önbelleğe almayı değil, blokları veya belirli değerleri vb. Veritabanı dışında, paylaşılan bellek segmentlerinde, dosya sisteminde, memcached'de önbellekleme yapabilirsiniz. Ayrıca, genellikle böyle bir durumda ESI yararlı olabilir

— Joris

0

Yorumlarınıza bakılırsa, en büyük faktör veri kümesi boyutunuz veya en azından "sıcak" veri kümesinin boyutu olacaktır. 16 çekirdekli bir sunucuda 3.000qps ve hatta 8.000qps, sunucunun sorguyu karşılamak için nadiren diske gitmesi gerektiği sürece sorun olmaz. Etkin veri kümesi InnoDB'nin önbelleğe almak için kullandığı bellek miktarını aştığında, performansınız hızla düşecektir.

— Elliott
kaynak

0

Büyük "sıcak" veri kümeleri için, muhtemelen bir "büyük veri" şemasına dönüştürmek için zamana yatırım yapmaya değer, bunun için ne var. Örneğin, alınacak çok büyük miktarda veriye sahipseniz, ancak hiçbir zaman yeniden yazmazsanız, yalnızca yeni veriler eklerseniz, Apache Hive'a bakın. Çevreye göz atın, genellikle mevcut koda yeterince kolay arayüz yapabileceğiniz bir lezzettir, bu da mide ekşimesinin önbellek boşluğunun tükenmesini önler.

— BHGalyean
kaynak

0

Saniyede sorgularınızı etkileyebilecek çok fazla şey var, lütfen kendinizi test etmeden verilerime güvenmeyin. Hız testi sonucumu, birinin geçerli (2018-09) mysql veritabanı ve makine ile qps'yi tahmin etmesine yardımcı olmak için buraya gönderiyorum. Testimde veri boyutu sunucu belleğinden daha azdır (bu, ES'yi önemli ölçüde azaltır ve performansı çok artırır).

Bir cpu 3.75GB bellek, 100GB ssd, gcp bulut mysql sunucu örneği kullanıyorum ve şunları alıyorum:

1 istemci, bir sql bir satır okuma: 799 sql / saniye.
50 istemci, bir sql bir satır okuma: 6403 sql / saniye.
50 müşteri, bir sql bir satır yazma: 4341 satır yazılmış, qps. 4341 metrekare / saniye.
1 istemci, sql başına 30k satır yazma: 92109 yazılı satır / sn.

— bronz adam
kaynak

yazma qps test sonucu (2018-11) gcp mysql 2cpu 7.5GB bellek 150GB ssd serileştirme yazma 10 iş parçacığı, sql başına 30k satır yazma, 7.0566GB tablo, veri anahtar uzunluğu 45 bayt ve değer uzunluğu 9 bayt, 154KB yazılı satır al saniyede cpu% 97.1 gcp konsolunda qps 1406 / s yazıyor.

— bronz adam