Plots2: स्मृति मुद्दे (रिसाव?) जांच

@icarito की टिप्पणी पर ध्यान देना:

मुझे आश्चर्य है कि जेवरन क्योंकि मैंने कम प्रक्रियाओं का उपयोग करने के लिए docker-compose-production.yml संपादित किया था (इसके लिए पीआर नहीं बनाया)। तो यह हो सकता है कि हमने इसे इस तरह फिट किया हो।

और यह ग्राफ:

हम बहुत सी एसएमटीपी परीक्षण त्रुटियां भी देख रहे हैं:

लिंक: | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZyu

हाँ लोड भी बहुत अधिक है। htop और विशेष रूप से iotop ऐसा प्रतीत होता है कि mailman काफी सक्रिय है। यह निश्चित रूप से अपराधी है! २२ मई से पहले हम इसे दिन में कुछ बार चलाते थे - अगर हम इसे हर कुछ मिनट में चला सकते हैं या तो (हर सेकेंड नहीं!) - यह ठीक रहेगा!

I, [2019-05-07T23:56:44.702410 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-08T21:33:03.762360 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T07:47:27.518491 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T08:18:47.825703 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T08:14:53.010705 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T21:45:50.739207 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-11T17:38:51.647335 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-13T03:33:15.682877 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:51:40.603184 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:53:20.857041 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:55:00.356772 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:56:40.487219 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-15T01:43:42.908744 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-16T10:13:45.703985 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-18T12:57:16.194957 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:27.019569 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:55.827419 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:18.722700 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:41.709075 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:00.124271 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:17.146210 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:33.745494 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:51.387282 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:09.145006 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:31.266559 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:03.176998 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:26.991989 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:54.074275 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:13.905343 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:37.736641 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:57.357057 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:15.522535 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:34.343241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:51.964241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:10.016964 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:42.822692 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:59.826809 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:16.178517 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:35.871196 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:59.731422 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:16.353160 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:33.608591 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:50.037296 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:06.912680 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:32.287362 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:59.201948 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:18.739067 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:42.144910 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:03.495556 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:20.493712 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:37.089192 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:53.921571 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:02:14.509227 #1]  INFO -- : Mailman v0.7.0 started

लॉग इनमें से चक्रों से भरा है, कोई त्रुटि नहीं:

I, [2019-06-02T02:35:26.270644 #1]  INFO -- : Mailman v0.7.0 started
I, [2019-06-02T02:35:26.270851 #1]  INFO -- : Rails root found in ., requiring environment...
I, [2019-06-02T02:35:56.930267 #1]  INFO -- : POP3 receiver enabled ([email protected]@pop.gmail.com).
I, [2019-06-02T02:35:56.938850 #1]  INFO -- : Polling enabled. Checking every 5 seconds.

ऐसा लगता है कि डाकिया दुर्घटनाग्रस्त हो रहा है और तुरंत प्रतिक्रिया दी जा रही है!

icarito@rs-plots2:/srv/plots_container/plots2$ docker ps
CONTAINER ID        IMAGE                COMMANDCREATED             STATUS              PORTS NAMES
8d13c675568e        containers_mailman   "script/mailman_serv…"4 days ago          Up 14 seconds containers_mailman_1
f423dec91ebe        containers_web       "/bin/bash -c 'sleep…"4 days ago          Up 4 days           127.0.0.1:4001->4001/tcp containers_web_1
24f7b43efebc        containers_sidekiq   "bundle exec sidekiq…"4 days ago          Up 4 days containers_sidekiq_1
070511ab43d1        redis:latest         "docker-entrypoint.s…"4 days ago          Up 4 days           6379/tcp containers_redis_1
6ea8f0498b2c        mariadb:10.2         "docker-entrypoint.s…"4 days ago          Up 3 days           3306/tcp containers_db_1

मैंने प्रदर्शन पर प्रभाव की निगरानी के लिए इस कंटेनर को आज रात के लिए बंद करने का निर्णय लिया है।

मुझे लगता है कि हम यह भी देख सकते हैं कि इस कोड प्रकाशन के लिए आने वाले दिनों में कौन से रत्न अद्यतन विलय किए गए थे। धन्यवाद!

मेलमैन के बारे में यह बहुत अजीब है, मैं कॉन्फ़िगरेशन को देखूंगा लेकिन मुझे दर में कोई बदलाव याद नहीं है।

अरे तुम जानते हो क्या? हमने इसे 3 बार पुनः प्रयास करने के लिए सेट किया है। शायद ये अब ओवरलैप हो रहे हैं? यह कम से कम प्रयासों की दर में वृद्धि कर सकता था क्योंकि यह प्रत्येक निर्धारित रन के लिए 3 बार पुन: प्रयास करता है।

https://github.com/publiclab/plots2/blob/faf66c0b15473add33c10c47d57a6e7cc46ea669/script/mailman_server#L32

ओके ने इसे 20 सेकंड के लिए संशोधित किया, जिसका मतलब है कि हर 5 सेकंड में अधिकतम पुन: प्रयास करना चाहिए -

https://github.com/publiclab/plots2/commit/a40ea5650f2ce9ec80ee2324cea2d8c9bd98e382

यह वही दर होगी जो पहले हमने दोबारा प्रयास जोड़े थे।

ठीक है, अब कुछ घंटों के बाद विश्लेषण पर काम कर रहा हूँ:

https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559574420/6h/endpoints

कुल मिलाकर अच्छा लग रहा है। लेकिन, करीब से देखने पर, यह लोड समय में तेजी से बढ़ रहा है:

बाद के हिस्से की तुलना करना जहां यह बैक अप जाना शुरू कर रहा है:

रीबूट के ठीक बाद पहले के लिए:

और फिर कुछ हफ़्ते पहले हमारी सारी परेशानी से पहले:

फिर अंत में जब हमने २२-२३ मई को मुद्दों को देखना शुरू किया:

कुल मिलाकर यह निर्णायक नहीं है।

संसाधन:

• मेमोरी-लीकी रत्नों और संस्करणों की एक सूची: https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

इसके बारे में कठिन चीजों में से एक यह है कि यह ठीक वही है जहां ये दोनों काम हुए हैं:

1. प्रोफाइल पर कैशिंग अक्षम करना (जिसे हमने बाद में वापस कर दिया): https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. कंटेनर निर्माण प्रक्रिया परिवर्तन: https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

मुझे लगता है कि यह https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 में retry 3 times कोड को जोड़ने से संबंधित है, जिसे मैंने आज ट्विक करने का प्रयास किया। लेकिन वास्तव में लोड समय अभी भी धीरे-धीरे बढ़ रहा है।

इसका मतलब यह हो सकता है कि ए) कुछ और इसे चला रहा है, या बी) "बचाव/पुनः प्रयास" चक्र स्वयं स्मृति रिसाव निर्माण का कारण बन सकता है?

क्या मैं पूरी तरह से बचाव/पुन: प्रयास कोड पर टिप्पणी करूं?

हो सकता है कि MySQL को लेने की प्रतीक्षा में फांसी वास्तव में धागे ले रही हो?

मैं यह कोशिश करूँगा। साइट लगभग अनुत्तरदायी है।

मैंने यहां retry हटा दिया: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

परिनियोजन... इसमें कुछ समय लगेगा।

हम्म यह वास्तव में हल नहीं लगता... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

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

ठीक है, रातों-रात यह चरम पर था और थोड़ा नीचे चला गया। लेकिन हमारे समस्याग्रस्त अभी भी काफी ऊंचे हैं, लगभग 20 सेकंड में चोटियों के साथ:

आँकड़े श्रेणी कॉल में 40+ सेकंड तक का समय लग रहा है!

वे हमेशा के लिए कैश पीढ़ी पर भी ले रहे हैं:

क्या हम कैश पढ़ने/लिखने में कोई समस्या देख रहे हैं?

@icarito पढ़ने/लिखने io या कैश पीढ़ी पर कुछ पर कोई समस्या हो सकती है? मुझे यकीन नहीं है कि सभी डेटा को कैश में पैक करने में इतना समय क्यों लगेगा।

टपका हुआ रत्न -- जांचें कि क्या हम ठीक हैं

• [x] सेल्युलाइड > ०.१६.०, < ०.१७.२
• [एक्स] सीएसएसपूल <४.०.३
• [x] अंगूर <०.२.५
• [एक्स] ओज <२.१२.४
• [एक्स] रेड कार्पेट <३.३.३
• [एक्स] रेडिस = ३.३.०
• [एक्स] साइडकीक < ३.५.१
• [x] साइडकीक-सांख्यिकी
• [एक्स] थेरूबीरेसर <0.12.2
• [एक्स] जिप्रुबी <= ०.३.६

किसी भी मामले में गैर-छिड़काव लेकिन स्मृति समस्याएं:

• [एक्स] सक्रिय व्यवस्थापक
• [एक्स] एक्सएलएसएक्स
• [x] विलंबित_नौकरी >= ४.०६
• [एक्स] libxml-रूबी <२.९.० नोकोगिरी आरसी३ के साथ
• [x] newrelic_rpm >= 3.9.4, <= 3.9.7
• [x] अगली कड़ी >= २.१२.०
• [एक्स] स्टॉम्प <= 1.3.5

मैं अभी भी stats_controller#range लिए इस विशाल कैश पीढ़ी के समय को देख रहा हूं और सोच रहा हूं कि क्या हमें कैश को संग्रहीत करने की आवश्यकता है। ऐसा लगता है कि डिफ़ॉल्ट फ़ाइल संग्रहण है (और मैंने जाँच की, हमारे पास कैश फ़ाइलें हैं /plots2/tmp/cache/ । क्या इन-मेमोरी कैशिंग या memcached पर स्विच करके हमें बिल्कुल भी मदद मिलेगी, जो दोनों हैं स्पष्ट रूप से बहुत सरल परिवर्तन?

https://guides.rubyonrails.org/v3.2/caching_with_rails.html#activesupport -cache-memorystore

https://www.skylight.io/support/performance-tips को भी देख रहे हैं

मैं अब ईमेल कॉन्फ़िगरेशन को देखूंगा लेकिन अगर यह कुछ भी नहीं देता है तो मैं इसे मर्ज कर दूंगा, begin/rescue लूप को बंद कर दूंगा: #5840

ठीक है https://github.com/publiclab/plots2/pull/5841 के लिए हमारा अगला कदम मेलमैन के नीचे जाने पर निगरानी रणनीति विकसित करना है।

नए ईमेल क्रेडेंशियल के साथ परिनियोजन, और begin/rescue निष्कासन। हालांकि, मुझे लगता है कि स्मृति रिसाव हल

नवीनतम त्रुटि:

mailman_1 | /app/app/models/comment.rb:265:in add_comment': undefined methodbody' for nil:NilClass (NoMethodError) mailman_1 | from /app/app/models/comment.rb:218:in receive_mail' mailman_1 | from script/mailman_server:31:inblock (2 levels) in <main>' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:in instance_exec' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:inroute' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:23:in block in process' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:33:inblock in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:38:in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:22:inprocess' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:43:in block in get_messages' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:ineach' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:in each_mail' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:42:inget_messages' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:133:in block in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:inloop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:83:inrun' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:11:in run' mailman_1 | from script/mailman_server:22:in<main>'

वह यहाँ है:

https://github.com/publiclab/plots2/blob/e62bb49e30df79a9ddca5300579b80ff0903e3f4/app/models/comment.rb#L265

इसे ठीक किया! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

यूजी, अंत में टिप्पणी प्रकाशित कर रहा है। आरबी फिक्स ....

ठीक है, हम यह देखने के लिए प्रतीक्षा कर रहे हैं कि क्या ईमेल कतार फ़्लश हो जाती है और हम कुछ सामान्य स्थिति में लौटते हैं ...

मैंने परीक्षण करने के लिए https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii पर एक टिप्पणी छोड़ी

हाय @jywarren मैं इसे दूसरा रूप दे रहा हूं और एक सिद्धांत है।

पिछले ३ महीनों के लिए RAM के उपयोग के लिए सबसे पहले यहाँ एक ग्राफ़ है:

इस ग्राफ से स्पष्ट है कि हम पिछले तीन महीनों से स्मृति खपत में वृद्धि कर रहे हैं!

मैं पूरे एक साल पीछे गया:

जाहिर है, 2019 में, हमारे एप्लिकेशन ने अपनी मेमोरी आवश्यकताओं को काफी बढ़ा दिया है।

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

स्मृति वृद्धि अच्छी तरह से हमारी कुछ तालिकाओं का आकार हो सकती है ( rusers मैं देख रहा हूँ)। इसका संबंध #5524 से हो सकता है।

हमें कुछ अनुकूलन लागू करने होंगे, डेटाबेस को किसी भिन्न होस्ट में माइग्रेट करना होगा, या अधिक RAM जोड़ना होगा।

स्पैम उपयोगकर्ताओं के डेटाबेस को काटने की भी अत्यधिक अनुशंसा की जाती है।

मैं अभी भी ऐप/साइट वृद्धि के कारण मेमोरी थकावट की ओर झुका रहा हूं, जो डिस्क पर स्वैप मेमोरी "थ्रैशिंग" के कारण उच्च आईओ लोड कर रहा है।
मैंने वेब कंटेनर से हमारे passenger-memory-stats की जांच की है और मुझे लगता है कि हम प्रक्रिया पूल को और कम कर सकते हैं:

मैं इसे प्रदर्शन में सुधार के लिए पहले कदम के रूप में आजमाऊंगा।

मैंने पाया कि फरवरी 2018 में हमने गणना की थी कि हम 11 प्रक्रियाएँ चला सकते हैं (क्योंकि हमारे ऐप को चलने में 500mb का समय लगा)।
सूत्र है:

max_app_processes = (TOTAL_RAM * 0.75) / RAM_PER_PROCESS
                  = 6000Mb / 750Mb
                  = 8

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

उपरोक्त दोनों छवियों से मुझे पता चलता है कि हम अभी भी एक प्रक्रिया को छोड़ सकते हैं, खासकर अगर यह प्रतिक्रियाओं को तेज कर देगा।

4 प्रक्रिया पूल आकार में जा रहा है।

पहला अनुकूलन किया गया।
पहले 30 मिनट का वादा!

ओह!

शनिवार, जून ८, २०१९, ८:४७ अपराह्न को सेबस्टियन सिल्वा नोटिफिकेशन @github.com
लिखा था:

पहला अनुकूलन किया गया।
पहले 30 मिनट का वादा!
[छवि: छवि]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3WTUL52HS4DFVREXG43VMVHQ26PZLGONMV
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

ठीक है, तो शमन सूची होगी:

• [x] प्रक्रिया पूल को कम करें
• [ ] डीबी को गूगल क्लाउड डीबी समाधान में ले जाएं
• [ ] rusers - शायद https://github.com/publiclab/plots2/issues/5450 में काम पर निर्माण
• [ ] memcached स्विच करें

अरे @jywarren और @icarito ,

सबसे पहले, (और मैं इसे बिना मजाक के कहता हूं): यह धागा वास्तव में काफी अच्छा पढ़ा गया। इसमें सभी तत्व थे, एक रहस्य, एक शिकार, मृत अंत, करीबी कॉल, आदि।

वैसे भी।

#५४५० और #५५२४ के सापेक्ष rusers तालिका के संबंध में, ४/२६/१३ - १/१/१४ के बीच हुई rusers में एक _ विशाल _ समूह है।

4/26/2013: 1366934400
१/१/२०१४: १३८८५३४४००
यूआईडी रेंज: 59627 - 420114
उपयोगकर्ता: 360466

क्या आप उस समूह के एक हिस्से पर #5450 में वर्णित परीक्षण परीक्षण की पहली क्वेरी आज़माना चाहते हैं?

जिन उपयोगकर्ताओं ने कोई नोड, टिप्पणी, पसंद या सदस्यता पोस्ट नहीं की है और कभी लॉग इन नहीं किया है

जैसा कि आपने कहा, यह एक आसान प्रश्न होगा क्योंकि कभी भी लॉग इन न करने से इससे पहले आने वाले सभी मानदंड शामिल हो जाएंगे।

दूसरे ईमेल में आपके प्रस्तावित पिछले 6 महीनों के बराबर हिस्से के आकार के संदर्भ के लिए: पिछले महीने में हमने ~250 पहली बार पोस्टिंग को स्पैम के रूप में चिह्नित किया है। तो, मान लें कि पिछले ६ महीनों में हमारे पास स्पैम के कारण ~१५०० प्रतिबंधित उपयोगकर्ता थे।

ओह, और मुझे लगता है कि यह एक अच्छी बात लाता है। यदि आप अपने आप को स्पैम उपयोगकर्ताओं से मुक्त करना चाहते हैं तो आप केवल उन सभी उपयोगकर्ताओं को ढूंढ सकते हैं जिनके पास स्पैम के रूप में चिह्नित सामग्री है और फिर उन्हें पोस्ट करने वाले उपयोगकर्ताओं को हटा दें।

जैसा कि एक मुद्दे में संक्षेप में बताया गया था, यह अच्छा हो सकता है कि पहली बार सामग्री वाले उपयोगकर्ताओं को स्पैम के रूप में चिह्नित किया गया हो, डेटाबेस से तुरंत हटा दिया गया हो।

हाय @skilfullycurled आपके इनपुट के लिए धन्यवाद! तो अधिकांश उपयोगकर्ता 2013-2014 से हैं: इसका मतलब यह है कि यह रैम के उपयोग को कम करने में मदद कर सकता है, वास्तव में, हमारी प्रमुख तालिकाएं सत्र और इंप्रेशन हैं ।

rsessions 30GB से अधिक है।
@jywarren और @skilfullycurled - इस तालिका का उपयोग करके इसे कम करने और/या प्रश्नों को अनुकूलित करने की रणनीति के साथ आना बहुत अच्छा होगा!

इसके अलावा, मुझे लगता है कि इस मुद्दे के लिए memcached एक अच्छा फिट नहीं है क्योंकि इसे अधिक रैम का उपभोग करना चाहिए कम नहीं ..

हालांकि कोई memcached के स्मृति उपयोग को सीमित कर सकता है, फिर भी मैं इसे आजमाउंगा!

नहीं, उपरोक्त दस्तावेज़ों से:

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

ऐसा लगता है कि _rsessions_ को हल करना बहुत कठिन नहीं है:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren चलो यह करते हैं!

@icarito, मैं नहीं यकीन है कि यह कभी किया गया था हूँ, लेकिन मैं 2016 में डेटाबेस के लिए उपयोग किया था और मैं हर किसी को सूचित किया है कि उपयोगकर्ता सत्र अप और अधिक स्थान की तो डेटाबेस की वास्तविक बाकी अब तक लिया। मुझे बताया गया था कि उन्हें फ्लश कर दिया जाएगा, इसलिए या तो वे नहीं थे या समस्या बनी हुई है कि डेटाबेस सत्र को जारी रखता है।

एक एहसास देने के लिए, 2016 तक, प्लॉट डेटाबेस _compressed_ bz2 के रूप में 1.9GB था (वास्तविक आकार के लिए डिकंप्रेस करने के लिए अभी कोई समय नहीं है), _uncompressed_, सत्रों को हटाकर, यह 518 एमबी था

धन्यवाद @skilfullycurled !!! मुझे लगता है कि मुझे 2016 से आपका इनपुट याद है, मुझे नहीं पता कि हम इसे कैसे फ्लश करने से चूक गए, लेकिन आज हमारे डेटाबेस डंप 8GB से अधिक संकुचित हैं, संभवतः ज्यादातर सत्र।
मैं @jywarren से पुष्टि की प्रतीक्षा

उन सत्रों से हटाएं जहां <DATE_SUB (अब (), अंतराल 1 दिन) पर अपडेट किया गया था;

मैं बहुत उत्सुक हो गया, असम्पीडित फ़ाइल 6.8GB है, इसलिए 518MB से कम है जो हमें 6.3GB पर रखता है। 😆

rsessions वास्तव में मेरा पसंदीदा डेटासेट है जो मेरे पास है। यह पूरी तरह से उपयोग-_less_ है, लेकिन मुझे बस इतना पसंद है कि यह उतना बड़ा है जितना मेरे पास मौजूद डेटासेट से बड़ा नहीं है-_फुल_! अगर किसी के पास इसके साथ क्या करना है इसके बारे में कोई विचार है तो मुझे बताएं!

icarito ( @icarito :matrix.org) इसे यहाँ से प्राप्त किया https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito :matrix.org) इसे हर उस सत्र से लॉग आउट करना चाहिए जो 'पिछले दिन या सप्ताह में सक्रिय नहीं था - हम इसे बदल सकते हैं

यहां सिर्फ नोट्स ले रहे हैं। बहुत अच्छा लगता है।

अस्थिर लगता है एक लंबा समय लगता है... कोशिश कर सकते हैं

हटाएं ... से ... कहां ... सीमा x

और उत्पादन में जितनी बार आवश्यकता हो उतनी बार निष्पादित करें।

7 घंटे के बाद भी यह मंचन में जारी है। स्पष्ट रूप से ऐसा नहीं है कि हम इसे एक ही बैच में उत्पादन में कैसे करना चाहते हैं। एक और बात यह है कि हटाने के बाद, तालिका खंडित हो जाएगी और फ़ाइल का आकार rsessions तालिका के लिए कम नहीं होगा। सर्वर संसाधनों को जारी करने के लिए तालिका को डंप और पुन: निर्मित करने की आवश्यकता है।

ऐसा करने की मेरी योजना निम्नलिखित है:

• [ ] where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY) साथ मैसकल डंप सत्र तालिका
• [ ] सत्र तालिका का नाम बदलें
• [] डंप की गई तालिका से नए सत्र तालिका में स्वच्छ डेटा लोड करें
• [ ] पुराने सत्र तालिका को छोड़ें

मैं इसे stable स्टेजिंग इंस्टेंस में आज़माउंगा।

ठीक है भयानक सेबस्टियन और मुझे लगता है कि यह सकारात्मक हो सकता है
इसके बाद हमारे डीबी प्रदर्शन में अपेक्षित सुधारों के लिए निहितार्थ
शमन पूरा हो गया है, अगर इस तालिका को फ्लश करने में भी इतना समय लग सकता है ...

सोम को, जून १७, २०१९, ९:५० अपराह्न सेबस्टियन सिल्वा नोटिफिकेशन @github.com
लिखा था:

मैं इसे स्थिर स्टेजिंग इंस्टेंस में आज़माउंगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVVBW63LNMV29TEH2K
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

@cesswairimu में लाना ताकि @icarito समाप्त होने पर वह फिर से स्थिर पर अपनी क्वेरी का प्रयास कर सके। यह हमें बताना चाहिए कि क्या #5917 के मुद्दे केवल #5490 (जो तय है) से संबंधित हैं या यदि वे #5524 से भी संबंधित हैं।

unstable अभी भी हटा रहा है...

स्थिर उदाहरण के मंचन में परीक्षण करते समय कुछ नोट्स यहाँ छोड़ रहे हैं।

• [x] मैसकल डंप सत्र तालिका जहां अपडेट_एट> DATE_SUB (अब (), इंटरवल 7 दिन)
  
  
  
  • आदेश: root<strong i="13">@tycho</strong>:/srv/plots_staging/plots2# time docker-compose exec db bash -c "mysqldump --databases plots --tables rsessions --where='updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)' -h 127.0.0.1 -u plots --password=plots" > /tmp/rsessions.sql
  
  
  • समय: १३ सेकंड
  
  
• [x] सत्र तालिका का नाम बदलें
  
  
  
  • सिंटैक्स: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • संतरी रिपोर्ट Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT सत्र .* FROM सत्र WHER...
  
  
  • होम पेज 500 . चला जाता है
  
  
• [x] डंप किए गए टेबल से नए सत्र तालिका में स्वच्छ डेटा लोड करें
  
  
  
  • सिंटैक्स: root<strong i="38">@tycho</strong>:/srv/plots_staging/plots2# time cat /tmp/rsessions.sql | docker-comp ose exec -T db bash -c "mysql -h 127.0.0.1 -u plots plots --password=plots"
  
  
  • समय: 7 s
  
  
  • नई सत्र तालिका फ़ाइल बनाता है (मंचन के लिए 13Mb!)
  
  
  • मुखपृष्ठ को पुनर्स्थापित करता है
  
  
• [x] पुराने सत्र तालिका छोड़ें:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

लॉगिन करने के लिए https://stable.publiclab.org का परीक्षण किया गया।

मैं इसे प्रोडक्शन में आज़माने के लिए तैयार हूँ!

unstable अभी भी हटा रहा है...

लाइव प्रोडक्शन डेटाबेस पर ऑपरेशन करना:

• [x] मैसकल डंप सत्र तालिका जहां अपडेट_एट> DATE_SUB (अब (), इंटरवल 7 दिन)
  
  
  
  • समय: 48 सेकंड
  
  
  • डंप आकार: 143Mb
  
  
• [x] सत्र तालिका का नाम बदलें
  
  
  
  • समय: ११ सेकंड
  
  
  • होम पेज ~ 6am UTC . पर 15 मिनट के लिए डाउन था
  
  
• [x] डंप किए गए टेबल से नए सत्र तालिका में स्वच्छ डेटा लोड करें
  
  
  
  • नई सत्र तालिका फ़ाइल बनाता है (220Mb)
  
  
  • मुखपृष्ठ को पुनर्स्थापित करता है
  
  
• [x] पुराने सत्र तालिका छोड़ें:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • मुक्त ~ 29 जीबी।
  
  

परीक्षण किया गया https://publiclab.org - सत्र बरकरार रखा गया था!
टाडा:

शमन किया! उम्मीद है कि यह हमें मुक्त कर देगा!

मैं इसे आज रात के लिए छोड़ दूँगा, साइट मुझे तेज़ लग रही है... :stuck_out_tongue_closed_eyes: उम्मीद है कि यही है!

ठीक है, तो शमन सूची होगी:

• [x] प्रक्रिया पूल को कम करें

• [ ] डीबी को गूगल क्लाउड डीबी समाधान में ले जाएं

• [x] rsessions

• [ ] memcached to पर स्विच करें

हम्म, आज सुबह बहुत तेज़ थी, लेकिन कुल मिलाकर मुझे कोई बड़ा अंतर नहीं दिख रहा है! 😞

नूओउउउउउओउ! खैर, केवल एक और स्पष्टीकरण है और वह है भूत। मैं एक और मुद्दा खोलूंगा और एक ओझा या घोस्टबस्टर्स रत्न ढूंढूंगा।

मुझे लगता है कि वास्तव में I/O उपयोग में सुधार हुआ है क्योंकि 30GB तालिका का उपयोग करना भारी है - यदि आप बारीकी से देखते हैं तो चोटियां Statscontroller से संबंधित लगती हैं ... शायद हम आंकड़े स्टेजिंग पर काम कर सकते हैं? मैं इसे प्रतिलिपि उत्पादन डेटाबेस नियमित रूप से साप्ताहिक कह सकता हूं?

अरे @icarito , मैं सोच रहा था कि क्या आप मेरे लिए कुछ "शैक्षिक" प्रश्नों का उत्तर दे सकते हैं:

यदि आप बारीकी से देखें तो चोटियाँ Statscontroller से संबंधित लगती हैं ...

यह क्यों होगा? कैशिंग के कारण? मैं केवल तीन लोगों के बारे में सोच सकता हूं जो इसका इस्तेमाल कर रहे होंगे और मैं उनमें से एक हूं और मैं नहीं हूं।

शायद हम आंकड़े मंचन पर काम कर सकते हैं?

मैं सुन रहा हूँ ... एर ... आप को हाल ही में "स्टेजिंग" शब्द का उपयोग करते हुए देखकर। वह क्या है और यह साइट/वर्कफ़्लो में कैसे चलता है? यदि यह डॉक्स का एक हिस्सा है, तो मुझे बताएं कि कौन सा है और मैं इसे पहले समझने की कोशिश करूंगा।

मैं इसे प्रतिलिपि उत्पादन डेटाबेस नियमित रूप से साप्ताहिक कह सकता हूं?

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

यह पढ़ने के लिए वास्तव में एक शानदार धागा था। हाँ, यह एक अच्छा विचार है कि आंकड़े मंच पर हों और साप्ताहिक प्रतिलिपि बनाना भी ठीक है: +1:
मैंने भविष्य में आँकड़ों को एक स्क्रिप्ट बनाने के बारे में सोचा है जो एक sql दृश्य बनाता है और इसे हटा दिया जाता है और एक नौकरी द्वारा दैनिक / या साप्ताहिक रूप से फिर से बनाया जाता है और शायद यह मंच में भी रह सकता है। इस पर आपके विचार सुनना चाहेंगे और यदि यह किसी भी तरह से स्मृति रिसाव में मदद कर सकता है।

अरे @icarito , क्या हम सर्वर की रैम बढ़ा सकते हैं? हो सकता है कि जब तक हम अपनी क्वेरी प्रतिक्रिया दर में सुधार नहीं करते, तब तक वेबसाइट को गति देने में मदद मिलेगी?

धन्यवाद!

आपके उत्तरों के लिए धन्यवाद! आप जो काम कर रहे हैं उसके लिए और इस मुद्दे का जवाब देने और हमारे प्रयासों को पढ़ने के लिए मैं आपका आभारी हूं! मैं आरोप लगाना या कुछ भी नहीं सुनना चाहता! मैं केवल डेटा देख रहा हूं और हमारी साइट की विश्वसनीयता में सुधार करने की कोशिश कर रहा हूं।
उदाहरण के लिए हमें आज सुबह एक चोटी मिली: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

हम कुछ घंटों के लिए बैकअप पर हर रात (6AM UTC) चोटी भी देखते हैं।

मंचन और उत्पादन के संबंध में, वर्तमान में हमारे पास तीन उदाहरण हैं:

उदाहरण | यूआरएल | लॉग बनाएँ | कार्यस्थान
-----------|----------|---------------|-----------
| अस्थिर | https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| स्थिर | https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| उत्पादन | https://publiclab.org/ | एन/ए | एन/ए

आप सही हैं कि दस्तावेज़ीकरण के अनुसार हमें इस प्रक्रिया का वर्णन करते हुए बेहतर काम करना चाहिए। वर्तमान में मुझे यहां कुछ दस्तावेज़ मिले हैं https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches लेकिन यह बिल्कुल स्पष्ट नहीं है कि जब हम उन शाखाओं को धक्का देते हैं तो ये शाखाएं बनती हैं।

डेटाबेस को वर्तमान में हर बार मैन्युअल रूप से अपडेट किया जाता है लेकिन अब इसे स्वचालित करना आसान होना चाहिए क्योंकि हमारे पास दैनिक डेटाबेस डंप हैं। मैं इसे स्थापित करूँगा और आपको पिंग करूँगा!

इसका मतलब यह नहीं है कि हमें और समाधान लागू नहीं करने चाहिए, इसके बाद मुझे लगता है कि एक थ्रेडेड वेबसर्वर (प्यूमा) मदद कर सकता है!

यह अच्छा सवाल है! हम अपनी होस्टिंग को यहां ले जाने की प्रक्रिया में हैं
नया प्रदाता और नए में एक कंटेनर क्लस्टर के रूप में तैनात करने की उम्मीद कर रहे थे
होस्टिंग प्रदाता।

चूंकि कंटेनरों में दौड़ना तुरंत तुच्छ नहीं है (क्योंकि हमारा ऐप
कंटेनर अपरिवर्तनीय नहीं है) - शुरू करने का एक विकल्प यह है कि हम कर सकते हैं
जगह बनाने के लिए पहले डेटाबेस को स्थानांतरित करें।

मुझे नहीं लगता कि हमें अपने वर्तमान होस्ट में अपने होस्टिंग उपयोग को बढ़ाना चाहिए
क्योंकि हम बमुश्किल अपने स्वीकृत कोटे के भीतर हैं, लेकिन @jywarren पुष्टि कर सकते हैं?

आपके काम के लिए धन्यवाद!

19/06/19 11:23 को गौरव सचदेवा ने लिखा:
>

अरे @icarito https://github.com/icarito , क्या हम RAM बढ़ा सकते हैं
सर्वर? हो सकता है कि जब तक हम वेबसाइट को गति देने में मदद न करें
हमारी क्वेरी प्रतिक्रिया दर में सुधार?

धन्यवाद!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWWK3TUL52HS4DFVREXG43VCMVBW63इश्यू 5ZGOW362ZORT
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q ।

वास्तव में मुझे आश्चर्य है कि क्या हम अस्थायी रूप से उस कंटेनर में अपने राम को बढ़ा सकते हैं
जब तक हम कदम नहीं उठाते हैं और अगर यह अल्पावधि में मदद करेगा। मुझे लगता है कि हम ठीक होंगे
उस लागत में वृद्धि के साथ!

बुधवार, जून 19, 2019, दोपहर 12:59 बजे सेबस्टियन सिल्वा नोटिफिकेशन @github.com
लिखा था:

यह अच्छा सवाल है! हम अपनी होस्टिंग को यहां ले जाने की प्रक्रिया में हैं
नया प्रदाता और नए में एक कंटेनर क्लस्टर के रूप में तैनात करने की उम्मीद कर रहे थे
होस्टिंग प्रदाता।

चूंकि कंटेनरों में दौड़ना तुरंत तुच्छ नहीं है (क्योंकि हमारा ऐप
कंटेनर अपरिवर्तनीय नहीं है) - शुरू करने का एक विकल्प यह है कि हम कर सकते हैं
जगह बनाने के लिए पहले डेटाबेस को स्थानांतरित करें।

मुझे नहीं लगता कि हमें अपने वर्तमान होस्ट में अपने होस्टिंग उपयोग को बढ़ाना चाहिए
क्योंकि हम बमुश्किल अपने स्वीकृत कोटे के भीतर हैं, लेकिन @jywarren पुष्टि कर सकते हैं?

आपके काम के लिए धन्यवाद!

19/06/19 11:23 को गौरव सचदेवा ने लिखा:
>

अरे @icarito https://github.com/icarito , क्या हम RAM बढ़ा सकते हैं
सर्वर? हो सकता है कि जब तक हम वेबसाइट को गति देने में मदद न करें
हमारी क्वेरी प्रतिक्रिया दर में सुधार?

धन्यवाद!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VCMVBW63# इश्यू
,
या थ्रेड को म्यूट करें
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVFCY
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

ओह, @icarito , नहीं, नहीं, मुझे कोई आरोप नहीं लगा, बिल्कुल नहीं। मैंने पढ़ा, "यही हो रहा है" और मैं बस इतना कह रहा था "यह अजीब है, ऐसा क्यों होगा अगर कोई उस पर नहीं था ...?" उसी तर्ज पर, मेरा मतलब यह नहीं था कि दस्तावेज़ीकरण खराब था। केवल इतना कि यदि कोई हो तो आपको उसे समझाने की आवश्यकता नहीं थी।

और हे, यह पूरी तरह से निराधार आरोप नहीं है:) हालांकि मुझे यह दिखावा करने में थोड़ा मज़ा आ रहा है कि मुझे फंसाया गया है और मैं भूमिगत हो गया हूं और मुझे अपनी बेगुनाही साबित करनी है लेकिन यह एक पूरी तरह से दूसरी पटकथा है जिस पर मैं काम कर रहा हूं .

