"Thomas B. Rücker"
2015-Feb-23 06:26 UTC
[Icecast] IceCast Server (2.3.2) Limits? Disconnections due to user and memory?
Hi, please see the inline comments. On 02/21/2015 08:21 PM, Dean Sauer wrote:> I have a VPS on OpenVZ 2GB RAM / 2GB Burst, and Ubuntu 12.04 64b server > > I use Icecast 2.3.2 <snip /> > > As posted in previous threads I am seeing a situation reoccur where the > sources and clients ALL GET DUMPED...ALL AT ONCE.We'd need error logs from such an incident, perferably at log level 4. Also dmesg and syslog from that time would be helpful> During this time clients get dumped to a source specific MP3 file, one > for each of the sources that plays till the source comes back. At times > the clients can connect to this, at times VLC etc. can't connect when it > should be playing that MP3 file. There is ONE MP3 file for EACH source. > I've found having ONE for all sources And Icecast can't figure out where > to send clients back to after the source comes back.. so I have one for > each source now.Yes that is correct. A client isn't bound to a certain origin mountpoint and if there are two mounts that use the same fallback with override, then the first one to connect gets all the listeners from the fallback. That's how it is intended and having separate fallbacks is the correct approach if you don't want this to happen.> I've had a SSH session connected since the last incident, it didn't drop, > BUT the way these SSH sessions are done may not be an accurate gauge as > they go in via some differing than the server IP... this CONNECTION DOES > seem to lag in getting data.. as I have top running in 24/7 right now. > > Then there is this gyration of sources and clients trying to reconnect... > > After looking at things... the only conclusion I can find is that 2GB is > NOT ENOUGH for the few sources but with LARGE CLIENTSWhat are "LARGE CLIENTS"? How do you reckon that it's a memory problem if Icecast isn't killed by OOM? What's its RSS/VSS during that sort of load?> There are 11 SOURCES... the latest incident of this situation finds that > 3 of the sources had from 45-100 clients each.That's rather mundane load for an Icecast server.> IS this the limit for a 2GB VPS?Most certainly not.> Comments, ideas???? > > I at the point that I am going to have to > > > 1) Find a solution on this host - comments, ideas??? > > Note: for this VPS host, 2GB RAM/2GB BURST is their MAX CONFIG. They > refuse to budge on this...I don't see staying with this particular virtualization technology and focusing on RAM as beneficial to resolving this. I actually suspect that it's openVZ with it's rather old and problem prone "virtualization" that is at the root of this. Or it's just a highly overcommitted host and you get squeezed out by one of the other tennants. Either way moving on is the answer.> 2)find a different host,I am quite sure, that you'll find switching to a host that uses a more mature virtualization technology will help. As you want to stay with 2.3.2, I'd suggest to find one that has Ubuntu 12.04 or another distribution that carries this version by default (e.g. Debian 7). I'd expect most of the large ones to support that, but as I haven't tried any of them I can't point to a specific one. Thomas
Possibly Parallel Threads
- IceCast Server (2.3.2) Limits? Disconnections due to user and memory?
- IceCast Server (2.3.2) Limits? Disconnections due to user and memory?
- Source Dropouts - More info
- BUG ? - Metadata/tags NOT UPDATING - Python IceCast 2.3.2[3]
- Asterisk 11 and old Thomson 2030S Hardphone => SIP Register/Auth Problem against V11