Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Configuration d'un serveur icacast 2

Configuration d'un serveur icacast 2

6 réponses
Avatar
Alain JUPIN
Bonjour,

Sur un serveur d=C3=A9di=C3=A9 (chez OVH), j'ai configur=C3=A9 un serveur=
Icecast 2.
La configuration des <limits> est celle par d=C3=A9faut .et notamment :=20
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>

Le flux est un flux st=C3=A9r=C3=A9o MP3 de 140kpbs (kilo bits par sec) e=
t la
source est sur une connexion avec un d=C3=A9bit montant de 1Mbps (SDSL)

Tout fonctionne au poil, sauf que sur certains "listeners", le flux
s'arrete, bufferise et reprend. Cela arrive toute les 2 =C3=A0 5 minutes =
et
toujours sur les m=C3=AAmes auditeurs.

Afin de r=C3=A9soudre le probl=C3=A8me, faut-il augmenter la queue-size ?
burst-size ? voire les deux ?
Je comptais doubler les 2 valeurs.

J'ai =C3=A9galement un doute sur threadpool, la doc indique que la valeur=
par
d=C3=A9faut convient pour un serveur avec un trafic faible =C3=A0 moyen. =
Peut on
consid=C3=A9rer que mon serveur rentre dans cette cat=C3=A9gorie (j'ai en=
pointe
un peu moins de 100 auditeurs) ?

Pour info, le serveur tourne sous Lenny (up to date) et donc avec
icecast 2.3.2.

Merci pour votre aide.

--=20
Alain

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/1319729208.2078.74.camel@kepler
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Bernard Schoenacker
Le Thu, 27 Oct 2011 17:26:47 +0200,
Alain JUPIN a écrit :

Bonjour,

Sur un serveur dédié (chez OVH), j'ai configuré un serveur Icecast 2.
La configuration des <limits> est celle par défaut .et notamment :
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>

Le flux est un flux stéréo MP3 de 140kpbs (kilo bits par sec) e t la
source est sur une connexion avec un débit montant de 1Mbps (SDSL)

Tout fonctionne au poil, sauf que sur certains "listeners", le flux
s'arrete, bufferise et reprend. Cela arrive toute les 2 à 5 minutes et
toujours sur les mêmes auditeurs.

Afin de résoudre le problème, faut-il augmenter la queue-size ?
burst-size ? voire les deux ?
Je comptais doubler les 2 valeurs.

J'ai également un doute sur threadpool, la doc indique que la valeur
par défaut convient pour un serveur avec un trafic faible à moy en.
Peut on considérer que mon serveur rentre dans cette catégorie (j'ai
en pointe un peu moins de 100 auditeurs) ?

Pour info, le serveur tourne sous Lenny (up to date) et donc avec
icecast 2.3.2.

Merci pour votre aide.




bonjour,

serait il possible de mettre à jour la babasse ?

relire la page d'accueil :

http://www.debian.org/

commentaire :

La dernière version stable de Debian est la 6.0.

La dernière mise à jour de cette version est 6.0.3 et a ét é
publiée le 8 octobre 2011. Vous pouvez aussi accéder a ux autres
versions disponibles de Debian.

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 27 Oct 2011 17:26:47 +0200
Alain JUPIN wrote:

Sur un serveur dédié (chez OVH), j'ai configuré un serveur Icecast 2.
La configuration des <limits> est celle par défaut .et notamment :



Pour un <clients> et une B.P. de combien?

<threadpool>5</threadpool>



Combien y'a t'il de cores actifs?
En Gal c'est Nb_cores+1, voire (Nb_coresx2)+1 pour un svr très
chargé.

<queue-size>524288</queue-size>



C'est trop gros, le default est maintenant de 102400 (bytes), ce qui est
largement suffisant.

...
Tout fonctionne au poil, sauf que sur certains "listeners", le flux
s'arrete, bufferise et reprend. Cela arrive toute les 2 à 5 minutes et
toujours sur les mêmes auditeurs.
Afin de résoudre le problème, faut-il augmenter la queue-size ?
burst-size ? voire les deux ?
Je comptais doubler les 2 valeurs.



