6 votes

Causes de la gigue RTP au niveau du serveur

Pour étudier certains problèmes de qualité d'appel (points morts de 0,5 à 1 seconde dans les appels), j'ai fait une capture de paquets d'un appel téléphonique entre deux extensions sur le même PBX. Comme je capturais à partir du PBX, j'ai été plutôt surpris de voir Wireshark rapporter un énorme pic de gigue qui correspondait à un point mort dans l'appel :

screenshot of jitter graph

D'après ce que j'ai compris, la gigue est causée par la perte de paquets et/ou la latence en transit, et le flux RTP qui quitte le PBX doit être relativement pur. Mais ce pic est apparu dans les quatre flux RTP (du bureau 1 au PBX, du bureau 2 au PBX, du PBX au bureau 1, du PBX au bureau 2). Il semble donc que les paquets soient déjà en mauvais état au moment où ils quittent le serveur.

Le PBX est Asterisk 13 sur Scientific Linux (RHEL) 6.9 (fonctionnant sur un invité VMWare ESXi 5.5 avec des outils récemment mis à jour et des adaptateurs VMXNET3). Le processeur se maintient assez régulièrement autour de 5-15% d'utilisation, et le trafic réseau est minimal. Où puis-je chercher à résoudre ce problème ? Existe-t-il des causes courantes pour ce type de problème ? Je suppose que puisque les problèmes sont présents sur le serveur, je peux exclure les problèmes du côté du réseau externe ?

0 votes

Veuillez fournir les données des couches inférieures. Combien de retransmissions peut-on observer au niveau IP ?

0 votes

@Nils, quel type de données recherchez-vous ? Il s'agit d'un flux UDP, donc pas de retransmissions ; pas de paquets perdus ou hors séquence non plus.

0 votes

Si rien de tel n'est visible, le problème se situe plus loin, probablement derrière votre premier routeur/commutateur. Pouvez-vous également analyser le trafic sur l'interface ESXi physique (par exemple, par la mise en miroir des ports par l'équipe réseau) ?

2voto

Gabedini Points 1

J'ai enfin trouvé la solution ! TLDR : désactivez la gestion de l'énergie sur l'hôte.

Malgré la faible utilisation du CPU, nous avons pensé que cela avait quelque chose à voir avec la charge du CPU. Nous avons donc essayé de charger le CPU, en nous attendant à ce que ce problème de points morts dans les appels s'aggrave. Au lieu de cela, il a complètement disparu. Donc, après avoir regardé les statistiques d'utilisation du CPU dans vCenter de nombreuses fois, j'ai finalement regardé dans le fichier autre sur ce graphique.

CPU usage graph showing high ready time

Ce n'est probablement pas une nouvelle pour beaucoup, mais j'ai découvert que Temps de préparation du CPU est le temps pendant lequel une VM est prête à utiliser le CPU, mais les ressources physiques ne peuvent pas être allouées par l'hôte. La plupart des sources que j'ai trouvées disent que tout ce qui est inférieur à 5 % n'est pas un problème, mais cela semblait certainement avoir un impact sur nos flux vocaux. Nous avons vu les coupures toutes les minutes, et le graphique a également montré un pic dans le temps de disponibilité toutes les minutes.

Je me suis donc demandé pourquoi cela disparaissait lorsque le processeur était très sollicité et j'ai pensé que cela devait être dû à une sorte de gestion de l'alimentation. Lorsque l'hôte voit une utilisation accrue, il met les ressources du CPU à la disposition de la VM de manière constante. J'ai donc désactivé la gestion de l'alimentation dans le BIOS de l'hôte, et voilà :

CPU usage graph showing low ready time

La légère augmentation du temps de préparation vers la fin du graphique correspond à une demi-douzaine d'autres VM qui migrent à nouveau vers cet hôte.

Les traces des appels montrent maintenant des quantités négligeables de gigue, et les coupures ont disparu des appels. Des recherches plus poussées ont montré qu'il s'agissait d'un problème assez courant avec les charges de travail qui sont à la fois sensibles à la latence et non gourmandes en ressources CPU. La gestion de l'énergie voit l'utilisation très faible du CPU et suppose qu'elle peut étrangler le processeur, alors qu'elle ne devrait pas le faire !

0 votes

Intéressant. Pouvez-vous tester s'il suffit de désactiver les états C (deep sleep) dans le BIOS ? A part cela - oui - "l'économie d'énergie" a des effets bizarres dans les VMs et les VMs uniques ne déclenchent pas de montée en puissance. La meilleure pratique consiste à désactiver la gestion de l'énergie pour les systèmes productifs - à partir de VMWare.

1 votes

Après avoir réalisé que la gestion de l'alimentation pouvait être à l'origine du problème, j'ai essayé de la désactiver sur l'hôte à partir du client web vSphere (en réglant la gestion de l'alimentation sur "haute performance" au lieu de "équilibré") et cela n'a pas empêché les pics dans le temps de préparation.

0voto

simonpa71 Points 208

J'ai eu un problème similaire, mais bien pire, avec de nombreux pics dans le graphique RTP de Wireshark, des sifflements et un son haché.

Au cours de nombreuses expériences, j'ai jeté le Base de données du PCEM qui avait atteint 1,5 Go. J'avais remarqué la taille, mais j'ai reporté l'élagage jusqu'à ce que j'aie réglé les problèmes audio. B-)

Cela a apparemment amélioré immédiatement la qualité audio, y compris le transcodage des messages IVR en G729.

Les retards étaient également visibles d'un SmokePing trace vers le VPS.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X