Oh Robert,
Nous migrons vers un nouveau vps avec 4 cœurs (Ryzen 9 5950x),
L’utilisation du processeur est toujours de près de 100 %. Je ne sais vraiment pas ce qui ne va pas.
Je pensais que vous alliez passer à un serveur Scaleway 8 cœurs ?
Quelle est la bande passante revendiquée de ce serveur ? Je me demande si une faible bande passante pourrait causer des connexions lentes/des déconnexions qui deviendraient un goulot d’étranglement ?
Scaleway a des VPS avec des bandes passantes de centaines de mégabits par seconde, pas 30.
30 me semble extrêmement bas.
Voici les spécifications.
4096 Mo de RAM DDR3 ECC
4 cœurs CPU (3,4+ GHz E3-1231 v3/1241 v3/1240 v5)
200 Go de stockage HDD Raid 10
5 To de bande passante @ 1 Gb/s (vitesse limitée à 5 Mb/s après utilisation de l'allocation)
1 IPv4, /64 IPv6
Protection DDoS TCP de 20 Gb/s, mise à niveau de 200 Gb/s disponible
Seattle, Washington, États-Unis
Panneau de contrôle Virtualizor
Non géré
En raison du délai, nous avons finalement choisi ce fournisseur de services cloud. Ils ont optimisé le réseau pour les visiteurs de notre pays.
Au fait, la sortie de htop est
100% d’utilisation du CPU est anormal.
Tout va bien sauf la charge et l’utilisation du CPU.
Quelque chose d’étrange dans les journaux d’accès ?
Il semble que la situation se calme maintenant.
Nous supposons que la restauration à partir d’une sauvegarde provoque une augmentation de l’utilisation du processeur.
Quoi qu’il en soit, merci beaucoup Robert !
Ah oui, cela fonctionnerait !
Hmm, tu devrais viser le SSD.
Bien vu Benjamin !
Scaleway et d’autres ont des SSD NVMe. Beaucoup mieux !
Le CPU pourrait attendre sur le disque.
oh désolé, j’ai juste collé une mauvaise spécification.
La spécification est
4096 Mo de RAM DDR4 ECC
4 cœurs CPU (3,4 GHz AMD Ryzen 5950X)
100 Go de stockage SSD NVMe en RAID
5 To de bande passante @ 10 Gbit/s (vitesse limitée à 5 Mbit/s après utilisation de l'allocation)
1 IPv4, /64 IPv6
Protection DDoS TCP 20 Gbit/s, mise à niveau disponible à 200 Gbit/s
Seattle, Washington, États-Unis
Panneau de contrôle Virtualizor
Non géré
C’est du NVMe. ![]()
Je pense qu’il est possible que les plugins que nous avons installés aient augmenté la charge.
Le plugin a apporté un tel changement au modèle utilisateur que lorsque nous accédons à la route de découverte, nous calculons toujours les points du modèle utilisateur dans le modèle de sujet plusieurs fois.
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
Je pensais que tu avais dit que tu avais supprimé tous les plugins et que ça se comportait de la même manière ?
Est-ce que cela a un index ?
Combien de lignes contient la table user_rewards ? Il est intéressant qu’elle ne distingue pas par utilisateur… (mais je suppose que cela doit être d’une manière ou d’une autre en dessous de ce niveau).
Je crains que cela n’établisse pas d’index.
Le modèle est montré ci-dessous.
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
J’ai désactivé tous les plugins en mode sans échec. Cependant, vous savez, la base de données n’a pas changé. ![]()
Quelque chose à discuter avec l’auteur, je suppose.
On dirait que cela ne fonctionne pas pour votre grand nombre d’utilisateurs ?
Vous devrez peut-être reconstruire sans le plugin. Ce serait une bonne comparaison et confirmerait peut-être si les problèmes sont causés par le plugin ou non.
La présence de tables n’aura pas d’importance si les requêtes ne s’exécutent pas.
discourse_rewards_user_points | 233525 | 27 Mo | 5152 Ko | 32 Mo
discourse_rewards_user_rewards | 61 | 16 Ko | 16 Ko | 32 Ko
discourse_rewards_user_points_categories | 9 | 16 Ko | 16 Ko | 32 Ko
discourse_rewards_rewards | 4 | 16 Ko | 16 Ko | 32 Ko
La table discourse_rewards_user_points est énorme.
Supprimez-le complètement (de la construction, pas besoin de détruire les tables), voyez ce qui se passe.
Merci, je vais essayer tout de suite.
Oh Robert, je reconstruis sans le plugin, le temps de réponse des pages de la route de découverte est réduit à moins de 200 ms contre 2-3 s auparavant. ![]()
Voilà. Je discuterais de l’optimisation avec l’auteur, ou si vous avez les compétences, une PR ?
Je demande de l’aide à notre ami qui connaît bien les bases de données.
Mais il travaille sur JAVA. Je pense que cela prendra du temps.




