Plots2: Исследование проблем с памятью (утечки?)

Отмечая комментарий @icarito :

Интересно, jywarren, потому что я отредактировал docker-compose-production.yml, чтобы использовать меньше процессов (не делал для этого PR). Так что, может быть, мы просто сделали это таким образом.

И этот график:

Мы также видим много ошибок тестирования 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

Я решил остановить этот контейнер на сегодня, чтобы оценить влияние на производительность.

Я думаю, мы также можем посмотреть, какие гемы updatea были объединены в дни, предшествовавшие публикации этого кода. Спасибо!

Это так странно с почтальоном, я посмотрю на конфиг, но не помню никаких изменений в ставке.

Знаете что? Устанавливаем на повторную попытку 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

Хорошо, интересно, повлияла ли настройка контейнера на контейнер почтальона? Потому что на этом этапе мы отменили все вероятные вещи из сценария mailman.

Хорошо, за ночь он достиг пика и немного снизился. Но наши проблемные по-прежнему довольно высоки, с пиками около 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] sidekiq-statistic
• [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 - разработать стратегию мониторинга на случай, если mailman выйдет из строя.

Развертывание с новыми учетными данными электронной почты И удалением 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

Угу, наконец-то опубликовал исправление comment.rb ....

Хорошо, мы ждем, чтобы увидеть, очистится ли очередь электронной почты, и мы увидим некоторое возвращение к нормальному состоянию, тогда ...

Я оставил комментарий на https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii для тестирования

Привет @jywarren, я еще раз посмотрел на это и у меня есть теория.

Сначала приведем график использования оперативной памяти за последние 3 месяца:

Из этого графика видно, что мы росли в потреблении памяти за последние три месяца!

Я вернулся на год назад:

Кстати, в 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, а также хотим запустить процесс mailman.
Большая часть оперативной памяти используется в веб-контейнере:

Из обоих приведенных выше изображений я сделал вывод, что мы все еще можем сэкономить один процесс, особенно если это ускорит ответы.

Переход к 4 размерам пула процессов.

Первая оптимизация сделана.
Перспективные первые 30 минут!

Ой!

В сб, 8 июня 2019 г., 20:47 Себастьян Сильва [email protected]
написал:

Первая оптимизация сделана.
Перспективные первые 30 минут!
[image: imagen]
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=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TULX63LVMV05BWWWK3TULX63LVMX5BXWMXX6C07B0B08B0B08B05B0B0B08
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

Хорошо, поэтому список смягчений будет:

• [x] уменьшить пул процессов
• [] переместить базу данных в решение облачной базы данных Google
• [] уменьшить rusers - возможно, основываясь на работе https://github.com/publiclab/plots2/issues/5450
• [] перейти на memcached

Привет, @jywarren и @icarito ,

Во-первых (и я говорю это без шуток): эта ветка на самом деле оказалась неплохим прочитанным. В нем были все элементы, тайна, охота, тупики, близкие вызовы и т. Д.

В любом случае.

Что касается таблицы рузеров, относящихся к № 5450 и № 5524, то существует _ огромная _ группировка _ русских, которая произошла между 26.04.13 - 01.01.14.

26.04.2013: 1366934400
01.01.2014: 1388534400
Диапазон UID: 59627-420114
Пользователей: 360466

Хотите попробовать выполнить первый запрос тестового прогона, описанного в # 5450, на части этой группы?

пользователи, которые не публиковали никаких нод, комментариев, лайков или подписок и никогда не входили в систему

Как вы сказали, это будет простой запрос, поскольку отказ от входа в систему когда-либо будет охватывать все критерии, которые были перед этим.

Для справки о размере порции, эквивалентном предложенному вами за последние 6 месяцев в другом электронном письме: за последний месяц мы отметили ~ 250 первых сообщений как спам. Итак, предположим, что за последние 6 месяцев у нас было ~ 1500 заблокированных пользователей из-за спама.

О, и я думаю, это поднимает хороший вопрос. Если вы хотите избавиться от пользователей спама, вы можете просто найти всех пользователей, у которых есть контент, помеченный как спам, а затем удалить пользователей, которые их разместили.

Как было кратко затронуто в одной из проблем, было бы неплохо, если бы пользователи, впервые содержащие контент, помеченные как спам, немедленно удалили из базы данных.

Привет, @skilfullycurled, спасибо за ваш вклад! Итак, большинство пользователей относятся к 2013–2014 годам : для меня это означает, что, хотя это может помочь уменьшить использование оперативной памяти, на самом деле наши основные таблицы - это впечатления .

rsessions превышает 30 ГБ.
@jywarren и @skilfullycurled - было бы здорово придумать стратегию, чтобы уменьшить это и / или оптимизировать запросы с использованием этой таблицы!

Также я думаю, что memcached не подходит для этой проблемы, поскольку он должен потреблять больше оперативной памяти, а не меньше.

Хотя можно ограничить использование памяти memcached, я все же попробую!

Нет, из документов выше:

Если вы запускаете несколько серверных процессов Ruby on Rails (что имеет место, если вы используете mongrel_cluster или Phusion Passenger), то ваши экземпляры серверных процессов Rails не смогут обмениваться данными кэша друг с другом. Это кеш-хранилище не подходит для развертывания больших приложений, но может хорошо работать для небольших сайтов с низким трафиком и всего несколькими серверными процессами или для сред разработки и тестирования.

Похоже, решить _rsessions_ не так уж и сложно:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren давай сделаем это!

@icarito, я не уверен , что это когда- либо делал, но я имел доступ к базе данных в 2016 году , и я уведомил всех , что пользовательские сессии приняли больше места , то фактический остаток базы данных на сегодняшний день. Мне сказали, что они будут сброшены, поэтому либо нет, либо проблема остается в том, что база данных просто продолжает сохранять сеансы.

Чтобы дать ощущение, по состоянию на 2016 год база данных графиков _сжатая_ как bz2 составляла 1,9 ГБ (сейчас некогда распаковывать до фактического размера), _ несжатая_, с удаленными сеансами, это было 518 МБ

Спасибо @skilfullycurled !!! Я думаю, что помню ваш вклад в 2016 году, я не знаю, как мы это пропустили, но наши дампы базы данных сегодня сжаты более 8 ГБ, скорее всего, в основном сеансы.
Я буду ждать подтверждения от @jywarren - сегодня я хотел бы запустить следующее в продакшене, и тогда мы сможем превратить его в задачу rake или задание cron:

УДАЛИТЬ ИЗ сеансов WHERE updated_at <DATE_SUB (NOW (), INTERVAL 1 DAY);

Мне стало слишком любопытно, размер несжатого файла составляет 6,8 ГБ, так что минус 518 МБ, что дает нам 6,3 ГБ. 😆

На самом деле сеансы - это мой любимый набор данных, который у меня есть. Он полностью бесполезен, но мне просто нравится, что он такой же большой, если не больше, чем наборы данных, которые у меня есть, которые полезны - _ful_! Если у кого-то есть идеи, что с этим делать, дайте мне знать!

icarito ( @icarito : matrix.org) получил его отсюда https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito : matrix.org) он должен выходить из системы каждый сеанс, который 'не был активен в последний день или неделю - мы можем настроить его

