NUMA आर्किटेक्चर ActivePivot के प्रदर्शन को कैसे प्रभावित करता है?

Question

हम एक सक्रिय सर्वर को एक नए सर्वर (4 सॉकेट इंटेल ज़ीऑन, 512 जीबी मेमोरी) में माइग्रेट कर रहे हैं। तैनाती के बाद हमने अपना आवेदन बेंचमार्क लॉन्च किया (यह वास्तविक समय लेनदेन के समवर्ती बड़े ओलाप प्रश्नों का मिश्रण है)। मापा गया प्रदर्शन हमारे पिछले सर्वर की तुलना में लगभग दोगुना धीमा है, जिसमें समान प्रोसेसर हैं लेकिन दो बार कम कोर और दो बार कम स्मृति है।

हम दो सर्वर के बीच मतभेद की जांच की है, और ऐसा लगता है बड़ा एक NUMA वास्तुकला (गैर वर्दी स्मृति acccess) है। प्रत्येक सीपीयू सॉकेट भौतिक रूप से स्मृति के 1/4 के करीब है, लेकिन इसके बाकी हिस्सों से आगे ... हमारे आवेदन को चलाने वाला जेवीएम एक बड़ा वैश्विक ढेर आवंटित करता है, प्रत्येक NUMA नोड पर उस ढेर का एक यादृच्छिक अंश होता है। हमारा विश्लेषण यह है कि मेमोरी एक्सेस पैटर्न बहुत यादृच्छिक है और सीपीयू कोर अक्सर रिमोट मेमोरी तक पहुंचने में समय बर्बाद कर देता है।

हम NUMA सेवर्स पर ActivePivot का लाभ उठाने के बारे में अधिक प्रतिक्रिया की देखभाल कर रहे हैं। क्या हम ActivePivot cubes, या थ्रेड पूल कॉन्फ़िगर कर सकते हैं, हमारे प्रश्नों को बदल सकते हैं, ऑपरेटिंग सिस्टम को कॉन्फ़िगर कर सकते हैं?

Answer 1

पीटर ने NUMA आर्किटेक्चर के प्रदर्शन प्रभाव को कम करने के लिए आज उपलब्ध सामान्य जेवीएम विकल्पों का वर्णन किया। इसे NUMA से कम रखने के लिए जागरूक JVM NUMA नोड्स के संबंध में ढेर को विभाजित करेगा, और जब कोई थ्रेड एक नई वस्तु बनाता है, तो ऑब्जेक्ट को कोर के NUMA नोड में आवंटित किया जाता है जो उस थ्रेड को चलाता है (यदि उसी थ्रेड बाद में उपयोग करता है यह, वस्तु स्थानीय स्मृति में होगी)। साथ ही जब हेप को समझते हुए NUMA को पता चलता है कि JVM नोड्स के बीच बड़े डेटा भाग को स्थानांतरित करता है (और स्टॉप-द-वर्ल्ड इवेंट्स की लंबाई को कम करता है)।

तो किसी भी NUMA हार्डवेयर और किसी भी जावा एप्लिकेशन के लिए -XX: + उपयोग करें ANA विकल्प संभवतः सक्षम होना चाहिए।

लेकिन ActivePivot के लिए जो बहुत मदद नहीं करता है: ActivePivot एक इन-मेमोरी डेटाबेस है। वास्तविक समय अपडेट हैं लेकिन डेटा का बड़ा हिस्सा एप्लिकेशन के जीवन के लिए मुख्य स्मृति में रहता है। JVM विकल्प जो भी हो, डेटा NUMA नोड्स के बीच विभाजित किया जाएगा, और क्वेरी निष्पादित करने वाले थ्रेड यादृच्छिक रूप से स्मृति तक पहुंच जाएंगे। यह जानकर कि ActivePivot क्वेरी इंजन के अधिकांश भाग स्मृति के रूप में तेज़ी से चलते हैं, NUMA प्रभाव विशेष रूप से दिखाई देता है।

तो आप NUMA हार्डवेयर पर अपने ActivePivot समाधान से सबसे अधिक कैसे प्राप्त कर सकते हैं?

एक आसान समाधान है जब ActivePivot एप्लिकेशन केवल संसाधनों के एक अंश का उपयोग करता है (हम पाते हैं कि अक्सर ऐसा होता है जब कई ActivePivot समाधान एक ही सर्वर पर चलते हैं)। उदाहरण के लिए एक ActivePivot समाधान जो 64 में से 16 कोर का उपयोग करता है, और टेराबाइट से 256GB का उपयोग करता है। उस स्थिति में आप JVM प्रक्रिया को स्वयं NUMA नोड पर प्रतिबंधित कर सकते हैं।

लिनक्स पर आप निम्नलिखित विकल्प (http://linux.die.net/man/8/numactl) के साथ JVM लांच उपसर्ग:

numactl --cpunodebind=xxx 

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

Answer 2

आप इस परिणाम आप उम्मीद कर आप एक विशिष्ट सॉकेट करने के लिए एक JVM लॉक करने के लिए taskset का उपयोग करें और प्रभावी रूप से चार मशीनों में सर्वर को तोड़ने के लिए हो सकता है उपज नहीं है, तो -XX:+UseNUMA

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

उपयोग करके देख सकते प्रत्येक एक जेवीएम के साथ।

मैंने देखा है कि अधिक सॉकेट वाली मशीन में उनकी स्मृति (यहां तक ​​कि उनकी स्थानीय मेमोरी) तक धीमी पहुंच है और परिणामस्वरूप आप हमेशा प्रदर्शन लाभ प्राप्त करते हैं।