Plots2: 메모리 문제 (누수?) 조사

@icarito 의 의견에 주목 :

나는 더 적은 프로세스를 사용하기 위해 docker-compose-production.yml을 편집했기 때문에 jywarren이 궁금합니다 (PR을하지 않았습니다). 그래서 우리가 그렇게 만들 수 있습니다.

그리고이 그래프 :

다음과 같은 많은 SMTP 테스트 오류도 발생합니다.

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

예 부하도 매우 높습니다. htop , 특히 iotop mailman 는 꽤 활동적인 것으로 보입니다. 확실히 범인입니다! 5 월 22 일 이전에는 하루에 몇 번 실행했습니다. 몇 분 단위로 실행할 수 있다면 (1 초 단위가 아닌!) 괜찮을 것입니다!

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

성능에 미치는 영향을 모니터링하기 위해 오늘 밤이 컨테이너를 중지하기로 결정했습니다.

이 코드 발행 이전에 어떤 gem updatea가 병합되었는지도 살펴볼 수있을 것 같습니다. 감사!

mailman에 대해 너무 이상해서 구성을 살펴 보 겠지만 속도에 대한 변경 사항은 기억 나지 않습니다.

오 그거 알아? 3 번 재 시도하도록 설정했습니다. 지금 겹치는 것일까 요? 예약 된 모든 실행에 대해 3 번 재 시도하므로 적어도 시도 비율이 증가했을 수 있습니다.

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

Ok는 20 초 동안 수정했습니다. 이는 5 초마다 최대 재 시도를 의미합니다.

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

재 시도를 추가했을 때와 같은 비율입니다.

이제 몇 시간 후에 분석 작업을 진행합니다.

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

전반적으로 좋아 보인다. 그러나 자세히 살펴보면로드 시간이 증가하고 있습니다.

백업이 시작되는 후반부를 비교 :

재부팅 직후 이전으로 :

그리고 우리의 모든 문제가 발생하기 몇 주 전에

마지막으로 5 월 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

오늘 조정을 시도한 https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6에 retry 3 times 코드 추가와 관련이 있다고 생각하고 싶습니다. 그러나 실제로로드 시간은 여전히 ​​천천히 증가하고 있습니다.

이것은 a) 다른 무언가가 그것을 주도하고 있거나 b) "구조 / 재시도"사이클 자체가 메모리 누수 축적을 일으킬 수 있음을 의미 할 수 있습니다.

구조 / 재시도 코드를 완전히 주석 처리해야합니까?

어쩌면 mysql이 선택하기를 기다리는 교수형이 실제로 스레드를 차지하고 있습니까?

나는 이것을 시도 할 것이다. 사이트가 거의 응답하지 않습니다.

여기에서 retry 제거 : https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

배포 중 ... 시간이 좀 걸립니다.

흠 정말 해결되지 않은 것 같습니다 ... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok 컨테이너 설정이 mailman 컨테이너에 영향을 미쳤는지 궁금합니다. 이 시점에서 우리는 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- 통계
• [x] 루비 레이서 <0.12.2
• [x] 지 루비 <= 0.3.6

누출되지 않지만 어떤 경우에도 메모리 문제 :

• [x] activeadmin
• [x] axlsx
• [x] delayed_job> = 4.06
• [x] libxml-ruby <2.9.0 with 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 제거. 그러나 메모리 누수가 해결되면 복원 된 begin/rescue 다시 배포 할 가치가 있다고 생각합니다 . 이메일 자격 증명 문제 일 수 있기 때문입니다.

최신 오류 :

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

여기에 있습니다.

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

수정했습니다! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, 마침내 comment.rb 수정을 게시합니다 ....

좋아, 우리는 이메일 대기열이 플러시되고 일부가 정상으로 돌아 오는지 확인하기를 기다리고 있습니다.

테스트를 위해 https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii 에 댓글을 남겼습니다.

안녕하세요 @jywarren 저는 이것을 두 번째 모습으로 보여주고 이론이 있습니다.

첫 번째는 지난 3 개월 동안의 RAM 사용 그래프입니다.

이 그래프를 보면 지난 3 개월 동안 메모리 사용량이 증가했음을 알 수 있습니다!

나는 일년 내내 돌아갔다.

