Plots2: Untersuchung von Speicherproblemen (Leck?)

Beachten Sie den Kommentar von

Ich frage mich, jywarren, weil ich docker-compose-production.yml bearbeitet hatte, um weniger Prozesse zu verwenden (keine PR dafür erstellt). Es könnte also sein, dass wir es einfach so gemacht haben.

Und diese Grafik:

Wir sehen auch viele SMTP-Testfehler:

Link: | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZyu

Ja, die Belastung ist auch sehr hoch. Von den htop und insbesondere von iotop scheint mailman ziemlich aktiv zu sein. Es ist mit Sicherheit der Täter! Vor dem 22. Mai haben wir es ein paar Mal am Tag laufen lassen - wenn wir es alle paar Minuten Minute oder so laufen lassen können (nicht jede Sekunde!) - wäre es in Ordnung!

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

Das Protokoll wird mit Zyklen davon gefüllt, kein Fehler:

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.

Sieht so aus, als würde der Postbote abstürzen und sofort wieder erscheinen!

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

Ich habe beschlossen, diesen Container für heute Abend zu stoppen, um die Auswirkungen auf die Leistung zu überwachen.

Ich denke, wir können uns auch ansehen, welche Gems Updatea in den Tagen vor dieser Code-Veröffentlichung zusammengeführt wurden. Vielen Dank!

Das ist so seltsam an Mailman, ich werde mir die Konfiguration ansehen, aber ich erinnere mich an keine Änderungen an der Rate.

Ach weißt du was? Wir haben es so eingestellt, dass es dreimal wiederholt wird. Vielleicht überschneiden sich diese jetzt? Es hätte zumindest die Anzahl der Versuche erhöhen können, da es für jede geplante Ausführung dreimal wiederholt wird.

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

Ok hat es für 20 Sekunden geändert, was maximal alle 5 Sekunden einen Wiederholungsversuch bedeuten sollte --

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

Dies ist die gleiche Rate wie zuvor, als wir Wiederholungen hinzugefügt haben.

OK, jetzt arbeite ich nach ein paar Stunden an der Analyse:

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

Insgesamt sieht gut aus. Aber bei näherer Betrachtung nimmt die Ladezeit zu:

Vergleichen Sie den letzteren Teil, in dem es beginnt, wieder nach oben zu gehen:

zum früheren direkt nach dem Neustart:

Und dann zu diesem von vor ein paar Wochen vor all unserem Ärger:

Dann endlich, kurz nachdem wir vom 22. bis 23. Mai Probleme gesehen haben:

Insgesamt ist es nicht schlüssig.

Ressourcen:

• eine Liste von speicherleckenden Edelsteinen und Versionen: https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

Eines der schwierigen Dinge dabei ist, dass es genau dort ist, wo diese beiden Commits passiert sind:

1. Caching in Profilen deaktivieren (das wir später wieder rückgängig gemacht haben): https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. die Container-Build-Prozessänderung: https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

Ich würde gerne denken, dass es mit dem Hinzufügen des retry 3 times Codes in https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 zusammenhängt , den ich heute versucht habe zu optimieren. Aber tatsächlich wachsen die Ladezeiten immer noch langsam.

Dies könnte bedeuten, dass a) etwas anderes es antreibt oder b) der "Rettungs-/Wiederholungszyklus" selbst zum Aufbau von Speicherlecks führen könnte?

Soll ich den Rettungs-/Wiederholungscode vollständig auskommentieren?

Vielleicht nimmt das Hängenbleiben, das darauf wartet, dass MySQL abgeholt wird, tatsächlich Threads auf?

Ich werde das versuchen. Die Site reagiert fast nicht mehr.

Ich habe das retry hier entfernt: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

Die Bereitstellung... wird eine Weile dauern.

Hmm, es scheint wirklich nicht gelöst zu sein ... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok, ich frage mich, ob das Container-Setup den Postboten-Container überhaupt beeinflusst hat? Denn an dieser Stelle haben wir alle wahrscheinlichen Dinge aus dem Mailman-Skript zurückgesetzt.

OK, über Nacht erreichte es seinen Höhepunkt und ging ein wenig zurück. Aber unsere problematischen sind immer noch ziemlich hoch, mit Spitzen bei etwa 20 Sekunden:

Die Statistik-Range-Anrufe dauern bis zu 40+ Sekunden!

