प्रदर्शन के तहत खान पंखों में इंतजार कर रहे हैं: भाग 2

पिछले लेख की तैयारी में , हमारे अनुप्रयोगों में से एक में पकड़े गए एक जिज्ञासु उदाहरण ने मेरा ध्यान आकर्षित किया। मैंने इसे एक अलग लेख के रूप में डिज़ाइन किया, जिसे आप वर्तमान में पढ़ रहे हैं।

सार अत्यंत सरल है: जब एक रिपोर्ट बनाते हैं और इसे डेटाबेस में लिखते हैं, तो समय-समय पर हमें OOME प्राप्त करना शुरू हो जाता है। त्रुटि तैर रही थी: कुछ डेटा पर इसे लगातार पुन: पेश किया गया था, दूसरों पर इसे कभी भी पुन: पेश नहीं किया गया था।

ऐसे विचलन के अध्ययन में, क्रियाओं का क्रम स्पष्ट है:

• हम पहले से मौजूद सेटिंग्स के साथ एक पृथक वातावरण में एप्लिकेशन को लॉन्च करते हैं, बिना प्रतिष्ठित ध्वज के -XX:+HeapDumpOnOutOfMemoryError , ताकि VM पूर्ण होने पर ढेर का ढेर बना सके
• एक गिरावट के लिए अग्रणी कार्रवाई करते हैं
• परिणामी कलाकारों को लें और इसकी जांच करना शुरू करें

पहले सन्निकटन में, 71 एमबी के दो बराबर टुकड़े स्पष्ट रूप से दिखाई देते हैं, और सबसे बड़ा 6 गुना बड़ा होता है।

कॉल और स्रोत कोड की श्रृंखला के लघु धूम्रपान ने सभी "of" को डॉट करने में मदद की।

 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.base/java.util.Arrays.copyOf(Arrays.java:3745) at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172) at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) at java.base/java.lang.StringBuilder.append(StringBuilder.java:174) at com.p6spy.engine.common.Value.quoteIfNeeded(Value.java:167) at com.p6spy.engine.common.Value.convertToString(Value.java:116) at com.p6spy.engine.common.Value.toString(Value.java:63) at com.p6spy.engine.common.PreparedStatementInformation.getSqlWithValues(PreparedStatementInformation.java:56) at com.p6spy.engine.common.P6LogQuery.logElapsed(P6LogQuery.java:203) at com.p6spy.engine.logging.LoggingEventListener.logElapsed(LoggingEventListener.java:107) at com.p6spy.engine.logging.LoggingEventListener.onAfterAnyExecute(LoggingEventListener.java:44) at com.p6spy.engine.event.SimpleJdbcEventListener.onAfterExecuteUpdate(SimpleJdbcEventListener.java:121) at com.p6spy.engine.event.CompoundJdbcEventListener.onAfterExecuteUpdate(CompoundJdbcEventListener.java:157) at com.p6spy.engine.wrapper.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:100) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3176) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3690) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3290) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2486) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271) at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:104) at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:532) 

परियोजना ने इस तरह के अनुप्रयोगों के लिए सामान्य स्प्रिंग + हाइबरनेट संयोजन का उपयोग किया। कुछ बिंदु पर, डेटाबेस में एप्लिकेशन की बढ़ोतरी का अध्ययन करने के लिए (जो कि ज्यादातर समय यही करता है), डेटा स्रोत को p6spy में लपेटा गया था। यह एक सरल और अत्यंत उपयोगी पुस्तकालय है जो डेटाबेस प्रश्नों को इंटरसेप्ट और लॉग करने के लिए डिज़ाइन किया गया है, साथ ही साथ उनके निष्पादन समय को मापता है। इसकी हाइलाइट एक क्वेरी की रिकॉर्डिंग है जो सभी तर्कों के साथ डेटाबेस में जाती है, अर्थात, लॉग से क्वेरी को तुरंत तर्क के रूपांतरण के साथ उपद्रव के बिना कंसोल में निष्पादित कर सकता है (क्या हाइबरनेट उनके बजाय लिखता है ? ), जो @Convert या का उपयोग करते समय सुविधाजनक है ? प्रकार Date / LocalDate / LocalTime और उनके डेरिवेटिव के क्षेत्रों की उपस्थिति में। IMHO, डेवलपर की अर्थव्यवस्था में एक बेहद उपयोगी चीज खूनी ई।

रिपोर्ट वाली इकाई ऐसी दिखती है:

 @Entity public class ReportEntity { @Id @GeneratedValue private long id; @Lob private byte[] reportContent; } 

बाइट सरणी का उपयोग करना बहुत सुविधाजनक होता है जब किसी इकाई का उपयोग केवल किसी रिपोर्ट को सहेजने / उतारने के लिए किया जाता है, और बॉक्स से बाहर xslx / pdf के साथ काम करने के अधिकांश उपकरण इस रूप में एक पुस्तक / दस्तावेज़ बनाने की क्षमता का समर्थन करते हैं।