분명히 2019 년에 우리 애플리케이션은 메모리 요구 사항을 상당히 증가 시켰습니다.

이론은 우리가 가지고있는 메모리 소비 궤적을 따라 가용 RAM을 소비하고 Swap에 의존하기 시작한 임계 값에 도달했을 수 있으며, 이는 상황을 상당히 느리게 만듭니다.

메모리 증가는 일부 테이블의 크기 일 수 있습니다 ( rusers 제가보고 있음). 이것은 # 5524와 관련이있을 수 있습니다.

최적화를 구현하거나 데이터베이스를 다른 호스트로 마이그레이션하거나 RAM을 추가해야합니다.

스팸 사용자의 데이터베이스를 정리하는 것도 적극 권장됩니다.

나는 여전히 앱 / 사이트 증가로 인한 메모리 고갈쪽으로 기울고 있으며, 이로 인해 디스크에 대한 스왑 메모리 "쓰 레싱"으로 인해 높은 IO로드가 발생합니다.
웹 컨테이너에서 passenger-memory-stats 을 확인했으며 프로세스 풀을 더 줄일 수 있다고 생각합니다.

성능을 개선하기위한 첫 번째 조치로 이것을 시도 할 것입니다.

2018 년 2 월에 11 개의 프로세스를 실행할 수 있다고 계산 했습니다 (앱 실행에 500MB가 소요 되었기 때문에).
공식은 다음과 같습니다.

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

그러나 우리는 또한 Skylightd와 트윗 댓글을 가져 오는 프로세스와 Sidekick을 실행하고 있으며 mailman 프로세스도 실행하려고합니다.
대부분의 RAM 사용은 웹 컨테이너에 있습니다.

위의 두 이미지에서 나는 특히 이것이 더 빨리 응답을 할 수 있다면 하나의 프로세스를 남겨 둘 수 있음을 알 수 있습니다.

4 개의 프로세스 풀 크기로 이동합니다.

첫 번째 최적화가 완료되었습니다.
약속 된 첫 30 분!

오!

2019 년 6 월 8 일 토요일 오후 8:47 Sebastian Silva [email protected]
썼다 :

첫 번째 최적화가 완료되었습니다.
약속 된 첫 30 분!
[이미지 : 이미지]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFWSVREXG43VMVIC5182658,WSVREXG43VMVIC5182658,issue5WWXXHJKW63LNMVXX
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

좋습니다. 완화 목록은 다음과 같습니다.

• [x] 프로세스 풀 감소
• [] DB를 Google 클라우드 DB 솔루션으로 이동
• [] rusers 줄이기-아마도 https://github.com/publiclab/plots2/issues/5450 에서 작업을 구축 할 수 있습니다.
• [] memcached

안녕하세요 @jywarren 및 @icarito ,

첫째, (그리고 농담없이 이것을 말합니다) :이 글은 실제로 꽤 좋은 읽기로 판명되었습니다. 모든 요소, 미스터리, 사냥, 막 다른 골목, 가까운 전화 등이 있습니다.

어쨌든.

# 5450 및 # 5524와 관련된 rusers 테이블과 관련하여 4/26/13-1/1/14 사이에 발생한 rusers에 _ 거대한 _ 그룹이 있습니다.

4/26/2013 : 1366934400
1/1/2014 : 1388534400
UID 범위 : 59627-420114
사용자 : 360466

해당 그룹의 일부에 대해 # 5450에서 설명한 테스트 실행의 첫 번째 쿼리를 시도 하시겠습니까?

노드, 댓글, 좋아요 또는 구독을 게시하지 않았고 로그인 한 적이없는 사용자

당신이 말했듯이, 이것은 로그인하지 않으면 이전에 온 모든 기준을 다루기 때문에 쉬운 쿼리가 될 것입니다.

다른 이메일에서 제안한 지난 6 개월과 동등한 부분 크기에 대한 참조 : 지난달에 ~ 250 개의 최초 게시물을 스팸으로 표시했습니다. 따라서 지난 6 개월 동안 스팸으로 인해 ~ 1500 명의 사용자가 차단되었다고 가정 해 보겠습니다.

