Plots2: Investigasi masalah memori (kebocoran?)

Memperhatikan komentar @icarito :

Saya bertanya-tanya jywarren karena saya telah mengedit docker-compose-production.yml untuk menggunakan lebih sedikit proses (tidak membuat PR untuk itu). Jadi bisa saja kita membuatnya pas seperti itu.

Dan grafik ini:

Kami juga melihat banyak kesalahan pengujian SMTP:

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

Ya beban juga sangat tinggi. Dari htop dan terutama iotop tampaknya mailman cukup aktif. Itu pasti pelakunya! Sebelum 22 Mei kami menjalankannya beberapa kali sehari - jika kami dapat menjalankannya setiap beberapa menit atau lebih (tidak setiap detik!) - itu akan baik-baik saja!

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

Log diisi dengan siklus ini, tidak ada kesalahan:

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.

Sepertinya tukang pos mogok dan segera respawn!

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

Saya telah memutuskan untuk menghentikan wadah ini untuk malam ini untuk memantau efeknya pada kinerja.

Saya pikir kita juga dapat melihat pembaruan permata apa yang digabungkan pada hari-hari menjelang publikasi kode ini. Terima kasih!

Itu sangat aneh tentang tukang pos, saya akan melihat konfigurasinya tetapi saya tidak ingat ada perubahan pada tarifnya.

Oh kamu tahu apa? Kami mengaturnya untuk mencoba lagi 3 kali. Mungkin ini tumpang tindih sekarang? Setidaknya bisa meningkatkan tingkat upaya karena mencoba ulang 3 kali untuk setiap jadwal yang dijadwalkan.

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

Ok dimodifikasi selama 20 detik, yang berarti maksimal coba lagi setiap 5 detik --

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

Itu akan menjadi tingkat yang sama seperti sebelumnya ketika kami menambahkan percobaan ulang.

Oke, sekarang mengerjakan analisis setelah beberapa jam:

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

Secara keseluruhan terlihat bagus. Namun, jika dilihat lebih dekat, waktu bukanya meningkat:

Membandingkan bagian terakhir di mana itu mulai naik kembali:

ke yang sebelumnya tepat setelah reboot:

Dan kemudian ke ini dari beberapa minggu yang lalu sebelum semua masalah kita:

Kemudian akhirnya tepat setelah kami mulai melihat masalah pada 22-23 Mei:

Secara keseluruhan itu tidak konklusif.

Sumber daya:

• daftar permata dan versi yang bocor memori: https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

Salah satu hal sulit tentang ini adalah tepat di tempat kedua komit ini terjadi:

1. menonaktifkan caching pada profil (yang kemudian kami kembalikan): https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. proses pembuatan wadah berubah: https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

Saya ingin berpikir ini terkait dengan penambahan kode retry 3 times di https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 , yang saya coba ubah hari ini. Namun sebenarnya waktu muat masih lambat berkembang.

Ini bisa berarti bahwa a) ada hal lain yang mendorongnya, atau b) siklus "penyelamatan/coba lagi" itu sendiri dapat menyebabkan penumpukan kebocoran memori?

haruskah saya mengomentari kode penyelamatan/coba lagi sepenuhnya?

mungkin gantung menunggu mysql untuk mengambil sebenarnya mengambil utas?

Saya akan mencoba ini. Situs hampir tidak responsif.

Saya menghapus retry sini: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

Menyebarkan ... itu akan memakan waktu cukup lama.

Hmm sepertinya tidak terpecahkan... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok saya ingin tahu apakah pengaturan wadah memengaruhi wadah tukang pos sama sekali? Karena pada titik ini kami telah mengembalikan semua kemungkinan dari skrip tukang pos.

OK, semalam itu memuncak dan turun kembali sedikit. Tapi yang bermasalah kami masih cukup tinggi, dengan puncak sekitar 20 detik:

Panggilan rentang statistik memakan waktu hingga 40+ detik!

Mereka juga mengambil selamanya pada generasi cache:

Mungkinkah kita melihat masalah dengan cache baca/tulis?

@icarito mungkinkah ada masalah pada read/write io atau sesuatu pada pembuatan cache? Saya hanya tidak yakin mengapa perlu waktu lama untuk mengemas semua data ke dalam cache.

