एक mysql सर्वर कितने प्रति सेकंड का चयन कर सकता है?

19

मैं एक व्यवसाय योजना लिख रहा हूं और मुझे लागत का अनुकरण करना होगा जब मेरी वेबसाइट 500.000 अद्वितीय आगंतुकों तक पहुंच जाएगी।

आगंतुक: 500.000
पृष्ठ साक्षात्कार: 1,500,000
मकड़ी के पृष्ठदृश्य: 500,000
कुल पृष्ठ साक्षात्कार: 2,000,000

प्रत्येक पृष्ठ 50 प्रश्न + करता है -

प्रति दिन प्रश्न: 100 मिलियन
प्रति घंटे: 4 मिलियन
प्रति मिनट: 70,000
प्रति सेकंड: 1,200
चोटी: 3,000

इस गणना को करते हुए मुझे 3,000 प्रश्नों की आवश्यकता है ... किस प्रकार का सर्वर इसे संभाल सकता है?

समस्या यह है: वास्तव में मेरी साइट दिन में 2,000 यात्राएं कर रही है, और होने पर - + 150/200 प्रश्न / सेकंड ... इस बिंदु से शुरू होकर मुझे 50,000 प्रश्न / सेकंड की उम्मीद होगी।

इस कार्य को प्रबंधित करने के लिए मुझे क्लस्टर या प्रतिकृति में कितने सर्वर चाहिए?

mysql linux

— मोनिका को बहाल करो
स्रोत

5

8k + साइट किस तरह की साइट पर जाती है?

— इग्नासियो वाज़क्वेज़-अब्राम्स

5

आपको तुरंत एक सिस्टम डिज़ाइन समीक्षा की आवश्यकता है।

— चॉपर 3

1

कहीं भी पर्याप्त जानकारी नहीं है, क्योंकि आपने हमें कुछ भी नहीं बताया है कि वास्तव में क्या मायने रखता है - स्वयं प्रश्न। और न ही हमें उस मशीन के बारे में बताया जो आप चला रहे हैं। क्या यह 486 है? नवीनतम और सबसे बड़ा सुपर कंप्यूटर या बीच में कुछ? आपके द्वारा सूचीबद्ध सभी नंबर प्रश्न के लिए अप्रासंगिक हैं। कृपया RELEVANT जानकारी प्रदान करें।

— जॉन गार्डनियर्स

> 8k + साइट किस तरह की साइट पर जाती है? मुझे 2000 अद्वितीय आगंतुक मिले हैं, लेकिन प्रत्येक आगंतुक कई पृष्ठ खोलता है, + मेरे अंदर बहुत सी मकड़ियाँ हैं। 2000 अद्वितीय उपयोगकर्ता रोजाना खोले जाने वाले 120.000 से अधिक पेज खोलने के लिए 6000 यूनीप जनरेट कर रहे हैं। साभार

22

मैं एक ई-कॉमर्स कंपनी के लिए एक वेबसाइट के साथ काम करता था जिसमें प्रति दिन कई मिलियन पेज हिट होते थे। हमारे पास 2 सिंगल कोर सीपीयू और 2 जीबी रैम, डेटाबेस साइज लगभग एक सिंगल डीईएल पीई 1750 था। 4GB। पीक समय में इस सर्वर ने प्रति सेकंड 50k + क्वेरीज़ को संभाला।

यह कहने के बाद: डेटाबेस को अच्छी तरह से संरचित किया गया था, सभी प्रश्नों को सूक्ष्मता से ट्यून किया गया था (हमारे पास साप्ताहिक सत्र थे जो धीमी क्वेरी लॉग का विश्लेषण कर रहे थे और क्वेरीज़ और इंडेक्स को ठीक कर रहे थे) और सर्वर सेटअप भी ठीक-ठीक था। कैशिंग निश्चित रूप से एक अच्छा विचार है, लेकिन MySQL यह करता है कि वैसे भी, आपको केवल प्रदर्शन का विश्लेषण करना है और फिर ठीक धुन है कि आपकी मेमोरी का उपयोग कैसे किया जाता है (क्वेरी कैश बनाम अन्य विकल्प)।

उस अनुभव से मैं आपको बता सकता हूं कि सबसे अधिक प्रभाव लापता इंडेक्स, गलत इंडेक्स और खराब डेटाबेस डिजाइन (उदाहरण के लिए प्राथमिक कुंजी और समान बकवास के रूप में लंबे स्ट्रिंग फ़ील्ड) के कारण होता है।

— wolfgangsz
स्रोत

8

यह सब इस बात पर निर्भर करता है कि क्वेरी कितनी जटिल है, और सर्वर में कितनी मेमोरी है, और डिस्क कितनी तेज़ है।

यदि क्वेरी बहुत सरल हैं, या बहुत अच्छी तरह से ट्यून की गई हैं, तो एक बड़ा डेटाबेस सर्वर इसे संभाल सकता है। यदि फिर भी प्रश्न बहुत जटिल हैं (या सरल लेकिन खराब ट्यून हैं) तो आपको कई सर्वरों की आवश्यकता होगी।