아, 좋은 지적 이네요. 스팸 사용자를 제거하려면 스팸으로 표시된 콘텐츠가있는 모든 사용자를 찾은 다음 게시 한 사용자를 삭제하면됩니다.

문제 중 하나에서 간략하게 언급했듯이 스팸으로 표시된 처음 콘텐츠를 가진 사용자를 데이터베이스에서 즉시 삭제하는 것이 좋습니다.

안녕하세요 @skilfullycurled 귀하의 의견에 감사드립니다! 따라서 대부분의 ruser는 2013-2014 년입니다. 즉, RAM 사용량을 줄이는 데 도움이 될 수 있지만 실제로 주요 테이블은 rsessions 및 인상 입니다.

rsessions 가 30GB 이상입니다.
@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 년 기준으로 플롯 데이터베이스 _compressed_ as bz2는 1.9GB (실제 크기로 압축 해제 할 시간 없음), _uncompressed_, 세션이 제거 된 상태에서 518MB였습니다.

감사합니다 @skilfullycurled !!! 2016 년에 입력 한 내용을 기억하고 있습니다. 어떻게 플러싱을 놓쳤는 지 모르겠지만 오늘 데이터베이스 덤프는 압축 된 8GB 이상이며 대부분 세션 일 가능성이 높습니다.
@jywarren의 확인을 기다릴 것입니다. 오늘 프로덕션에서 다음을 실행하고 레이크 작업 또는 크론 작업으로 만들 수 있습니다.

업데이트 된 세션에서 <DATE_SUB (NOW (), INTERVAL 1 DAY);

너무 궁금해서 압축되지 않은 파일이 6.8GB이므로 518MB를 빼면 6.3GB가됩니다. 😆

rsessions는 실제로 제가 가지고있는 가장 좋아하는 데이터 세트입니다. 완전히 use-_less_이지만 use-_ful_ 인 데이터 세트보다 크지는 않지만 크기가 크다는 것을 좋아합니다! 누구든지 그것으로 무엇을 할 수 있는지에 대한 아이디어가 있으면 알려주십시오!

icarito ( @icarito : matrix.org)는 여기에서 가져 왔습니다 https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito : matrix.org) 지난 1 주일 동안 활성화되지 않은 모든 세션에서 로그 아웃해야합니다. 조정할 수 있습니다.

여기서 메모 만하세요. 멋지네요.

불안정한 시간이 걸리는 것 같습니다 ... 시도해 볼 수 있습니다

삭제 ... From ... WHERE ... LIMIT x

그리고 프로덕션에서 필요한만큼 실행합니다.

7 시간 후에도 이것은 스테이징에서 계속 진행됩니다. 분명히 이것은 단일 배치로 프로덕션에서 이것을 수행하려는 방법이 아닙니다. 또 다른 한 가지는 삭제 후 테이블이 조각화되고 rsessions 테이블의 파일 크기가 줄어들지

이를위한 나의 계획은 다음과 같습니다.

• [] where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY) MySQL 덤프 rsessions 테이블
• [] rsessions 테이블 이름 바꾸기
• [] 덤프 된 테이블에서 새 rsessions 테이블로 깨끗한 데이터로드
• [] 이전 rsessions 테이블 삭제

stable 스테이징 인스턴스에서 시도해 보겠습니다.

좋아요 Sebastian 그리고 저는 이것이 긍정적일지도 모른다고 생각합니다
이 후 DB 성능에 대한 예상 개선에 대한 의미
완화가 완료된 것입니다.이 테이블을 플러시해도 이렇게 오래 걸릴 수 있습니다.

2019 년 6 월 17 일 월요일 오후 9:50 Sebastian Silva [email protected]
썼다 :

안정적인 스테이징 인스턴스에서 시도해 보겠습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVLOBW63LNODW502913425PWSZDNMVX45TEI#63LNMVXHJKissue
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

@icarito 가 완료되면 다시 stable에서 쿼리를 시도 할 수 있도록 @cesswairimu를 가져

unstable 삭제 중 ...

스테이징 안정적인 인스턴스에서 테스트를 수행하는 동안 여기에 메모를 남겨 둡니다.

• [x] updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY) 인 Mysql 덤프 rsessions 테이블
  
  
  
  • 명령 : 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] rsessions 테이블 이름 바꾸기
  
  
  
  • 구문 : MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • 센트리 보고서 Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • 홈페이지가 500 개
  
  