शुक्र है कि ये बेबुनियाद और निराधार आरोप; ) दोनों भागों को साफ कर दिया गया है और हम काम पर वापस आ सकते हैं।

संबंधित प्रश्न: यदि कोई इसका उपयोग नहीं कर रहा था या यह रहस्य है तो सांख्यिकी नियंत्रक सक्रिय क्यों होगा?

मंचन के संबंध में, स्पष्टीकरण के लिए धन्यवाद। यह सुनिश्चित करने के लिए कि मुझे मिल गया है, कह रहा है...

मैं इसे स्थिर स्टेजिंग इंस्टेंस में आज़माउंगा।

... यह कहने के साथ विनिमेय है, "मैं इसे static.publiclab.org पर आज़माउंगा"?

Stable.publiclab.org Q को -- हाँ! और यह किसी भी धक्का से बनाया गया है
master शाखा - आशा है कि मदद करता है!

बुध, जून १९, २०१९ अपराह्न ३:१९ बजे बेंजामिन शुगर नोटिफिकेशन @github.com
लिखा था:

ओह, @icarito https://github.com/icarito , नहीं, नहीं, मुझे कुछ समझ नहीं आया
आरोप, बिल्कुल नहीं। मैंने पढ़ा, "यही हो रहा है" और मैं सही था
कह रहा है "यह अजीब है, अगर कोई उस पर नहीं था तो ऐसा क्यों कर रहा होगा ...?"
उसी तर्ज पर, मेरा मतलब यह नहीं था कि दस्तावेज़ीकरण खराब था।
केवल इतना कि यदि कोई हो तो आपको उसे समझाने की आवश्यकता नहीं थी।

