Oh Robert,
Migramos para um novo vps com 4 núcleos (Ryzen 9 5950x),
o uso da CPU ainda está quase 100%. Eu realmente não sei o que está errado.
Eu pensei que você fosse mudar para um servidor Scaleway de 8 núcleos?
Qual é a largura de banda reivindicada deste servidor? Eu me pergunto se a baixa largura de banda pode causar lentidão nas conexões/desconexões como um gargalo?
A Scaleway tem VPS com larguras de banda de centenas de megabits por segundo, não 30.
30 parece extremamente baixo para mim.
Esta é a especificação.
4096MB DDR3 ECC RAM
4 vCores de CPU (3.4+ GHz E3-1231 v3/1241 v3/1240 v5)
200GB de Armazenamento HDD Raid 10
5TB de largura de banda @ 1Gb/s (velocidade limitada a 5Mb/s após o uso da alocação)
1 IPv4, /64 IPv6
Proteção DDoS TCP de 20Gb/s, upgrade de 200Gb/s disponível
Seattle, Washington, EUA
Painel de Controle Virtualizor
Não gerenciado
Devido ao atraso, finalmente escolhemos este provedor de serviços de nuvem. Eles fizeram a otimização da rede para visitantes do nosso país.
A propósito, a saída do htop é
100% de uso da CPU é anormal.
Tudo está bem, exceto pela carga e uso da CPU.
Algo estranho nos logs de acesso?
Agora parece que está se acalmando.\n
\nAcho que restaurar de um backup causa um pico no uso da CPU.\nDe qualquer forma, muito obrigado, Robert!
2 curtidas
Ah sim, isso resolveria!
Hum, você deveria mirar em SSD
2 curtidas
Boa observação, Benjamin!
A Scaleway e outras empresas oferecem SSDs NVMe. Muito melhor!
A CPU pode estar esperando pelo disco.
1 curtida
oh desculpe, acabei de colar uma especificação errada.
A especificação é
4096MB DDR4 ECC RAM
4 vCores de CPU (3.4GHz AMD Ryzen 5950X)
100GB de Armazenamento NVMe SSD Raid
Largura de banda de 5TB a 10Gb/s (velocidade limitada a 5Mb/s após o uso da alocação)
1 IPv4, /64 IPv6
Proteção DDoS TCP de 20Gb/s, upgrade de 200Gb/s disponível
Seattle, Washington, EUA
Painel de Controle Virtualizor
Não gerenciado
É NVMe. 
3 curtidas
Acho que é possível que os plugins que instalamos tenham aumentado a carga.
O plugin fez uma alteração no modelo do usuário de tal forma que, quando acessamos a rota de descoberta, sempre calculamos os pontos do modelo do usuário no modelo de tópico várias vezes.
add_to_class(:user, :total_earned_points) do
self.user_points.sum(:reward_points)
end
add_to_class(:user, :available_points) do
self.total_earned_points - self.user_rewards.sum(:points)
end
add_to_class(:user, :rewards) do
DiscourseRewards::Reward.where(created_by_id: self.id)
end
add_to_serializer(:basic_user, :total_earned_points) do
user&.total_earned_points
end
add_to_serializer(:basic_user, :available_points) do
user&.available_points
end
add_to_serializer(:current_user, :total_earned_points) do
scope.user.total_earned_points
end
add_to_serializer(:current_user, :available_points) do
scope.user.available_points
end
add_to_serializer(:current_user, :user_rewards) do
scope.user.user_rewards
end
add_to_serializer(:current_user, :rewards) do
scope.user.rewards
end
Pensei que você tinha dito que removeu todos os plugins e que estava se comportando da mesma forma?
Isso tem um índice?
Quantas linhas tem a tabela user_rewards? Interessante que não está distinguindo por usuário… (mas presumo que de alguma forma deva ser abaixo deste nível).
Oh, receio que ele não defina um índice.
O modelo é mostrado abaixo.
module DiscourseRewards
class Reward < ActiveRecord::Base
self.table_name = 'discourse_rewards_rewards'
has_many :user_rewards
belongs_to :created_by, class_name: 'User'
default_scope { where(deleted_at: nil) }
end
end
module DiscourseRewards
class UserPoint < ActiveRecord::Base
self.table_name = 'discourse_rewards_user_points'
belongs_to :user
belongs_to :user_badge
belongs_to :user_points_category
def self.user_total_points(user)
UserPoint.where(user_id: user.id).sum(:reward_points)
end
end
end
module DiscourseRewards
class UserReward < ActiveRecord::Base
self.table_name = 'discourse_rewards_user_rewards'
belongs_to :user
belongs_to :reward
enum status: [:applied, :granted]
end
end
Desabilitei todos os plugins no modo de segurança. No entanto, você sabe, o banco de dados não mudou. 
Algo para discutir com o autor, suspeito.
Parece que pode não estar a escalar para o seu grande número de utilizadores?
Talvez você precise reconstruir sem o plugin. Seria uma boa comparação e talvez confirmasse se os problemas são causados pelo plugin ou não.
A presença de tabelas não importará se as consultas não estiverem sendo executadas.
2 curtidas
discourse_rewards_user_points | 233525 | 27 MB | 5152 kB | 32 MB
discourse_rewards_user_rewards | 61 | 16 kB | 16 kB | 32 kB
discourse_rewards_user_points_categories | 9 | 16 kB | 16 kB | 32 kB
discourse_rewards_rewards | 4 | 16 kB | 16 kB | 32 kB
A tabela discourse_rewards_user_points é enorme.
1 curtida
Remova-o completamente (da compilação, não é necessário destruir as tabelas), veja o que acontece.
2 curtidas
Obrigado, vou tentar agora mesmo.
1 curtida
Ah, Robert, eu reconstruo sem o plugin, o tempo de resposta para páginas de rota de descoberta é reduzido para menos de 200ms de 2-3s antes.
1 curtida
Bom, aí está. Discutiria a otimização com o autor, ou se você tiver as habilidades, um PR?
1 curtida
Estou pedindo ajuda a um amigo nosso que entende de banco de dados.
Mas ele está trabalhando com JAVA. Acho que vai levar algum tempo.
1 curtida