जैसे ही पिछला साल समाप्त हो रहा था, हमारे लंबे समय के ग्राहकों में से एक हमारे पास आया क्योंकि पोस्टजीआईएस ज्यामिति गणनाओं से जुड़े उनके लंबे समय से मौजूद पोस्टग्रेएसक्यूएल प्रश्नों में से एक विशिष्ट मूल्यों के लिए बहुत धीमा था। हमने समस्या पर शोध किया और पता लगाया कि इसे कैसे हल किया जाए; पढ़ते रहिये! समस्या के कारण के रूप में हमने जो पाया वह आपको चौंका देगा!
हमारे ग्राहक द्वारा रिपोर्ट किया गया प्रारंभिक अवलोकन यह था कि ST_DistanceSpheroid से संबंधित एक क्वेरी चला रहा था POINT(33.681953 23.155994) पर दूरी वापस करने के लिए कहने पर लगभग 7 मिलीसेकंड का समय लगा एक विशिष्ट गोलाकार पर, लेकिन अगर उस बिंदु को POINT(33.681953 23.1559941) पर ले जाया गया था (केवल 0.0000001 . का अंतर ) तो इसमें 0.13 मिलीसेकंड का समय लगा। 60 गुना तेज! पृथ्वी पर क्या (एक और गोलाकार!) हो सकता है?
प्रारंभ में, हम अपने परीक्षण वातावरण में धीमेपन को पुन:उत्पन्न करने में असमर्थ थे। हमारे हाथ में, दोनों प्रश्न बिना किसी मंदी के समान रूप से शीघ्रता से प्रदर्शन करेंगे। हमने उपयोग में आने वाले सॉफ़्टवेयर के विशिष्ट संस्करणों को यह सोचकर खोदा कि एक अद्यतन की आवश्यकता हो सकती है। हमने ग्राहक द्वारा रिपोर्ट किए गए संस्करणों का उपयोग किया:PostgreSQL 10.11, PostGIS 2.4.4, libproj 4.93। हम बिना किसी सफलता के उन सटीक संस्करणों में डाउनग्रेड करके गुफा युग में लौट आए।
आखिरकार हमें पता चला कि ग्राहक उबंटू 18.04 का उपयोग कर रहा था, इसलिए हमने कोशिश की कि ... और देखो और देखो, समस्या वहां पुन:उत्पन्न हुई। यह कहने के लिए पर्याप्त है कि हम उस मशीन में क्वेरी को प्रोफाइल करने के अवसर पर कूद पड़े। हमें यह मिला:
Samples: 224K of event 'cpu-clock', Event count (approx.): 56043500000 Children Self Command Shared Object Symbol + 84.86% 0.00% postgres [unknown] [.] 0xffffffffffffffff + 84.59% 0.00% postgres postgres [.] DirectFunctionCall4Coll + 84.58% 0.00% postgres postgis-2.5.so [.] geometry_distance_spheroid + 84.56% 0.00% postgres liblwgeom-2.5.so.0.0.0 [.] lwgeom_distance_spheroid + 84.31% 0.19% postgres libm-2.27.so [.] __sincos + 84.18% 0.00% postgres libm-2.27.so [.] __cos_local (inlined) + 84.13% 0.00% postgres libm-2.27.so [.] cslow2 (inlined) + 84.05% 0.01% postgres libm-2.27.so [.] __mpcos + 83.95% 0.32% postgres libm-2.27.so [.] __c32 + 83.87% 0.00% postgres postgres [.] ExecInterpExpr + 83.75% 0.00% postgres postgres [.] standard_ExecutorRun + 83.75% 0.00% postgres postgres [.] ExecutePlan (inlined) + 83.73% 0.00% postgres postgres [.] ExecProcNode (inlined) + 83.73% 0.00% postgres postgres [.] ExecScan + 83.67% 0.00% postgres postgres [.] ExecProject (inlined) + 83.67% 0.00% postgres postgres [.] ExecEvalExprSwitchContext (inlined) + 83.65% 0.00% postgres postgres [.] _SPI_execute_plan + 83.60% 0.00% postgres postgres [.] _SPI_pquery (inlined) + 83.49% 0.01% postgres plpgsql.so [.] exec_stmts + 83.49% 0.00% postgres plpgsql.so [.] exec_stmt (inlined) + 83.49% 0.00% postgres plpgsql.so [.] exec_stmt_fori (inlined) + 83.48% 0.00% postgres plpgsql.so [.] exec_stmt_perform (inlined) + 83.48% 0.00% postgres plpgsql.so [.] exec_run_select + 83.47% 0.00% postgres postgres [.] SPI_execute_plan_with_paramlist + 81.67% 0.01% postgres liblwgeom-2.5.so.0.0.0 [.] edge_distance_to_point + 81.67% 0.00% postgres liblwgeom-2.5.so.0.0.0 [.] 0x00007f2ce1c2c0e6 + 61.85% 60.82% postgres libm-2.27.so [.] __mul + 54.83% 0.01% postgres liblwgeom-2.5.so.0.0.0 [.] sphere_distance + 27.14% 0.00% postgres plpgsql.so [.] exec_stmt_block + 26.67% 0.01% postgres liblwgeom-2.5.so.0.0.0 [.] geog2cart + 19.24% 0.00% postgres libm-2.27.so [.] ss32 (inlined) + 18.28% 0.00% postgres libm-2.27.so [.] cc32 (inlined) + 12.55% 0.76% postgres libm-2.27.so [.] __sub + 11.46% 11.40% postgres libm-2.27.so [.] sub_magnitudes + 8.15% 4.89% postgres libm-2.27.so [.] __add + 4.94% 0.00% postgres libm-2.27.so [.] add_magnitudes (inlined) + 3.18% 3.16% postgres libm-2.27.so [.] __acr + 2.66% 0.00% postgres libm-2.27.so [.] mcr (inlined) + 1.44% 0.00% postgres liblwgeom-2.5.so.0.0.0 [.] lwgeom_calculate_gbox_geodetic + 1.44% 0.00% postgres liblwgeom-2.5.so.0.0.0 [.] ptarray_calculate_gbox_geodetic
जिबरिश, आप कहते हैं। हालांकि, इस प्रोफ़ाइल के बारे में कुछ बहुत ही उत्सुकता है ... और आपको पहली 26 पंक्तियों को अनदेखा करना होगा और __mul पर ध्यान केंद्रित करना होगा। वहाँ लाइन। देखें कि "स्वयं" समय का 60.82%? (मैं अभी-अभी आपके मन द्वारा बनाए गए अहसास की आवाज सुन सकता हूं)। तो गोलाकार पर कुछ बिंदुओं के लिए इतना समय क्यों लगता है और दूसरों को नहीं? और यह भी कि Ubuntu 18.04 में अधिक समय क्यों लगता है लेकिन अन्य मशीनों में नहीं? PostGIS को अपग्रेड करने से समस्या का समाधान क्यों नहीं होता?
एक बार जब मुझे एहसास हुआ कि क्या स्पष्ट था, तो मुझे जवाब का सुझाव दिया गया था:PostGIS libm पर कॉल करके बहुत सारी त्रिकोणमिति (साइन, कोसाइन, स्पर्शरेखा आदि) करता है। कार्य। ग्लिबैक चैंजों को देखते हुए हमने त्रिकोणमिति कार्यों में कुछ अनुकूलन पाया:कुछ इनपुट के लिए, त्रिकोणमिति गणना शॉर्टकट लेते हैं जिन्हें अन्य इनपुट के लिए नहीं लिया जा सकता है; और ऐसे शॉर्टकट समय के साथ अनुकूलित किए गए हैं। दरअसल, ग्लिबैक ने 2.27 और 2.29 दोनों के लिए साइन/कोसाइन/आदि कार्यों में अनुकूलन का उल्लेख किया है। जाहिरा तौर पर, एक बार इंटेल द्वारा कुछ अनुकूलन थे जो बहुत सटीक परिणाम प्रदान करने वाले थे, लेकिन तब किसी ने महसूस किया कि सटीकता का दावा गलत था, इसलिए ग्लिबैक ने उन अनुकूलन के उपयोग को अक्षम कर दिया; बाद में, उस सामान को एक अलग लेकिन फिर से तेज़ तरीके से फिर से लागू किया गया। या ऐसा ही कुछ — मेरे जैसे बाहरी लोगों के लिए सटीक विवरण का पता लगाना कठिन है।
हमें संदेह था कि ग्लिबक के नए संस्करण में अपग्रेड करने से समस्या ठीक हो जाएगी, बाकी सब कुछ वैसा ही रहेगा। हमारे ग्राहक ने कोशिश की, और वास्तव में यह सच था, और वे खुश थे। हम वास्तव में निश्चित नहीं हैं कि कौन सा इन ग्लिबक परिवर्तनों के लिए जिम्मेदार थे, लेकिन एक बात स्पष्ट है:अप-टू-डेट सॉफ़्टवेयर पर सामान चलाना हमेशा एक अच्छा विचार है।
ध्यान रखें कि खून बहने वाले किनारे नुकीले हों... इसलिए सावधान रहें।