Просто делаю заметки здесь. Звучит здорово.

Нестабильность, кажется, требует долгого времени ... может попробовать

УДАЛИТЬ ... ОТ ... ГДЕ ... LIMIT x

И выполняйте столько раз, сколько необходимо в процессе производства.

Спустя 7 часов постановка все еще продолжается. Ясно, что это не то, как мы хотим делать это в производстве одной партией. Другое дело, что после удаления таблица будет фрагментирована и размер файла для rsessions table не уменьшится. Чтобы высвободить ресурсы сервера, необходимо создать дамп и воссоздать таблицу.

Мой план для этого следующий:

• [] Mysql дамп таблицы сеансов с where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [] Переименовать таблицу сеансов
• [] Загрузить чистые данные из дампа таблицы в новую таблицу сеансов
• [] Удалить старую таблицу сеансов

Я попробую это сделать в промежуточном экземпляре stable .

Хорошо, потрясающе, Себастьян, и я думаю, что это может иметь положительное значение.
последствия для ожидаемых улучшений производительности нашей базы данных после этого
смягчение последствий завершено, если даже очистка этой таблицы может занять столько времени ...

В пн, 17 июня 2019 г., 21:50 Себастьян Сильва [email protected]
написал:

Я попробую это в стабильном промежуточном экземпляре.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS443DVMVREXDNVWWK3TUL52HS443DFMVREXWOK3TUL52HS443DFMVREX4TUL52HS443DFMVREX5
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Добавление @cesswairimu, чтобы она могла снова попробовать свой запрос на стабильном сервере, когда

