👩‍👦 🐂 💸 जावा और ऑफ-हेप कैशिंग में साझा मेमोरी का उपयोग करना 🔡 ♦️ ⤵️

पिछले हफ्ते, डाउनलोड सेवा के लिए एक नया समाधान लॉन्च करने के लिए एक सफल प्रयोग किया गया था। एक काफी मामूली सर्वर (2 x Intel Xeon E5620, 64 GB RAM) जो एक मालिकाना जावा एप्लिकेशन चला रहा है, ने आठ टॉमकैट का भार उठाया, जो 3000 एमबी / एस के कुल थ्रूपुट के साथ प्रति सेकंड 70 हजार से अधिक HTTP अनुरोधों की सेवा प्रदान करता है। इस प्रकार, उपयोगकर्ता इमोटिकॉन्स से जुड़े सभी Odnoklassniki ट्रैफ़िक को एकल सर्वर द्वारा संसाधित किया गया था।

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

कैशिंग

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

कैश के लिए आवश्यकताएं इस प्रकार थीं:

64-बिट कुंजियाँ, बाइट सरणी मान: छवि पहचानकर्ता लंबे प्रकार का पूर्णांक है, और डेटा 4 KB के औसत आकार के साथ PNG, GIF या JPG छवि है;
इन-प्रोसेस, इन-मेमोरी: अधिकतम एक्सेस स्पीड के लिए, सारा डेटा प्रोसेस मेमोरी में है;
रैम उपयोग: सभी उपलब्ध रैम को कैश के तहत आवंटित किया गया है;
ऑफ-हीप: जावा हीप में 50 जीबी डेटा रखने से समस्या होगी;
LRU या FIFO: अप्रचलित चाबियों को नए लोगों द्वारा अधिगृहित किया जा सकता है;
कंसीडर: एक सौ सूत्र में कैश का समवर्ती उपयोग;
दृढ़ता: पहले से ही कैश्ड डेटा को संरक्षित करते हुए एप्लिकेशन को फिर से शुरू किया जा सकता है।

जावा से हीप के बाहर मेमोरी एक्सेस करने का सबसे तेज़ तरीका sun.misc.Unsafe क्लास है, क्योंकि इसके getLong/putLong मेथड जेवीएम इंट्रिंसिक्स हैं, getLong/putLong , इनके कॉल को जेआईटी कंपाइलर द्वारा शाब्दिक रूप से एक मशीन निर्देश में बदल दिया जाता है। मेमोरी लॉन्च की गई फ़ाइलों का उपयोग करके एप्लिकेशन लॉन्च के बीच कैश की दृढ़ता हासिल की जाती है। हालांकि, मैं वास्तव में कैश को डिस्क पर वास्तविक फ़ाइल के साथ जोड़ना नहीं चाहता था (डिस्क पर पहुंच से प्रदर्शन गंभीर रूप से प्रभावित होगा), इसलिए, एप्लिकेशन का पता स्थान एक वास्तविक फ़ाइल नहीं दिखाता है, लेकिन एक साझा मेमोरी ऑब्जेक्ट है। इस मामले में, निश्चित रूप से, कैश अब गैर-वाष्पशील नहीं होगा, लेकिन, सबसे महत्वपूर्ण बात, यह आपको डेटा खोए बिना एप्लिकेशन को पुनरारंभ करने की अनुमति देगा।

साझा की गई स्मृति

