Oh Robert,
Migriamo a un nuovo vps con 4 core (Ryzen 9 5950x),
l’utilizzo della CPU è ancora quasi al 100%. Non so davvero cosa c’è che non va.
Pensavo che ti saresti spostato su un server Scaleway a 8 core?
Qual è la larghezza di banda dichiarata di questo server? Mi chiedo se una bassa larghezza di banda possa causare colli di bottiglia nelle connessioni lente/disconnessioni?
Scaleway ha VPS con larghezze di banda di centinaia di megabit al secondo, non 30.
30 mi sembra estremamente basso.
Questa è la specifica.
4096 MB di RAM DDR3 ECC
4 vCore CPU (3.4+ GHz E3-1231 v3/1241 v3/1240 v5)
200 GB di spazio su disco HDD Raid 10
5 TB di larghezza di banda a 1 Gb/s (velocità limitata a 5 Mb/s dopo l'utilizzo dell'allocazione)
1 IPv4, /64 IPv6
Protezione DDoS TCP da 20 Gb/s, upgrade disponibile da 200 Gb/s
Seattle, Washington, USA
Pannello di controllo Virtualizor
Non gestito
A causa del ritardo, abbiamo finalmente scelto questo provider di servizi cloud. Hanno ottimizzato la rete per i visitatori del nostro paese.
A proposito, l’output di htop è
L’utilizzo della CPU al 100% è anomalo.
Tutto va bene tranne il carico e l’utilizzo della CPU.
Qualcosa di strano nei log di accesso?
Ora sembra che si stia calmando.
Supponiamo che il ripristino da un backup causi un picco nell’utilizzo della CPU.
Comunque, grazie mille Robert!
2 Mi Piace
Sì, certo, questo risolverebbe il problema!
Hum, dovresti puntare agli SSD
2 Mi Piace
Ottima osservazione Benjamin!
Scaleway e altri hanno SSD NVMe. Molto meglio!
La CPU potrebbe essere in attesa del disco.
1 Mi Piace
oh scusa ho incollato una specifica sbagliata.
La specifica è
4096MB DDR4 ECC RAM
4 CPU vCore (3.4GHz AMD Ryzen 5950X)
100GB Raid NVMe SSD Storage
5TB bandwidth @ 10Gb/s (velocità limitata a 5Mb/s dopo l'utilizzo dell'allocazione)
1 IPv4, /64 IPv6
20Gb/s TCP DDoS Protection, upgrade disponibile a 200Gb/s
Seattle, Washington, US
Virtualizor Control Panel
Unmanaged
È NVMe. 
3 Mi Piace
Penso sia possibile che i plugin che abbiamo installato abbiano aumentato il carico.
Il plugin ha apportato una tale modifica al modello utente che quando andiamo al percorso di discovery, calcoliamo sempre i punti del modello utente nel modello argomento molte volte
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
Pensavi avessi detto che avevi rimosso tutti i plugin e che si comportava allo stesso modo?
Ha un indice?
Quante righe ha la tabella user_rewards? Interessante che non distingua per utente… (ma presumo che in qualche modo debba essere a un livello inferiore).
Temo che non imposti un indice.
Il modello è mostrato di seguito.
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
Ho disabilitato tutti i plugin in modalità provvisoria. Tuttavia, sai, il database non è cambiato. 
Qualcosa con cui sospetto che dovrai confrontarti con l’autore.
Sembra che potrebbe non scalare per il tuo elevato numero di utenti?
Potrebbe essere necessario ricostruire senza il plugin. Sarebbe un buon confronto e forse confermerebbe se i problemi sono causati dal plugin o meno.
La presenza di tabelle non avrà importanza se le query non vengono eseguite.
2 Mi Piace
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
La tabella discourse_rewards_user_points è enorme.
1 Mi Piace
Rimuovilo completamente (dalla build, non è necessario distruggere le tabelle), vedi cosa succede.
2 Mi Piace
Grazie, ci proverò subito.
1 Mi Piace
Oh Robert, ricostruisco senza il plugin, il tempo di risposta per le pagine del percorso di scoperta è ridotto a meno di 200 ms da 2-3 secondi prima.
1 Mi Piace
Ecco fatto. Discuterei l’ottimizzazione con l’autore, o se hai le competenze, una PR?
1 Mi Piace
Chiedo aiuto a un nostro amico esperto di database.
Ma lui lavora in JAVA. Penso che ci vorrà un po’ di tempo.
1 Mi Piace