A small update from my side.. i have updated both icecast and libshout to
the nightly snapshot versions of icecast.org. Also, in the configfile i have
raised the threadpool to 500 and all timeouts to 3000.
This did help a bit. Right now i can get it up to 1020 inputstreams, however
then it just stops accepting new connections.
Is there a theoretical maximum to the number of mountpoints icecast can
handle?
-----Oorspronkelijk bericht-----
Van: icecast-bounces@xiph.org [mailto:icecast-bounces@xiph.org] Namens Henri
Zikken
Verzonden: woensdag 5 oktober 2005 17:02
Aan: icecast@xiph.org
Onderwerp: [Icecast] icecast2 mountpoints maximum
We are using icecast as stream-relay for a true narrowcast solution
we've developed. The idea behind the system is that each individual
client gets it's own mountpoint.
Basically we have an application that creates streams. Its written in
c++ and uses libshout to handle connecting to icecast.
Everything works fine, as long as we keep the number of mountpoints
below 347. As soon as we try to create more mountpoints, it stops, as
in, it never returns a mountpoint.
in our application, we create a new mountpoint by doing:
shout = shout_new()
this never returns after the 347th stream, so our application waits
indefinatly for icecast to return a mountpoint.
Our icecast2.xml reads as follows:
<icecast>
<limits>
<clients>3000</clients>
<sources>3000</sources>
<threadpool>30</threadpool>
<queue-size>102400</queue-size>
<client-timeout>300</client-timeout>
<header-timeout>300</header-timeout>
<source-timeout>300</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>12800</burst-size>
</limits>
<authentication>
<source-password>hackme</source-password>
<relay-password>hackme</relay-password>
<admin-user>admin</admin-user>
<admin-password>do_not_hackme</admin-password>
</authentication>
<hostname>localhost</hostname>
<listen-socket>
<port>8000</port>
</listen-socket>
<paths>
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<alias source="/" dest="/status.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1
Error -->
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
The icecast version is: 2.2.0
The last part of the (error.log) logfile reads:
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_total_connections (346)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listeners (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
server_name ("10308")
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
connections (347)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_client_connections (347)
[2005-10-05 16:59:23] DBUG stats/process_source_event new source stat
/10309
[2005-10-05 16:59:23] DBUG stats/process_source_event new node public (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listenurl (http://localhost:8000/10309)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node sources
(347)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_total_connections (347)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listeners (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
server_name ("10309")
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
connections (348)
Is this a hard-coded limit of sources, or are we doing something wrong?
Regards,
Henri Zikken
_______________________________________________
Icecast mailing list
Icecast@xiph.org
http://lists.xiph.org/mailman/listinfo/icecast
On 10/5/05, Henri Zikken <henri.zikken@deltasolutions.nl> wrote:> A small update from my side.. i have updated both icecast and libshout to > the nightly snapshot versions of icecast.org. Also, in the configfile i have > raised the threadpool to 500 and all timeouts to 3000. > > This did help a bit. Right now i can get it up to 1020 inputstreams, however > then it just stops accepting new connections. > > Is there a theoretical maximum to the number of mountpoints icecast can > handle?Using icecast 2.3 may help, using the development version will not (right now, I don't think it contains anything significant that isn't in 2.3 - when it does, it probably won't be stable). As for limits: yes, but it'll be highly platform specific, and is not a limit in icecast itself. You'll probably first hit either a limit on the number of threads permitted (one per source, plus a few for the rest of icecast), or the limit on open file descriptors (one per source, plus one per client, plus a few for the rest of icecast) Also, icecast will be horribly inefficient for this, it's really totally the wrong tool. Why not just make your application stream directly to the single client that's listening to that stream? Anyway, I can't say what limit you might have hit, or whether it's a limit that's increasable, or how to increase it, since you didn't say what platform you were running on. We can't guess things like that. Mike
> A small update from my side.. i have updated both icecast and libshout to > the nightly snapshot versions of icecast.org. Also, in the configfile i have > raised the threadpool to 500 and all timeouts to 3000. > > This did help a bit. Right now i can get it up to 1020 inputstreams, however > then it just stops accepting new connections. > > Is there a theoretical maximum to the number of mountpoints icecast can > handle?No, but most Unix-like operating systems impose a 1024 file descriptor limit by default for any user. Considering that you have stdin, stdout, and stderr + 1020, that's probably what you're seeing. Read up on how to extend your operating system limits via ulimit or some other similar command. jack.
We are using icecast as stream-relay for a true narrowcast solution
we've developed. The idea behind the system is that each individual
client gets it's own mountpoint.
Basically we have an application that creates streams. Its written in
c++ and uses libshout to handle connecting to icecast.
Everything works fine, as long as we keep the number of mountpoints
below 347. As soon as we try to create more mountpoints, it stops, as
in, it never returns a mountpoint.
in our application, we create a new mountpoint by doing:
shout = shout_new()
this never returns after the 347th stream, so our application waits
indefinatly for icecast to return a mountpoint.
Our icecast2.xml reads as follows:
<icecast>
<limits>
<clients>3000</clients>
<sources>3000</sources>
<threadpool>30</threadpool>
<queue-size>102400</queue-size>
<client-timeout>300</client-timeout>
<header-timeout>300</header-timeout>
<source-timeout>300</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>12800</burst-size>
</limits>
<authentication>
<source-password>hackme</source-password>
<relay-password>hackme</relay-password>
<admin-user>admin</admin-user>
<admin-password>do_not_hackme</admin-password>
</authentication>
<hostname>localhost</hostname>
<listen-socket>
<port>8000</port>
</listen-socket>
<paths>
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<alias source="/" dest="/status.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1
Error -->
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
The icecast version is: 2.2.0
The last part of the (error.log) logfile reads:
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_total_connections (346)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listeners (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
server_name ("10308")
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
connections (347)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_client_connections (347)
[2005-10-05 16:59:23] DBUG stats/process_source_event new source stat
/10309
[2005-10-05 16:59:23] DBUG stats/process_source_event new node public (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listenurl (http://localhost:8000/10309)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node sources
(347)
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
source_total_connections (347)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
listeners (0)
[2005-10-05 16:59:23] DBUG stats/process_source_event new node
server_name ("10309")
[2005-10-05 16:59:23] DBUG stats/modify_node_event update node
connections (348)
Is this a hard-coded limit of sources, or are we doing something wrong?
Regards,
Henri Zikken