Non, c'est aux users à augmenter leur buffer; ce sont des choses qui
arrivent à cause de routers déficients, de congestion de rés eaux, de
changement de route pendant l'écoute, etc.
Cependant V. à la fin.

J'ai également un doute sur threadpool, la doc indique que la valeur par
défaut convient pour un serveur avec un trafic faible à moyen. Peut on
considérer que mon serveur rentre dans cette catégorie (j'ai en pointe
un peu moins de 100 auditeurs) ?



Normalement non.
Est-ce que les logs indiquent des timeouts?

Pour info, le serveur tourne sous Lenny (up to date) et donc avec
icecast 2.3.2.



Dernière version, mais certains ont eu des PBs de memory leaks avec:
http://old.nabble.com/Memory-leak-on-Icecast-2.3.2---Debian---td26691536.ht ml
Il te faudra sans doute surveiller de près la conso de RAM, et
éventuellement updater vers une version trunk si tu rencontres le mà ªme PB.

--
Q: Why did the germ cross the microscope?
A: To get to the other slide.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Alain JUPIN
Le jeudi 27 octobre 2011 à 18:21 +0200, Jean-Yves F. Barbier a é crit :
On Thu, 27 Oct 2011 17:26:47 +0200
Alain JUPIN wrote:

> Sur un serveur dédié (chez OVH), j'ai configuré un ser veur Icecast 2.
> La configuration des <limits> est celle par défaut .et notamment :

Pour un <clients> et une B.P. de combien?




Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.

> <threadpool>5</threadpool>

Combien y'a t'il de cores actifs?
En Gal c'est Nb_cores+1, voire (Nb_coresx2)+1 pour un svr très
chargé.




Vu que c'est un core 2 duo, je vais descendre à 3

> <queue-size>524288</queue-size>

C'est trop gros, le default est maintenant de 102400 (bytes), ce qui es t
largement suffisant.




OK, je vais donc descendre cette valeur à 102400.


Est-ce que les logs indiquent des timeouts?




Non, pas de déconnexion de la source ou de client du à un timeo ut. Par
contre, j'ai pas mal d'entrée comme celle ci :
[2011-10-27 14:49:33] INFO source/send_to_listener Client 75520
(1.2.3.4) has fallen too far behind, removing

> Pour info, le serveur tourne sous Lenny (up to date) et donc avec
> icecast 2.3.2.

Dernière version, mais certains ont eu des PBs de memory leaks ave c:
http://old.nabble.com/Memory-leak-on-Icecast-2.3.2---Debian---td2669153 6.html
Il te faudra sans doute surveiller de près la conso de RAM, et
éventuellement updater vers une version trunk si tu rencontres le même PB.



Pour l'instant RAS de ce coté là. Je vais surveiller l'usage de la RAM
donc.

Et merci pour les infos ;)

--
Alain JUPIN

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 27 Oct 2011 18:58:57 +0200
Alain JUPIN wrote:

> Pour un <clients> et une B.P. de combien?
Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.



Elles est pas mal celle-là, on ne me l'avait jamais encore faite!
Alors comment as-tu décidé du nombre max d'auditeurs??

Dans ton cas le download à peu d'importance, à partir du moment o ù sa B.P.
couvre le débit original de la source; mais l'upload est primordial pu isque
c'est lui qui décide du nb max de clients simultanés.
Excepté bien sûr si tu broadcast en multicast.

Non, pas de déconnexion de la source ou de client du à un timeo ut. Par
contre, j'ai pas mal d'entrée comme celle ci :
[2011-10-27 14:49:33] INFO source/send_to_listener Client 75520
(1.2.3.4) has fallen too far behind, removing



Ca parait relativement logique puisque tu ne connais pas la B.P. de
sortie: si elle est saturée les clients en sus se retrouvent avec
des trous dans le stream suffisamment gros pour ne plus pouvoir
être comblés (augmenter <queue-size> ne sert à rien dans ce cas là).
Et la capacité ne se calcule pas en faisant BP/(140000*Nb clients), il
faut aussi tenir compte de l'overhead des en-têtes (IP, UDP,RTP?),
de la taille de chaque packet et du nombre de packets/s.