Permata bocor -- centang jika kami baik-baik saja

• [x] seluloid > 0.16.0, < 0.17.2
• [x] csspool < 4.0.3
• [x] anggur < 0.2.5
• [x] oj < 2.12.4
• [x] karpet merah < 3.3.3
• [x] redis = 3.3.0
• [x] sidekiq < 3.5.1
• [x] sidekiq-statistik
• [x] therubyracer < 0.12.2
• [x] zipruby <= 0,3.6

Tidak bocor tetapi masalah memori dalam hal apa pun:

• [x] admin aktif
• [x] axlsx
• [x] pekerjaan_tertunda >= 4.06
• [x] libxml-ruby < 2.9.0 dengan Nokogiri RC3
• [x] newrelic_rpm >= 3.9.4, <= 3.9.7
• [x] sekuel >= 2.12.0
• [x] menginjak <= 1.3.5

Saya masih melihat waktu pembuatan cache yang besar ini untuk stats_controller#range dan bertanya-tanya apakah kita perlu mengubah di mana cache disimpan. Sepertinya default adalah penyimpanan file (dan saya memeriksa, kami memiliki file cache di /plots2/tmp/cache/ . Apakah kami akan terbantu dengan beralih ke cache dalam memori atau memcached , keduanya adalah perubahan yang tampaknya cukup sederhana?

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

Lihat juga https://www.skylight.io/support/performance-tips

Saya akan melihat konfigurasi email sekarang tetapi jika tidak menghasilkan apa-apa, saya akan menggabungkan ini, mematikan loop begin/rescue : #5840

Oke, langkah kami selanjutnya untuk https://github.com/publiclab/plots2/pull/5841 adalah mengembangkan strategi pemantauan jika tukang pos mati.

Menyebarkan dengan kredensial email baru, DAN penghapusan begin/rescue . Namun, saya pikir itu layak digunakan kembali dengan begin/rescue dipasang kembali jika kebocoran memori teratasi, karena itu bisa menjadi masalah kredensial email.

Kesalahan terbaru:

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

Itu di sini:

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

Memperbaiki itu! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, akhirnya relaly menerbitkan perbaikan comment.rb ....

OK, kami menunggu untuk melihat apakah antrian email keluar dan kami melihat beberapa kembali normal kemudian...

Saya meninggalkan komentar di https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii untuk menguji

Hai @jywarren Saya telah melihat ini lagi dan punya teori.

Pertama, berikut adalah grafik penggunaan RAM selama 3 bulan terakhir:

Terlihat dari grafik ini bahwa konsumsi memori kita telah meningkat selama tiga bulan terakhir!

Saya kembali setahun penuh:

Ternyata, pada tahun 2019, aplikasi kami telah meningkatkan sedikit persyaratan memori.

Teorinya adalah bahwa mengikuti lintasan konsumsi memori yang kami alami, kami mungkin telah mencapai ambang batas di mana kami telah menggunakan RAM yang tersedia dan mulai mengandalkan Swap, yang sangat memperlambat segalanya.

Peningkatan memori bisa jadi ukuran beberapa tabel kami ( rusers saya sedang melihat). Ini mungkin ada hubungannya dengan #5524 .

Kami harus menerapkan beberapa pengoptimalan, memigrasikan database ke host yang berbeda, atau menambahkan lebih banyak RAM.

Pemangkasan database pengguna spam juga sangat dianjurkan.

Saya masih condong ke kehabisan memori karena pertumbuhan aplikasi/situs, yang menyebabkan beban IO tinggi karena menukar memori "meronta-ronta" ke disk.
Saya telah memeriksa passenger-memory-stats dari penampung web dan berpikir bahwa kami dapat mengurangi kumpulan proses lebih lanjut:

Saya akan mencoba ini sebagai langkah pertama untuk memulihkan kinerja.

Saya menemukan bahwa pada Februari 2018 kami telah menghitung bahwa kami dapat menjalankan 11 proses (karena aplikasi kami membutuhkan 500mb untuk dijalankan).
Rumusnya adalah:

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

tetapi kami juga menjalankan Skylightd, plus proses untuk mengambil komentar tweet, plus Sidekick, dan juga ingin menjalankan proses tukang pos.
Sebagian besar penggunaan RAM ada di wadah web:

