Old 6th December 2013, 08:26   #1
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Maximum Shoutcast listener slots

I'm currently still using Shoutcast v1, but thinking about upgrading to v2 eventually.
Question:
How many listener slots can a Shoutcast instance reliably support, if bandwidth (and server resources) isn't an issue? Looking for answers for both v1 and v2...
I remember seeing the number 1000 somewhere - does this make sense?
Thanks!
isaacl is offline   Reply With Quote
Old 6th December 2013, 16:41   #2
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
Pretty sure each instance can handle about 1000.
Bryon Stout is offline   Reply With Quote
Old 6th December 2013, 20:02   #3
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Thanks!
isaacl is offline   Reply With Quote
Old 6th December 2013, 20:16   #4
DrO
 
Join Date: Sep 2003
Posts: 27,880
it primarily depends on whether the machine can keep up with large numbers of concurrent network connections and all of the processing the DNAS needs to do to cope with it. i've had under testing ~2500 concurrent test connections with a v2 DNAS though it started to get unstable at that point (and with how most streams are running, going over a hundred is not the norm but it can cope with it). so would say 1500 is probably a decent limit (as after that, and even a few hundred), you're probably better splitting the provision of the stream over multiple DNAS and locations to better cater for demand variations.
DrO is offline   Reply With Quote
Old 6th December 2013, 20:21   #5
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Thanks!
Did you find the same thing with v1? Are the numbers around the same?
My current v1 limit is set to 1000 slots, but I often get close to 800 filled (not always unique - that's normally closer to 500-600), and I wouldn't mind increasing the limits a bit...
Thanks.
isaacl is offline   Reply With Quote
Old 6th December 2013, 20:28   #6
DrO
 
Join Date: Sep 2003
Posts: 27,880
never tried with v1 as there was no need for me to do so as i was trying to ensure the v2 DNAS could cope with such levels (and since v1 hasn't been actively developed in years).
DrO is offline   Reply With Quote
Old 6th December 2013, 20:31   #7
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Got it - thanks!
Any recommendations/ideas around what it might be able to handle?
isaacl is offline   Reply With Quote
Old 6th December 2013, 20:35   #8
DrO
 
Join Date: Sep 2003
Posts: 27,880
i did mention what i'd been able to get under testing in my prior reply to the one above
DrO is offline   Reply With Quote
Old 9th December 2013, 01:22   #9
SomaFM
Member
 
Join Date: Oct 2000
Posts: 83
Some notes on sc_serv v1 - you should be able to get 5000 concurrents on a decent box with no problem. You'll need to do some tuning possibly, a big issue is making sure your ulimit is set correctly. Here are some notes I have on tuning Ubuntu for sc_serv with lots of capacity:

verify that the following are all set to the default value of 1; this command will show the results:

/sbin/sysctl net.ipv4.tcp_window_scaling
/sbin/sysctl net.ipv4.tcp_timestamps
/sbin/sysctl net.ipv4.tcp_sack

We add the following to /etc/sysctl.conf :

#sc_serv tuning for sysctl.conf:

net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
fs.file-max = 798200
net.ipv4.tcp_fin_timeout=25
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
fs.file-max=798200


Then run sysctl -p to load those changed values.

#Increase the ulimit for maximum open files
#Add this to /etc/security/limits.conf

shoutcast hard nofile 10240
shoutcast soft nofile 10240
root hard nofile 10240
root soft nofile 10240

###In /etc/pam.d/su add or uncomment the line
session required pam_limits.so

These should be similar for other Linuxes.

Note that you can see a really high load on a sc_serv box and it will still stream OK.

FYI- We use Intel E3-1230 V2 CPUs in our streaming servers. You should also make sure you have a motherboard with a good ethernet chipset. We're using Supermicro SYS-5017C-LF boxes which have Intel LAN controllers.
SomaFM is offline   Reply With Quote
Old 9th December 2013, 01:47   #10
DrO
 
Join Date: Sep 2003
Posts: 27,880
well the maximum is always going to vary upon what / how the DNAS is being run like i can get 500-600 on the raspberry pi build before i get consistent stuttering compared to a CentOS VM on my main dev machine which can hit 2500 before stuttering (and that's only from it using up too much of the machine resources).

obviously a recently spec'd dedicated machine is going to (or at least should) be able to go far higher when you're not using the same machine to run things as the test connections or as part of a shared VM setup where you're contending for the same resources as other VMs on the same host.


so really the only way to know is to stress test what's going to be used to determine what it can actually support as there's no general fixed rule on capacity when there's so many different factors.
DrO is offline   Reply With Quote
Old 10th December 2013, 17:42   #11
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
SomaFM....

I see you said to "Then run sysctl -p to load those changed values"

I followed your instructions to a "T" and wanted to know if I need to restart shoutcast or anything else for your instructions to be working properly.?


Reason I am trying your method is because 1. why not and 2. my shoutcast shut off once I hit 350 listeners. I thought my config files were properly set..

Here are my current file descriptor limit data
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63896
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 63896
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited


my open files here is set to 4096 and that still didnt help. So I hope your above instructions allow my station to handle more listeners. My machine is very well capable of handling them (see my sig)
Bryon Stout is offline   Reply With Quote
Old 10th December 2013, 21:15   #12
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
This was the message I got..

[MICROSERVER] Could not create signal pipe [Increase the open files (ulimit -n) limit]


Hopefully I fixed it with the instructions listed above
Bryon Stout is offline   Reply With Quote
Old 10th December 2013, 21:18   #13
DrO
 
Join Date: Sep 2003
Posts: 27,880
ergh... what was the DNAS showing in it's log as the ulimit -n value? and any changes to those settings generally requires the process to be restarted so it'll be started with the changed values.
DrO is offline   Reply With Quote
Old 10th December 2013, 21:21   #14
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
DrO.


Is there a way for me to test if my changes helped? Other than naturally getting 350+ concurrent listeners?
Bryon Stout is offline   Reply With Quote
Old 10th December 2013, 21:22   #15
DrO
 
Join Date: Sep 2003
Posts: 27,880
just hit it with a load of timed curl connections to push it over the listener limit (is one of the simplest ways to do load testing).
DrO is offline   Reply With Quote
Old 10th December 2013, 21:24   #16
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
Thanks DrO!
Bryon Stout is offline   Reply With Quote
Old 10th December 2013, 22:37   #17
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
damn.. after doing what SomaFM said I went to check my ulimit -a

Here is what came back...


core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63896
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 63896
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Now do the changes I made with SomaFM instructions over ride this?
Bryon Stout is offline   Reply With Quote
Old 11th December 2013, 03:05   #18
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
another question.

When I add this...

shoutcast hard nofile 10240
shoutcast soft nofile 10240
root hard nofile 10240
root soft nofile 10240

If I am running shoutcast 2.2.1 should it be the following?

shoutcast2 hard nofile 10240
shoutcast2 soft nofile 10240
root hard nofile 10240
root soft nofile 10240
Bryon Stout is offline   Reply With Quote
Old 11th December 2013, 03:09   #19
DrO
 
Join Date: Sep 2003
Posts: 27,880
'shoutcast' is the user account being used to run the DNAS, etc in this instance.
DrO is offline   Reply With Quote
Old 11th December 2013, 05:40   #20
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
Thanks DrO
Bryon Stout is offline   Reply With Quote
Old 26th December 2013, 07:52   #21
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Quote:
Originally Posted by SomaFM View Post
Some notes on sc_serv v1 - you should be able to get 5000 concurrents on a decent box with no problem. You'll need to do some tuning possibly, a big issue is making sure your ulimit is set correctly. Here are some notes I have on tuning Ubuntu for sc_serv with lots of capacity:

verify that the following are all set to the default value of 1; this command will show the results:

/sbin/sysctl net.ipv4.tcp_window_scaling
/sbin/sysctl net.ipv4.tcp_timestamps
/sbin/sysctl net.ipv4.tcp_sack

We add the following to /etc/sysctl.conf :

#sc_serv tuning for sysctl.conf:

net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
fs.file-max = 798200
net.ipv4.tcp_fin_timeout=25
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
fs.file-max=798200


Then run sysctl -p to load those changed values.

#Increase the ulimit for maximum open files
#Add this to /etc/security/limits.conf

shoutcast hard nofile 10240
shoutcast soft nofile 10240
root hard nofile 10240
root soft nofile 10240

###In /etc/pam.d/su add or uncomment the line
session required pam_limits.so

These should be similar for other Linuxes.

Note that you can see a really high load on a sc_serv box and it will still stream OK.

FYI- We use Intel E3-1230 V2 CPUs in our streaming servers. You should also make sure you have a motherboard with a good ethernet chipset. We're using Supermicro SYS-5017C-LF boxes which have Intel LAN controllers.
Hey, thanks for the info, just seeing this info now.

I'm currently running Shoutcast v1 through WHMSonic with cPanel on a CentOS VM on my server (it has 4 cores of my E3-1270 CPU, and 12 GB of RAM).

(I also have a Centova VM set up that currently isn't in use, but I might switch to that eventually, though I'm not sure whether to use Shoutcast v1 or v2.)

Will these instructions also work on my cPanel/CentOS VM?
And I also have websites hosted on the same box - will these changes cause any issues with cPanel and everything else running on the box?

And when you say 5000 concurrent listeners, is that all on one Shoutcast instance?

My server has a gigabit connection to the internet, and I haven't had any problems with bandwidth/capacity yet, so that shouldn't be a problem, though I don't have anywhere near 5000 listeners yet, but hopefully we'll get there!

Thanks a lot!
isaacl is offline   Reply With Quote
Old 26th December 2013, 07:59   #22
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Quote:
Originally Posted by DrO View Post
just hit it with a load of timed curl connections to push it over the listener limit (is one of the simplest ways to do load testing).
Do you happen to have any commands/scripts which will do this?
Thanks!
isaacl is offline   Reply With Quote
Old 26th December 2013, 10:03   #23
jaromanda
Forum King
 
Join Date: Jun 2007
Location: Under the bridge
Posts: 2,261
Quote:
Originally Posted by isaacl View Post
Do you happen to have any commands/scripts which will do this?
Thanks!
code:

MAX=1000
while [ $MAX -gt 0 ]
do
MAX=$((MAX-1))
curl -o /dev/null {insert url here}
done


Is it just me or are shoutcast users getting dumber?
jaromanda is offline   Reply With Quote
Old 31st December 2013, 17:38   #24
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
Thanks again SomaFM and DrO.

With those changes that were suggested I was able to pass the 350 tune ins today.
Bryon Stout is offline   Reply With Quote
Old 2nd February 2014, 08:49   #25
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
@SomaFM - forgot to respond, but I tried your settings on my recently set up Debian/Centova box, and they seemed to work well - much appreciated!
I had to subsitute ccuser for shoutcast in the limits.conf file, but otherwise, everything seemed to work perfectly!
Now all I need is to get more listeners!
isaacl is offline   Reply With Quote
Old 2nd February 2014, 08:52   #26
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Just came across this Shoutcast v1 server from one of the highest listed station on the Shoutcast YP - http://203.150.225.71:8000 (and they also have http://203.150.225.77:8400).
I didn't think a Shoutcast v1 server could go that high - very curious to find out what kind of servers and bandwidth they need for that...
isaacl is offline   Reply With Quote
Old 10th February 2014, 14:35   #27
DrO
 
Join Date: Sep 2003
Posts: 27,880
if the underlying machine can cope with it and subject to how the software is coded, you can hit 1000s of listeners without too much issue. though i've always suspected at some of the 'large' stations are fiddling things with the DNAS (fake updates to get around load balancing for example) and being the first on the list skews things as well.
DrO is offline   Reply With Quote
Old 11th February 2014, 07:25   #28
isaacl
Junior Member
 
Join Date: May 2010
Posts: 34
Thanks for the info, DrO!
My current instance (Shoutcast v1 at the moment, through Centova) averages over 700 unique listeners during the peak hours of the day, normally with over 1000 total listeners/slots, and so far, it seems to be holding up well.
I set the Shoutcast config to limit it at 2500 listeners for now, but things have been working well...
isaacl is offline   Reply With Quote
Old 11th April 2014, 22:54   #29
Bryon Stout
Senior Member
 
Join Date: Feb 2011
Posts: 375
welp.

I have been successful with my server getting over 300. I was having issues with it crapping out at around 350. Ive done all the above from what SomaFM suggested and was able to get those numbers above 350 with no issues BUT today we got to the 500 number for the first time and shoutcast restarted.

* i was a dummy and restarted centovacast before getting the log files ** Doh!

I should also mention I have 3 other stations on my server but they all have like 5-20 people tunned in at once.

Also I have my itunes podcast mp3s on this server. But the traffic isnt that much. Its about 1000-2000 listens a day.
Bryon Stout is offline   Reply With Quote
Old 12th September 2014, 23:37   #30
dregs
Junior Member
 
Join Date: Jul 2013
Posts: 2
SomaFM's instructions work

Just letting everybody know that SomaFM's instructions work perfectly on my Ubuntu 12.04 32 bit server! I kept hitting 1017 peak listeners and nothing would work. His instructions finally got my stream over 1000! Thanks man.

edit: Here's a little script I wrote to load test my server. It requires vnstat to work properly (you can comment that out though).

code:
#!/bin/bash
echo "enter a URL to stress test. ex: http://radio.derp.com:8123"
read URL
echo "enter number of threads to run. ex: 50"
read THREADS

for ((N=0; N<$THREADS; N++))
do curl -o /dev/null $URL >> /dev/null 2>&1 &
done
echo "Created "$THREADS" threads connected to "$URL
echo "Live Bandwidth"
echo "hit ctrl-c when you are finished"
vnstat -l
echo "Press any button and hit enter to kill all curl processes! Thanks!"
read Q
killall -e curl


dregs is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > SHOUTcast > SHOUTcast Discussions

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump