Plots2: قضايا الذاكرة (تسرب؟) التحقيق

مع ملاحظة تعليق icarito :

أتساءل عن jywarren لأنني قمت بتحرير docker-compose-production.yml لاستخدام عمليات أقل (لم تصنع لها علاقات عامة). لذلك يمكن أن نكون قد جعلناه مناسبًا بهذه الطريقة.

وهذا الرسم البياني:

نشاهد أيضًا الكثير من أخطاء اختبار SMTP:

الارتباط: | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZyu

نعم ، الحمل مرتفع جدًا أيضًا. من htop وخاصة iotop يبدو أن mailman نشط تمامًا. إنه الجاني بالتأكيد! قبل 22 مايو ، قمنا بتشغيله عدة مرات في اليوم - إذا تمكنا من تشغيله كل بضع دقائق أو نحو ذلك (ليس كل ثانية!) - فسيكون ذلك جيدًا!

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

بشكل عام تبدو جيدة. ولكن عند إلقاء نظرة فاحصة ، فإنه يزداد في وقت التحميل:

مقارنة الجزء الأخير حيث بدأ في العودة للأعلى:

إلى الأقدم بعد إعادة التشغيل مباشرة:

ثم إلى هذا منذ أسبوعين قبل كل مشاكلنا:

ثم أخيرًا بعد أن بدأنا في رؤية المشكلات في يومي 22 و 23 مايو:

بشكل عام ، هذا ليس قاطعًا.

موارد:

• قائمة بالأحجار الكريمة والإصدارات التي تتسرب منها الذاكرة: 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

أود أن أعتقد أنه يتعلق بإضافة رمز retry 3 times في https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 ، الذي حاولت التغيير والتبديل اليوم. لكن أوقات التحميل لا تزال تنمو ببطء.

قد يعني هذا أن أ) شيء آخر يقودها ، أو ب) دورة "الإنقاذ / إعادة المحاولة" نفسها يمكن أن تتسبب في تراكم تسرب الذاكرة؟

هل يمكنني التعليق على كود الإنقاذ / إعادة المحاولة بالكامل؟

ربما التعليق الذي ينتظر mysql لالتقاط هو في الواقع تناول المواضيع؟

سأحاول هذا. الموقع غير مستجيب تقريبًا.

أزلت retry هنا: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

جارٍ النشر ... سيستغرق بعض الوقت.

حسنًا ، لا يبدو أنه تم حلها حقًا ... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

حسنًا ، أتساءل عما إذا كان إعداد الحاوية قد أثر على حاوية ساعي البريد على الإطلاق؟ لأنه في هذه المرحلة ، قمنا بإعادة جميع الأشياء المحتملة من البرنامج النصي لرجل البريد.

حسنًا ، بلغ ذروته بين عشية وضحاها وعاد للأسفل قليلاً. لكن إشكالياتنا لا تزال عالية جدًا ، حيث تبلغ ذروتها حوالي 20 ثانية:

تستغرق مكالمات نطاق الإحصائيات ما يصل إلى 40 ثانية!

إنهم أيضًا يأخذون إلى الأبد في إنشاء ذاكرة التخزين المؤقت:

هل يمكن أن نشاهد مشكلة في ذاكرة التخزين المؤقت للقراءة / الكتابة؟

icarito هل يمكن أن يكون هناك مشكلة في القراءة / الكتابة io أو شيء ما في إنشاء ذاكرة التخزين المؤقت؟ لست متأكدًا من سبب استغراق هذا الوقت الطويل لحزم جميع البيانات في ذاكرة التخزين المؤقت.

جواهر متسربة - تحقق مما إذا كنا على ما يرام

• [x] السليلويد> 0.16.0 ، <0.17.2
• [x] csspool <4.0.3
• [x] عنب <0.2.5
• [x] oj <2.12.4
• [x] سجادة حمراء <3.3.3
• [x] redis = 3.3.0
• [x] sidekiq <3.5.1
• [x] احصاء الصاحب
• [x] جهاز المعالجة الحرارية <0.12.2
• [x] zipruby <= 0.3.6

مشاكل عدم التسرب ولكن الذاكرة في أي حال:

• [x] Activeadmin
• [x] axlsx
• [x] delayed_job> = 4.06
• [x] libxml-ruby <2.9.0 مع Nokogiri RC3
• [x] newrelic_rpm> = 3.9.4 ، <= 3.9.7
• [x] تتمة> = 2.12.0
• [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 . ومع ذلك ، أعتقد أنه من المفيد إعادة النشر مع إعادة تثبيت 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

ug ، أخيرًا أعد نشر التعليق. rb fix ....

حسنًا ، نحن ننتظر لنرى ما إذا كانت قائمة انتظار البريد الإلكتروني ستخرج ونرى بعضًا من العودة إلى الوضع الطبيعي بعد ذلك ...

لقد تركت تعليقًا على https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii للاختبار

مرحبًا jywarren ، لقد قمت بإلقاء نظرة ثانية على هذه النظرة ولدي نظرية.

أولاً ، هنا رسم بياني لاستخدام ذاكرة الوصول العشوائي للأشهر الثلاثة الماضية:

يتضح من هذا الرسم البياني أننا كنا ننمو في استهلاك الذاكرة خلال الأشهر الثلاثة الماضية!

عدت سنة كاملة:

إلى حد ما ، في عام 2019 ، زاد تطبيقنا من متطلبات الذاكرة قليلاً.

النظرية هي أنه باتباع مسار استهلاك الذاكرة الذي كنا نمر به ، فقد نكون قد وصلنا إلى عتبة حيث استهلكنا ذاكرة الوصول العشوائي المتاحة وبدأنا في الاعتماد على Swap ، مما يؤدي إلى إبطاء الأمور إلى حد كبير.

قد تكون زيادة الذاكرة بحجم بعض طاولاتنا ( rusers أنا أنظر إليها). قد يكون لهذا علاقة بالرقم 5524.

سيتعين علينا تنفيذ بعض التحسينات ، أو ترحيل قاعدة البيانات إلى مضيف مختلف ، أو إضافة المزيد من ذاكرة الوصول العشوائي.

يوصى بشدة أيضًا بتقليم قاعدة بيانات مستخدمي البريد العشوائي.

ما زلت أميل إلى استنفاد الذاكرة بسبب نمو التطبيق / الموقع ، مما يتسبب في ارتفاع تحميل الإدخال / الإخراج بسبب تبديل الذاكرة "الضرب" بالقرص.
لقد تحققت من passenger-memory-stats من حاوية الويب وأعتقد أنه يمكننا تقليل مجموعة العمليات بشكل أكبر:

سأحاول هذا كخطوة أولى لإصلاح الأداء.

لقد وجدت أنه في فبراير 2018 ، حسبنا أنه يمكننا تشغيل 11 عملية (لأن تطبيقنا استغرق 500 ميجابايت للتشغيل).
الصيغة هي:

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

لكننا نقوم أيضًا بتشغيل Skylightd ، بالإضافة إلى عملية لجلب تعليقات التغريدات ، بالإضافة إلى Sidekick ، ​​ونريد أيضًا تشغيل عملية ساعي البريد.
غالبية استخدام ذاكرة الوصول العشوائي في حاوية الويب:

من كلتا الصورتين المذكورتين أعلاه ، لا يزال بإمكاننا توفير عملية واحدة ، خاصة إذا كان هذا سيجعل الردود أسرع.

الانتقال إلى حجم تجمع العمليات 4.

تم إجراء التحسين الأول.
واعد أول 30 دقيقة!

اوه!

يوم السبت 8 يونيو 2019 الساعة 8:47 مساءً Sebastian Silva [email protected]
كتب:

تم إجراء التحسين الأول.
واعد أول 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=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VM58
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

حسنًا ، ستكون قائمة عوامل التخفيف كما يلي:

• [x] تقليل تجمع العمليات
• [] نقل ديسيبل إلى حل جوجل سحابة ديسيبل
• [] تقليل rusers - ربما يتم البناء على العمل في https://github.com/publiclab/plots2/issues/5450
• [] التبديل إلى memcached

مرحبًا @ jywarren و icarito ،

أولاً ، (وأنا أقول هذا بدون مزاح): لقد تبين في الواقع أن هذا الموضوع جيد القراءة. كان يحتوي على كل العناصر ، لغز ، مطاردة ، طريق مسدود ، مكالمات قريبة ، إلخ.

على أي حال.

فيما يتعلق بجدول rusers بالنسبة إلى # 5450 و # 5524 ، هناك مجموعة _ هائلة _ في rusers حدثت بين 4/26/13 - 1/1/14.

4/26/2013: 1366934400
1/1/2014: 1388534400
نطاق UID: 59627-420114
المستخدمون: 360466

هل تريد تجربة الاستعلام الأول للتشغيل التجريبي الذي وصفته في # 5450 على جزء من تلك المجموعة؟

المستخدمون الذين لم ينشروا أي عقدة أو تعليق أو إعجاب أو اشتراك ولم يقوموا بتسجيل الدخول مطلقًا

كما قلت ، سيكون هذا استعلامًا سهلاً لأن عدم تسجيل الدخول على الإطلاق سيغطي جميع المعايير التي سبقته.

للإشارة إلى حجم الجزء المكافئ للأشهر الستة الأخيرة المقترحة في رسالة البريد الإلكتروني الأخرى: في الشهر الماضي ، قمنا بوضع علامة على حوالي 250 من المنشورات لأول مرة كرسائل غير مرغوب فيها. لذلك ، لنفترض أنه في الأشهر الستة الماضية كان لدينا حوالي 1500 مستخدم محظور بسبب البريد العشوائي.

أوه ، وأعتقد أن هذا يجلب نقطة جيدة. إذا كنت تريد التخلص من مستخدمي البريد العشوائي ، يمكنك فقط العثور على جميع المستخدمين الذين تم وضع علامة على المحتوى على أنهم بريد عشوائي ثم حذف المستخدمين الذين قاموا بنشرهم.

كما تم التطرق لفترة وجيزة في إحدى المشكلات ، قد يكون من الجيد أن يتم حذف المستخدمين الذين تم وضع علامة على المحتوى لأول مرة كرسائل غير مرغوب فيها على الفور من قاعدة البيانات.

مرحبًا skilfullycurled ، شكرًا لك على طاولاتنا الرئيسية هي وانطباعات .

rsessions تزيد عن 30 جيجا بايت.
jywarren و skilfullycurled - سيكون من الرائع التوصل إلى استراتيجية لتقليل هذا و / أو تحسين الاستعلامات باستخدام هذا الجدول!

كما أعتقد أن memcached ليس مناسبًا لهذه المشكلة لأنه يجب أن يستهلك المزيد من ذاكرة الوصول العشوائي وليس أقل ..

على الرغم من أنه يمكن للمرء أن يحد من استخدام الذاكرة لـ memcached ، إلا أنني ما زلت أحاول ذلك!

كلا ، من المستندات أعلاه:

إذا كنت تقوم بتشغيل عدة عمليات خادم Ruby on Rails (وهذا هو الحال إذا كنت تستخدم mongrel_cluster أو Phusion Passenger) ، فلن تتمكن مثيلات عملية خادم Rails من مشاركة بيانات ذاكرة التخزين المؤقت مع بعضها البعض. لا يعد مخزن ذاكرة التخزين المؤقت هذا مناسبًا لعمليات نشر التطبيقات الكبيرة ، ولكنه يمكن أن يعمل بشكل جيد للمواقع الصغيرة ذات حركة المرور المنخفضة مع عمليتي خادم أو لبيئات التطوير والاختبار.

يبدو أنه ليس من الصعب جدًا حل _ الجلسات_:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@ jywarren دعونا نفعل هذا!

icarito ، لست متأكدًا من حدوث ذلك على الإطلاق ، ولكن كان لدي وصول إلى قاعدة البيانات في عام 2016 وأخطرت الجميع أن جلسات المستخدم حد بعيد . قيل لي أنه سيتم مسحهم لذا إما أنهم لم يكونوا كذلك أو تظل المشكلة أن قاعدة البيانات تستمر في الاحتفاظ بالجلسات.

لإعطاء إحساس ، اعتبارًا من عام 2016 ، كانت قاعدة بيانات المؤامرات _ مضغوطة _ حيث كانت bz2 1.9 جيجابايت (لا يوجد وقت الآن لفك الضغط للحصول على الحجم الفعلي) ، _غير مضغوط _ ، مع إزالة الجلسات ، كانت 518 ميجابايت

شكرا skilfullycurled !!! أعتقد أنني أتذكر مدخلاتك من عام 2016 ، ولا أعرف كيف فاتنا مسح ذلك ، لكن مقالب قاعدة البيانات لدينا اليوم مضغوطة أكثر من 8 جيجابايت ، على الأرجح جلسات.
سأنتظر التأكيد من jywarren - أود تشغيل ما يلي في الإنتاج اليوم وبعد ذلك يمكننا تحويله إلى مهمة أشعل النار أو وظيفة cron:

احذف من الجلسات WHERE updated_at <DATE_SUB (NOW () ، INTERVAL 1 DAY) ؛

لقد شعرت بالفضول الشديد ، فالملف غير المضغوط يبلغ 6.8 جيجا بايت ، لذا ناقص 518 ميجا بايت الذي يضعنا في 6.3 جيجا بايت. 😆

الجلسات هي في الواقع مجموعة البيانات المفضلة لدي. إنه لا يستخدم تمامًا ، لكني أحب أنه كبير جدًا إن لم يكن أكبر من مجموعات البيانات التي أمتلكها والتي تعد مفيدة __! إذا كان لدى أي شخص أي أفكار حول ما يجب فعله به ، فأخبرني بذلك!

icarito ( icarito : matrix.org) حصلت عليه من هنا https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( icarito : matrix.org) يجب تسجيل الخروج من كل جلسة لم تكن نشطة في اليوم أو الأسبوع الماضي - يمكننا تعديلها

مجرد تدوين الملاحظات هنا. يبدو عظيما.

يبدو أن عدم الاستقرار يستغرق وقتًا طويلاً ... يمكن المحاولة

حذف ... من ... أين ... تحديد x

وتنفيذ عدة مرات حسب الحاجة في الإنتاج.

بعد 7 ساعات لا يزال هذا مستمرًا في التدريج. من الواضح أن هذه ليست الطريقة التي نريد القيام بها في الإنتاج دفعة واحدة. شيء آخر هو أنه بعد الحذف ، سيتم تجزئة الجدول ولن يتم تقليل حجم الملف لجدول rsessions . يجب تفريغ الجدول وإعادة إنشائه من أجل تحرير موارد الخادم.

خطتي للقيام بذلك هي التالية:

• [] جدول جلسات تفريغ Mysql بـ where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [] إعادة تسمية جدول الدورات
• [] تحميل بيانات نظيفة من الجدول الملغى إلى جدول جلسات جديد
• [] إسقاط جدول الجلسات القديمة

سأحاول هذا في مثيل التدريج stable .

حسنًا ، سيباستيان رائع ، وأعتقد أن هذا قد يكون إيجابيًا
الآثار المترتبة على التحسينات المتوقعة لأداء ديسيبل لدينا بعد ذلك
اكتمل التخفيف ، حتى لو كان مسح هذا الجدول يمكن أن يستغرق هذا الوقت الطويل ...

في يوم الاثنين 17 يونيو 2019 الساعة 9:50 مساءً Sebastian Silva [email protected]
كتب:

سأحاول هذا في مثيل التدريج المستقر.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMV
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

أحضرcesswairimu حتى تتمكن من تجربة استعلامها مرة أخرى عند الانتهاء من icarito . يجب أن يخبرنا ذلك ما إذا كانت المشكلات في # 5917 تتعلق فقط بـ # 5490 (تم إصلاحها) أو إذا كانت مرتبطة أيضًا بـ # 5524.

unstable يحذف ...

ترك بعض الملاحظات هنا أثناء إجراء الاختبار في مثيل ثابت.

• [x] جدول جلسات تفريغ Mysql مع حيث updated_at> DATE_SUB (NOW () ، INTERVAL 7 DAY)
  
  
  
  • الأمر: 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
  
  
  • الوقت: 13 ثانية
  
  
• [x] إعادة تسمية جدول الدورات
  
  
  
  • بناء الجملة: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • تقارير الحراسة Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions 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 ثوانٍ
  
  
  • إنشاء ملف جدول rsessions جديد (13 ميجا بايت للتشغيل المرحلي!)
  
  
  • يستعيد الصفحة الرئيسية
  
  
• [x] إسقاط جدول الجلسات القديم:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

تم اختباره https://stable.publiclab.org لتسجيل الدخول ..

أنا مستعد لتجربة هذا في الإنتاج!

unstable لا يزال حذف ...

إجراء العملية على قاعدة بيانات الإنتاج المباشر:

• [x] جدول جلسات تفريغ Mysql مع حيث updated_at> DATE_SUB (NOW () ، INTERVAL 7 DAY)
  
  
  
  • الوقت: 48 ثانية
  
  
  • حجم التفريغ: 143 ميجابايت
  
  
• [x] إعادة تسمية جدول الدورات
  
  
  
  • الوقت: 11 ثانية
  
  
  • تعطلت الصفحة الرئيسية لمدة 15 دقيقة في حوالي الساعة 6 صباحًا بالتوقيت العالمي المنسق
  
  
• [x] تحميل بيانات نظيفة من الجدول الملغى إلى جدول جلسات جديد
  
  
  
  • إنشاء ملف جدول rsessions جديد (220 ميجا بايت)
  
  
  • يستعيد الصفحة الرئيسية
  
  
• [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

حسنًا ، كان الأمر سريعًا جدًا هذا الصباح ، لكن بشكل عام لا أرى فرقًا كبيرًا! 😞

لا! حسنًا ، هناك تفسير واحد آخر وهو الأشباح. سأفتح قضية أخرى وسأبحث في إيجاد جوهرة طارد الأرواح الشريرة أو صائد الأشباح

أعتقد أن هناك بالفعل تحسنًا في استخدام الإدخال / الإخراج لأن استخدام جدول سعة 30 غيغابايت يعد أمرًا ثقيلًا - إذا نظرت عن كثب ، تبدو القمم مرتبطة بـ Statscontroller ... ربما يمكننا عمل الإحصائيات على التدريج؟ يمكنني أن أجعلها نسخة من قاعدة بيانات الإنتاج بانتظام أقول أسبوعيا؟

مرحبًا icarito ، كنت أتساءل عما إذا كان بإمكانك الإجابة على بعض الأسئلة "التعليمية" بالنسبة لي:

إذا نظرت عن كثب ، فإن القمم تبدو مرتبطة بـ Statscontroller ...

لماذا يكون هذا؟ بسبب التخزين المؤقت؟ لا يسعني سوى التفكير في ثلاثة أشخاص سيستخدمونها وأنا واحد منهم ولم أكن كذلك.

ربما يمكننا عمل الإحصائيات على التدريج؟

كنت أسمع ... إيه ... أشاهدك تستخدم كلمة "التدريج" كثيرًا مؤخرًا. ما هذا وكيف يلعب في الموقع / سير العمل؟ إذا كان جزءًا من المستندات ، فأخبرني بأي منها وسأنتظر في فهمه أولاً.

يمكنني أن أجعلها نسخة من قاعدة بيانات الإنتاج بانتظام أقول أسبوعيا؟

أعتقد أن هذا سيكون جيدًا. لا تعتبر أحدث البيانات مهمة ، ولكن بين نظام الأسئلة والأجوبة الذي يتم تغييره وترحيل العلامات الأخيرة ، أفترض أن أسبوعيًا فكرة جيدة لأنها cesswairimu ، ما رأيك ؟

كان هذا موضوعًا رائعًا حقًا للقراءة. نعم ، إنها فكرة رائعة وجود الإحصائيات على خشبة المسرح والنسخ الأسبوعي أمر جيد أيضًا: +1:
لقد فكرت في المستقبل في جعل استعلامات الإحصائيات نصًا يقوم بإنشاء عرض sql وحذفه وإعادة إنشائه يوميًا / أو أسبوعيًا بواسطة وظيفة وربما يمكن أن يعيش هذا في المرحلة أيضًا. هل ترغب في سماع أفكارك حول هذا وإذا كان هذا يمكن أن يساعد في تسريب الذاكرة بأي شكل من الأشكال.

مرحبًا icarito ، هل يمكننا زيادة ذاكرة الوصول العشوائي للخادم؟ ربما سيساعد ذلك في تسريع موقع الويب حتى نحسن معدل استجابة الاستعلام؟

شكرا!

شكرا على ردودكم! أنا ممتن للعمل الذي تقوم به وعلى الرد على هذه المشكلة والقراءة من خلال جهودنا! لا أريد أن أبدو متهماً أو أي شيء! أنا فقط أنظر إلى البيانات وأحاول تحسين موثوقية موقعنا.
على سبيل المثال ، وصلنا إلى ذروة هذا الصباح: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

نرى أيضًا قممًا كل ليلة (6 صباحًا بالتوقيت العالمي المنسق) على النسخ الاحتياطي لبضع ساعات.

فيما يتعلق بالتدريج والإنتاج ، لدينا حاليًا ثلاث حالات:

مثيل | URL | سجل البناء | مساحة العمل
----------- | ------- | ------------ | -------------
| غير مستقر | 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 - الفروع ولكن ليس من الواضح على الإطلاق ما إذا كانت هذه الفروع تبني عندما ننتقل إلى تلك الفروع.

يتم تحديث قاعدة البيانات حاليًا يدويًا بين الحين والآخر ، ولكن يجب أن يكون من السهل أتمتة ذلك الآن بعد أن أصبح لدينا تفريغ قاعدة البيانات يوميًا. سوف أقوم بإعداده وأتصل بك!

هذا لا يعني أننا لا يجب أن ننفذ المزيد من الحلول ، بعد ذلك أعتقد أن خادم ويب مترابط (Puma) يمكن أن يساعد!

هذا سؤال جيد! نحن بصدد نقل استضافتنا إلى
مزود جديد وكانوا يأملون في نشره كمجموعة حاويات في الجديد
مزود استضافة.

نظرًا لأن التشغيل في الحاويات ليس بالأمر السهل على الفور (لأن تطبيقنا
الحاوية ليست ثابتة) - البديل للبدء هو أننا نستطيع
انقل قاعدة البيانات أولاً لإفساح المجال.

لا أعتقد أنه يجب علينا زيادة استخدام الاستضافة في مضيفنا الحالي
لأننا بالكاد ضمن الحصة المسموح بها ، لكن @ jywarren يمكنه التأكيد؟

شكرا لعملكم!

في 19/06/19 11:23 ، كتب غوراف ساشديفا:
>

مرحبًا icarito https://github.com/icarito ، هل يمكننا زيادة ذاكرة الوصول العشوائي لـ
الخادم؟ ربما سيساعد ذلك في تسريع الموقع حتى نقوم بذلك
تحسين معدل استجابة الاستعلام لدينا؟

شكرا!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW97
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

في الواقع أتساءل عما إذا كان بإمكاننا زيادة ذاكرة الوصول العشوائي مؤقتًا في تلك الحاوية
حتى نقوم بهذه الخطوة وإذا كانت ستساعد على المدى القصير. أعتقد أننا سنكون بخير
مع زيادة التكلفة!

يوم الأربعاء ، 19 يونيو 2019 ، الساعة 12:59 مساءً Sebastian Silva [email protected]
كتب:

هذا سؤال جيد! نحن بصدد نقل استضافتنا إلى
مزود جديد وكانوا يأملون في نشره كمجموعة حاويات في الجديد
مزود استضافة.

نظرًا لأن التشغيل في الحاويات ليس بالأمر السهل على الفور (لأن تطبيقنا
الحاوية ليست ثابتة) - البديل للبدء هو أننا نستطيع
انقل قاعدة البيانات أولاً لإفساح المجال.

لا أعتقد أنه يجب علينا زيادة استخدام الاستضافة في مضيفنا الحالي
لأننا بالكاد ضمن الحصة المسموح بها ، لكن @ jywarren يمكنه التأكيد؟

شكرا لعملكم!

في 19/06/19 11:23 ، كتب غوراف ساشديفا:
>

مرحبًا icarito https://github.com/icarito ، هل يمكننا زيادة ذاكرة الوصول العشوائي لـ
الخادم؟ ربما سيساعد ذلك في تسريع الموقع حتى نقوم بذلك
تحسين معدل استجابة الاستعلام لدينا؟

شكرا!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
<
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW97
و
أو كتم الخيط
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVM11
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

أوه ، icarito ، لا ، لا ، لم أشعر بأي اتهام ، على الإطلاق. قرأت ، "هذا ما يحدث" وكنت أقول فقط "هذا غريب ، لماذا يفعل ذلك إذا لم يكن هناك أحد ...؟" على نفس المنوال ، لم أقصد الإشارة إلى أن التوثيق كان سيئًا. فقط أنه ليس عليك شرح ذلك إذا كان هناك أي شيء.

مهلا ، إنه ليس اتهامًا لا أساس له من الصحة تمامًا :) على الرغم من أنني أستمتع قليلاً بالتظاهر بأنني كنت مؤطّرًا وأنني ذهبت تحت الأرض ويجب أن أثبت براءتي ، لكن هذا سيناريو آخر بالكامل أعمل عليه .

الحمد لله هذه الاتهامات الباطلة التي لا أساس لها. ) في كلا الجزأين تم توضيحهما ويمكننا العودة إلى العمل في متناول اليد.

سؤال ذو صلة: لماذا تكون وحدة التحكم في الإحصائيات نشطة إذا لم يستخدمها أحد أم أن هذا هو اللغز؟

بخصوص المرحلة ، شكرا على الشرح. للتأكد من أنني حصلت ، أقول ...

سأحاول هذا في مثيل التدريج المستقر.

... قابلة للتبديل مع القول ، "سأحاول ذلك على موقع Stable.publiclab.org"؟

إلى موقع stabil.publiclab.org س - نعم! وهذا مبني على أي دفع لـ
الفرع master - أتمنى أن يساعدك ذلك!

يوم الأربعاء 19 يونيو 2019 الساعة 3:19 مساءً Benjamin Sugar [email protected]
كتب:

أوه ، icarito https://github.com/icarito ، لا ، لا ، لم أشعر بأي شيء
الاتهام ، لا على الإطلاق. قرأت ، "هذا ما يحدث" وكنت فقط
يقول "هذا غريب ، لماذا يفعل ذلك إذا لم يكن هناك أحد ...؟"
على نفس المنوال ، لم أقصد الإشارة إلى أن التوثيق كان سيئًا.
فقط أنه ليس عليك شرح ذلك إذا كان هناك أي شيء.

مهلا ، إنه ليس اتهامًا لا أساس له على الإطلاق :) على الرغم من أنني كذلك
أستمتع قليلاً بالتظاهر بأنني قد تم تأطري وذهبت
تحت الأرض ويجب أن أثبت براءتي ولكن هذا شيء آخر تمامًا
السيناريو الذي أعمل عليه.

الحمد لله هذه الاتهامات الباطلة التي لا أساس لها. ) على كلا الجزأين لديك
تمت تصفيته ويمكننا العودة إلى العمل في متناول اليد.

السؤال ذو الصلة: لماذا تكون وحدة التحكم في الإحصائيات نشطة إذا لم يكن هناك أحد
استخدامه أم أن هذا اللغز؟

بخصوص المرحلة ، شكرا على الشرح. للتأكد من أنني حصلت ،
يقول...

سأحاول هذا في مثيل التدريج المستقر.

... قابلة للتبديل مع القول ، "سأحاول ذلك على موقع Stable.publiclab.org"؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW50
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@ jywarren ، نعم! حصلت الآن. شكرا لك!

شكرا للتوضيح skilfullycurled !
إنه بالفعل لغز لماذا يكون StatsController نشطًا جدًا؟

قبل لحظات وجيزة ، كان لدينا ذروة أخرى أطاحت بنا لبضع دقائق:

المشغل في هذه الحالة كان في الواقع البحث عن النص الكامل.
ولكن يمكن للمرء أن يرى أنه حتى في هذه الشريحة الزمنية القصيرة (3 دقائق) ، تم استدعاء StatsController 21 مرة .

أعتقد أن هذا قد يؤثر بشكل كبير على أدائنا الأساسي. إذا كان هذا الاستخدام غير معروف ، فربما تصل برامج الزحف إلى نقاط النهاية هذه؟ ربما يعمل ملف robots.txt أو بعض عناصر التحكم في الوصول على إصلاحه؟

jywarren شكرًا للتوضيح ، سأفعل ذلك في أسرع وقت ممكن.

في الواقع ، إليك تفاصيل Statscontroller لشريحة زمنية سابقة:

هل يجب أن نقوم بملف robots.txt بجميع مسارات الإحصائيات؟ إذن / الإحصائيات * بشكل أساسي؟

يوم الخميس 20 حزيران (يونيو) 2019 الساعة 12:21 صباحًا سيباستيان سيلفا [email protected]
كتب:

في الواقع ، إليك تفاصيل Statscontroller لشريحة زمنية سابقة:
[صورة: تخيل]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253 definitely.png

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVM
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

حسنًا ، لقد فعلت ، واستثنيت أيضًا / api / * - لقد حظرنا بالفعل / الإحصائيات / النطاق *
ولكن الآن كل شيء / احصائيات *

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

في الخميس 20 يونيو 2019 الساعة 2:45 مساءً كتب جيفري وارين [email protected] :

هل يجب أن نقوم بملف robots.txt بجميع مسارات الإحصائيات؟ إذن / الإحصائيات * بشكل أساسي؟

يوم الخميس 20 حزيران (يونيو) 2019 الساعة 12:21 صباحًا سيباستيان سيلفا [email protected]
كتب:

في الواقع ، إليك تفاصيل Statscontroller لشريحة زمنية سابقة:
[صورة: تخيل]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253 definitely.png

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVM
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

إذن أنت لا تعتقد أن هذا هو التخزين المؤقت؟

يتم إنشاء ذاكرة التخزين المؤقت من خلال الاستخدام ، أي يتم إنشاؤها عند أ) انتهاء صلاحيتها ، و
ب) يأتي طلب جديد. لذلك يجب أن يطلبه شيء من أجل
ذاكرة التخزين المؤقت لإنشاء ... إذا كان بإمكاني حل مشكلتين غير مرتبطين ودمجهما
العلاقات العامة الخاصة بهم ، سأبدأ إصدارًا جديدًا للإنتاج الليلة (وإلا
غدًا) ويمكننا معرفة ما إذا كان ملف robots.txt مفيدًا على الإطلاق؟

يوم الخميس 20 يونيو 2019 الساعة 4:53 مساءً Benjamin Sugar [email protected]
كتب:

إذن أنت لا تعتقد أن هذا هو التخزين المؤقت؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/publiclab/plots2/issues/5817؟email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVB5
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

يتم استدعاء Statscontroller 5.5 مرة في الدقيقة

عبر icarito - لذا في تحديث الليلة ، يمكننا معرفة ما إذا كانت تغييرات robots.txt تساعد في ذلك.

مرحبًا jywarren ، لقد رأيت أنه تم دفع الالتزام بتحديث ملف robot.txt إلى الاستقرار منذ بضعة أيام. هل لاحظت أي تحسن؟

