Support Technique

[Armel]

Wow, merci à tous pour vos messages, j’essaie de répondre à toutes vos questions.

Une chose peut-être à savoir est que suite au problèmes de lenteur, j’ai doublé la RAM (2 GB à 4 GB) et le Disk (40 GB à 80 GB, qui ne suffisait plus pour mettre à jour le forum, surtout la BDD Postgres).

La procédure d’installation que j’ai suivi à l’origine est ici :

discourse/discourse/blob/master/docs/INSTALL-cloud.md

L’hébergement et le prix sont ici :

Ubuntu Cloud Server One-Click Deploy

L’espace disque est remplit a combien actuellement ?

> df -h

Filesystem                 Size  Used Avail Use% Mounted on
udev                       2.0G     0  2.0G   0% /dev
tmpfs                      396M   11M  385M   3% /run
/dev/disk/by-label/DOROOT   79G   24G   52G  32% /
tmpfs                      2.0G  1.1M  2.0G   1% /dev/shm
tmpfs                      5.0M     0  5.0M   0% /run/lock
tmpfs                      2.0G     0  2.0G   0% /sys/fs/cgroup
cgmfs                      100K     0  100K   0% /run/cgmanager/fs
none                        79G   24G   52G  32% /var/lib/docker/aufs/mnt/a5ce0a3f449e8491169e3764afa5b46c06651e37dfc4d4960767c210ceee19db
shm                        512M  8.0K  512M   1% /var/lib/docker/containers/f3a0053f6fb37c0202ac8dd5b0bcf3aed6176819b9741dce6b2d488671e99b69/mounts/shm
tmpfs                      396M     0  396M   0% /run/user/0

Oui si sur un Mutu les autres seront touché aussi mais ça il y as que l’hébergeur qui peut répondre …

J’ai contacté Digital Ocean en premier lieu, voici leur réponse :

As a self-managed provider we do not have the ability to log into your Droplet and gather additional information on this. Our recommendation would be that if you cannot access your Droplet that you powercycle it to hopefully get it to a point where you can at least log into and investigate this. 

Once you are able to connect to the Droplet we would recommend that you review your system logs as well as review running processes to get a better idea of why there is a high amount of CPU utilization. Steps on how to review your system logs and monitor running processes and their utilization can be found here: 
https://www.digitalocean.com/community/tutorials/how-to-view-and-configure-linux-logs-on-ubuntu-and-centos
https://www.digitalocean.com/community/tutorials/how-to-use-top-netstat-du-other-tools-to-monitor-server-resources

Peux tu confirmer le mombre de core de la machine ? et si l hyperthreading est activé ? (
cat /proc/cpuinfo )

> /proc/cpuinfo

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
stepping	: 2
microcode	: 0x1
cpu MHz		: 1797.917
cache size	: 30720 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm xsaveopt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips	: 3595.83
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
stepping	: 2
microcode	: 0x1
cpu MHz		: 1797.917
cache size	: 30720 KB
physical id	: 1
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm xsaveopt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips	: 3595.83
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

Peux tu donner plus de detail sur ce qui tourne sur la machine ?
uniquement le forum ? Discourse + db postgress ? ( si postgress, peux tu fournir un certain nombre de pg_top durant une periode d activité/lenteur )

Oui, uniquement Discourse et sa DB.

d ailleur tu as essayé de passer le app.yml db_shared_buffers a 2G ?

Non, mais je peux essayer

ubuntu 18.04 est aussi une LTS , une upgrade pourrait faire du bien !

Effectivement j’ai aussi pensé à ça mais c’est une grosse mise à jour, je suis sûr à 100% que tout se passe bien et ça devient un peu compliqué si y’a un problème pendant la mise à jour.

En ce moment un top donne :

top - 01:34:11 up 12:38,  1 user,  load average: 0.79, 0.85, 0.90
Tasks: 127 total,   3 running, 124 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.8 us,  4.5 sy,  0.0 ni, 67.0 id,  0.9 wa,  0.0 hi,  0.9 si,  0.0 st
KiB Mem :  4048268 total,   186576 free,  2286964 used,  1574728 buff/cache
KiB Swap:  1048572 total,   960532 free,    88040 used.   451658 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                          
 1402 1000      20   0 1739572 350624   9820 S  16.2  8.7  19:06.16 ruby                                                                             
 3410 1000      20   0 1710896 323132  12312 S  12.2  8.0  15:17.55 ruby                                                                             
 1895 1000      20   0 1703216 339204  11076 R   9.2  8.4  17:15.99 ruby                                                                             
28431 systemd+  20   0 1286808 496396 482900 S   6.3 12.3   0:30.39 postmaster                                                                       
26241 systemd+  20   0 1287660 536176 521812 S   5.0 13.2   0:49.21 postmaster                                                                       
10462 _apt      20   0  302564 266240   1236 S   3.0  6.6  21:18.85 redis-server                                                                     
28933 systemd+  20   0 1280256 447740 438456 S   3.0 11.1   0:31.99 postmaster                                                                       
    7 root      20   0       0      0      0 S   1.7  0.0  12:45.43 rcu_sched                                                                        
 3396 1000      20   0 1696560 326488  11980 S   1.3  8.1  15:51.07 ruby                                                                             
