# Melhorando o desempenho da instância (Megatopics, tamanho do banco de dados e carga extrema)
**URL:** https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277
**Category:** Self-hosting
**Created:** [14 Março , 2020 01:02 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277 "2020-03-14T01:02:32Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Iceman](https://meta.discourse.org/u/Iceman)
#### Post date: [14 Março , 2020 01:02 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/1 "2020-03-14T01:02:32Z")
Olá, Comunidade Discourse!
Recentemente, tenho tentado melhorar o desempenho da minha instalação do Discourse e fazer uma pequena limpeza, já que meu site tem crescido exponencialmente ultimamente.
Identifiquei dois problemas, pesquisei sobre eles aqui, mas não encontrei uma resposta clara para alguns detalhes específicos, então espero que isso não cause muito incômodo a ninguém.
O primeiro problema que tenho é o tamanho do banco de dados (DB), que é bastante grande. Estou executando uma instância com 4 GB de RAM e 80 GB de disco no Digital Ocean, e o banco de dados já está esgotando o espaço do disco. Acredito que, eventualmente, terei que movê-lo (se for o caso, como fazer isso?), mas talvez eu esteja fazendo algo errado. Seguindo o [Auxílio de Sam](https://meta.discourse.org/t/getting-basic-database-table-size-and-count-statistics/68783), exportei o seguinte para facilitar a análise:
```plaintext
table_name | row_estimate | table_size | index_size | total_size
--------------------------------------------------------------------------
post_timings | 155307152 | 8004 MB | 16 GB | 24 GB
posts | 2257277 | 2432 MB | 4810 MB | 7242 MB
post_search_data | 2279749 | 1992 MB | 769 MB | 2761 MB
user_actions | 6549714 | 570 MB | 2189 MB | 2759 MB
topic_views | 8843734 | 444 MB | 1494 MB | 1937 MB
user_visits | 569317 | 33 MB | 1892 MB | 1925 MB
notifications | 1482664 | 465 MB | 914 MB | 1379 MB
topic_users | 4821392 | 500 MB | 449 MB | 949 MB
top_topics | 47437 | 28 MB | 773 MB | 802 MB
user_auth_token_logs | 1690555 | 515 MB | 133 MB | 648 MB
post_actions | 1610428 | 145 MB | 367 MB | 512 MB
post_revisions | 113187 | 396 MB | 9312 kB | 406 MB
topic_links | 605525 | 135 MB | 254 MB | 389 MB
topics | 56970 | 104 MB | 227 MB | 331 MB
web_hook_events | 107760 | 295 MB | 10 MB | 306 MB
post_stats | 1955191 | 151 MB | 97 MB | 248 MB
directory_items | 13026 | 1312 kB | 157 MB | 158 MB
incoming_links | 812553 | 73 MB | 82 MB | 155 MB
post_replies | 1111686 | 69 MB | 71 MB | 139 MB
topic_link_clicks | 806821 | 54 MB | 43 MB | 97 MB
draft_sequences | 654989 | 36 MB | 48 MB | 84 MB
topic_search_data | 54056 | 40 MB | 24 MB | 65 MB
stylesheet_cache | 901 | 57 MB | 200 kB | 57 MB
user_profile_views | 204427 | 15 MB | 30 MB | 46 MB
quoted_posts | 223337 | 18 MB | 23 MB | 41 MB
poll_votes | 142349 | 13 MB | 20 MB | 32 MB
users | 2211 | 2360 kB | 29 MB | 32 MB
given_daily_likes | 252806 | 12 MB | 16 MB | 28 MB
scheduler_stats | 115081 | 17 MB | 4736 kB | 21 MB
user_histories | 30331 | 8848 kB | 10040 kB | 18 MB
reviewables | 16263 | 10032 kB | 8344 kB | 18 MB
optimized_images | 34463 | 8088 kB | 10 MB | 18 MB
post_uploads | 73123 | 4104 kB | 13 MB | 17 MB
uploads | 18897 | 5088 kB | 9080 kB | 14 MB
email_logs | 23224 | 4024 kB | 9960 kB | 14 MB
post_custom_fields | 11043 | 3192 kB | 9328 kB | 12 MB
search_logs | 68429 | 7480 kB | 4776 kB | 12 MB
user_badges | 37176 | 2920 kB | 5008 kB | 7928 kB
unsubscribe_keys | 14820 | 3352 kB | 4480 kB | 7832 kB
user_auth_tokens | 5328 | 2536 kB | 3608 kB | 6144 kB
reviewable_scores | 14681 | 3144 kB | 2768 kB | 5912 kB
reviewable_histories | 31482 | 2976 kB | 2616 kB | 5592 kB
poll_options | 20886 | 2560 kB | 2552 kB | 5112 kB
skipped_email_logs | 11164 | 2528 kB | 2328 kB | 4856 kB
topic_allowed_users | 21933 | 1424 kB | 1872 kB | 3296 kB
user_uploads | 19038 | 1040 kB | 1688 kB | 2728 kB
user_stats | 2211 | 1888 kB | 160 kB | 2048 kB
drafts | 1324 | 1424 kB | 368 kB | 1792 kB
user_custom_fields | 7467 | 688 kB | 1064 kB | 1752 kB
application_requests | 11244 | 792 kB | 528 kB | 1320 kB
topic_tags | 10257 | 696 kB | 528 kB | 1224 kB
user_associated_accounts | 670 | 1032 kB | 184 kB | 1216 kB
user_profiles | 2211 | 424 kB | 720 kB | 1144 kB
email_tokens | 3439 | 480 kB | 528 kB | 1008 kB
polls | 4030 | 520 kB | 408 kB | 928 kB
user_search_data | 2215 | 376 kB | 520 kB | 896 kB
topic_custom_fields | 2738 | 280 kB | 568 kB | 848 kB
group_users | 4364 | 344 kB | 448 kB | 792 kB
plugin_store_rows | 2090 | 488 kB | 296 kB | 784 kB
incoming_referers | 3779 | 352 kB | 424 kB | 776 kB
user_avatars | 2210 | 208 kB | 560 kB | 768 kB
web_crawler_requests | 1389 | 264 kB | 440 kB | 704 kB
group_histories | 2210 | 272 kB | 416 kB | 688 kB
user_emails | 2218 | 224 kB | 376 kB | 600 kB
user_archived_messages | 3019 | 240 kB | 232 kB | 472 kB
user_options | 2218 | 384 kB | 72 kB | 456 kB
topic_allowed_groups | 2098 | 128 kB | 216 kB | 344 kB
schema_migration_details | 994 | 192 kB | 88 kB | 280 kB
group_mentions | 933 | 104 kB | 152 kB | 256 kB
categories | 23 | 96 kB | 112 kB | 208 kB
google_user_infos | 314 | 136 kB | 72 kB | 208 kB
theme_fields | 24 | 168 kB | 32 kB | 200 kB
category_users | 569 | 64 kB | 136 kB | 200 kB
javascript_caches | 8 | 112 kB | 64 kB | 176 kB
incoming_domains | 701 | 80 kB | 96 kB | 176 kB
groups | 51 | 120 kB | 48 kB | 168 kB
category_tag_stats | 173 | 48 kB | 104 kB | 152 kB
tag_search_data | 109 | 64 kB | 72 kB | 136 kB
schema_migrations | 994 | 88 kB | 48 kB | 136 kB
topic_embeds | 218 | 80 kB | 56 kB | 136 kB
badges | 51 | 80 kB | 48 kB | 128 kB
translation_overrides | 170 | 72 kB | 48 kB | 120 kB
invites | 21 | 56 kB | 64 kB | 120 kB
user_api_keys | 4 | 48 kB | 64 kB | 112 kB
category_search_data | 20 | 48 kB | 64 kB | 112 kB
tags | 109 | 56 kB | 48 kB | 104 kB
screened_ip_addresses | 9 | 48 kB | 48 kB | 96 kB
user_second_factors | 26 | 48 kB | 48 kB | 96 kB
oauth2_user_infos | 4 | 48 kB | 48 kB | 96 kB
site_settings | 165 | 64 kB | 32 kB | 96 kB
api_keys | 1 | 48 kB | 48 kB | 96 kB
category_featured_topics | 123 | 48 kB | 48 kB | 96 kB
screened_emails | 4 | 48 kB | 48 kB | 96 kB
screened_urls | 1 | 48 kB | 48 kB | 96 kB
topic_groups | 245 | 56 kB | 32 kB | 88 kB
muted_users | 103 | 40 kB | 48 kB | 88 kB
tag_group_permissions | 11 | 40 kB | 48 kB | 88 kB
tag_users | 8 | 40 kB | 48 kB | 88 kB
child_themes | 6 | 40 kB | 48 kB | 88 kB
category_tags | 9 | 40 kB | 48 kB | 88 kB
topic_timers | 15 | 40 kB | 48 kB | 88 kB
ignored_users | 10 | 40 kB | 48 kB | 88 kB
group_requests | 0 | 24 kB | 64 kB | 88 kB
user_warnings | 7 | 40 kB | 48 kB | 88 kB
email_change_requests | 64 | 56 kB | 32 kB | 88 kB
web_hooks | 1 | 72 kB | 16 kB | 88 kB
custom_emojis | 132 | 56 kB | 32 kB | 88 kB
color_scheme_colors | 110 | 56 kB | 32 kB | 88 kB
tag_group_memberships | 192 | 48 kB | 32 kB | 80 kB
category_custom_fields | 17 | 48 kB | 32 kB | 80 kB
themes | 10 | 48 kB | 32 kB | 80 kB
badge_types | 3 | 48 kB | 32 kB | 80 kB
onceoff_logs | 39 | 48 kB | 32 kB | 80 kB
category_tag_groups | 8 | 40 kB | 32 kB | 72 kB
group_archived_messages | 56 | 40 kB | 32 kB | 72 kB
category_groups | 3 | 40 kB | 32 kB | 72 kB
push_subscriptions | 12 | 48 kB | 16 kB | 64 kB
tag_groups | 10 | 48 kB | 16 kB | 64 kB
theme_settings | 6 | 48 kB | 16 kB | 64 kB
ar_internal_metadata | 1 | 48 kB | 16 kB | 64 kB
backup_metadata | 6 | 48 kB | 16 kB | 64 kB
user_fields | 9 | 48 kB | 16 kB | 64 kB
remote_themes | 7 | 48 kB | 16 kB | 64 kB
badge_groupings | 5 | 48 kB | 16 kB | 64 kB
web_hook_event_types | 10 | 48 kB | 16 kB | 64 kB
user_security_keys | 0 | 8192 bytes | 56 kB | 64 kB
color_schemes | 11 | 48 kB | 16 kB | 64 kB
permalinks | 0 | 24 kB | 32 kB | 56 kB
incoming_emails | 0 | 8192 bytes | 48 kB | 56 kB
post_action_types | 8 | 40 kB | 16 kB | 56 kB
web_hook_event_types_hooks | 1 | 40 kB | 16 kB | 56 kB
watched_words | 0 | 24 kB | 32 kB | 56 kB
user_exports | 0 | 24 kB | 16 kB | 40 kB
github_user_infos | 0 | 8192 bytes | 24 kB | 32 kB
backup_draft_posts | 0 | 8192 bytes | 24 kB | 32 kB
categories_web_hooks | 0 | 16 kB | 16 kB | 32 kB
theme_translation_overrides | 0 | 8192 bytes | 24 kB | 32 kB
single_sign_on_records | 0 | 8192 bytes | 24 kB | 32 kB
post_reply_keys | 0 | 0 bytes | 24 kB | 24 kB
backup_draft_topics | 0 | 0 bytes | 24 kB | 24 kB
user_open_ids | 0 | 8192 bytes | 16 kB | 24 kB
post_details | 0 | 8192 bytes | 16 kB | 24 kB
message_bus | 0 | 8192 bytes | 16 kB | 24 kB
anonymous_users | 0 | 0 bytes | 24 kB | 24 kB
group_custom_fields | 0 | 8192 bytes | 16 kB | 24 kB
topic_invites | 0 | 0 bytes | 24 kB | 24 kB
shared_drafts | 0 | 0 bytes | 24 kB | 24 kB
instagram_user_infos | 0 | 8192 bytes | 8192 bytes | 16 kB
reviewable_claimed_topics | 0 | 0 bytes | 16 kB | 16 kB
user_field_options | 0 | 8192 bytes | 8192 bytes | 16 kB
embeddable_hosts | 0 | 8192 bytes | 8192 bytes | 16 kB
invited_groups | 0 | 0 bytes | 8192 bytes | 8192 bytes
developers | 0 | 0 bytes | 8192 bytes | 8192 bytes
tags_web_hooks | 0 | 0 bytes | 8192 bytes | 8192 bytes
groups_web_hooks | 0 | 0 bytes | 8192 bytes | 8192 bytes
badge_posts | 0 | 0 bytes | 0 bytes | 0 bytes
```
(por outro lado, a pasta `/var/discourse/shared/standalone/postgres_data/base` tem mais de 47 GB)
Será que é possível [reduzir isso de alguma forma](https://meta.discourse.org/t/how-to-reduce-database-size/110204) ou é lógico, dado o tamanho de alguns tópicos? (mais detalhes abaixo).
O outro problema _talvez_ esteja relacionado, acredito, que é o fato de eu continuar recebendo a famosa mensagem: „Devido à carga extrema, isso está temporariamente sendo mostrado para todos como um usuário deslogado veria
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [14 Março , 2020 03:51 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/2 "2020-03-14T03:51:20Z")
Essa tabela `post_timings` é um monstro. Há algo que possamos fazer para truncar ou “abreviar” ou “resumir” essa tabela sem quebrar nada, @sam?
---
### Author:  [@Iceman](https://meta.discourse.org/u/Iceman)
#### Post date: [16 Março , 2020 01:34 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/3 "2020-03-16T01:34:15Z")
Mini-atualização: Tentei ajustar as configurações do Unicorn Runners, mas não tenho certeza se há uma relação entre núcleo e worker ou se é algo como CPU compartilhada, tipo `CPU % x Segundo`. Existe alguma melhor prática para isso?
Além disso, tenho lido sobre PostgreSQL para entender como lidar com o tamanho do banco, mas, mesmo com backups, não sei como o aplicativo reagirá a longo prazo se eu simplesmente começar a cortar dados.
Edição rápida: Removi o arquivo de swap e agora estou analisando como proceder com os mais de 10 mil tópicos. Aproveito para perguntar: qual é o risco que eles representam para o panorama geral? (Assumo que exista algum, dada a recomendação, mas se houver algo mais que eu deva saber, gostaria de aprender, se possível).
---
### Author:  [@DiscourseMetrics](https://meta.discourse.org/u/DiscourseMetrics)
#### Post date: [18 Março , 2020 21:42 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/4 "2020-03-18T21:42:20Z")
> [@Iceman](#):
>
> Como observação [temos vários tópicos com mais de 10 mil respostas](https://meta.discourse.org/t/need-help-with-site-server-tweaking/91391/5), então isso pode ser uma correlação entre o tamanho do banco de dados e problemas de desempenho? (Só jogando a ideia, não tenho certeza).
Eu também tenho alguns tópicos com mais de 10 mil respostas e também vejo essa mensagem de vez em quando quando o site está muito movimentado.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [18 Março , 2020 22:00 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/5 "2020-03-18T22:00:15Z")
Eu _recomendo fortemente_ que você não substitua os padrões do Discourse, que **fecham automaticamente tópicos com mais de 10 mil respostas**. Existe um motivo para essa configuração estar ativada por padrão. 😱
Além disso, esse problema da tabela `post_timings` massiva está em nosso radar 📡 e estamos atualmente brainstormando maneiras de lidar com isso, talvez até na versão 2.5 atual cc @sam @eviltrout
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [19 Março , 2020 04:37 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/6 "2020-03-19T04:37:41Z")
> [@codinghorror](#):
>
> Existe um motivo para termos essa configuração ativada por padrão.
Sinto que seria necessário uma confirmação tripla, com o botão final dizendo “`Estou ok com coisas ruins acontecendo`”.
Alguém está fazendo os megatópicos funcionarem de verdade?
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [19 Março , 2020 15:10 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/7 "2020-03-19T15:10:32Z")
Temos cerca de 80 megatópicos ativos o tempo todo (128 mil posts no maior deles).
> **[FórumSCP](https://www.forumscp.com)**
>
> A comunidade dos Sportinguistas dedicada ao Sporting Clube de Portugal onde se aborda o futebol, as modalidades e outros temas da actualidade leonina.
Às vezes, ocorrem alguns problemas 502 (talvez relacionados a isso, não consigo afirmar), mas tudo funciona sem problemas desde que ajustamos o parâmetro `db_shared_buffers` para um valor superior ao tamanho do banco de dados.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [19 Março , 2020 15:34 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/8 "2020-03-19T15:34:21Z")
> [@Paracelsus](#):
>
> Temos cerca de 80 megatópicos rodando o tempo todo (128 mil posts no maior deles).
Essa é uma ideia profundamente ruim, e você deveria encerrar esses tópicos em favor de tópicos menores, anuais ou sazonais. Veja
> [@The MEGATOPIC: public good, or public menace?](https://meta.discourse.org/t/the-megatopic-public-good-or-public-menace/85592):
>
> When we founded Discourse in 2013, I had the idea that we’d support topics of any length or size, from 10 replies to 100 to 10,000 to 100,000 or even more! A few years ago we ran into a technical limitation where we send down a list of all the post IDs in the topic when you enter the topic. This starts to cause problems on the client – particularly older smartphones with less memory and CPU power – at around ~10,000 replies, so we created a site setting that automatically closes topic…
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [19 Março , 2020 15:47 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/9 "2020-03-19T15:47:24Z")
Tenho um site com algumas dezenas de tópicos gigantes com mais de 100 mil posts. Eu disse que era um erro, mas eles insistiram em mantê-los. Agora estão reclamando de problemas de desempenho. Espero conseguir alterar o valor de volta para o padrão de 10 mil em breve.
Isso me fez aprender algumas coisas sobre otimização de banco de dados, então é um bônus. 🙂
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [19 Março , 2020 17:51 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/10 "2020-03-19T17:51:06Z")
> [@codinghorror](#):
>
> > [@Paracelsus](#):
> >
> > Temos cerca de 80 megatópicos ativos o tempo todo (128 mil posts no maior deles).
>
> Essa é uma ideia profundamente ruim e vocês deveriam encerrar esses tópicos em favor de outros menores, anuais ou sazonais. Veja:
>
> [The MEGATOPIC: public good, or public menace?](https://meta.discourse.org/t/the-megatopic-public-good-or-public-menace/85592)
Entendo o que você quer dizer, mas também preciso admitir que pode ser complicado dividir um tópico por anos, especialmente porque temos muitas conversas girando em torno de pessoas.
Imagine um tópico sobre Trump em geral ou outro sobre os Estados Unidos em geral. No nosso fórum, temos um tópico sobre um ex-presidente do nosso clube, outro para o presidente atual, e um para cada jogador de futebol. Você entendeu a ideia. É fácil dividir outros tópicos por estações, mas não esses. Claro, não é impossível, mas bastante impraticável.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [19 Março , 2020 18:26 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/11 "2020-03-19T18:26:10Z")
> [@Paracelsus](#):
>
> Imagine um tópico sobre Trump em geral ou um sobre os Estados Unidos em geral.
Imagine uma _categoria_ sobre Trump em geral ou os Estados Unidos em geral.
Ninguém vai ler mais de 10.000 postagens em um tópico direto. Simplesmente não vão. Em algum momento, você pode apenas respirar e começar de novo. Suspeito que esses tópicos são mais como bate-papo do que discussão, e que poucas pessoas leem o que aconteceu ontem, quanto mais na semana passada, no mês passado ou no ano passado.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [19 Março , 2020 18:33 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/12 "2020-03-19T18:33:51Z")
> [@Paracelsus](#):
>
> Claro, não é impossível, mas é bastante impraticável.
OK, mas minha resposta a isso é
… você está optando por causar a si mesmo bastante dor aqui por “motivos”.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [20 Março , 2020 19:16 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/13 "2020-03-20T19:16:08Z")
Aqui está uma consulta do explorador de dados que imita a consulta feita para obter uma página de posts:
```plaintext
-- [params]
-- int :topic_id = 107216
-- int :offset = 10000
SELECT "posts"."id" FROM "posts"
WHERE ("posts"."deleted_at" IS NULL)
AND "posts"."topic_id" = :topic_id
AND "posts"."post_type" IN (1,2,3) ORDER BY "posts"."sort_order" ASC LIMIT 20
OFFSET :offset
```
Aqui está um tópico normal:
```plaintext
Limit (cost=1911.35..1915.38 rows=1 width=8)
```
Aqui está um tópico mega:
```plaintext
Limit (cost=37475.88..37550.83 rows=20 width=8)
```
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [20 Março , 2020 19:29 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/14 "2020-03-20T19:29:41Z")
👍
Acredito em vocês, é apenas que nossos usuários estão acostumados assim e levará um pouco de esforço para chegar lá… mas é factível.
Relacionado a isso, eu estava apenas lendo o post do @codinghorror [Natural breakpoints or "chapters" for long topics? - #53 by codinghorror](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/53?u=paracelsus) e pensei que esse tipo de índice, mas apenas para tópicos, seria uma boa solução para poder reunir e ter visível uma sequência de tópicos enquanto navega e responde apenas em um único.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [20 Março , 2020 19:33 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/15 "2020-03-20T19:33:03Z")
> [@Paracelsus](#):
>
> Acredito em vocês, é apenas que nossos usuários estão acostumados assim e levará um pouco de esforço para chegar lá.
Não me entendam mal, fiz esse trabalho não para convencer _vocês_, mas para convencer meu _cliente_ **com mais de 120 mil tópicos de posts** que está reclamando do desempenho!
Minha esperança é que isso também ajude vocês. Boa sorte com isso. 😉
🥂
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [20 Março , 2020 20:26 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/16 "2020-03-20T20:26:54Z")
Muito útil! Obrigado por compartilhar!
Temos planos concretos a curto prazo para otimizar a tabela `post_timings`, mas os megatópicos serão uma fonte de dor considerável e contínua por muitos e muitos anos.
> ⚠ e lembre-se de que isso é _após_ @tgxworld ter feito um ótimo trabalho há cerca de um ano para reduzir a quantidade geral de trabalho que realizamos em megatópicos, essencialmente alternando para o “modo de baixo consumo” nesses tópicos para que eles não causem _tanto_ dano.
Mas não se engane: os megatópicos ainda causam um impacto _forte_. 💥🥊
---
### Author:  [@Iceman](https://meta.discourse.org/u/Iceman)
#### Post date: [24 Março , 2020 11:54 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/17 "2020-03-24T11:54:36Z")
Seguindo suas recomendações e enquanto tento entender as outras questões (reconhecendo que vocês estão trabalhando na tabela `post_timings`), estou procedendo com a restauração dos padrões para o tamanho dos tópicos (e pedindo desculpas pela minha burrice, por que não).
Com isso em mente, tenho algumas perguntas que espero que vocês possam responder:
1. Uma vez que a configuração for restaurada, esses tópicos serão fechados. Novos serão criados. No entanto, a existência desses tópicos antigos e grandes é perigosa para o site como um todo? Ou seja, devo “dividi-los” X vezes em tópicos menores ou, desde que não estejam ativos, está tudo bem?
2. Vi o debate que @Paracelsus levantou sobre a conveniência para os usuários. Com isso em mente, gostaria de saber se seria possível ter uma configuração para “Continuar Automaticamente Tópicos Fechados devido ao Tamanho Máximo”. Ou seja, quando um mega-tópico for fechado automaticamente, seria possível abrir outro com o mesmo autor, mesmo título (talvez com um número no final do tópico?) e o único conteúdo sendo um link para o anterior? (Ao mesmo tempo, adicionando o link para o novo no tópicos fechado).
Sei que é meio complicado e talvez não seja desejado por todos (por isso estou levantando como uma configuração opcional), mas para sites de alto tráfego com tópicos relevantes, pode ser útil, imagino. O que acham?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [25 Março , 2020 05:13 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/18 "2020-03-25T05:13:20Z")
> [@Iceman](#):
>
> quando um mega-tópico é fechado automaticamente, seria possível abrir outro com o mesmo autor e o mesmo título?
Isso é como perguntar: “devemos incentivar as pessoas a fumar cigarros comprando automaticamente um novo maço quando elas ficam sem?” 😉
> [@Iceman](#):
>
> No entanto, a existência desses tópicos antigos e grandes é perigosa para o site como um todo?
Não, a menos que recebam muito tráfego, o que não deveria acontecer se estiverem fechados, eu diria? Veja como funciona, mas parar o sangramento dos mega-tópicos ativos é o passo zero, então você está no caminho certo 👍
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [9 Abril , 2020 14:03 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/19 "2020-04-09T14:03:29Z")
Só um acompanhamento… Estamos tentando agora lidar com esses mega-assuntos dividindo-os em blocos de 10 mil posts cada. No entanto, o sistema parece não estar disposto a seguir nossa estratégia 😅
Recebo um erro “502 Bad Gateway” ao selecionar pelo menos 8.000 posts de uma vez e movê-los para um novo tópico (ainda não tentei com quantidades menores de posts). Existe uma maneira de aumentar a capacidade ou outra forma melhor de realizar isso? @codinghorror @pfaffman
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9 Abril , 2020 16:00 UTC](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277/20 "2020-04-09T16:00:43Z")
A solução é fazer isso no console do Rails, mas não sei de imediato como proceder.
Algo assim:
```plaintext
old_topic=1
new_topic=2
Posts.where(topic_id: old_topic).where("post_number > 10000 and post_number < 20000").update_all(topic_id: new_topic, post_number=...)
```
mas… acho que você pode precisar colocar isso em um loop para gerar os novos números de postagem. Você vai querer testar sua solução em um ambiente de staging. Se algo der errado, você vai se meter em grandes apuros.
Se isso não for suficiente para você descobrir como fazer, provavelmente precisará postar em #Marketplace. Mas aposto que ninguém vai ler as postagens antigas de qualquer forma, e que você deveria apenas fechá-las e deixá-las grandes, talvez até excluí-las ou removê-las da listagem, a menos que você ache que elas tenham algum valor de SEO.
[Próxima página](https://meta.discourse.org/t/improving-instance-performance-megatopics-database-size-and-extreme-load/144277.md?page=2)