Son qui saccade
#1
Bonjour,

Pendant les 10/15 minutes post-réveil, le son saccade.
C'est apparemment causé par la charge du système qui est supérieure à 1 et l'iowait, bref, le hardware.

Pendant les 5 premières minutes, je comprends, le temps que tout démarre, mais au final, c'est plutôt long.
Et l'os swappe qui plus est.

Peut-être y'a-t-il des optimisations système de réalisable.
Par exemple, pour postgresql, on a 37 processus, ce qui est sans doute trop vu le hardware du PI 0 et la faible nombre de requêtes que le lapin doit générer non ?
max_parallel_workers
shared_buffers à 128MB me semble également un peu lourd
wal_level doit impérativement être passé à minimal pour générer moins d'I/O
checkpoint_timeout et checkpoint_completion_target pourraient être passés à 30 et 0.8


De base, postgresql est plus gourmand (pré-requis de 2 Go de ram) que mysql (sans parler de sqlite), donc cela n'arrange pas les choses.

Il y a sans doute d'autres choses à optimiser, mais je dois regarder ça d'un peu plus près, et sans doute mettre sysstat en place pour voir ce qui limite réellement.
Nabaztag:tag Konia revenu à la vie grâce à TagTagTag !
Répondre
#2
Bonjour,

L'optimisation des réglages de PostgreSQL, c'est une bonne idée, effectivement les réglages par défaut sont utilisés. N'hésitez pas à faire un PR sur GitHub, l'installation se fait via des scripts sur les branches releng et release (faites plutôt le PR sur la branche releng).

Cependant il faudrait mesurer et s'assurer de l'impact des différents réglages.

Par exemple, si vous regardez avec top, vous verrez le temps CPU total utilisé par PostgreSQL au démarrage (et dans le temps), qui est particulièrement bas. Au bout de 10 minutes sur un des lapins, j'ai un temps total de PostgreSQL inférieur à la seconde !

J'attire votre attention sur le fait que les différents processus PostgreSQL partagent de la mémoire, et il ne faut pas additionner la quantité utilisée.
Typiquement, vous verrez, malgré les 128 MB de shared_buffers, PostgreSQL en utilise très peu (autour de 10-15 MB au total). C'est très faible par rapport aux 20 Mo par interpréteur Python.

Par ailleurs, max_parallel_workers n'a strictement aucun impact ici. Ça ne sert que pour les requêtes que l'optimisateur de PostgreSQL va décider de paralléliser, et vu le modèle de données, il n'y en a aucune.

Normalement, l'OS ne swappe pas du tout et sur la distribution de base, tout tient sans swap (vérifié), à part lors de la reconnaissance vocale, avec certaines phrases. C'est une limitation connue, et c'est dû à kaldi qui peut devenir très gourmand en mémoire pour reconnaître des phrases qui ne sont pas générables par la grammaire. J'ai une piste assez sérieuse, et j'espère qu'on va pouvoir revenir à une configuration de swap par défaut. Je préfère qu'on ne désactive pas la swap parce que Linux gère très mal les situations de manque de mémoire, et il vaut mieux swapper que de se retrouver en situation de manque de mémoire. Autant PostgreSQL sur un Pi Zero c'est parfaitement jouable, autant la reconnaissance vocale (ASR + NLU), c'était un des challenges.

Le son qui saccade, c'est bizarre, et je pense que ça vient d'un autre problème. Utilisez-vous la SD fournie avec le kit ?
Répondre
#3
J'utilise bien la sd fournie et c'est un bon modèle, c'est également celle que j'emploie sur rspi et odroid.
Je vais prendre le temps de suivre tôt ça et je ferai un retour ensuite.
Nabaztag:tag Konia revenu à la vie grâce à TagTagTag !
Répondre
#4
Bon, pour le moment, je n'ai vraiment ça que post-réveil du lapin (il est bien allumé, il se réveille simplement à 8h).

