I will test those in a little bit. Currently in the VPS I run the delay
is now over a minute from the person broadcasts to when the guests hear
it. The memory on the VPS has only gone up about 300MB since people
started coming in @ 8:30am EST (so about 2 hours of running).
I have an active stream going in both 4.0.7 and the 4.0.8snap will watch
them to see if they all start having the same delay affect.
Oddly the screen sharing which uses the same port (1935) does not
experience the delay. So this may possible be leading to a flash issue
and not an OM issue.
I was going to start testing version 5 since that does away with flash,
but noticed the different file structure in there for getting https to
work. Do you have a quick how to on setting up version 5 on 443?
On 1/17/19 10:28 AM, Maxim Solodovnik wrote:
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]
<mailto:[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] <mailto:[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] <mailto:[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