unstable все еще удаляет ...

Оставьте здесь несколько заметок при тестировании в промежуточном стабильном экземпляре.

• [x] Mysql dump rsessions table, где 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 с
  
  
  • создает новый файл таблицы сеансов (13Мб для постановки!)
  
  
  • восстанавливает домашнюю страницу
  
  
• [x] Удалить старую таблицу сеансов:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Протестировано https://stable.publiclab.org для входа в систему ..

Я готов попробовать это в продакшене!

unstable все еще удаляет ...

Выполнение операции с действующей производственной базой данных:

• [x] Mysql dump rsessions table, где updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY)
  
  
  
  • время: 48 с
  
  
  • размер дампа: 143Мб
  
  
• [x] Переименовать таблицу сеансов
  
  
  
  • время: 11 с
  
  
  • домашняя страница не работала в течение 15 минут примерно в 6 утра по всемирному координированному времени
  
  
• [x] Загрузить чистые данные из дампа таблицы в новую таблицу сеансов.
  
  
  
  • создает новый файл таблицы сеансов (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] уменьшить пул процессов

• [] переместить базу данных в решение облачной базы данных Google

• [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 -branches, но совсем не ясно, что эти ветки создаются, когда мы нажимаем на эти ветки.

База данных в настоящее время обновляется вручную время от времени, но теперь, когда у нас есть ежедневные дампы базы данных, это должно быть просто автоматизировать. Я его настрою и пингую!

Это не значит, что мы не должны внедрять больше решений, в следующий раз, я думаю, может помочь многопоточный веб-сервер (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=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFMVREXG43
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

На самом деле мне интересно, можем ли мы временно ускорить наш барана в этом контейнере
пока мы не переедем, и если это поможет в краткосрочной перспективе. Я думаю, у нас все будет хорошо
с увеличением стоимости!

В среду, 19 июня 2019 г., 12:59 Себастьян Сильва [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=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFMVREXG43
,
или отключить поток
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TREX52GJQ2PNVWWK3TREX63CMWWWWK3TREXW2C0VMWWWK3TREXW2C0VMWWWK3TULXW2C08C08
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

О, @icarito , нет, нет, я не чувствовал обвинений, совсем нет. Я прочитал: «Вот что происходит», и я просто сказал: «Это странно, зачем ему это делать, если на этом никого нет ...?» В том же духе я не имел в виду, что документация была плохой. Только то, что вам не нужно было объяснять это, если таковое было.

И, эй, это не совсем безосновательное обвинение :) хотя я немного развлекаюсь, делая вид, что меня подставили, я ушел в подполье и должен доказать свою невиновность, но это совсем другой сценарий, над которым я работаю .

К счастью, эти зловещие и беспочвенные обвинения; ) по обоим частям были прояснены, и мы можем вернуться к текущему делу.

Связанный вопрос: почему контроллер статистики был бы активен, если бы никто не использовал его, или это тайна?

Что касается постановки, спасибо за объяснение. Чтобы убедиться, что у меня есть, говорит ...

Я попробую это в стабильном промежуточном экземпляре.

... можно заменить словами: «Я попробую это на stable.publiclab.org»?

На stable.publiclab.org Q - да! И это построено на любом толчке
ветка master - надеюсь, что это поможет!

В среду, 19 июня 2019 г., в 15: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=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFMVREXWG43
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren ,

Спасибо за разъяснение @skilfullycurled !
Действительно, остается загадкой, почему StatsController так активен?

Несколько минут назад у нас был еще один пик, который сбил нас с ног на несколько минут:

В данном случае триггером был полнотекстовый поиск.
Но видно, что даже за этот короткий отрезок времени (3 мин) StatsController был вызван 21 раз .

Я думаю, что это может существенно повлиять на нашу базовую производительность. Если это использование неизвестно, возможно, сканеры достигают этих конечных точек? Может быть, это исправит robots.txt или какой-нибудь контроль доступа?

@jywarren спасибо за разъяснения, я постараюсь сделать это как можно скорее.

На самом деле вот детали Statscontroller для предыдущего временного интервала:

Должны ли мы robots.txt всю статистику маршрутов? Итак, / stats * в основном?

В чт, 20 июня 2019 г., в 00:21 Себастьян Сильва [email protected]
написал:

На самом деле вот детали Statscontroller для предыдущего временного интервала:
[image: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFMVREPNVWWK3TUL52HS4DFMVREK3TULX2HC4DFMVR03TULX5X4DFMVR08
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Хорошо, я сделал, и также исключил / api / * - мы уже заблокировали / stats / range *
а теперь все / статистика *

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

В четверг, 20 июня 2019 г., в 14:45 Джеффри Уоррен [email protected] написал:

Должны ли мы robots.txt всю статистику маршрутов? Итак, / stats * в основном?

В чт, 20 июня 2019 г., в 00:21 Себастьян Сильва [email protected]
написал:

На самом деле вот детали Statscontroller для предыдущего временного интервала:
[image: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFMVREPNVWWK3TUL52HS4DFMVREK3TULX2HC4DFMVR03TULX5X4DFMVR08
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Так вы не думаете, что дело в кешировании?

Кеш генерируется по факту использования, то есть создается, когда: а) срок его действия истек, И
б) поступает новый запрос. Итак, что-то должно запрашивать его для
кеш для генерации ... если я могу решить пару несвязанных проблем и объединить
их PR, я начну новую публикацию в производство сегодня вечером (в противном случае
завтра) и посмотрим, поможет ли вообще robots.txt?

В чт, 20 июня 2019 г., в 16:53 Benjamin Sugar [email protected]
написал:

Так вы не думаете, что дело в кешировании?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS443DFMVREX45WWWK3TUL52HS443DFMVREXWOK3TUL52HS443DFMVREXGWWWK3TUL52HS443DFVREX
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller вызывается 5,5 раз в минуту

через @icarito - так что в сегодняшнем обновлении мы увидим, помогают ли этому изменения robots.txt.

Привет, @jywarren , я видел, что фиксация обновления robot.txt была перенесена в стабильную несколько дней назад. Вы заметили какие-нибудь улучшения?

Да, хотелось бы обновления! Не уверен, что я получил правильные данные, но вот несколько изображений из окна в крыше до фиксации, после фиксации и за последние ~ 24 часа. Красная линия указывает, когда была сделана фиксация. На первый взгляд кажется, что ответ - да, но это может быть неважно, или я могу неправильно интерпретировать данные.

Да, я думаю, что полный анализ был бы отличным. Но краткий ответ таков:
мы почти вдвое сократили среднее время ответа на все запросы сайта
от 5,5+ до 3 и менее. Это действительно огромное улучшение. Это было
сочетание а) почти удвоения оперативной памяти с 8-15 ГБ, б) блокировки маркетинга
бота в robots.txt, и c) блокирование его в конфигурациях nginx (я думаю,
Диапазон IP-адресов). Сложность заключается в том, насколько сильно бот / stats_controller
часть этого, потому что мы не хотели сдерживать общее обновление сайта.

Время было:

1. robots.txt примерно в 17-18:00 по восточноевропейскому времени, я думаю
2. блок nginx спустя несколько часов после того, как мы не были уверены, насколько быстро был создан robots.txt.
   читал или уважал
3. ~ 7 утра по восточному времени расширение памяти сайта в субботу.

В любом случае, сейчас у нас все хорошо. Средняя нагрузка <4 вместо ~ 8,
и у нас 6 процессоров вместо 4.

Во вторник, 25 июня 2019 г., в 17: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=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS443DFMVREXDNVWWK3TUL52HS443DFMVREXDNVWWK3TUL52HS443DFMVREX
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

Закрытие сейчас!