Sie brauchen auch ewig bei der Cache-Generierung:

Könnten wir ein Problem mit dem Cache-Lese-/Schreibzugriff sehen?

@icarito könnte es ein Problem mit dem Lese-/Schreib-IO oder etwas bei der Cache-Generierung geben? Ich bin mir nur nicht sicher, warum es so lange dauern sollte, alle Daten in den Cache zu packen.

Undichte Edelsteine ​​– kreuzen Sie an, ob es uns gut geht

• [x] Zelluloid > 0,16,0, < 0,17,2
• [x] CSS-Pool < 4.0.3
• [x] Traube < 0.2.5
• [x] oj < 2.12.4
• [x] roter Teppich < 3.3.3
• [x] redis = 3.3.0
• [x] Sidekiq < 3.5.1
• [x] Sidekiq-Statistik
• [x] Therubyracer < 0.12.2
• [x] Ziprubin <= 0.3.6

Nicht undicht, aber in jedem Fall Speicherprobleme:

• [x] aktivadmin
• [x] Achsenx
• [x] verzögerter_job >= 4.06
• [x] libxml-ruby < 2.9.0 mit Nokogiri RC3
• [x] newrelic_rpm >= 3.9.4, <= 3.9.7
• [x] Fortsetzung >= 2.12.0
• [x] stampfen <= 1.3.5

Ich sehe immer noch diese enorme Cache-Generierungszeit für stats_controller#range und frage mich, ob wir optimieren müssen, wo der Cache gespeichert wird. Es sieht so aus, als ob die Standardeinstellung die Dateispeicherung ist (und ich habe überprüft, wir haben Cache-Dateien in /plots2/tmp/cache/ . Würde uns der Wechsel zu In-Memory-Caching oder memcached helfen, die beide sind? anscheinend ziemlich einfache Änderungen?

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

Siehe auch https://www.skylight.io/support/performance-tips

Ich schaue mir jetzt die E-Mail-Konfiguration an, aber wenn sie nichts ergibt, füge ich dies zusammen und schalte die begin/rescue Schleife aus: #5840

OK, unser nächster Schritt für https://github.com/publiclab/plots2/pull/5841 ist die Entwicklung einer Überwachungsstrategie für den Fall, dass der Postbote ausfällt.

Bereitstellung mit den neuen E-Mail-Anmeldeinformationen UND der Entfernung von begin/rescue . Ich denke jedoch, gehandelt haben könnte.

Letzter Fehler:

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>'

Das ist hier:

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

Habe das behoben! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, endlich relaly veröffentlichen den Kommentar.rb Fix ....

OK, wir warten ab, ob die E-Mail-Warteschlange leer ist und wir sehen, dass dann etwas zur Normalität zurückkehrt...

Ich habe einen Kommentar auf https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii zum Testen hinterlassen

Hallo @jywarren Ich habe mir das noch einmal angesehen und habe eine Theorie.

Hier zunächst eine Grafik für die RAM-Nutzung der letzten 3 Monate:

Aus dieser Grafik ist ersichtlich, dass der Speicherverbrauch in den letzten drei Monaten zugenommen hat!

Ich ging ein ganzes Jahr zurück:

Anscheinend hat unsere Anwendung im Jahr 2019 ihren Speicherbedarf erheblich erhöht.

Die Theorie ist, dass wir nach der Entwicklung des Speicherverbrauchs, die wir hatten, möglicherweise einen Schwellenwert erreicht haben, an dem wir verfügbaren RAM verbraucht haben und begonnen haben, uns auf Swap zu verlassen, was die Dinge erheblich verlangsamt.

Der Speicherzuwachs könnte durchaus die Größe einiger unserer Tabellen haben ( rusers schaue ich mir an). Dies kann eine Beziehung zu #5524 haben.

Wir müssen einige Optimierungen implementieren, die Datenbank auf einen anderen Host migrieren oder mehr RAM hinzufügen.

Es wird auch dringend empfohlen, die Datenbank von Spam-Benutzern zu bereinigen.

Ich neige immer noch zur Erschöpfung des Speichers aufgrund des App- / Site-Wachstums, was zu einer hohen IO-Last aufgrund des "Thrashing" des Swap-Speichers auf der Festplatte führt.
Ich habe unser passenger-memory-stats aus dem Webcontainer überprüft und denke, dass wir den Prozesspool weiter reduzieren können:

Ich werde dies als ersten Schritt versuchen, um die Leistung zu verbessern.

Ich fand heraus, dass wir im Februar 2018 berechnet hatten, dass wir 11 Prozesse ausführen können (da unsere App 500 MB zum Ausführen benötigte).
Die Formel lautet:

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

aber wir führen auch Skylightd aus, plus einen Prozess zum Abrufen von Tweet-Kommentaren, plus Sidekick und möchten auch den Mailman-Prozess ausführen.
Der Großteil der RAM-Nutzung befindet sich im Webcontainer:

Aus den beiden obigen Bildern leite ich ab, dass wir uns noch einen Vorgang ersparen können, insbesondere wenn dies schnellere Antworten ermöglicht.

Umstellung auf die Poolgröße von 4 Prozessen

Erste Optimierung durchgeführt.
Vielversprechende erste 30 Minuten!

Oh!

Am Sa, 08.06.2019, 20:47 Uhr Sebastian Silva [email protected]
schrieb:

Erste Optimierung durchgeführt.
Vielversprechende erste 30 Minuten!
[Bild: Bild]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DN18WQ5
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

OK, die Liste der Schadensbegrenzungen wäre also:

• [x] Prozesspool reduzieren
• [ ] db in die google cloud db-Lösung verschieben
• [ ] rusers reduzieren - vielleicht aufbauend auf der Arbeit in https://github.com/publiclab/plots2/issues/5450
• [ ] zu memcached wechseln

Hallo @jywarren und @icarito ,

Erstens (und das sage ich ohne Scherz): Dieser Thread hat sich tatsächlich als recht lesenswert erwiesen. Es hatte alle Elemente, ein Geheimnis, eine Jagd, Sackgassen, enge Anrufe usw.

Wie auch immer.

In Bezug auf die rusers-Tabelle relativ zu #5450 und #5524 gibt es eine _ enorme _ Gruppierung in rusern, die zwischen dem 26.04.13 und dem 01.01.14 aufgetreten ist.

26.04.2013: 1366934400
01.01.2014: 1388534400
UID-Bereich: 59627 - 420114
Benutzer: 360466

Möchten Sie die erste Abfrage des Testlaufs, den Sie in #5450 beschrieben haben, an einem Teil dieser Gruppe versuchen?

Benutzer, die keine Nodes, Kommentare, Likes oder Abonnements gepostet und sich noch nie angemeldet haben

Wie Sie sagten, wäre dies eine einfache Abfrage, da ein Nicht-Anmelden alle vorherigen Kriterien abdecken würde.

Als Referenz für die äquivalente Portionsgröße Ihrer vorgeschlagenen letzten 6 Monate in der anderen E-Mail: Im letzten Monat haben wir ~250 erstmalige Posts als Spam markiert. Nehmen wir also an, dass wir in den letzten 6 Monaten ~1500 gesperrte Benutzer aufgrund von Spam hatten.

Oh, und ich denke, das bringt einen guten Punkt. Wenn Sie sich von Spam-Benutzern befreien möchten, können Sie einfach alle Benutzer finden, deren Inhalte als Spam gekennzeichnet sind, und dann die Benutzer löschen, die diese gepostet haben.

Wie in einer der Ausgaben kurz angerissen wurde, kann es sinnvoll sein, Benutzer mit als Spam gekennzeichneten erstmaligen Inhalten sofort aus der Datenbank zu löschen.

Hi @skillcurled danke für deinen Input! Die Mehrheit der Benutzer stammt also von 2013-2014: Das bedeutet für mich, dass es zwar helfen kann, die RAM-Auslastung zu reduzieren, aber unsere Haupttabellen sind Impressions .

rsessions ist über 30 GB.
@jywarren und @skillcurled - es wäre toll, eine Strategie zu entwickeln, um dies zu reduzieren und / oder Abfragen mithilfe dieser Tabelle zu optimieren!

Ich denke auch, dass Memcached für dieses Problem nicht geeignet ist, da es mehr RAM verbrauchen sollte, nicht weniger.

Obwohl man den Speicherverbrauch von Memcached einschränken kann, werde ich es trotzdem versuchen!

Nein, aus den obigen Dokumenten:

Wenn Sie mehrere Ruby on Rails-Serverprozesse ausführen (was der Fall ist, wenn Sie mongrel_cluster oder Phusion Passenger verwenden), können Ihre Rails-Serverprozessinstanzen keine Cache-Daten miteinander teilen. Dieser Cachespeicher ist nicht für große Anwendungsbereitstellungen geeignet, kann aber gut für kleine Websites mit geringem Datenverkehr mit nur wenigen Serverprozessen oder für Entwicklungs- und Testumgebungen funktionieren.

Sieht so aus, als ob es nicht allzu schwer ist, _rsessions_ zu lösen:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren lass uns das machen!

@icarito , ich bin mir nicht sicher, ob dies jemals getan wurde, aber ich hatte 2016 Zugriff auf die Datenbank und informierte alle, dass die Benutzersitzungen bei weitem mehr Platz beanspruchten als der eigentliche Rest der Datenbank. Mir wurde gesagt, dass sie geleert werden würden, also waren sie es entweder nicht oder das Problem bleibt, dass die Datenbank die Sitzungen einfach weiterhin behält.

Um ein Gefühl zu geben, war die Plot-Datenbank ab 2016 _komprimiert_ als bz2 1,9 GB (im Moment keine Zeit, um die tatsächliche Größe zu dekomprimieren), _unkomprimiert_, mit entfernten Sitzungen waren es 518 MB

Danke @skillfullycurled !!! Ich glaube, ich erinnere mich an Ihren Beitrag aus dem Jahr 2016, ich weiß nicht, wie wir das Löschen verpasst haben, aber unsere Datenbank-Dumps sind heute über 8 GB komprimiert, wahrscheinlich hauptsächlich Sitzungen.
Ich warte auf die Bestätigung von @jywarren - ich möchte heute Folgendes in der Produktion ausführen und dann können wir daraus eine Rake-Aufgabe oder einen Cron-Job machen:

DELETE FROM Sitzungen WHERE aktualisiert_at < DATE_SUB(NOW(), INTERVAL 1 DAY);

Ich bin zu neugierig geworden, die unkomprimierte Datei ist 6,8 GB, also minus 518 MB, die uns auf 6,3 GB bringt. 😆

Die rsessions ist eigentlich mein Lieblingsdatensatz, den ich habe. Es ist völlig nutzlos, aber ich liebe es einfach, dass es so groß, wenn nicht sogar größer ist als Datensätze, die ich habe, die nutzlos sind! Wenn jemand eine Idee hat, was man damit machen kann, lass es mich wissen!

icarito ( @icarito :matrix.org) hat es von hier https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito :matrix.org) Es sollte jede Sitzung abmelden, die im letzten Tag oder in der letzten Woche nicht aktiv war - wir können es optimieren

Mach dir hier nur Notizen. Klingt gut.

Instabil scheint lange zu dauern ... kann es versuchen

LÖSCHEN ... VON ... WO ... LIMIT x

Und so oft wie nötig in der Produktion ausführen.

Nach 7 Stunden läuft dies noch in der Inszenierung. Das wollen wir natürlich nicht in der Produktion in einer einzigen Charge. Eine andere Sache ist, dass die Tabelle nach dem Löschen fragmentiert wird und die Dateigröße für die rsessions- Tabelle nicht abnimmt. Die Tabelle muss gesichert und neu erstellt werden, um Serverressourcen freizugeben.

Mein Plan dafür ist folgender:

• [ ] MySQL-Dump rsessions-Tabelle mit where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [ ] rsessions-Tabelle umbenennen
• [ ] Laden Sie saubere Daten aus der gedumpten Tabelle in die neue rsessions-Tabelle
• [ ] Alte rsessions-Tabelle löschen

Ich werde dies in der Staging-Instanz stable versuchen.

Ok super Sebastian und ich würde vermuten, dass das positiv sein kann
Auswirkungen auf die erwarteten Verbesserungen unserer DB-Leistung danach
Die Abschwächung ist abgeschlossen, wenn selbst das Löschen dieser Tabelle so lange dauern kann...

Am Mo, 17.06.2019, 21:50 Uhr Sebastian Silva [email protected]
schrieb:

Ich werde dies in einer stabilen Staging-Instanz versuchen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVZ#50ZJ45
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Bringen Sie @cesswairimu ein, damit sie ihre Abfrage auf Stable erneut versuchen kann, wenn @icarito fertig ist. Das sollte uns sagen, ob die Probleme in #5917 nur mit #5490 zusammenhängen (was behoben ist) oder ob sie auch mit #5524 zusammenhängen.