Dari kedua gambar di atas saya menyimpulkan bahwa kita masih dapat menyisihkan satu proses, terutama jika ini akan membuat respons lebih cepat.

Pindah ke 4 ukuran kolam proses.

Optimasi pertama dilakukan.
Menjanjikan 30 menit pertama!

Ooh!

Pada Sabtu, Jun 8, 2019, 8:47 Sebastian Silva [email protected]
menulis:

Optimasi pertama dilakukan.
Menjanjikan 30 menit pertama!
[gambar: gambar]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX58
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

OK, jadi daftar mitigasinya adalah:

• [x] kurangi kumpulan proses
• [ ] pindahkan db ke solusi google cloud db
• [ ] kurangi rusers - mungkin membangun pekerjaan di https://github.com/publiclab/plots2/issues/5450
• [ ] beralih ke memcached

Hai @jywarren dan @icarito ,

Pertama, (dan saya mengatakan ini tanpa bercanda): utas ini ternyata cukup bagus untuk dibaca. Itu memiliki semua elemen, misteri, perburuan, jalan buntu, panggilan dekat, dll.

Bagaimanapun.

Mengenai tabel rusers relatif terhadap #5450 dan #5524, ada _ pengelompokan _ yang sangat besar dalam rusers yang terjadi antara 26/4/13 - 1/1/14.

26/4/2013: 1366934400
1/1/2014: 1388534400
Rentang UID: 59627 - 420114
Pengguna: 360466

Apakah Anda ingin mencoba kueri pertama dari uji coba yang Anda jelaskan di #5450 pada sebagian grup itu?

pengguna yang belum memposting simpul, komentar, suka, atau langganan apa pun dan belum pernah masuk

Seperti yang Anda katakan, ini akan menjadi kueri yang mudah karena tidak masuk akan mencakup semua kriteria yang ada sebelumnya.

Untuk referensi tentang ukuran porsi yang setara dengan 6 bulan terakhir yang Anda usulkan di email lain: Dalam sebulan terakhir kami telah menandai ~250 posting pertama kali sebagai spam. Jadi, katakanlah dalam 6 bulan terakhir kami memiliki ~1500 pengguna yang diblokir karena spam.

Oh, dan saya kira itu membawa poin yang bagus. Jika Anda ingin membebaskan diri dari pengguna spam, Anda cukup menemukan semua pengguna yang memiliki konten yang ditandai sebagai spam dan kemudian menghapus pengguna yang mengeposkannya.

Seperti yang telah disinggung secara singkat di salah satu masalah, mungkin ada baiknya jika pengguna dengan konten pertama kali ditandai sebagai spam segera dihapus dari database.

Hai @skillfullycurled terima kasih atas masukan Anda! Jadi mayoritas pengguna adalah dari 2013-2014: Itu berarti bagi saya bahwa meskipun dapat membantu mengurangi penggunaan RAM, sebenarnya, tabel utama kami adalah sesi dan tayangan .

sesi lebih dari 30GB.
@jywarren dan @skillfullycurled - akan sangat bagus untuk membuat strategi untuk mengurangi ini dan/atau mengoptimalkan kueri menggunakan tabel ini!

Juga saya pikir memcached tidak cocok untuk masalah ini karena harus mengkonsumsi lebih banyak ram bukan lebih sedikit..

Meskipun seseorang dapat membatasi penggunaan memori memcached, saya akan tetap mencobanya!

Tidak, dari dokumen di atas:

Jika Anda menjalankan beberapa proses server Ruby on Rails (yang terjadi jika Anda menggunakan mongrel_cluster atau Phusion Passenger), maka instance proses server Rails Anda tidak akan dapat berbagi data cache satu sama lain. Penyimpanan cache ini tidak sesuai untuk penerapan aplikasi besar, tetapi dapat bekerja dengan baik untuk situs kecil dengan lalu lintas rendah dengan hanya beberapa proses server atau untuk lingkungan pengembangan dan pengujian.

Sepertinya tidak terlalu sulit untuk menyelesaikan _rsessions_:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren ayo lakukan ini!