और फिर एक भयानक और अप्रत्याशित बात हुई: हाइबरनेट का संयोजन, बाइट्स और p6spy की एक सरणी एक टाइम बम में बदल गई, जो समय के लिए चुपचाप टिक गया था, और जब बहुत अधिक डेटा था, तो विस्फोट हुए।

जैसा कि ऊपर उल्लेख किया गया है, इकाई को बचाते समय, p6spy ने अनुरोध को रोक दिया और इसे सभी तर्कों के साथ लॉग में लिखा। इस मामले में, उनमें से केवल 2 हैं: कुंजी और रिपोर्ट स्वयं। P6spy डेवलपर्स ने फैसला किया कि यदि तर्क बाइट्स की एक सरणी है, तो इसे हेक्साडेसिमल में बदलना अच्छा होगा। संस्करण 3.6.0 में हम उपयोग कर रहे हैं, यह इस तरह किया गया था:

 // class com.p6spy.engine.common.Value private String toHexString(byte[] bytes) { StringBuilder sb = new StringBuilder(); for (byte b : bytes) { int temp = (int) b & 0xFF; sb.append(HEX_CHARS[temp / 16]); sb.append(HEX_CHARS[temp % 16]); } return sb.toString(); } 

 private String toHexString(byte[] bytes) { char[] result = new char[bytes.length * 2]; int idx = 0; for (byte b : bytes) { int temp = (int) b & 0xFF; result[idx++] = HEX_CHARS[temp / 16]; result[idx++] = HEX_CHARS[temp % 16]; } return new String(result); } 

परिणामस्वरूप, लॉग के लिए ऐसा कुछ लिखा गया था

 insert into report_entity (report_content, id) values ('6C6F..........7565', 1); 

आप देखिए, हां? परिस्थितियों के असफल संयोजन की स्थिति में, निम्नलिखित एप्लिकेशन मेमोरी में दिखाई दे सकता है:

• रिपोर्ट, बाइट्स की एक सरणी के रूप में
• चरित्र सरणी बाइट सरणी से ली गई है
• चरित्र सरणी से प्राप्त स्ट्रिंग बाइट सरणी से प्राप्त की
• StringBuilder , जिसमें बाइट सरणी से प्राप्त वर्ण सरणी से प्राप्त स्ट्रिंग की एक प्रति शामिल है
• एक स्ट्रिंग जिसमें StringBuilder अंदर सरणी की एक प्रति शामिल होती है, जिसमें बाइट सरणी से प्राप्त वर्ण सरणी से प्राप्त स्ट्रिंग की एक प्रति शामिल होती है।

इन शर्तों के तहत, एक प्रदर्शन अनुप्रयोग जिसमें 2 कक्षाएं शामिल हैं, जावा 11 पर इकट्ठा होने और लॉन्च होने के बाद (यानी संपीड़ित लाइनों के साथ) 1 जीबी ढेर के साथ, आप केवल 71 एमबी का वजन कर एक रिपोर्ट डाल सकते हैं!

P6spy को दूर किए बिना इस समस्या को हल करने के दो तरीके हैं:

• byte[] को java.sql.Clob (सो-सो सॉल्यूशन के साथ बदलें, क्योंकि डेटा तुरंत लोड नहीं होता है और InputStream / OutputStream साथ उपद्रव OutputStream )
• excludebinary=true फ़ाइल में excludebinary=true संपत्ति जोड़ें (यह पहले से ही परीक्षण एप्लिकेशन में जोड़ा गया है, आपको इसे खोलने की आवश्यकता है)

इस स्थिति में, क्वेरी लॉग हल्का और सुंदर है:

 insert into report_entity (report_content, id) values ('[binary]', 1); 

प्लेबैक गाइड README.MD देखें

निष्कर्ष:

• अपरिवर्तनीयता (विशेष पंक्तियों में) मूल्य की है नरमी से महंगी बहुत प्रिय
• यदि आपके पास संवेदनशील डेटा (दिखावट, पासवर्ड, आदि) के साथ तालिकाओं हैं, तो आप p6spy का उपयोग करते हैं, और लॉग खराब हैं, फिर ... ठीक है, आप समझते हैं
• यदि आपके पास p6spy है और आप सुनिश्चित हैं कि यह स्थायी रूप से / स्थायी रूप से होगा, तो बड़ी संस्थाओं के लिए यह @DynamicInsert / @DynamicUpdate को देखने के लिए समझ में आता है। बिंदु प्रत्येक व्यक्तिगत अद्यतन / सम्मिलित करने के लिए अनुरोध बनाकर लॉग की मात्रा को कम करना है। हां, इन प्रश्नों को हर बार नए सिरे से बनाया जाएगा, लेकिन ऐसे मामलों में जहां एक इकाई 20 में से 1 क्षेत्र को अपडेट करती है, इस तरह का समझौता काम में आ सकता है। अधिक जानकारी के लिए उपरोक्त एनोटेशन के लिए दस्तावेज़ देखें।

आज के लिए बस इतना ही :)