लिनक्स पर, साझा मेमोरी ऑब्जेक्ट को एक विशेष फ़ाइल सिस्टम के माध्यम से कार्यान्वित किया जाता है, जिसे /dev/shm लगाया जाता है। इसलिए, उदाहरण के लिए, POSIX फ़ंक्शन shm_open("name", ...) open("/dev/shm/name", ...) सिस्टम कॉल open("/dev/shm/name", ...) बराबर है। इस प्रकार, जावा में, हम नियमित फाइलों की तरह लिनक्स साझा मेमोरी के साथ काम कर सकते हैं। निम्न कोड स्निपेट एक साझा मेमोरी ऑब्जेक्ट खोलेगा जिसका नाम इमेज-कैश 1 जीबी है। यदि समान नाम वाली कोई वस्तु मौजूद नहीं है, तो एक नया बनाया जाएगा। यह महत्वपूर्ण है कि आवेदन पूरा होने के बाद, ऑब्जेक्ट मेमोरी में रहेगा और अगली बार शुरू होने पर उपलब्ध होगा।

  RandomAccessFile f = new RandomAccessFile("/dev/shm/image-cache", "rw"); f.setLength(1024*1024*1024L);

अब बनाई गई फ़ाइल ऑब्जेक्ट को प्रक्रिया के पते स्थान पर मैप करना होगा और इस मेमोरी लोकेशन का पता प्राप्त करना होगा।

विधि 1. कानूनी, लेकिन दोषपूर्ण

हम जावा NIO API का उपयोग करते हैं:

  RandomAccessFile f = ... MappedByteBuffer buffer = f.getChannel().map(FileChannel.MapMode.READ_WRITE, 0, f.length());

इस पद्धति का मुख्य दोष यह है कि आप 2 GB से बड़ी फ़ाइलों को प्रदर्शित नहीं कर सकते हैं, जो कि Javadoc मानचित्र विधि में वर्णित है: मैप किए जाने वाले क्षेत्र का आकार; गैर-नकारात्मक होना चाहिए और Integer.MAX_VALUE से अधिक नहीं होना चाहिए।

आप प्राप्त स्मृति के साथ मानक बाइटबफ़र विधियों द्वारा या सीधे असुरक्षित के माध्यम से काम कर सकते हैं, प्रतिबिंब का उपयोग करके मेमोरी पते को बाहर निकाल सकते हैं:

  public static long getByteBufferAddress(ByteBuffer buffer) throws Exception { Field f = Buffer.class.getDeclaredField("address"); f.setAccessible(true); return f.getLong(buffer); }

इस तरह के MpedByteBuffer में सार्वजनिक रूप से सुलभ अनमैप विधि नहीं है, हालांकि GC को कॉल किए बिना मेमोरी को मुक्त करने का एक अर्ध-कानूनी तरीका है:

  ((sun.nio.ch.DirectBuffer) buffer).cleaner().clean();

विधि 2. जावा में पूरी तरह से, लेकिन "गुप्त ज्ञान" का उपयोग करना

Oracle JDK में एक क्लास sun.nio.ch.FileChannelImpl जिसमें निजी तरीके map0 और unmap0 , जो 2 जीबी की सीमा से unmap0 हैं। map0 सीधे "बाढ़" साइट का पता देता है, जो हमारे लिए और भी सुविधाजनक है यदि हम असुरक्षित का उपयोग करते हैं।

  Method map0 = FileChannelImpl.class.getDeclaredMethod( "map0", int.class, long.class, long.class); map0.setAccessible(true); long addr = (Long) map0.invoke(f.getChannel(), 1, 0L, f.length()); Method unmap0 = FileChannelImpl.class.getDeclaredMethod( "unmap0", long.class, long.class); unmap0.setAccessible(true); unmap0.invoke(null, addr, length);

इस तरह का एक तंत्र लिनक्स और विंडोज के तहत दोनों पर काम करेगा। इसका एकमात्र दोष एक विशिष्ट पते का चयन करने में असमर्थता है जहां फ़ाइल "मैप" की जाएगी। इसके लिए आवश्यकता तब उत्पन्न हो सकती है यदि कैश में उसी कैश के अंदर मेमोरी पतों के लिए पूर्ण लिंक होते हैं: यदि फ़ाइल किसी अन्य पते पर प्रदर्शित होती है तो ऐसे लिंक अमान्य हो जाएंगे। दो तरीके हैं: या तो फ़ाइल की शुरुआत के सापेक्ष एक ऑफसेट के रूप में सापेक्ष लिंक स्टोर करें, या जेएनआई या जेएनए के माध्यम से मूल कोड को कॉल करने का सहारा लें। विंडोज पर Linux और MapViewOfFileEx पर mmap सिस्टम कॉल आपको पसंदीदा पते को निर्दिष्ट करने की अनुमति देता है जहां फ़ाइल को "मैप" करना है।