@icarito , saya tidak yakin ini pernah dilakukan, tetapi saya memiliki akses ke database pada tahun 2016 dan saya memberi tahu semua orang bahwa sesi pengguna mengambil lebih banyak ruang daripada sisa database yang sebenarnya sejauh ini . Saya diberitahu bahwa mereka akan memerah sehingga tidak atau masalahnya tetap bahwa database terus menyimpan sesi.

Untuk memberikan perasaan, pada 2016, basis data plot _compressed_ as bz2 adalah 1.9GB (tidak ada waktu sekarang untuk dekompresi untuk ukuran sebenarnya), _uncompressed_, dengan sesi dihapus, itu adalah 518 MB

Terima kasih @skillfullycurled !!! Saya pikir saya ingat masukan Anda dari 2016, saya tidak tahu bagaimana kami melewatkan pembilasan itu, tetapi dump basis data kami hari ini terkompresi lebih dari 8GB, kemungkinan sebagian besar sesi.
Saya akan menunggu konfirmasi dari @jywarren - Saya ingin menjalankan yang berikut ini dalam produksi hari ini dan kemudian kita dapat membuatnya menjadi tugas rake atau tugas cron:

HAPUS DARI sesi WHERE updated_at < DATE_SUB(NOW(), INTERVAL 1 DAY);

Saya terlalu penasaran, file yang tidak terkompresi adalah 6,8GB jadi minus 518MB yang menempatkan kami di 6,3GB. 😆

Rsessions sebenarnya adalah dataset favorit saya yang saya miliki. Ini benar-benar use-_less_ , tapi saya suka itu sama besar jika tidak lebih besar dari kumpulan data yang saya miliki yang use-_ful_! Jika ada yang punya ide tentang apa yang harus dilakukan dengannya, beri tahu saya!

icarito ( @icarito :matrix.org) mendapatkannya dari sini https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito :matrix.org) itu harus logout setiap sesi yang tidak aktif dalam satu hari atau minggu terakhir - kita dapat men-tweaknya

Hanya mencatat di sini. Kedengarannya bagus.

Tidak stabil sepertinya butuh waktu lama... bisa dicoba

HAPUS ... DARI ... MANA ... BATAS x

Dan jalankan sebanyak yang dibutuhkan dalam produksi.

Setelah 7 jam ini masih berlangsung dalam staging. Jelas ini bukan bagaimana kami ingin melakukan ini dalam produksi dalam satu batch. Hal lain adalah bahwa setelah penghapusan, tabel akan terfragmentasi dan ukuran file tidak akan berkurang untuk tabel rssessions . Tabel perlu dibuang dan dibuat ulang untuk melepaskan sumber daya server.

Rencana saya untuk melakukan ini adalah sebagai berikut:

• [ ] Tabel sesi dump MySQL dengan where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [ ] Ganti nama tabel sesi
• [ ] Muat data bersih dari tabel yang dibuang ke tabel sesi baru
• [ ] Jatuhkan tabel sesi lama

Saya akan mencoba ini dalam contoh pementasan stable .

Ok Sebastian yang luar biasa dan saya kira ini mungkin positif
implikasi untuk peningkatan yang diharapkan pada kinerja db kami setelah ini
mitigasi selesai, bahkan jika membersihkan meja ini bisa memakan waktu selama ini...

Pada Senin, 17 Juni 2019 09:50 Sebastian Silva [email protected]
menulis:

Saya akan mencoba ini dalam contoh pementasan yang stabil.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBWZ25XLOORTEPWZ2JK45DN5WWZJJ63LN5MVXHmasalah
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Membawa @cesswairimu agar dia bisa mencoba querynya di stable lagi ketika @icarito selesai. Itu akan memberi tahu kami jika masalah di #5917 hanya terkait dengan #5490 (yang telah diperbaiki) atau jika mereka juga terkait dengan #5524.

unstable masih dihapus...

Meninggalkan beberapa catatan di sini saat melakukan pengujian dalam staging instance stable.

• [x] Tabel sesi dump MySQL dengan tempat updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
  
  
  
  • perintah: 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
  
  
  • waktu: 13 detik
  
  
• [x] Ganti nama tabel sesi
  
  
  
  • sintaks: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • laporan penjaga Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rssessions .* FROM rssessions WHER...
  
  
  • halaman rumah mencapai 500
  
  