unstable wird noch gelöscht...

Hinterlassen Sie hier einige Notizen, während Sie die Staging-Stable-Instanz testen.

• [x] MySQL-Dump rsessions-Tabelle mit where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
  
  
  
  • Befehl: 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
  
  
  • Zeit: 13 s
  
  
• [x] rsessions-Tabelle umbenennen
  
  
  
  • Syntax: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • Wachposten Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • Homepage geht 500
  
  
• [x] Laden Sie saubere Daten aus der gedumpten Tabelle in die neue rsessions-Tabelle
  
  
  
  • Syntax: 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"
  
  
  • Zeit: 7 s
  
  
  • erstellt eine neue rsessions-Tabellendatei (13 MB für das Staging!)
  
  
  • stellt die Homepage wieder her
  
  
• [x] Alte rsessions-Tabelle löschen:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Getestet https://stable.publiclab.org zum Anmelden..

Ich bin bereit, dies in der Produktion zu versuchen!

unstable wird noch gelöscht...

Ausführen des Betriebs in der Live-Produktionsdatenbank:

• [x] MySQL-Dump rsessions-Tabelle mit where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
  
  
  
  • Zeit: 48 s
  
  
  • Dump-Größe: 143 MB
  
  
• [x] rsessions-Tabelle umbenennen
  
  
  
  • Zeit: 11 s
  
  
  • Homepage war um ~6 Uhr UTC für 15 Minuten nicht erreichbar
  
  
• [x] Laden Sie saubere Daten aus der gedumpten Tabelle in die neue rsessions-Tabelle
  
  
  
  • erstellt eine neue rsessions-Tabellendatei (220 MB)
  
  
  • stellt die Homepage wieder her
  
  
• [x] Alte rsessions-Tabelle löschen:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • ~29 GB freigegeben.
  
  

Getestet https://publiclab.org - Sitzung wurde beibehalten!
:tada:

Entschärfung gemacht! Hoffentlich befreit uns das!

Ich lasse es für heute Abend, die Seite sieht mir schnell aus... :stuck_out_tongue_closed_eyes: hoffentlich ist es das!

OK, die Liste der Schadensbegrenzungen wäre also:

• [x] Prozesspool reduzieren

• [ ] db in die google cloud db-Lösung verschieben

• [x] rsessions reduzieren

• [ ] zu memcached wechseln

Hmm, es war heute Morgen sehr schnell, aber insgesamt sehe ich keinen großen Unterschied! 😞

Nooooooooooooo! Nun, es gibt nur eine andere Erklärung und das sind Geister. Ich werde ein anderes Thema eröffnen und nach einem Exorzisten- oder Geisterjäger-Edelstein suchen.

Ich denke, die I/O-Nutzung hat sich tatsächlich verbessert, da die Verwendung einer 30-GB-Tabelle schwer ist - wenn Sie genau hinschauen, scheinen die Spitzen mit Statscontroller zusammenzuhängen ... vielleicht könnten wir die Statistiken beim Staging bearbeiten? Ich kann die Produktionsdatenbank regelmäßig kopieren, sagen wöchentlich?

Hey @icarito , ich habe mich gefragt, ob du mir ein paar "pädagogische" Fragen beantworten könntest:

Wenn man genau hinschaut, scheinen die Peaks mit Statscontroller zusammenzuhängen...

Warum sollte das sein? Wegen der Zwischenspeicherung? Ich kann mir nur drei Leute vorstellen, die es benutzen würden und ich bin einer von ihnen und ich war es nicht.

Vielleicht könnten wir die Statistiken über die Inszenierung bearbeiten?

Ich habe gehört, ... äh ... gesehen, dass Sie in letzter Zeit häufig das Wort "Inszenierung" verwenden. Was ist das und wie spielt es in die Site/den Workflow ein? Wenn es Teil der Dokumentation ist, lassen Sie es mich wissen, und ich werde es zuerst verstehen.

Ich kann die Produktionsdatenbank regelmäßig kopieren, sagen wöchentlich?