نعم ، سأحب التحديث! لست متأكدًا من أنني حصلت على البيانات الصحيحة ، ولكن إليك بعض الصور من كوة قبل الالتزام وبعد الالتزام وآخر 24 ساعة تقريبًا. يشير الخط الأحمر إلى وقت إجراء الالتزام. يبدو ظاهريًا أن الإجابة بنعم ، لكنها قد لا تكون مهمة ، أو ربما أفسر البيانات بشكل غير صحيح.

نعم ، أعتقد أن التحليل الكامل سيكون رائعًا. لكن الجواب القصير هو ذلك
لقد خفضنا متوسط ​​وقت الاستجابة لجميع طلبات الموقع إلى النصف تقريبًا
من 5.5+ إلى 3 أو أقل. إنه حقًا تحسن كبير. كانت
مزيج من أ) مضاعفة ذاكرة الوصول العشوائي تقريبًا من 8 إلى 15 جيجابايت ، ب) منع التسويق
bot في ملف robots.txt ، وج) حظره في تكوينات nginx أيضًا (على ما أعتقد
نطاق عنوان IP). الجزء الصعب هو مقدار bot / stats_controller
جزء منه ، لأننا لم نرغب في إعاقة الترقية الشاملة للموقع.

كان التوقيت:

1. robots.txt في حوالي 5-6 مساءً بالتوقيت الشرقي ، على ما أعتقد
2. بعد ساعات من حظر nginx ، لم نكن متأكدين من مدى سرعة ملف robots.txt
   قراءة أو احترام
3. ~ 7 صباحًا توسيع ذاكرة موقع ET يوم السبت.

على أي حال ، نحن نقوم بعمل جيد الآن. متوسط ​​الحمل <4 بدلاً من ~ 8 ،
ولدينا 6 بدلاً من 4 وحدات معالجة مركزية.

يوم الثلاثاء 25 يونيو 2019 الساعة 5:32 مساءً Benjamin Sugar [email protected]
كتب:

نعم ، سأحب التحديث! لست متأكدًا من أنني حصلت على البيانات الصحيحة ، ولكن هنا
بعض الصور من كوة قبل التنفيذ وبعد التنفيذ و
~ آخر 24 ساعة. يشير الخط الأحمر إلى وقت إجراء الالتزام. انظر يا بنى، اسمع يا بنى
السطح مثل الجواب نعم ، لكنه قد لا يكون مهمًا ، أو أنا
ربما يفسر البيانات بشكل غير صحيح.

[صورة: 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=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVB5
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

إغلاق هذا الآن!