10484 systemd+  20   0 1263924 677320 675272 S   1.3 16.7   1:24.66 postmaster                                                                       
18319 1000      20   0 1744228 362604  11736 S   1.3  9.0   4:13.61 ruby                                                                             
  704 root      20   0  677328  14320   1540 S   1.0  0.4   7:34.32 dockerd                                                                          
10477 www-data  20   0   83100   4196   2024 S   1.0  0.1   4:37.85 nginx                                                                            
    8 root      20   0       0      0      0 R   0.7  0.0   4:36.81 rcuos/0                                                                          
    9 root      20   0       0      0      0 S   0.7  0.0   5:17.70 rcuos/1                                                                          
  769 root      20   0  500656   7216   1292 S   0.7  0.2   5:11.17 docker-containe                                                                  
27088 systemd+  20   0 1286668 559684 546212 S   0.7 13.8   0:52.35 postmaster                                                                       
31449 root      20   0   41812   1928   1348 R   0.7  0.0   0:00.07 top              

sar -d serait aussi interressant

> sar -d

Cannot open /var/log/sysstat/sa04: No such file or directory
Please check if data collecting is enabled

[Zebre_bicolore]

Apparement tu n as que deux core, un cpu load >2 est donc préoccupant.
De plus, en relisant ton premier poste ( second en fait ) il semble qu il y a bcp de IO wait ( 10 % , ce n est pas enorme mais pas negligeable non plus )

Pour le CPU : un top regulier durant une periode de charge devrait pouvoir identifer le process incriminé , probablement postmaster , et dans ce cas il faudra digguer sur les requetes prenant le plus de temps , soit ruby , dans le cas de ruby , tu peux prendre le PID et faire un ps -elf | grep PID pour avoir la commande complete utilisant le CPU.

Pour analyser les IO , cela serait bien de fixer SAR , sarc tourne ?

[anon62058358]

C’est une vm, donc vcpu, donc il a, (a priori), du cpu a gogo s’il a besoin (emulation de 2 cpu a 12 coeurs).
Sans une vue sur les stat de l’hyperviseur, comment savoir si ca sature…
Pas facile de traduire leur offre commerciale en réalité technique.

[Derf59 (Derf59 ImmunePB ALC / Gewo Hype EL Pro 40 / DrNeubauer TroubleMaker)]

C’est une vm, donc vcpu, donc il a, (a priori), du cpu a gogo s’il a besoin (emulation de 2 cpu a 12 coeurs).
Sans une vue sur les stat de l’hyperviseur, comment savoir si ca sature…
Pas facile de traduire leur offre commerciale en réalité technique.

Tout à fait, en plus quand tu regardes les messages d’erreur, tu avais un message d’erreur “cloudfare” comme quoi souvent le site n’était pas en ligne.
A mon avis le problème n’est pas je pense sur le site en lui même.

[anon62058358]

> sar -d

Cannot open /var/log/sysstat/sa04: No such file or directory
Please check if data collecting is enabled

-> vérifier qu’il y a bien un répertoire sysstat dans var/log , et qqe chose dedans.
Si ce n’est pas le cas :
mkdir /var/log/sysstat
service sysstat restart

C’est probablement un bug du pkg_mgr fourni

[FRnunurs]

Yep 2 core, c’est ptet un poil juste mais via docker c’est jamais facile de se prononcer… et sans le nombre d’opérations seconde et de user simultanés c’est compliqué d’être fermé sur la question. Les io et le CPU semblent les 2 bonnes pistes.

Discourse est sensé embarquer un redis de base, donc ça serait intéressant de savoir exactement qui vient tabasser le CPU (et les disques) donc parce qu’en théorie c’est bien foutu avec plein de cache partout et les ressources externes qui sont servies via s3.

Est ce que c’est les users avec trop de connexions / requêtes concurrentes ou la DB qui étouffe avec ses pauvres disques rotatifs (et si oui c’est quoi comme type de requêtes ? Read / write / …)
Je pense qu’il va falloir dans tous les cas investir un peu de temps dans un système de métrologie un peu plus consistant que des top dans une boucle for. Même si c’est un bon début !
Avoir les stats de son webserver , son système, du redis et de la bdd semble quand même un bon point pour avancer dans la bonne direction.

Après ça serait cool que tu postes les logs de discourse et du serveur web aussi (dans un gist ou ici même) . On a ptet affaire a des timeouts, du rate limiting, ou du stalling de requêtes dans des files quelconques. Et ça permettrait de vérifier que les services sont bien UP en continu.
et en premier secours ça serait intéressant de voir si il est possible de brider un peu le serveur (genre virer des options qui font des opérations bdd pour rien , comme les sauvegardes auto des messages en train d’être écrits, le nombre de messages récupérés quand on Scroll up, et autres joyeusetés comme ça … )