और हे, यह पूरी तरह से निराधार आरोप नहीं है:) हालांकि मैं हूँ
यह दिखाने में थोड़ा मज़ा आ रहा है कि मुझे फंसाया गया है और मैं चला गया हूँ
भूमिगत और मुझे अपनी बेगुनाही साबित करनी है लेकिन वह पूरी तरह से है
पटकथा जिस पर मैं काम कर रहा हूं।

शुक्र है कि ये बेबुनियाद और निराधार आरोप; ) दोनों भागों पर है
साफ़ कर दिया गया है और हम हाथ में व्यवसाय पर वापस आ सकते हैं।

संबंधित प्रश्न: यदि कोई नहीं होता तो सांख्यिकी नियंत्रक सक्रिय क्यों होता
इसका उपयोग कर रहे हैं या यह रहस्य है?

मंचन के संबंध में, स्पष्टीकरण के लिए धन्यवाद। यह सुनिश्चित करने के लिए कि मेरे पास है,
कह रहा हे...

मैं इसे स्थिर स्टेजिंग इंस्टेंस में आज़माउंगा।

... यह कहने के साथ विनिमेय है, "मैं इसे static.publiclab.org पर आज़माउंगा"?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DNMVWW3710YKT
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren , हाँ! अब मिल गया। धन्यवाद!