कैशिंग एल्गोरिथ्म

कैश प्रदर्शन के लिए कुंजी, और डाउनलोड सर्वर एक पूरे के रूप में, कैश खोज एल्गोरिदम है, अर्थात। विधि get । हमारी लिपि में put विधि को अक्सर कम कहा जाता है, लेकिन यह बहुत धीमी भी नहीं होनी चाहिए। मैं एक निरंतर निश्चित-आकार के मेमोरी क्षेत्र में तेजी से थ्रेड-सुरक्षित फीफो कैश के लिए हमारे समाधान को पेश करना चाहता हूं।

सभी मेमोरी को एक ही आकार के खंडों में विभाजित किया गया है - हैश टेबल बास्केट, जिसके साथ चाबियाँ समान रूप से वितरित की जाती हैं। अपने सरलतम रूप में

  Segment s = segments[key % segments.length];

कई खंड हो सकते हैं - कई हजार। उनमें से प्रत्येक ReadWriteLock लिए मैप किया गया है। एक ही समय में, या तो एक असीमित संख्या में पाठक या केवल एक लेखक एक सेगमेंट के साथ काम कर सकता है।

एक दिलचस्प विवरण: मानक ReentrantReadWriteLock' के उपयोग से जावा हीप में 2 जीबी का नुकसान हुआ। जैसा कि यह पता चला है, JDK 6 में एक त्रुटि है जो कि ThreadLocal के कार्यान्वयन में ThreadLocal तालिकाओं द्वारा अत्यधिक मेमोरी खपत की ओर जाता है। यद्यपि बग को पहले से ही जेडीके 7 में तय किया गया है, हमारे मामले में हमने वीभत्स Lock को Semaphore बदल दिया। वैसे, यहाँ थोड़ा व्यायाम है:
सेमाफोर का उपयोग करके ReadWriteLock कैसे लागू करें?

तो खंड। इसमें एक इंडेक्स एरिया और एक डेटा एरिया होता है। सूचकांक 256 कुंजियों का एक क्रमबद्ध सरणी है, जिसके तुरंत बाद समान लंबाई के लिए 256 संदर्भों की एक सरणी होती है। लिंक बाइट्स में डेटा ब्लॉक की शुरुआत और बाइट में इस ब्लॉक की लंबाई के भीतर ऑफसेट सेट करता है।

डेटा ब्लॉक, अर्थात्, वास्तविक चित्र स्वयं, इष्टतम प्रतिलिपि के लिए आठ-बाइट सीमा पर संरेखित होते हैं। सेगमेंट इसमें कुंजी की संख्या और put विधि के लिए अगले डेटा ब्लॉक का पता भी संग्रहीत करता है। एक परिपत्र बफर के सिद्धांत के अनुसार एक के बाद एक नए ब्लॉक लिखे जाते हैं। जैसे ही एक सेगमेंट में जगह निकलती है, पहले के डेटा के शीर्ष पर सेगमेंट की शुरुआत से एक रिकॉर्डिंग बनाई जाती है।

विधि प्राप्त करने का एल्गोरिथ्म बहुत तेज़ और सरल है:

कुंजी हैश उस खंड की गणना करता है जिसमें खोज की जाएगी;
सूचकांक क्षेत्र में, एक कुंजी के लिए एक द्विआधारी खोज खोजता है;
यदि कुंजी पाई जाती है, तो जिस ऑफसेट पर डेटा स्थित है, वह लिंक के सरणी से प्राप्त होता है।

