Thanks Aaron, both 4.0.7 and 4.0.8 are available for testing I would appreciate if you can check both versions :)
On Thu, 17 Jan 2019 at 19:37, Aaron Hepp <[email protected]> wrote: > On the demo (4.0.8 rb66ef46) there is only about a 5-7 second delay from > the talking till it is broadcasted (this would be expected depending on > where the servers are located and the speed of its connection). Currently > about the same delay I have on a fresh restart of the OM service on my > VPS. I will keep both open all day and see if the delay changes any. > > On 1/16/19 11:01 PM, Maxim Solodovnik wrote: > > Hello Aaron, > > According to `top` our two OM instances consuming not very much memory on > demo: > 1186 nobody 20 0 6716968 1.421g 23308 S 20.9 6.0 1116:35 java > > 25008 nobody 20 0 6647688 752492 26656 S 1.0 3.0 97:29.05 java > > > 4.0.7 consuming 1.4G (was started right after release, more than 2 weeks > ago), will additionally check audio delay > > java options used differs: > > 4.0.7: > export JAVA_OPTS="-Xrs -Xms4G -Xmx4G -Xss1M -XX:PermSize=192m > -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled -XX:NewSize=256m > -XX:SurvivorRatio=16 -XX:MinHeapFreeRatio=20 > -XX:+ExplicitGCInvokesConcurrent -XX:+UseConcMarkSweepGC > -Djava.net.preferIPv4Stack=true -Xverify:none" > > 4.0.8 > export JAVA_OPTS="-Xrs -Xms4G -Xmx4G -Xss1M -XX:+CMSClassUnloadingEnabled > -XX:NewSize=256m -XX:SurvivorRatio=16 -XX:MinHeapFreeRatio=20 > -XX:+ExplicitGCInvokesConcurrent -XX:+UseConcMarkSweepGC > -Djava.net.preferIPv4Stack=true -Xverify:none" > > 4.0.8 options looks better to me. > > Could you also check demo? > I'll update "next" with most recent build (with most recent wicket) > > On Thu, 17 Jan 2019 at 10:12, Maxim Solodovnik <[email protected]> > wrote: > >> Hello Aaron, >> >> I'm afraid this might be caused by this >> https://issues.apache.org/jira/browse/WICKET-6629 issue >> I'll try to double-check on our demo server, and maybe speed up next >> releases of both wicket and openmeetings >> >> Thanks for the report >> >> On Thu, 17 Jan 2019 at 07:16, Aaron Hepp <[email protected]> wrote: >> >>> Looks like this has started with 4.0.7, but will need to look into >>> further. On Sunday I restarted my VPS (Ubuntu 16.04 core 4vCPU and 6GB >>> memory) The only applications I have running on this one is the items >>> needed to run OpenMeeting (java, libreoffice, etc) When I start up the >>> process the memory hovers around 850MB. During the day people come and go >>> max at any given time is 15. Only one room; items in that room are chat, a >>> screen share, and a single mic broadcasting. At the end of the day after >>> everyone is out and the items stopped (screenshare and mic) the memory >>> usage reports around 1.5GB. The next day everyone comes and goes as >>> previous day idle memory after everyone is gone is 2.1GB, today idle was >>> running @ 2.5GB. What I have noticed is that usually on the 2nd delay >>> there starts being a delay in the mic. Audio is broadcast but there is >>> about a 30 second delay. Today was got all the way up to about a minute >>> delay when the audio would be broadcasted and it gets heard by the users. >>> So tonight I was testing and the 1min audio delay was still there. Stop >>> and started the red5 process re-entered the room and the delay was gone. I >>> have included the options in the red5 file to maybe I could need some >>> tweaking. As stated this did not really show up till this 4.0.7 as there >>> had been times the process had ran for weeks without being restarted and >>> the memory usage would never get above 2GB. >>> >>> >>> JVM_OPTS="-Xms1024m -Xmx4096m -Xverify:none -XX:+TieredCompilation >>> -XX:+UseBiasedLocking -XX:InitialCodeCacheSize=8m >>> -XX:ReservedCodeCacheSize=32m -Dorg.terracotta.quartz.skipUpdateCheck=true >>> -XX:MaxMetaspaceSize=128m -XX:+DisableExplicitGC -XX:+UseParNewGC >>> -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4" >>> >>> >>> >>> >> >> -- >> WBR >> Maxim aka solomax >> > > > -- > WBR > Maxim aka solomax > > > -- WBR Maxim aka solomax