[anon62058358]

Peut etre cronner qqes netstat toutes les 5 min pourrait aider a comparer un moment ou ca va bien et un moment ou tu te manges un 502…
Les io réseaux sont peut être une partie du problème ou le sommet de l’iceberg.

Et surtout , ne les balance pas en clair dans ce forum s’il y a les ip de tout le monde, merci.

[anon62058358]

Si à partir de maintenant, sans modifications supplémentaires de l’admin armel, tout se remet à marcher nickel sur une bonne période…
Je met une pièce sur le fait que ton mail au support a pousser un gars a jeter un oeil à l’hyperviseur et à restreindre un petit copain qui partageait la même machine physique dans une autre vm …

[FRnunurs]

Le matin a 9h c’est pas le pic d’utilisation non plus ;p
Attends de voir ce midi et ce soir 20h avant de te prononcer

[Armel]

top - 04:03:07 up 15:06,  1 user,  load average: 6.64, 5.66, 5.55
Tasks: 129 total,   2 running, 127 sleeping,   0 stopped,   0 zombie
%Cpu(s): 41.8 us, 12.2 sy,  0.0 ni, 36.0 id,  0.2 wa,  0.0 hi,  9.8 si,  0.0 st
KiB Mem :  4048268 total,   221076 free,  2121752 used,  1705440 buff/cache
KiB Swap:  1048572 total,   879484 free,   169088 used.   609560 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                          
18319 1000      20   0 2001316 384192   5164 S  92.1  9.5  18:45.25 ruby                                                                             
11827 1000      20   0 1657648 281404   4476 S   6.9  7.0   2:31.28 ruby                                                                             
11228 1000      20   0 1659696 279716   4712 S   5.6  6.9   2:52.54 ruby                                                                             
10462 _apt      20   0  302564 207884   1204 S   4.9  5.1  29:01.79 redis-server                                                                     
   17 root      20   0       0      0      0 S   3.3  0.0   2:44.28 ksoftirqd/1                                                                      
    7 root      20   0       0      0      0 S   2.6  0.0  15:50.69 rcu_sched                                                                        
 8796 1000      20   0 1680688 307140   5456 S   2.3  7.6   5:54.27 ruby                                                                             
12106 systemd+  20   0 1283832 389420 377604 S   2.3  9.6   0:19.25 postmaster                                                                       
11544 systemd+  20   0 1288328 456476 441532 R   2.0 11.3   0:24.62 postmaster                                                                       
    9 root      20   0       0      0      0 S   1.0  0.0   6:22.51 rcuos/1                                                                          
  769 root      20   0  500656   6928   1284 S   1.0  0.2   6:08.48 docker-containe                                                                  
  704 root      20   0  677328  13092   1520 S   0.7  0.3   8:42.37 dockerd                                                                          
 9048 systemd+  20   0 1286668 652204 641216 S   0.7 16.1   0:54.83 postmaster                                                                       
 9922 root      20   0   41812   1732   1328 R   0.7  0.0   0:10.77 top              

[Zebre_bicolore]

top dans une boucle for

Mais non , dans la crontab

[FRnunurs]

Rien de foufou. Discourse fonctionne, le rails ça bouffe le peu de CPU que tu as évidemment, mais les temps de réponses du serveur sont ok depuis ce matin. Sur un instantané c’est jamais facile de se prononcer , c’est en continu ? C’est des pics ? Etc … mais là je vois rien d’alarmant.

Tu as les logs discourse ?
Tu va devoir passer une formation accélérée sur prometheus je pense
Y a un exporter discourse, postgres et tout ce qu’il faut !

[Zebre_bicolore]

Un ps sur le PID en question ?

[Armel]

Tu as les logs discourse ?
Tu va devoir passer une formation accélérée sur prometheus je pense

Quels logs exactement ?
J’aimerais bien mais malheureusement pas le temps et le sysadmin n’est vraiment pas mon truc

[Zebre_bicolore]

Le load average 15 min est mauvais , donc ce n est pas juste instané .

[anon62058358]

J’ai aussi eu des 520 et 521 hier, mais c’etait peut-être une relance de la base en live, ou lors du resizing… No se

[anon62058358]

Tu va devoir passer une formation accélérée sur prometheus je pense

ah ca a l’air top prometheus, je connaissai pas. Merci !!
Et grafana, c’est bien ??

[FRnunurs]

C’est le standard absolu maintenant ouais (et grafana aussi c’est top)

[Kheops (Xiom Vega Intro / Sternenfall Ox / Neottec Gammal All+)]

déja la base, le serveur a été reboot depuis que ca fonctionne moyen?

Depuis qu’on dit ca, y a plus de bug

[anon62058358]

Chuuuttt