Re: [Upstage-list] 8083 broken

[helen v. j. <he...@cr...>]

thanks very much, douglas, martin & paul :)

paul - will the setting up of it happen today? & will everything be ok
for our show, at 7.30am sunday morning (tomorrow)? i'll test late
tonight ...

h : )

On 8/11/14 8:19 AM, Paul Rohrlach wrote:
>
> My apologies... I assumed rotation was already happening (don't even
> remember the last time I manually did that) anyhow, I'll set that up.
>
> On 8 Nov 2014 00:51, "Martin Eisenbarth" <ey...@fo...
> <mailto:ey...@fo...>> wrote:
>
>     Hi all,
>
>     That does probably also explain why Red5 stopped working...
>     To prevent these problems mentioned I would suggest the following:
>     A rotating logfile seems appropriate to limit the produced logfile
>     size
>     (I guess 17GB logfile in compressed form is probably just a few MBs).
>     This can easily be done for example with Logrotate.
>     Also reducing server load with a reverse proxy (like Varnish or Squid)
>     should allow many more connections at once as the UpStage server
>     spends
>     most of the time just for serving files. I have done this for my
>     server
>     and the UpStage server load was reduced by far more than 90%. Of
>     course
>     all ports should nonetheless be closed properly.
>     Integrating a reverse proxy also requires to have the HTTP cache
>     headers
>     set properly. IIRC I had done some header modifications for this in my
>     fork...
>
>     Cheers,
>     Martin
>
>
>
>     Am 07.11.2014 um 07:06 schrieb Douglas Bagnall:
>     > Hi Paul, Helen,
>     >
>     > The disk filled up completely the other day, which may or may
>     not have
>     > caused these problems (by e.g., not closing properly sockets in the
>     > case of an IOException). Some obvious big things are
>     >
>     > 17G     /opt/upstage3-beta/server/src/upstage.log
>     > 100G    /home/UpStage Media Backups/
>     >
>     > I deleted one of the backups from last year, and now the disk is at
>     > 99%. But if this backup occurs automatically and weekly (which seems
>     > to be the case), the disk is likely to fill up again at around 6:52
>     > either this Sunday morning or the next one.
>     >
>     > cheers,
>     > Douglas
>     >
>     >
>     >>>>
>     >>>> This happens when connections aren't closed properly. It's a
>     combination
>     >>>> of a Linux security feature and poor connection handling in
>     UpStage code.
>     >>>>
>     >
>     >
>     ------------------------------------------------------------------------------
>     > _______________________________________________
>     > Upstage-list mailing list
>     > Ups...@li...
>     <mailto:Ups...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/upstage-list
>     >
>
>
>     --
>     Martin Eisenbarth
>     Gärtnerstraße 21
>     86161 Augsburg
>     Germany
>     ey...@fo... <mailto:ey...@fo...>
>     http://www.foobarlab.net
>     Phone +49 821 5679295 <tel:%2B49%20821%205679295>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Upstage-list mailing list
>     Ups...@li...
>     <mailto:Ups...@li...>
>     https://lists.sourceforge.net/lists/listinfo/upstage-list
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Upstage-list mailing list
> Ups...@li...
> https://lists.sourceforge.net/lists/listinfo/upstage-list

-- 
helen varley jamieson
he...@cr... <mailto:he...@cr...>
http://www.creative-catalyst.com
http://www.talesfromthetowpath.net
http://www.upstage.org.nz