— mrdenny
स्रोत

या कुछ गंभीर स्कीमा परिवर्तन और रीइन्डेक्सिंग ...

— मासिमो

3

ट्यूनिंग अधिक हार्डवेयर जोड़ने पर हमेशा पसंदीदा है। अधिक हार्डवेयर जोड़ने से समस्या का सामना करना पड़ता है जब तक कि समस्या को हल करना बहुत कठिन है।

— मर्डनी

जवाब के लिए धन्यवाद, इसलिए मुझे लगता है कि 2 सर्वरों में समानांतर + 1 निष्क्रियता के लिए redoundance ठीक होना चाहिए, है ना? मैं राम और त्वरित ड्राइव के 32 ग्राम के साथ 2x क्वाड कोर सर्वर के बारे में बात कर रहा हूँ। क्या मैं सही हू? याद रखें कि मुझे प्रदर्शन की आवश्यकता है!

1

सब कुछ ठीक है और अनुक्रमित है, मेरे पास प्रति सप्ताह 1 या 2 धीमी क्वेरी है (और धीमी-क्वेरी-समय सिर्फ 2 सेकंड है) वैसे भी मैं एक व्यवसाय योजना लिख रहा हूं, और मैं जानना चाहता हूं कि किस तरह का सर्वर पूल कर सकता है १२,०००,००० पृष्ठों को प्रतिदिन /००० प्रश्नों / सेकंड के साथ खोला

8000 प्रश्न एक सेकंड इतना सब नहीं है। एक सिंगल 16 कोर सर्वर शायद चाल चलेगा। 64 गीगा RAM (या अधिक या कम डेटाबेस कितना बड़ा है और किसी भी एक समय में कैश में कितना डेटा रखने की आवश्यकता है) के आधार पर चाल करना चाहिए। माई डीबी (इसका एसक्यूएल सर्वर प्रदान किया गया) 16 कोर 64 गीगा रैम सर्वर पर 1 टीबी है, जिसमें 40-50k उपयोगकर्ता रोजाना प्रति मिनट कई बार प्रति मिनट (प्रत्येक) इसे मारते हैं।

— मर्डनी

3

यह वास्तव में आपके द्वारा चलाए जा रहे विशिष्ट प्रश्नों, डेटाबेस योजना और इसके आकार के बारे में कुछ भी जानने के बिना अनुमानित नहीं किया जा सकता है।

अनुक्रमित स्तंभ पर एक साधारण चयन गैर-अनुक्रमित लोगों के आधार पर जोइन के एक जोड़े से काफी अलग जानवर है ... और निश्चित रूप से चीजें बहुत बदल जाती हैं यदि इसमें शामिल तालिकाओं में 1K रिकॉर्ड या 1M है।

इसके अलावा:

आपका वर्तमान हार्डवेयर कॉन्फ़िगरेशन क्या है?
वर्तमान लोड के तहत आपके सर्वर (CPU, RAM, डिस्क I / O) का कितना उपयोग हो रहा है?

— मास्सिमो
स्रोत

वास्तव में मेरे पास 8 जीबी रैम के साथ 2x क्वाड कोर वाला एक सर्वर है। मैं पूर्ण RAM और 100% प्रोसेसर का उपयोग कर रहा हूं (ऐसा लगता है कि मैं 800% का उपयोग कर सकता हूं, यहां देखें :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ डाउनलोड 2p.png डिस्क: img213.imageshack.us/i/download1x.png धन्यवाद

उन ग्राफ़ के आधार पर, आप केवल अपने CPU कोर में से एक (या अधिकतम दो) का उपयोग कर रहे हैं; इसलिए आपका एप्लिकेशन निश्चित रूप से सीपीयू-बाउंड नहीं है ... या यह है, लेकिन यह कई सीपीयू का लाभ लेने में असमर्थ है। इसके अलावा, "कैश" के लिए उपयोग की जाने वाली सभी मेमोरी को किसी की भी जरूरत नहीं है, यह सिर्फ ओएस का लाभ उठा रहा है क्योंकि "यह" है।

— मासिमो

मैं सभी सीपीयू कोर का उपयोग करने के बारे में जानकारी कैसे प्राप्त कर सकता हूं? मैं दीपक का उपयोग कर रहा हूँ ...

सबसे पहले, आपको यह जांचना चाहिए कि क्या आप उनका उपयोग नहीं कर रहे हैं क्योंकि उनके लिए (= कम लोड) की कोई आवश्यकता नहीं है, क्योंकि आपके संचालन को ठीक से समानांतर नहीं किया जा सकता है, या क्योंकि आपके MySQL और / या Apache को कॉन्फ़िगर नहीं किया गया है। उन्हें इस्तेमाल करें। और, चूंकि उन दो कार्यक्रमों को आम तौर पर डिफ़ॉल्ट रूप से गुणा किया जाता है, मुझे आपके सर्वर लोड और आपके एसक्यूएल प्रश्नों पर एक नज़र होगी ...

— मैसिमो

3

जैसा कि इग्नासियो ने टिप्पणी की है, आप कैशिंग में देखना चाहते हैं। सेमी में या शायद स्टैक के सामने भी। हर (हर!) पृष्ठ के लिए 50+ क्वेरी सही मायने में बहुत कुछ है।

— जोरिस
स्रोत

हाँ यह एक जटिल वेबसाइट है, यह एक समुदाय है, मैं कुछ भी कैश नहीं कर सकता, यह हर पल बदल रहा है। मैंने पृष्ठों को कैश करने की कोशिश की, लेकिन कैश हिट्रेट लगभग 0 था, क्योंकि जब भी मैं किसी पृष्ठ को कैश करता हूं, तो इसे फिर से कभी नहीं पढ़ा जा सकता है, या इसे फिर से खोलने से पहले इसे बदल सकता है। साभार

4

बहुत कम अनचाही साइटें हैं; यदि यह केवल हर दूसरे को बदलता है, तो आप अभी भी 10 सेकंड के लिए, पूरे 10 सेकंड के लिए कैश कर सकते हैं ;-) क्या आपने पृष्ठों को पूरी तरह से कैशिंग नहीं माना है, बल्कि ब्लॉक या विशिष्ट मान आदि? आप साझा मेमोरी सेगमेंट, फाइलसिस्टम, मेमेकैच्ड पर डेटाबेस के बाहर कैश कर सकते हैं। इसके अलावा, आम तौर पर ऐसी स्थिति में ईएसआई उपयोगी हो सकता है