• [x] 덤프 된 테이블에서 새 rsessions 테이블로 깨끗한 데이터로드
  
  
  
  • 구문 : root<strong i="38">@tycho</strong>:/srv/plots_staging/plots2# time cat /tmp/rsessions.sql | docker-comp ose exec -T db bash -c "mysql -h 127.0.0.1 -u plots plots --password=plots"
  
  
  • 시간 : 7 초
  
  
  • 새 rsessions 테이블 파일을 생성합니다 (스테이징을 위해 13Mb!)
  
  
  • 홈페이지 복원
  
  
• [x] 이전 rsessions 테이블 삭제 :
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

https://stable.publiclab.org 에서 로그인을 테스트했습니다.

프로덕션에서이 작업을 시도 할 준비가되었습니다!

unstable 여전히 삭제됩니다 ...

라이브 프로덕션 데이터베이스에서 작업 수행 :

• [x] updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY) 인 Mysql 덤프 rsessions 테이블
  
  
  
  • 시간 : 48 초
  
  
  • 덤프 크기 : 143Mb
  
  
• [x] rsessions 테이블 이름 바꾸기
  
  
  
  • 시간 : 11 초
  
  
  • 홈페이지는 UTC 기준 오전 6시 15 분 동안 다운되었습니다.
  
  
• [x] 덤프 된 테이블에서 새 rsessions 테이블로 깨끗한 데이터로드
  
  
  
  • 새 rsessions 테이블 파일 (220Mb) 생성
  
  
  • 홈페이지 복원
  
  
• [x] 이전 rsessions 테이블 삭제 :
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • 최대 29GB를 확보했습니다.
  
  

https://publiclab.org 테스트-세션이 유지되었습니다!
: tada :

완화 완료! 바라건대 이것은 우리를 자유롭게 할 것입니다!

나는 오늘 밤에 그것을 떠날 것이다, 사이트는 나에게 신속하게 보인다 ... : stuck_out_tongue_closed_eyes : 바라건대 이것이 그 것이다!

좋습니다. 완화 목록은 다음과 같습니다.

• [x] 프로세스 풀 감소

• [] DB를 Google 클라우드 DB 솔루션으로 이동

• [x] rsessions 줄이기

• [] memcached

흠, 오늘 아침은 매우 빠르지 만 전반적으로 큰 차이는 보이지 않습니다! 😞

안돼! 글쎄, 다른 설명은 하나 뿐이고 그것은 유령입니다. 나는 또 다른 문제를 열고 엑소시스트 또는 고스트 버스터 보석을 찾는 방법을 살펴볼 것입니다.

30GB 테이블을 사용하는 것이 무겁기 때문에 실제로 I / O 사용이 개선되었다고 생각합니다. 자세히 살펴보면 피크가 Statscontroller와 관련되어있는 것 같습니다. 아마도 스테이징에 대한 통계 작업을 수행 할 수 있을까요? 매주 정기적으로 프로덕션 데이터베이스를 복사하도록 만들 수 있습니까?

안녕하세요 @icarito , 저에게 "교육적인"질문에 답

자세히 보면 피크가 Statscontroller와 관련이있는 것 같습니다 ...

왜 그럴까요? 캐싱으로 인해? 나는 그것을 사용할 세 사람 만 생각할 수 있으며 나는 그들 중 한 명이고 나는 그렇지 않았습니다.

스테이징에 통계를 적용 할 수 있을까요?

들었어 .. 최근에 "스테이징"이라는 단어를 많이 사용하시는 걸 봤어. 그게 무엇이며 사이트 / 워크 플로에서 어떻게 작용합니까? 문서의 일부인 경우 어느 것을 알려 주시면 먼저 이해하도록하겠습니다.

매주 정기적으로 프로덕션 데이터베이스를 복사하도록 만들 수 있습니까?

그게 좋을 것 같아요. 최신 데이터가 중요하지는 않지만 Q & A 시스템이 변경되고 최근 태그 마이그레이션 사이에 들어 오면 구조적 변화를 포착하므로 매주 좋은 생각이라고 생각합니다. @cesswairimu , 어떻게 생각하십니까? ?

이것은 읽기에 정말 멋진 스레드였습니다. 예, 통계를 무대에두고 매주 복사하는 것도 좋은 아이디어입니다. + 1 :
나는 미래에 통계 쿼리를 SQL 뷰를 생성하고 작업에 의해 매일 / 또는 매주 삭제되고 다시 생성되는 스크립트를 만드는 것에 대한 생각을 가지고 있었고 아마도 이것은 무대에서 살 수있을 것입니다. 이것에 대한 당신의 생각을 듣고 이것이 어떤 식 으로든 메모리 누수에 도움이 될 수 있는지 듣고 싶습니다.

안녕하세요 @icarito , 서버의 RAM을 늘릴 수 있습니까? 쿼리 응답률을 개선 할 때까지 웹 사이트 속도를 높이는 데 도움이 될까요?

감사!

답장 해 주셔서 감사합니다! 여러분이 해주신 일과이 문제에 대한 답장과 노력을 통해 읽어 주셔서 감사합니다! 나는 비난이나 아무것도하고 싶지 않다! 나는 단지 데이터를보고 우리 사이트의 안정성을 향상시키기 위해 노력하고 있습니다.
예를 들어 오늘 아침 최고조에 달했습니다 : https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

또한 몇 시간 동안 백업시 매일 밤 (6AM UTC) 피크가 발생합니다.

스테이징 및 프로덕션과 관련하여 현재 세 가지 인스턴스가 있습니다.

인스턴스 | 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)가 도움이 될 수 있다고 생각합니다!

좋은 질문입니다! 우리는 호스팅을
새로운 공급자와 새로운 공급 업체에 컨테이너 클러스터로 배포하기를 원했습니다.
호스팅 제공 업체.

컨테이너에서 실행하는 것은 즉시 사소한 것이 아니기 때문에
컨테이너는 불변하지 않습니다)-시작의 대안은
공간을 확보하기 위해 먼저 데이터베이스를 이동하십시오.

현재 호스트에서 호스팅 사용량을 늘려서는 안된다고 생각합니다.
허용 된 할당량 내에 거의 도달 하지 않았지만

작업 해주셔서 감사합니다!

19/06/19 11:23에 Gaurav Sachdeva는 다음과 같이 썼습니다.
>

안녕하세요 @icarito https://github.com/icarito , RAM을 늘릴 수 있습니까?
서버? 웹 사이트 속도를 높이는 데 도움이 될 것입니다.
쿼리 응답률을 개선 하시겠습니까?

감사!

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43CMVLOBW63LNDYW503797ZLOBW63LNMVXHJKissue ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

사실 그 컨테이너에있는 숫양을 일시적으로 부스트 할 수 있을지 궁금합니다
우리가 움직일 때까지 그리고 그것이 단기적으로 도움이 될 때까지. 나는 우리가 괜찮을 것 같아
그 비용이 증가합니다!

2019 년 6 월 19 일 수요일 오후 12:59 Sebastian Silva [email protected]
썼다 :

좋은 질문입니다! 우리는 호스팅을
새로운 공급자와 새로운 공급 업체에 컨테이너 클러스터로 배포하기를 원했습니다.
호스팅 제공 업체.

컨테이너에서 실행하는 것은 즉시 사소한 것이 아니기 때문에
컨테이너는 불변하지 않습니다)-시작의 대안은
공간을 확보하기 위해 먼저 데이터베이스를 이동하십시오.

현재 호스트에서 호스팅 사용량을 늘려서는 안된다고 생각합니다.
허용 된 할당량 내에 거의 도달 하지 않았지만

작업 해주셔서 감사합니다!

19/06/19 11:23에 Gaurav Sachdeva는 다음과 같이 썼습니다.
>

안녕하세요 @icarito https://github.com/icarito , RAM을 늘릴 수 있습니까?
서버? 웹 사이트 속도를 높이는 데 도움이 될 것입니다.
쿼리 응답률을 개선 하시겠습니까?

감사!

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43CMVLOBW63LNDYW5037972ZLOBW63LNMVXHJKTDNMVXHJKcomment
,
또는 스레드 음소거
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFWSVREXG43VMVFCBW63LNMVWXHORPW63LNMVXHORP
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

오, @icarito , 아니, 아니, 전혀 비난을 느끼지 못했습니다. 나는 "이게 무슨 일이 일어나고 있는지"라고 읽었고 "이상한데, 아무도 없다면 왜 그렇게 했을까 ...?"라고 말하고 있었다. 같은 맥락에서 문서가 형편 없다는 의미는 아닙니다. 설명 할 필요가 없었을뿐입니다.

그리고 헤이, 그것은 완전히 근거없는 비난이 아닙니다 :) 내가 틀에 박힌 척하고 지하에 가서 내 결백을 증명 해야하는 척하는 약간 재미 있지만 그것은 내가 작업하고있는 완전히 다른 시나리오입니다 .

고맙게도 이러한 어리 석고 근거없는 비난; ) 둘 다 부분이 정리되었으며 당면한 비즈니스로 돌아갈 수 있습니다.

관련 질문 : 통계 컨트롤러를 사용하는 사람이 없거나 그게 미스테리 인 경우 왜 통계 컨트롤러가 활성화됩니까?

스테이징과 관련하여 설명해 주셔서 감사합니다. 내가 가지고 있는지 확인하기 위해 ...

안정적인 스테이징 인스턴스에서 시도해 보겠습니다.

... "stable.publiclab.org에서 시도해 볼게"라는 말과 바꿔 사용할 수 있습니까?

stable.publiclab.org Q-예! 그리고 그것은
master 지점-도움이되기를 바랍니다!

2019 년 6 월 19 일 수요일 오후 3:19 Benjamin Sugar [email protected]
썼다 :

오, @icarito https://github.com/icarito , 아니, 아니, 나는 아무것도 감지하지 못했다
고발, 전혀 아닙니다. 나는 "이것이 무슨 일이 일어나고 있는지"읽고
"이상한데, 아무도 없으면 왜 그렇게 했을까 ...?"
같은 맥락에서 문서가 형편 없다는 의미는 아닙니다.
설명 할 필요가 없었을뿐입니다.

그리고 헤이, 그것은 완전히 근거없는 비난이 아닙니다 :) 비록 나는
내가 누명을 썼고 내가 갔던 척하는 약간의 재미
내 결백을 증명해야하지만 그건 완전히 다른
내가 작업중인 각본.

고맙게도 이러한 어리 석고 근거없는 비난; ) 둘 다 부품이 있습니다
정리되고 우리는 당면한 사업으로 돌아갈 수 있습니다.

관련 질문 : 아무도 없다면 통계 컨트롤러가 왜 활성화됩니까?
그것을 사용하거나 그게 미스터리입니까?

스테이징과 관련하여 설명해 주셔서 감사합니다. 내가 가지고 있는지 확인하기 위해
이 말은 ...

안정적인 스테이징 인스턴스에서 시도해 보겠습니다.

... "stable.publiclab.org에서 시도해 볼게"라는 말과 바꿔 사용할 수 있습니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNDY-5037101ZLOPWSZGONMVXHJKissue,WSZGONMVXHJKissue ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren ,

@skilfullycurled 설명에 감사드립니다!
StatsController가 왜 그렇게 활동적인지 정말 미스테리입니다.

잠시 전에 몇 분 동안 우리를 쓰러 뜨린 또 다른 절정이있었습니다.

이 경우 트리거는 실제로 전체 텍스트 검색이었습니다.
그러나이 짧은 타임 슬라이스 (3 분)에서도 StatsController가 21 번 호출되었음을 알 수 있습니다.

이것이 기준 성능에 큰 영향을 미칠 수 있다고 생각합니다. 이 사용법을 알 수없는 경우 크롤러가 이러한 엔드 포인트에 도달하고 있습니까? robots.txt 또는 일부 액세스 제어로 해결할 수 있습니까?

@jywarren 설명을

실제로 이전 타임 슬라이스에 대한 Statscontroller 세부 정보는 다음과 같습니다.

모든 통계 경로를 robots.txt로 만들까요? 그래서 / stats *는 기본적으로?

2019 년 6 월 20 일 목요일 오전 12:21 Sebastian Silva [email protected]
썼다 :

실제로 이전 타임 슬라이스에 대한 Statscontroller 세부 정보는 다음과 같습니다.
[이미지 : 이미지]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFWSVREXG43Z835Z855,issueLNMVXHJKW63LNMVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