एक कारण के लिए कुंजी एक चयनित क्षेत्र में एक पंक्ति में लिखी जाती है: यह बाइनरी कुंजी खोज की अधिकतम गति प्रदान करते हुए, सूचकांक को प्रोसेसर कैश में रखने में मदद करता है।

पुट विधि भी सरल है:

एक खंड की गणना करने के लिए एक कुंजी हैश का उपयोग किया जाता है;
अगले डेटा ब्लॉक का पता पढ़ा जाता है और अगले ब्लॉक के पते की गणना रिकॉर्ड की गई वस्तु के आकार को खाते के संरेखण में जोड़कर की जाती है;
यदि खंड भरा हुआ है, तो लिंक्स की सरणी के माध्यम से एक रेखीय खोज उस सूचकांक से कुंजियों को ढूंढती है और हटाती है जिनके डेटा को अगले ब्लॉक द्वारा अधिलेखित किया जाएगा;
बाइट सरणी द्वारा दर्शाया गया मान डेटा क्षेत्र में कॉपी किया जाता है;
बाइनरी सर्च इंडेक्स में वह जगह है जहां नई कुंजी डाली जाती है।

काम की गति

बेशक, हमारे अलावा, जावा हीप के बाहर कैशिंग डेटा के लिए कई अन्य समाधान हैं, दोनों मुफ्त और भुगतान किए गए हैं। सबसे प्रसिद्ध हैं टेराकोटा इहचे (इन-मेमोरी ऑफ-हीप स्टोरेज) और अपाचे जावा कैशिंग सिस्टम । यह उनके साथ था कि हमने अपने स्वयं के एल्गोरिथ्म की तुलना की। प्रयोग लिनक्स JDK 7u4 64-बिट पर किए गए थे और इसमें तीन परिदृश्य शामिल थे:

पुट: 0 से 8 केबी तक प्रत्येक आकार में 1 मिलियन मान लिखें;
प्राप्त करें: 1 मिलियन मूल्यों के लिए कुंजी द्वारा खोजें;
90% get + 10% put: व्यावहारिक कैश उपयोग परिदृश्य के समान अनुपात में संयोजन / पुट प्राप्त करें।

माप परिणाम तालिका में दिखाए गए हैं। जैसा कि आप देख सकते हैं, वर्णित एल्गोरिथ्म के प्रदर्शन में Ehcache और JCS दोनों कई बार अवर हैं।

हालांकि, यह ध्यान देने योग्य है कि वर्णित एल्गोरिथ्म, छवि कैशिंग की समस्या को हल करने के लिए डिज़ाइन किया गया है, कई अन्य परिदृश्यों को कवर नहीं करता है। उदाहरण के लिए, ऑपरेशन को remove और replace , हालांकि उन्हें आसानी से लागू किया जा सकता है, पिछले मूल्यों द्वारा कब्जा की गई स्मृति को मुक्त नहीं करेगा।

कहाँ देखना है?

जीथब पर साझा मेमोरी का उपयोग करके कैशिंग एल्गोरिथ्म के स्रोत:
https://github.com/odnoklassniki/shared-memory-cache

सुनने के लिए कहाँ?

25 जुलाई, 2012 को सेंट पीटर्सबर्ग में आयोजित JUG.RU की बैठक में, अपंगिन जावा में एक अत्यधिक लोड किए गए सर्वर को विकसित करने में अपना अनुभव साझा करेंगे, विशिष्ट समस्याओं और अपरंपरागत तकनीकों के बारे में बात करेंगे।

आगे क्या है?

निम्नलिखित लेखों में मैं आपको एक आरपीसी सर्वर लिखने का तरीका बताऊंगा जो प्रति सेकंड हजारों अनुरोधों को संसाधित करता है, साथ ही एक वैकल्पिक क्रमांकन विधि जो प्रदर्शन और ट्रैफ़िक वॉल्यूम के मामले में मानक जावा तंत्रों की तुलना में कई गुना तेज है। हमारे साथ रहो!

जावा और ऑफ-हेप कैशिंग में साझा मेमोरी का उपयोग करना