— जोरीस जूल

0

आपकी टिप्पणियों को देखते हुए, सबसे बड़ा कारक आपका डेटा सेट आकार होगा, या कम से कम "हॉट" डेटा सेट का आकार होगा। 16-कोर सर्वर पर 3,000qps या 8,000qps तब तक कोई समस्या नहीं है जब तक कि क्वेरी को संतुष्ट करने के लिए सर्वर को शायद ही कभी डिस्क पर जाना पड़े। एक बार जब सक्रिय डेटा सेट मेमोरी की मात्रा से अधिक हो जाता है तो इसे कैश करने के लिए इनोबीडी का उपयोग किया जाता है, आपका प्रदर्शन तेजी से गिर जाएगा।

— इलियट
स्रोत

0

बड़े "हॉट" डेटासेट के लिए, संभवतः "बड़े डेटा" योजना में बदलने के लिए निवेश के लायक है, यह वही है जो वे करने के लिए हैं। उदाहरण के लिए, यदि आपके पास पुनर्प्राप्त करने के लिए विशाल मात्रा में डेटा है, लेकिन आप कभी भी फिर से लिखना नहीं चाहते हैं, लेकिन केवल नए डेटा को जोड़ते हैं, तो अपाचे हाइव को देखें। चारों ओर ब्राउज़ करें, उनका आम तौर पर एक स्वाद है जिसे आप आसानी से मौजूदा कोड के लिए पर्याप्त इंटरफ़ेस कर सकते हैं, जो कैश स्थान से बाहर निकलने की नाराज़गी को भी रोक देगा।

— BHGalyean
स्रोत

0

बहुत सी चीजें हैं जो प्रति सेकंड आपके प्रश्नों को प्रभावित कर सकती हैं, कृपया बिना अपने परीक्षण के मेरे डेटा पर भरोसा न करें। मैं अपना स्पीड टेस्ट परिणाम पोस्ट करने के लिए किसी को वर्तमान (2018-09) mysql डेटाबेस और मशीन के साथ qps का अनुमान लगाने में मदद करता हूं। मेरे परीक्षण में डेटा का आकार सर्वर मेमोरी से कम है (जो नाटकीय रूप से IO को कम करता है और प्रदर्शन को बहुत बढ़ाता है)।

मैं एक cpu 3.75GB मेमोरी, 100GB ssd, gcp क्लाउड mysql सर्वर इंस्टेंस का उपयोग करता हूं और प्राप्त करता हूं:

1 ग्राहक, एक sql एक पंक्ति पढ़ी जाती है: 799 sql / second।
50 ग्राहक, एक sql एक पंक्ति पढ़ते हैं: 6403 sql / second।
50 ग्राहक, एक sql एक पंक्ति लिखते हैं: 4341 पंक्तियाँ लिखी गईं, qps। 4341 sql / सेकंड।
1 ग्राहक, 30k पंक्ति प्रति वर्ग लिख: 92109 लिखित पंक्तियाँ / एस।

— कांसे का आदमी
स्रोत

लिखना qps परीक्षा परिणाम (2018-11) gcp mysql 2cpu 7.5GB मेमोरी 150GB ssd क्रमांकन 10 सूत्र, 30k पंक्ति प्रति वर्ग लिख, 7.0566GB तालिका, डेटा कुंजी लंबाई 45 बाइट्स और मान लंबाई 9 बाइट्स है, 154KB लिखित पंक्तियाँ लिखें। प्रति सेकंड, cpu 97.1% gcp कंसोल में qps 1406 / s लिखें।

— कांस्य पुरुष