@Skilfullycurled स्पष्टीकरण के लिए धन्यवाद!
यह वास्तव में एक रहस्य है कि StatsController इतना सक्रिय क्यों है?

कुछ क्षण पहले हमारे पास एक और चोटी थी जिसने हमें कुछ मिनटों के लिए नीचे गिरा दिया:

इस मामले में ट्रिगर वास्तव में पूर्ण पाठ खोज था।
लेकिन कोई देख सकता है कि इस संक्षिप्त समय (3 मिनट) में भी, StatsController को 21 बार कॉल किया गया था।

मुझे लगता है कि यह हमारे आधारभूत प्रदर्शन को महत्वपूर्ण रूप से प्रभावित कर सकता है। यदि यह उपयोग ज्ञात नहीं है, तो शायद क्रॉलर इन समापन बिंदुओं को मार रहे हैं? हो सकता है कि कोई robots.txt या कोई एक्सेस कंट्रोल इसे ठीक कर दे?

@jywarren स्पष्टीकरण के लिए धन्यवाद, मैं इसे तब तक करने पर ध्यान दूंगा।

वास्तव में यहाँ पिछले समय के लिए Statscontroller विवरण है:

क्या हम सभी आँकड़े रूट robots.txt करेंगे? तो /आँकड़े* मूल रूप से?

