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,
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,
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.
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>
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 à moyen. 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.
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>
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 à moyen. 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.
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>
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 à moyen. 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.
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?
> <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 es t
largement suffisant.
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 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.
On Thu, 27 Oct 2011 17:26:47 +0200
Alain JUPIN <ajupin@jupin.net> 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?
> <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 es t
largement suffisant.
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 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.
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?
> <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 es t
largement suffisant.
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 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 un <clients> et une B.P. de combien?
Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.
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 un <clients> et une B.P. de combien?
Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.
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 un <clients> et une B.P. de combien?
Coté source, SDSL 1Mbps. Coté auditeurs, j'en sais rien.
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
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.
> 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.
On Thu, 27 Oct 2011 18:58:57 +0200
Alain JUPIN <ajupin@jupin.net> 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.
> 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.
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.
> 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.
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
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.
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
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.
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
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.