Le reste du temps, cela swappe certes (après, cela peut être normal si il s'agit de données peu utilisées), mais à part un processus zombie, RAS (cela change sans doute quand on utilise le tts ou la reconnaissance vocale).

sysstat installé, je verrai déjà demain matin si le problème se reproduit
Code :
oot@konia:~# free -m
              total        used        free      shared  buff/cache  available
Mem:            480        303          62          8        114        118
Swap:          309        198        111

root@konia:~# ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }'
        0.00 Mb COMMAND
      467.62 Mb /home/pi/pynab/venv/bin/python -m nabd.nabd
        67.31 Mb /home/pi/pynab/venv/bin/python -m nabweatherd.nabweatherd
        58.36 Mb /home/pi/pynab/venv/bin/python -m nabmastodond.nabmastodond
        56.55 Mb /home/pi/pynab/venv/bin/python -m nabairqualityd.nabairqualityd
        55.04 Mb /home/pi/pynab/nabblockly/_build/default/rel/nabblockly/bin/nabblockly -Bd -K true -A30 -- -root /home/pi/pynab/nabblockly/_build/default/rel/nabblockly -progname home/pi/pynab/nabblockly/_build/default/rel/nabblockly/bin/nabblockly -- -home /root -- -noshell -noshell -noinput -boot /home/pi/pynab/nabblockly/_build/default/rel/nabblockly/releases/0.1.0/nabblockly -mode embedded -boot_var ERTS_LIB_DIR /usr/lib/erlang/lib -config /home/pi/pynab/nabblockly/_build/default/rel/nabblockly/releases/0.1.0/sys.config -sname nabblockly -setcookie nabblockly_cookie -heart -- foreground
        53.14 Mb /home/pi/pynab/venv/bin/python -m nabtaichid.nabtaichid
        53.14 Mb /home/pi/pynab/venv/bin/python -m nabsurprised.nabsurprised
        29.17 Mb /home/pi/pynab/venv/bin/python -m nabclockd.nabclockd
        24.59 Mb /home/pi/pynab/venv/bin/python3.7 /home/pi/pynab/venv/bin/gunicorn nabweb.wsgi
        24.43 Mb /usr/sbin/rngd -r /dev/hwrng
        20.69 Mb /home/pi/pynab/venv/bin/python -m nab8balld.nab8balld
        18.96 Mb (sd-pam)
        18.68 Mb /sbin/init
        17.33 Mb /usr/sbin/rsyslogd -n -iNONE
        9.08 Mb /home/pi/pynab/venv/bin/python3.7 /home/pi/pynab/venv/bin/gunicorn nabweb.wsgi
        8.67 Mb /lib/systemd/systemd-timesyncd
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        2.27 Mb postgres: 11/main: pynab pynab [local] idle
        1.82 Mb nginx: worker process
        1.77 Mb postgres: 11/main: autovacuum launcher
        1.66 Mb postgres: 11/main: logical replication launcher
        1.50 Mb postgres: 11/main: stats collector
        1.49 Mb postgres: 11/main: checkpointer
        1.38 Mb /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
        1.38 Mb postgres: 11/main: background writer
        1.38 Mb postgres: 11/main: walwriter
        1.31 Mb nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
        1.25 Mb sshd: root@pts/0
...

root@konia:~# ps aux | grep Z
USER      PID %CPU %MEM    VSZ  RSS TTY      STAT START  TIME COMMAND
root      2310  0.0  0.0      0    0 ?        Z    Feb02  0:00 [sh] <defunct>
root      8532  0.0  0.3  7332  1916 pts/0    S+  18:47  0:00 grep Z

root@konia:~# ps -ef |grep 2310
root      2310  2180  0 Feb02 ?        00:00:00 [sh] <defunct>
root      8537  8018  0 18:48 pts/0    00:00:00 grep 2310

root@konia:~# ps -ef |grep 2180
root      2180  522  0 Feb02 ?        00:00:37 /home/pi/pynab/venv/bin/python3.7 /home/pi/pynab/venv/bin/gunicorn nabweb.wsgi
root      2310  2180  0 Feb02 ?        00:00:00 [sh] <defunct>
root      8539  8018  0 18:48 pts/0    00:00:00 grep 2180
Nabaztag:tag Konia revenu à la vie grâce à TagTagTag !
Répondre
#5
Bon, pour la saccade, c'est "résolu".
Je l'avais mis au réveil à 8h et comme il devait se réveiller et annoncer l'heure en même temps, cela devait lui faire trop.

Réveil avancé un peu et le problème ne se produit plus.
Je regarderai quand même ce que l'on peut optimiser.
Nabaztag:tag Konia revenu à la vie grâce à TagTagTag !
Répondre
#6
Ça ressemble beaucoup à un problème d'utilisation massive de la swap (198 Mo sur 310), du fait d'un besoin trop important de RAM pour la reconnaissance vocale.
Avec la 0.7.2, ça devrait être réglé.
Répondre
#7
Un petit up, parce que non seulement l'accès web / SSH au lapin est extrêmement lent (voire, je tombe sur une 504...), mais le son est saccadé sans cesse, et ce, alors qu'il est à jour Sad
Quelque chose à faire sur le swap pour le sauver ?
Merci Smile
Répondre
#8
(04-02-2020, 05:14 PM)waazdakka a écrit : Un petit up, parce que non seulement l'accès web / SSH au lapin est extrêmement lent (voire, je tombe sur une 504...), mais le son est saccadé sans cesse, et ce, alors qu'il est à jour Sad
Quelque chose à faire sur le swap pour le sauver ?
Merci Smile

Il faut commencer par voir si c'est une anomalie avec un redémarrage (via le ssh c'est facile).
Après son redémarrage, si le problème persiste, il va falloir creuser la liste des processus.

Un lapin lent est un lapin qui manque de ressources (mémoire ou processeur) et soit il a trop à faire (reconnaissance vocale comme discuté plus haut) soit il a une fuite mémoire.

À voir donc après redémarrage si les symptômes persistent et si oui, dans quel état sont le processeur et la mémoire quand il est comme ca.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)