Ich denke, das wäre gut. Es ist nicht so sehr wichtig, dass die aktuellsten Daten wichtig sind, aber zwischen der Änderung des Q&A-Systems und der jüngsten Tag-Migration ist wöchentlich eine gute Idee, da alle strukturellen Änderungen sofort erfasst werden . ? ?

Das war ein wirklich toll zu lesender Thread. Ja, es ist eine großartige Idee, die Statistiken in der Phase zu haben und wöchentlich zu kopieren ist auch in Ordnung :+1:
Ich hatte den Gedanken, in Zukunft die Statistikabfragen zu einem Skript zu machen, das eine SQL-Ansicht erstellt und täglich / oder wöchentlich von einem Job gelöscht und neu erstellt wird, und vielleicht kann dies auch in der Phase leben. Würde gerne Ihre Meinung dazu hören und ob dies den Speicherlecks in irgendeiner Weise helfen kann.

Hey @icarito , können wir den RAM des Servers erhöhen? Vielleicht hilft das dabei, die Website zu beschleunigen, bis wir unsere Antwortrate für Anfragen verbessern?

Vielen Dank!

Danke für eure Antworten! Ich bin dankbar für die Arbeit, die Sie leisten, für die Beantwortung dieses Problems und das Durchlesen unserer Bemühungen! Ich will nicht anklagend klingen oder so! Ich schaue mir nur die Daten an und versuche, die Zuverlässigkeit unserer Website zu verbessern.
Zum Beispiel haben wir heute Morgen einen Peak bekommen: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

Wir sehen auch jede Nacht (6AM UTC) Spitzenwerte beim Backup für ein paar Stunden.

In Bezug auf Inszenierung und Produktion haben wir derzeit drei Instanzen:

Instanz | URL | Protokoll erstellen | Arbeitsplatz
-----------|-------|------------|-------------
| instabil | https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| stabil | https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| Produktion | https://publiclab.org/ | n/a | n / A

Sie haben Recht, dass wir diesen Prozess in Bezug auf die Dokumentation besser beschreiben sollten. Derzeit habe ich einige Dokumente hier https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches gefunden, aber es ist überhaupt nicht klar, dass diese Branches erstellt werden, wenn wir zu diesen Branches pushen.

Die Datenbank wird derzeit von Zeit zu Zeit manuell aktualisiert, aber es sollte einfach sein, sie zu automatisieren, da wir tägliche Datenbank-Dumps haben. Ich werde es einrichten und dich anpingen!

Dies bedeutet nicht, dass wir nicht mehr Lösungen implementieren sollten, als nächstes denke ich, dass ein Threaded-Webserver (Puma) helfen könnte!

Das ist eine gute Frage! Wir sind dabei, unser Hosting nach zu verlegen
neuer Anbieter und hofften, als Container-Cluster im neuen
Hosting-Anbieter.

Da das Ausführen in Containern nicht sofort trivial ist (weil unsere App
Container ist nicht unveränderlich) - eine Alternative zum Start ist, dass wir es könnten
Verschieben Sie zuerst die Datenbank, um Platz zu schaffen.

Ich denke nicht, dass wir unsere Hosting-Nutzung in unserem aktuellen Host erhöhen sollten
da wir kaum innerhalb unseres erlaubten Kontingents sind, aber @jywarren bestätigen kann?

Danke für deine Arbeit!

Am 19.06.19 11:23 schrieb Gaurav Sachdeva:
>

Hey @icarito https://github.com/icarito , können wir den RAM von . erhöhen
der Kellner? Vielleicht hilft das, die Website zu beschleunigen, bis wir
unsere Anfrage-Response-Rate verbessern?

Vielen Dank!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DN5WW2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

Eigentlich frage ich mich, ob wir unseren Widder in diesem Container vorübergehend verstärken könnten
bis wir den Umzug machen und ob es kurzfristig helfen würde. Ich denke, wir wären in Ordnung
mit steigenden Kosten!

Am Mi, 19.06.2019, 12:59 Uhr Sebastian Silva [email protected]
schrieb:

Das ist eine gute Frage! Wir sind dabei, unser Hosting nach zu verlegen
neuer Anbieter und hofften, als Container-Cluster im neuen
Hosting-Anbieter.

Da das Ausführen in Containern nicht sofort trivial ist (weil unsere App
Container ist nicht unveränderlich) - eine Alternative zum Start ist, dass wir es könnten
Verschieben Sie zuerst die Datenbank, um Platz zu schaffen.

