Petit soucis d’augmentation de l’utilisation CPU du serveur dans le temps lors d’un live
Sur un des premiers essais que nous avons fais avec plusieurs utilisateurs qui regardaient le stream (environ une douzaine) tout se passait bien au début. Mais au bout d’un moment les utilisateurs on commencé à ressentir du lag. Et au même moment l’OBS utilisé pour générer le stream a commencé à avoir son compteur de dropped frames qui s’incrémentait.
Le problème ne semblait pas venir de l’utilisation mémoire, des disques ni de la bande passante réseau. Seule l’utilisation CPU sur le serveur semblait significative, sans toutefois saturer complètement les capacités du serveur.
Comme il y avait plusieurs paramètres changeant pendant le déroulement du test il n’était pas évident de comprendre ce qui s’était passé
- nombre de clients qui visualisaient le stream non constant
- flux vidéo qui passait d’images relativement statique a des séquence avec plus de mouvements
Il semblait y avoir une tendance dans l’utilisation CPU qui augmentait pendant le déroulement du test.
Mais en première analyse l’hypothèse était que que ffmpeg utilisait trop de CPU pour le transcoding dans les phases où le flux vidéo était très dynamique où bien que nous avions atteint un nombre trop important d’utilisateur pour ce serveur a un moment donné du test.
Exemple d’utilisation CPU lors d’un de ces premier test :
Cependant des test supplémentaire réalisé dans le but de déterminer des valeurs optimales pour la résolution de streaming et les résolutions de transcoding ont montré que dans certaines configuration de streaming le niveau de CPU augmentait de manière linéaire au fur et a mesure de la durée de streaming alors que rien de changeait au niveau du nombre de client regardant le stream ou de la dynamique du flux vidéo.
Exemple, test d’une heure de streaming avec
- un seul client visualisant le live
- 4 résolutions de transcoding d’activées
- publication du replay activée
Le début du palier dans l’utilisation CPU vers la fin correspond au moment ou OBS commençait à avoir des dropped frames.
La rampe d’utilisation mémoire un peu après correspond au moment ou OBS à perdu la connexion avec le serveur qui a alors fermé le stream et à commencé à publier le replay.
Test d’une heure de streaming avec :
- un seul client visualisant le live
- **1 seule résolutions de transcoding d’activée **
- publication du replay activée
On peut voir sur ce test qu’avec moins de résolutions de transcoding d’activées l’augmentation d’utilisation CPU a été plus lente.
On a donc essayé de faire un test sans transcoding du tout :
- un seul client visualisant le live
- **pas de transcoding activé : **
- publication du replay activée
Mais il y avait toujours une augmentation de l’utilisation CPU dans le temps.
Première heure de streaming :
Après environ 10h30 de streaming :
Graphe sur toute la durée du test :
Ce n’est qu’en désactivant la publication du replay que l’utilisation CPU semble rester stable, même en avec du trascoding activé.
Exemple, Test de 13h30 avec
- un seul client visualisant le live
- 1 résolutions de transcoding d’activée
- publication du replay désactivée
Les différents paliers d’utilisation CPU et réseau correspondent à des changements qui ont eu lieu dans la vidéo qui était streamée, pas à un comportement anormal du serveur peertube.
Durée totale du test :
Dernière heure du test :
Il semblerait que l’augmentation de CPU soit corrélée au nombre de fichiers générés dans /var/www/peertube/storage/streaming-playlists/hls/<hash-de-la-vidéo> (entre 2000 et 4000 fichiers vers la fin des tests ci dessus sauf le dernier ou seuls les quelques fichiers les plus récent sont conservés par le serveur)