좋습니다. / api / *도 제외했습니다. 이미 / stats / range *를 차단했습니다.
하지만 이제는 모두 / stats *

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

2019 년 6 월 20 일 목요일 오후 2:45 Jeffrey Warren [email protected] 은 다음과 같이 썼습니다.

모든 통계 경로를 robots.txt로 만들까요? 그래서 / stats *는 기본적으로?

2019 년 6 월 20 일 목요일 오전 12:21 Sebastian Silva [email protected]
썼다 :

실제로 이전 타임 슬라이스에 대한 Statscontroller 세부 정보는 다음과 같습니다.
[이미지 : 이미지]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFWSVREXG43Z835Z855,issueLNMVXHJKW63LNMVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

그래서 캐싱이라고 생각하지 않습니까?

캐시는 사용 생성됩니다. 즉, a) 만료 된 경우 생성됩니다. 그리고
b) 새로운 요청이 들어옵니다. 따라서 무언가를 요청해야합니다.
생성 할 캐시 ... 몇 가지 관련되지 않은 문제를 해결하고 병합 할 수있는 경우
그들의 PR, 나는 오늘 밤 프로덕션에 새 출판을 시작할 것입니다 (그렇지 않으면
내일) robots.txt가 도움이되는지 확인할 수 있습니까?

2019 년 6 월 20 일 목요일 오후 4:53 Benjamin Sugar [email protected]
썼다 :

그래서 캐싱이라고 생각하지 않습니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVSOBW63LNDYMVXHJKissue,WSZDYMVXHJKissue
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller는 분당 5.5 번 호출됩니다.

@icarito 를 통해-오늘 밤 업데이트에서 robots.txt 변경이 도움이되는지 확인할 수 있습니다.

안녕하세요 @jywarren , 나는 robot.txt 업데이트 커밋이 며칠 전에 안정된 상태로 푸시되는 것을 보았습니다. 개선 된 점이 있습니까?

예, 업데이트를 원합니다! 올바른 데이터를 가져 왔는지 확실하지 않지만, 여기에 커밋 전, 커밋 후, 마지막 ~ 24 시간의 스카이 라이트 이미지가 있습니다. 빨간색 선은 커밋이 이루어진시기를 나타냅니다. 대답은 '예'인 것처럼 보이지만 중요하지 않거나 데이터를 잘못 해석하고있을 수 있습니다.

예, 전체 분석이 좋을 것 같습니다. 하지만 짧은 대답은
모든 사이트 요청에 대한 평균 문제 응답 시간을 거의 절반으로 줄였습니다.
5.5+에서 3 이하. 정말 대단한 개선입니다. 그것은
a) 8-15GB에서 거의 두 배의 RAM, b) 마케팅 차단의 조합
robots.txt의 봇, c) nginx 구성에서도 차단합니다 (나는
IP 주소 범위). 어려운 부분은 bot / stats_controller가 얼마나
전체 사이트 업그레이드를 보류하고 싶지 않았기 때문입니다.

타이밍은 :

1. robots.txt는 동부 표준시 기준 오후 5시 ~ 6 시경에
2. nginx 블록 시간 후 robots.txt가 얼마나 빨랐는지 확신하지 못한 후
   읽거나 존경하는
3. 토요일 오전 7시 ET 사이트 메모리 확장.

어쨌든 우리는 지금 정말 잘하고 있습니다. 부하 평균은 ~ 8 ​​대신 4 미만입니다.
4 개의 CPU 대신 6 개의 CPU가 있습니다.

2019 년 6 월 25 일 화요일 오후 5:32 Benjamin Sugar [email protected]
썼다 :

예, 업데이트를 원합니다! 올바른 데이터를 가져 왔는지 확실하지 않지만 여기에
커밋 전, 커밋 후, 스카이 라이트의 일부 이미지
지난 ~ 24 시간. 빨간색 선은 커밋이 이루어진시기를 나타냅니다. 에 보인다
대답과 같은 표면은 '예'이지만 중요하지 않을 수도 있습니다.
데이터를 잘못 해석하고있을 수 있습니다.

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

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFWSVREXG43754ZLOBW63LNMVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

지금 종료합니다!