Ich denke nicht, dass wir unsere Hosting-Nutzung in unserem aktuellen Host erhöhen sollten
da wir kaum innerhalb unseres erlaubten Kontingents sind, aber @jywarren bestätigen kann?

Danke für deine Arbeit!

Am 19.06.19 11:23 schrieb Gaurav Sachdeva:
>

Hey @icarito https://github.com/icarito , können wir den RAM von . erhöhen
der Kellner? Vielleicht hilft das, die Website zu beschleunigen, bis wir
unsere Anfrage-Response-Rate verbessern?

Vielen Dank!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBJ63LNWW2
,
oder den Thread stumm schalten
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNQcomment-5
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

Oh, @icarito , nein, nein, ich habe keine Anschuldigung

Und hey, das ist keine ganz unbegründete Anschuldigung :) Obwohl es mir ein bisschen Spaß macht, so zu tun, als wäre ich eingerahmt worden und ich bin untergetaucht und muss meine Unschuld beweisen, aber das ist ein ganz anderes Drehbuch, an dem ich arbeite .

Zum Glück diese reißerischen und unbegründeten Anschuldigungen; ) auf beiden sind Teile aufgeräumt und wir können uns wieder der Sache widmen.

Verwandte Frage: Warum sollte der Statistik-Controller aktiv sein, wenn ihn niemand benutzt, oder ist das das Geheimnis?

Bezüglich der Inszenierung danke für die Erklärung. Um sicher zu gehen, dass ich es habe, sage ich...

Ich werde dies in einer stabilen Staging-Instanz versuchen.

... austauschbar mit dem Spruch "Ich versuche das auf stable.publiclab.org"?

An stable.publiclab.org Q -- ja! Und das baut auf jedem Druck auf
der master -Zweig - hoffe das hilft!

Am Mittwoch, 19. Juni 2019 um 15:19 Uhr Benjamin Sugar [email protected]
schrieb:

Oh, @icarito https://github.com/icarito , nein, nein, ich habe keine gespürt
Vorwurf, gar nicht. Ich habe gelesen "das ist was passiert" und ich war einfach
"Das ist seltsam, warum sollte es das tun, wenn niemand dabei war...?"
In diesem Sinne wollte ich nicht andeuten, dass die Dokumentation schlecht ist.
Nur, dass Sie es nicht erklären mussten, wenn es welche gab.

Und hey, das ist keine ganz unbegründete Anschuldigung :) obwohl ich es bin
Ich habe ein bisschen Spaß damit, so zu tun, als wäre ich eingerahmt worden und ich bin gegangen
Untergrund und muss meine Unschuld beweisen, aber das ist eine ganz andere
Drehbuch, an dem ich arbeite.

Zum Glück diese reißerischen und unbegründeten Anschuldigungen; ) auf beiden sind Teile haben
geklärt und wir können uns wieder dem eigentlichen Geschäft widmen.

Verwandte Frage: Warum sollte der Statistik-Controller aktiv sein, wenn niemand es war?
benutzt oder ist das das Geheimnis?

Bezüglich der Inszenierung danke für die Erklärung. Um sicher zu gehen, dass ich
sagt...

Ich werde dies in einer stabilen Staging-Instanz versuchen.

... austauschbar mit dem Spruch "Ich versuche das auf stable.publiclab.org"?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOG63LNMVX2GO710D199
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren ,

Danke für die Klarstellung @skillcurled !
Es ist in der Tat ein Rätsel, warum StatsController so aktiv ist?

Vor wenigen Augenblicken hatten wir einen weiteren Höhepunkt, der uns für einige Minuten umwarf:

Auslöser war in diesem Fall eigentlich die Volltextsuche.
Aber man sieht auch in dieser kurzen Zeitscheibe (3 min), dass StatsController 21 mal aufgerufen

Ich denke, dies könnte unsere Basisleistung erheblich beeinträchtigen. Wenn diese Verwendung nicht bekannt ist, treffen Crawler möglicherweise auf diese Endpunkte? Vielleicht würde eine robots.txt oder eine Zugriffskontrolle das Problem beheben?

@jywarren danke für die Klarstellung, ich werde es dann so

Hier sind eigentlich die Statscontroller-Details für die vorherige Zeitscheibe:

Sollen wir alle Statistikrouten robots.txt? Also /stats* im Grunde?