गुरु, 20 जून 2019 को दोपहर 12:21 बजे सेबस्टियन सिल्वा नोटिफिकेशन @github.com
लिखा था:

वास्तव में यहाँ पिछले समय के लिए Statscontroller विवरण है:
[छवि: छवि]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVZ35Z85P63PW
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

ठीक है, मैंने किया, और छूट भी दी /api/* - हमने पहले ही अवरुद्ध कर दिया था /stats/range*
लेकिन अब यह सब /आँकड़े*

https://github.com/publiclab/plots2/commit/aa93dc3465b0cbaaee41ac7bec5e690437a27f5d

गुरु, 20 जून, 2019 दोपहर 2:45 बजे जेफरी वॉरेन [email protected] ने लिखा:

क्या हम सभी आँकड़े रूट robots.txt करेंगे? तो /आँकड़े* मूल रूप से?

गुरु, 20 जून 2019 को दोपहर 12:21 बजे सेबस्टियन सिल्वा नोटिफिकेशन @github.com
लिखा था:

वास्तव में यहाँ पिछले समय के लिए Statscontroller विवरण है:
[छवि: छवि]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVZ35Z85P63PW
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

तो आपको नहीं लगता कि यह कैशिंग है?

कैश उपयोग द्वारा उत्पन्न होता है, अर्थात, यह तब उत्पन्न होता है जब a) इसकी समय सीमा समाप्त हो जाती है, और
बी) एक नया अनुरोध आता है। तो इसके लिए कुछ अनुरोध करना होगा
कैश उत्पन्न करने के लिए ... अगर मैं कुछ असंबंधित मुद्दों को हल कर सकता हूं और विलय कर सकता हूं
उनके पीआर, मैं आज रात उत्पादन के लिए एक नया प्रकाशन शुरू करूंगा (अन्यथा
कल) और हम देख सकते हैं कि क्या robots.txt बिल्कुल मदद करता है?

गुरु, जून 20, 2019 अपराह्न 4:53 बजे बेंजामिन शुगर नोटिफिकेशन @github.com
लिखा था:

तो आपको नहीं लगता कि यह कैशिंग है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63#IGOMWW2ZORT45
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller प्रति मिनट 5.5 बार कहा जाता है

@icarito के माध्यम से - इसलिए आज रात के अपडेट पर हम देख सकते हैं कि क्या robots.txt परिवर्तन इससे मदद करते हैं।

अरे @jywarren , मैंने देखा कि कुछ दिन पहले robot.txt अपडेट कमिट को स्थिर करने के लिए धकेल दिया गया था। कोई सुधार आपने देखा?

हाँ, एक अद्यतन पसंद करेंगे! सुनिश्चित नहीं है कि मैंने सही डेटा पकड़ा है, लेकिन प्रतिबद्धता से पहले, प्रतिबद्धता के बाद, और पिछले ~ 24 घंटों के स्काइलाईट से कुछ छवियां यहां दी गई हैं। लाल रेखा इंगित करती है कि कब प्रतिबद्ध किया गया था। सतह पर ऐसा लगता है कि उत्तर हां है, लेकिन यह महत्वपूर्ण नहीं हो सकता है, या मैं डेटा की गलत व्याख्या कर रहा हूं।

हाँ, मुझे लगता है कि एक पूर्ण विश्लेषण बहुत अच्छा होगा। लेकिन संक्षिप्त उत्तर यह है कि
हमने सभी साइट अनुरोधों के लिए हमारे औसत समस्या प्रतिक्रिया समय को लगभग आधा कर दिया है
5.5+ से 3 या उससे कम तक। यह वास्तव में बहुत बड़ा सुधार है। वह एक था
a) 8-15GB से RAM को लगभग दोगुना करना, b) मार्केटिंग को ब्लॉक करना
robots.txt में bot, और c) इसे nginx config में भी ब्लॉक करना (मुझे लगता है कि
आईपी ​​​​एड्रेस रेंज)। कठिन हिस्सा यह है कि bot/stats_controller कितना था
इसका एक हिस्सा, क्योंकि हम समग्र साइट अपग्रेड को रोकना नहीं चाहते थे।

समय था:

1. लगभग 5-6pm ET पर robots.txt, मुझे लगता है
2. nginx घंटों बाद ब्लॉक हो गया जब हमें यकीन नहीं था कि robots.txt कितनी जल्दी था
   पढ़ें या सम्मान करें
3. ~ 7am ET साइट स्मृति विस्तार शनिवार को।

किसी भी मामले में अब हम वास्तव में अच्छा कर रहे हैं। लोड औसत ~8 के बजाय <4 है,
और हमारे पास 4 सीपीयू के बजाय 6 हैं।

मंगलवार, जून 25, 2019 को शाम 5:32 बजे बेंजामिन शुगर नोटिफिकेशन @github.com
लिखा था:

हाँ, एक अद्यतन पसंद करेंगे! सुनिश्चित नहीं है कि मैंने सही डेटा पकड़ा है, लेकिन यहां है
कमिट से पहले, कमिट के बाद, और के रोशनदान से कुछ छवियां
पिछले ~ 24 घंटे। लाल रेखा इंगित करती है कि कब प्रतिबद्ध किया गया था। देखो बेटा
उत्तर की तरह सतह हाँ है, लेकिन यह महत्वपूर्ण नहीं हो सकता है, या I
हो सकता है कि डेटा की गलत व्याख्या कर रहा हो।

[छवि: robots_txt]
https://user-images.githubusercontent.com/950291/60135129-05718300-976f-11e9-8fe7-3ca1c081abe3.png

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3WWUL52HS4DFVREXG43VMVBJ75HZP-50H56HGODNMVK
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

इसे अभी बंद करें!