• [x] Muat data bersih dari tabel yang dibuang ke tabel sesi baru
  
  
  
  • sintaks: 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"
  
  
  • waktu: 7 detik
  
  
  • membuat file tabel rsessions baru (13Mb untuk pementasan!)
  
  
  • mengembalikan beranda
  
  
• [x] Jatuhkan tabel sesi lama:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Diuji https://stable.publiclab.org untuk login..

Saya siap untuk mencoba ini dalam produksi!

unstable masih dihapus...

Melakukan operasi pada basis data produksi langsung:

• [x] Tabel sesi dump MySQL dengan tempat updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
  
  
  
  • waktu: 48 detik
  
  
  • ukuran sampah: 143Mb
  
  
• [x] Ganti nama tabel sesi
  
  
  
  • waktu: 11 detik
  
  
  • halaman beranda turun selama 15 menit pada ~ 6 pagi UTC
  
  
• [x] Muat data bersih dari tabel yang dibuang ke tabel sesi baru
  
  
  
  • membuat file tabel rssessions baru (220Mb)
  
  
  • mengembalikan beranda
  
  
• [x] Jatuhkan tabel sesi lama:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • Dibebaskan ~29 GB.
  
  

Diuji https://publiclab.org - sesi dipertahankan!
:tada:

mitigasi selesai! Semoga ini akan membebaskan kita!

saya akan meninggalkannya untuk malam ini, situs terlihat cepat bagi saya... :stuck_out_tongue_closed_eyes: semoga ini dia!

OK, jadi daftar mitigasinya adalah:

• [x] kurangi kumpulan proses

• [ ] pindahkan db ke solusi google cloud db

• [x] kurangi rsessions

• [ ] beralih ke memcached

Hmm, pagi ini sangat cepat, tapi secara keseluruhan saya tidak melihat perbedaan yang besar! 😞

Tidakuuuuuuuu! Nah, hanya ada satu penjelasan lain dan itu adalah hantu. Saya akan membuka edisi lain dan mencari untuk menemukan permata pengusir setan atau ghostbusters.

Saya pikir sebenarnya ada peningkatan pada penggunaan I/O karena menggunakan tabel 30GB itu berat - jika Anda melihat lebih dekat, puncak tampaknya terkait dengan Statscontroller ... mungkin kita bisa melakukan pekerjaan statistik pada pementasan? Saya bisa membuatnya menyalin database produksi secara teratur mengatakan mingguan?

Hai @icarito , saya ingin tahu apakah Anda dapat menjawab beberapa pertanyaan "pendidikan" untuk saya:

jika Anda melihat lebih dekat, puncak tampaknya terkait dengan Statscontroller ...

Mengapa ini terjadi? Karena caching? Saya hanya bisa memikirkan tiga orang yang akan menggunakannya dan saya salah satunya dan saya belum pernah menggunakannya.

mungkin kita bisa melakukan pekerjaan statistik pada pementasan?

Saya telah mendengar ... er ... melihat Anda menggunakan kata "pementasan" akhir-akhir ini. Apa itu dan bagaimana cara memainkannya di situs/alur kerja? Jika itu adalah bagian dari dokumen, beri tahu saya yang mana dan saya akan mencoba memahaminya terlebih dahulu.

Saya bisa membuatnya menyalin database produksi secara teratur mengatakan mingguan?

Saya pikir itu bagus. Bukan karena data terbaru yang penting, tetapi antara sistem Q&A yang diubah dan migrasi tag terbaru, saya kira mingguan adalah ide yang bagus karena akan menangkap perubahan struktural apa pun saat mereka masuk. @cesswairimu , bagaimana menurut Anda ?

Ini adalah utas yang benar-benar luar biasa untuk dibaca. Ya itu ide bagus memiliki statistik di panggung dan menyalin setiap minggu juga baik-baik saja: +1:
Saya telah memikirkan ini di masa depan untuk membuat statistik menanyakan skrip yang membuat tampilan sql dan dihapus dan dibuat ulang setiap hari/atau mingguan oleh pekerjaan dan mungkin ini juga dapat hidup di panggung. Ingin mendengar pendapat Anda tentang ini dan jika ini dapat membantu kebocoran memori dengan cara apa pun.