--
BOFH excuse #1:
clock speed

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Alain JUPIN
Le jeudi 27 octobre 2011 à 19:17 +0200, Jean-Yves F. Barbier a é crit :
On Thu, 27 Oct 2011 18:58:57 +0200
Alain JUPIN wrote:

> > Pour un <clients> et une B.P. de combien?
> Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.

Elles est pas mal celle-là, on ne me l'avait jamais encore faite!
Alors comment as-tu décidé du nombre max d'auditeurs??

Dans ton cas le download à peu d'importance, à partir du mome nt où sa B.P.
couvre le débit original de la source; mais l'upload est primordia l puisque
c'est lui qui décide du nb max de clients simultanés.
Excepté bien sûr si tu broadcast en multicast.




Donc par coté auditeurs, j'entendais débit de la connexion chez
l'auditeur (par son FAI)
Coté connexion serveur, c'est du 100Mbps (serveur dédié ch ez OVH)

Le calcul du nombre max a été fait "à la louche" en utilis ant
80Mbps/0.2Mbps => 400

Désolé pour le malentendu.

> Non, pas de déconnexion de la source ou de client du à un t imeout. Par
> contre, j'ai pas mal d'entrée comme celle ci :
> [2011-10-27 14:49:33] INFO source/send_to_listener Client 75520
> (1.2.3.4) has fallen too far behind, removing

Ca parait relativement logique puisque tu ne connais pas la B.P. de
sortie: si elle est saturée les clients en sus se retrouvent avec
des trous dans le stream suffisamment gros pour ne plus pouvoir
être comblés (augmenter <queue-size> ne sert à rien dans ce cas là).
Et la capacité ne se calcule pas en faisant BP/(140000*Nb clients) , il
faut aussi tenir compte de l'overhead des en-têtes (IP, UDP,RTP?),
de la taille de chaque packet et du nombre de packets/s.




Oui ca je sais, mais je suis très loin des 100Mbps garantis par
l'hébergeur. Dans mon calcul (cf plus haut) pour voir "large" j'ai
compter 200kpbs/auditeurs. Actuellement, lors des pics de fréquentat ion
(environ 80 auditeurs), la BP en sortie (upload) grimpe à 14Mbps
environ.

Cordialement,

--
Alain JUPIN

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Yves F. Barbier
On Thu, 27 Oct 2011 19:59:40 +0200
Alain JUPIN wrote:

Donc par coté auditeurs, j'entendais débit de la connexion chez
l'auditeur (par son FAI)
Coté connexion serveur, c'est du 100Mbps (serveur dédié ch ez OVH)

Le calcul du nombre max a été fait "à la louche" en utilis ant
80Mbps/0.2Mbps => 400



Ok, ça roule.
Je suppose, pour ce type d'appli, que le débit le service a étà © choisi
en conséquence et qu'il est garanti à 100%?

...
Oui ca je sais, mais je suis très loin des 100Mbps garantis par
l'hébergeur.



V. ci-dessus (le contrat précise-t'il bien que c'est 100Mbps garanti?)

Si c'est le cas, c'est qu'il y a autre chose qui merdouille, tel que
décrit dans l'email dont je t'ai passé l'URL sans doute.

Dans mon calcul (cf plus haut) pour voir "large" j'ai
compter 200kpbs/auditeurs. Actuellement, lors des pics de fréquentat ion
(environ 80 auditeurs), la BP en sortie (upload) grimpe à 14Mbps
environ.



Alors augmente <threadpool> disons à 7 ou 9, vérifie que le Nb de fichiers
ouvrables est suffisamment élevé, augmente le niveau de log du sv r,
et fais un test à partir de chez toi (utilise vlc &| audacious en auto risant
plusieurs instances) pour charger la mule et 'gade ce que dit un 'top'
(1s de délai) au niveau CPU & RAM consommés (le lancer dans valgr ind, tel
qu'indiqué, donnerait plus d'infos mais c'est déjà ça).

Tant qu'à faire, donne aussi l'URL de ton svr pour voir si ici ça lag ou pas.

Question subsidiaire: pourquoi avoir choisi un débit de 140kbps?

--
It is impossible to experience one's death objectively and still carry a tu ne.
-- Woody Allen

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/