Am Do, 20.06.2019 um 00:21 Sebastian Silva [email protected]
schrieb:

Hier sind eigentlich die Statscontroller-Details für die vorherige Zeitscheibe:
[Bild: Bild]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBJKDNcom2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

OK, habe ich und auch /api/* ausgenommen - wir hatten bereits /stats/range* blockiert
aber jetzt ist alles /stats*

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

Am Do, 20.06.2019 um 14:45 Uhr schrieb Jeffrey Warren

Sollen wir alle Statistikrouten robots.txt? Also /stats* im Grunde?

Am Do, 20.06.2019 um 00:21 Sebastian Silva [email protected]
schrieb:

Hier sind eigentlich die Statscontroller-Details für die vorherige Zeitscheibe:
[Bild: Bild]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBJKDNcom2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Du denkst also nicht, dass es am Caching liegt?

Der Cache ist nutzungsgeneriert, d. h. er wird generiert, wenn a) er abgelaufen ist UND
b) es kommt eine neue Anfrage. Also muss es etwas für die
Cache zu generieren ... wenn ich ein paar nicht verwandte Probleme lösen und zusammenführen kann
ihre PRs, ich werde heute Abend eine neue Veröffentlichung zur Produktion starten (sonst
morgen) und wir können sehen, ob die robots.txt überhaupt hilft?

Am Do, 20. Juni 2019 um 16:53 Uhr Benjamin Sugar [email protected]
schrieb:

Du denkst also nicht, dass es am Caching liegt?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOKTDN5WS2HJment5
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller wird 5,5 mal pro Minute aufgerufen

via @icarito - im heutigen Update können wir also sehen, ob Änderungen an der robots.txt dazu beitragen.

Hey @jywarren , ich habe gesehen, dass der Robot.txt-Update-Commit vor einigen Tagen auf Stable verschoben wurde. Ist Ihnen eine Verbesserung aufgefallen?

Ja, würde mich über ein Update freuen! Ich bin mir nicht sicher, ob ich die richtigen Daten erfasst habe, aber hier sind einige Bilder von Skylight vor dem Commit, nach dem Commit und den letzten ~24 Stunden. Die rote Linie zeigt an, wann der Commit durchgeführt wurde. Auf den ersten Blick sieht die Antwort so aus, als wäre sie ja, aber sie ist möglicherweise nicht signifikant, oder ich interpretiere die Daten falsch.

Ja, ich denke, eine vollständige Analyse wäre großartig. Aber die kurze Antwort ist das
wir haben unsere durchschnittliche Reaktionszeit bei Problemen für alle Site-Anfragen fast halbiert
von 5,5+ bis 3 oder weniger. Es ist wirklich eine enorme Verbesserung. Es war ein
Kombination aus a) fast Verdoppelung des Arbeitsspeichers von 8-15GB, b) Blockieren eines Marketings
bot in robots.txt und c) Blockieren auch in nginx-Konfigurationen (ich denke von
IP-Adressbereich). Der schwierige Teil ist, wie viel der Bot/stats_controller war
einen Teil davon, weil wir das gesamte Site-Upgrade nicht aufhalten wollten.

Der Zeitpunkt war:

1. robots.txt um ca. 17-18 Uhr ET, glaube ich
2. nginx-Block Stunden später, nachdem wir nicht sicher waren, wie schnell robots.txt war
   gelesen oder respektiert
3. ~7:00 Uhr ET Speichererweiterung am Samstag.

Auf jeden Fall geht es uns jetzt richtig gut. Lastdurchschnitt ist <4 statt ~8,
und wir haben 6 statt 4 CPUs.

Am Dienstag, 25. Juni 2019 um 17:32 Uhr Benjamin Sugar [email protected]
schrieb:

Ja, würde mich über ein Update freuen! Ich bin mir nicht sicher, ob ich die richtigen Daten erfasst habe, aber hier ist
einige Bilder vom Oberlicht vor dem Commit, nach dem Commit und die
dauert ~24 Stunden. Die rote Linie zeigt an, wann der Commit durchgeführt wurde. Sieh Sohn
die Oberfläche wie die Antwort ist ja, aber sie ist möglicherweise nicht signifikant, oder ich
könnte die Daten falsch interpretieren.

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

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJ
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

Schließe das jetzt ab!