Hai @icarito , bisakah kita menambah RAM server? Mungkin itu akan membantu mempercepat situs web hingga kami meningkatkan tingkat respons kueri kami?

Terima kasih!

Terima kasih atas balasan Anda! Saya berterima kasih atas pekerjaan yang Anda lakukan dan untuk membalas masalah ini dan membaca upaya kami! Saya tidak ingin terdengar menuduh atau apa! Saya hanya melihat data dan mencoba meningkatkan keandalan situs kami.
Misalnya kami mendapat puncak pagi ini: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

Kami juga melihat puncak setiap malam (6AM UTC) pada cadangan selama beberapa jam.

Mengenai pementasan dan produksi, saat ini kami memiliki tiga contoh:

Contoh | URL | Buat log | Ruang kerja
-----------|-------|------------|-------------
| tidak stabil | 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/
| produksi | https://publiclab.org/ | t/a | tidak ada

Anda benar bahwa dokumentasi bijaksana kita harus melakukan pekerjaan yang lebih baik menggambarkan proses ini. Saat ini saya menemukan beberapa dokumen di sini https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches tetapi tidak jelas sama sekali bahwa cabang-cabang ini dibangun ketika kami mendorong ke cabang-cabang itu.

Basis data saat ini sering diperbarui secara manual tetapi seharusnya mudah untuk mengotomatiskannya sekarang karena kami memiliki dump basis data harian. Saya akan mengaturnya dan melakukan ping kepada Anda!

Ini tidak berarti kita tidak boleh mengimplementasikan lebih banyak solusi, selanjutnya saya pikir server web berulir (Puma) dapat membantu!

Itu pertanyaan yang bagus! Kami sedang dalam proses memindahkan hosting kami ke
penyedia baru dan berharap untuk digunakan sebagai kluster kontainer di yang baru
penyedia hosting.

Karena menjalankan dalam wadah tidak langsung sepele (karena aplikasi kami
container tidak dapat diubah) - alternatif untuk memulai adalah kita bisa
pindahkan database terlebih dahulu untuk memberi ruang.

Saya tidak berpikir kami harus meningkatkan penggunaan hosting kami di host kami saat ini
karena kami hampir tidak memenuhi kuota yang diizinkan, tetapi @jywarren dapat mengonfirmasi?

Terima kasih atas pekerjaan Anda!

Pada 19/06/19 11:23, Gaurav Sachdeva menulis:
>

Hai @icarito https://github.com/icarito , bisakah kita menambah RAM RAM
server? Mungkin itu akan membantu dalam mempercepat situs web sampai kami
meningkatkan tingkat respons kueri kami?

Terima kasih!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW3JKDYLNMVX17
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

Sebenarnya saya ingin tahu apakah kami dapat meningkatkan sementara ram kami di wadah itu
sampai kita melakukan langkah dan jika itu akan membantu jangka pendek. Saya pikir kita akan baik-baik saja
dengan biaya yang meningkat!

Pada Wed, Jun 19, 2019, 12:59 Sebastian Silva [email protected]
menulis:

Itu pertanyaan yang bagus! Kami sedang dalam proses memindahkan hosting kami ke
penyedia baru dan berharap untuk digunakan sebagai kluster kontainer di yang baru
penyedia hosting.

Karena menjalankan dalam wadah tidak langsung sepele (karena aplikasi kami
container tidak dapat diubah) - alternatif untuk memulai adalah kita bisa
pindahkan database terlebih dahulu untuk memberi ruang.

Saya tidak berpikir kami harus meningkatkan penggunaan hosting kami di host kami saat ini
karena kami hampir tidak memenuhi kuota yang diizinkan, tetapi @jywarren dapat mengonfirmasi?

Terima kasih atas pekerjaan Anda!

Pada 19/06/19 11:23, Gaurav Sachdeva menulis:
>

Hai @icarito https://github.com/icarito , bisakah kita menambah RAM RAM
server? Mungkin itu akan membantu dalam mempercepat situs web sampai kami
meningkatkan tingkat respons kueri kami?

Terima kasih!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
<
Https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBZW63CMORNIMVX197
,
atau matikan utasnya
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMZ3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVVW63DYLNMVX
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

Oh, @icarito , tidak, tidak, saya tidak merasakan tuduhan apa pun, tidak sama sekali. Saya membaca, "inilah yang terjadi" dan saya hanya mengatakan "aneh, mengapa melakukan itu jika tidak ada orang di dalamnya...?" Sejalan dengan itu, saya tidak bermaksud menyiratkan bahwa dokumentasinya buruk. Hanya saja Anda tidak perlu menjelaskannya jika ada.

Dan hei, itu bukan tuduhan yang sepenuhnya tidak berdasar :) meskipun saya bersenang-senang berpura-pura bahwa saya telah dijebak dan saya pergi ke bawah tanah dan harus membuktikan bahwa saya tidak bersalah, tetapi itu adalah skenario lain yang sedang saya kerjakan .

Syukurlah tuduhan-tuduhan yang mengerikan dan tidak berdasar ini; ) pada keduanya adalah bagian yang telah dibersihkan dan kita dapat kembali ke bisnis yang ada.

Pertanyaan terkait: Mengapa pengontrol statistik aktif jika tidak ada yang menggunakannya atau apakah itu misteri?

Mengenai pementasan, terima kasih atas penjelasannya. Untuk memastikan aku punya, mengatakan...

Saya akan mencoba ini dalam contoh pementasan yang stabil.

...bisa diganti dengan mengatakan, "Saya akan mencoba ini di stable.publiclab.org"?

Ke stable.publiclab.org T -- ya! Dan itu dibangun dari dorongan apa pun untuk
cabang master - semoga membantu!

Pada Wed, Jun 19, 2019 at 15:19 Benjamin Gula [email protected]
menulis:

Oh, @icarito https://github.com/icarito , tidak, tidak, saya tidak merasakan apapun
tuduhan, tidak sama sekali. Saya membaca, "inilah yang terjadi" dan saya hanya
mengatakan "itu aneh, mengapa melakukan itu jika tidak ada orang di dalamnya ...?"
Sejalan dengan itu, saya tidak bermaksud menyiratkan bahwa dokumentasinya buruk.
Hanya saja Anda tidak perlu menjelaskannya jika ada.

Dan hei, itu bukan tuduhan yang sepenuhnya tidak berdasar :) meskipun saya although
bersenang-senang berpura-pura bahwa saya telah dijebak dan saya telah pergi
bawah tanah dan harus membuktikan bahwa saya tidak bersalah, tetapi itu adalah hal lain
skenario yang saya kerjakan.

Syukurlah tuduhan-tuduhan yang mengerikan dan tidak berdasar ini; ) pada keduanya adalah bagian memiliki
telah dibersihkan dan kita bisa kembali ke bisnis di tangan.

Pertanyaan terkait: Mengapa pengontrol statistik aktif jika tidak ada orang
menggunakannya atau itu misteri?

Mengenai pementasan, terima kasih atas penjelasannya. Untuk memastikan aku punya,
mengatakan...

Saya akan mencoba ini dalam contoh pementasan yang stabil.

...bisa diganti dengan mengatakan, "Saya akan mencoba ini di stable.publiclab.org"?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNDMVXHJKTDN1
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren , yup! Punya sekarang. Terima kasih!

Terima kasih atas klarifikasinya @skillfullycurled !
Memang menjadi misteri mengapa StatsController begitu aktif?

Beberapa saat yang lalu kami memiliki puncak lain yang menjatuhkan kami selama beberapa menit:

Pemicu dalam hal ini sebenarnya adalah Pencarian Teks Lengkap.
Tetapi orang dapat melihat bahwa bahkan dalam potongan waktu yang singkat ini (3 menit), StatsController dipanggil sebanyak 21 kali .

Saya pikir ini mungkin secara signifikan mempengaruhi kinerja dasar kami. Jika penggunaan ini tidak diketahui, maka mungkin perayap mencapai titik akhir ini? Mungkin robots.txt atau beberapa kontrol akses akan memperbaikinya?

@jywarren terima kasih atas klarifikasinya, saya akan segera melakukannya.

Sebenarnya inilah detail Statscontroller untuk timeslice sebelumnya:

Haruskah kita robots.txt semua rute statistik? Jadi /stats* pada dasarnya?

Pada Kam, 20 Jun 2019 pukul 12:21 Sebastian Silva [email protected]
menulis:

Sebenarnya inilah detail Statscontroller untuk timeslice sebelumnya:
[gambar: gambar]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMZW3JKDYLNMVX58
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Oke, saya lakukan, dan juga mengecualikan /api/* - kami telah memblokir /stats/range*
tapi sekarang semua /stats*

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

Pada Kamis, 20 Juni 2019 pukul 14:45 Jeffrey Warren [email protected] menulis:

Haruskah kita robots.txt semua rute statistik? Jadi /stats* pada dasarnya?

Pada Kam, 20 Jun 2019 pukul 12:21 Sebastian Silva [email protected]
menulis:

Sebenarnya inilah detail Statscontroller untuk timeslice sebelumnya:
[gambar: gambar]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMZW3JKDYLNMVX58
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Jadi menurut Anda itu bukan caching?

Cache dihasilkan oleh penggunaan, yaitu, dibuat ketika a) kedaluwarsa, DAN
b) permintaan baru masuk. Jadi, sesuatu harus memintanya untuk
cache untuk menghasilkan ... jika saya dapat menyelesaikan beberapa masalah yang tidak terkait dan menggabungkan
PR mereka, saya akan memulai publikasi baru untuk produksi malam ini (jika tidak
besok) dan kita dapat melihat apakah robots.txt membantu?

Pada Kam, 20 Jun 2019 pukul 16.53 Benjamin Sugar [email protected]
menulis:

Jadi menurut Anda itu bukan caching?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
Https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW4issue
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller dipanggil 5,5 kali per menit

melalui @icarito - jadi pada pembaruan malam ini kita dapat melihat apakah perubahan robots.txt membantu ini.

Hai @jywarren , saya melihat komit pembaruan robot.txt didorong ke stabil beberapa hari yang lalu. Adakah peningkatan yang Anda perhatikan?

Ya, akan menyukai pembaruan! Tidak yakin saya mengambil data yang benar, tetapi inilah beberapa gambar dari skylight sebelum komit, setelah komit, dan ~ 24 jam terakhir. Garis merah menunjukkan kapan komit dibuat. Tampak di permukaan seperti jawabannya adalah ya, tetapi mungkin tidak signifikan, atau saya mungkin salah menafsirkan data.

Ya saya pikir analisis lengkap akan bagus. Tapi jawaban singkatnya adalah
kami hampir mengurangi separuh waktu respons masalah rata-rata kami untuk semua permintaan situs
dari 5,5+ hingga 3 atau kurang. Ini benar-benar peningkatan besar. Itu merupakan
kombinasi dari a) hampir dua kali lipat RAM dari 8-15GB, b) memblokir pemasaran
bot di robots.txt, dan c) memblokirnya di konfigurasi nginx juga (saya pikir dengan
rentang alamat IP). Bagian yang sulit adalah seberapa banyak bot/stats_controller itu
sebagian, karena kami tidak ingin menunda peningkatan situs secara keseluruhan.

Waktunya adalah:

1. robots.txt sekitar jam 5-6 sore ET, saya pikir
2. nginx memblokir beberapa jam kemudian setelah kami tidak yakin seberapa cepat robots.txt itu
   baca atau hormati
3. ~7am ET ekspansi memori situs pada hari Sabtu.

Bagaimanapun, kami melakukannya dengan sangat baik sekarang. Rata-rata beban <4 bukannya ~8,
dan kami memiliki 6 bukannya 4 CPU.

Pada Tue, Jun 25, 2019 at 17:32 Benjamin Gula [email protected]
menulis:

Ya, akan menyukai pembaruan! Tidak yakin saya mengambil data yang benar, tapi ini
beberapa gambar dari skylight sebelum komit, setelah komit, dan
terakhir ~ 24 jam. Garis merah menunjukkan kapan komit dibuat. terlihat pada
permukaan seperti jawabannya adalah ya, tetapi mungkin tidak signifikan, atau saya
mungkin salah menafsirkan data.

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

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBF4ZLOVORPWQ75W63LNMVXF4issue
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

Tutup ini sekarang!