[
http://dev.sourcefabric.org/browse/LS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Baelde closed LS-376.
---------------------------
Resolution: Fixed
This issue is getting old and we've never managing to convince ourselves that
the spike is abnormally high.
For the record, it is easy to test the issue. I did it again today:
output.file(%vorbis,"/dev/null",fallible=true,server.insert_metadata(id="x",playlist("<some
dir>")))
next, setup an insertion loop:
while true ; do sleep 1 ; ask-liquidsoap.sh "x.insert title=\"bla\"" ; done
On my laptop the CPU load of liquidsoap goes from 20% to 35%. It's not
negligible but not necessarily insane.
Regarding the detailed report above, I think that the spike creates
complications with OSS timing, which could be removed by using clocks in recent
versions of liquidsoap. This should make the CPU load problem much less
critical on weak servers.
> CPU spike on metadata updates
> -----------------------------
>
> Key: LS-376
> URL: http://dev.sourcefabric.org/browse/LS-376
> Project: Liquidsoap
> Issue Type: Bug
> Components: Liquidsoap
> Affects Versions: 1.0 beta
> Reporter: anonymous
> Assignee: Romain Beauxis
> Priority: Major
> Fix For: NEAR FUTURE
>
> Attachments: spikes.liq, vorbis_tricky_reset.patch
>
>
> The primary machine that I have experienced this issue on is:
> VIA C7 Processor 1000MHz with 512MB of RAM
> FreeBSD 7.1 i386.
> Liquidsoap 0.9.2-2 using OSS input module
> aotuv 20090303 libvorbis (http://www.geocities.jp/aoyoume/aotuv/)
> I have run these tests using a single vorbis stream. I have found that
> regardless of the quality level (-2.0, -1.0, 0), the skips can occur during
> metadata changes. In some situations I have found that the stream continues
> to loop the same audio over and over again and does not get unstuck until
> liquidsoap is restarted, which is really bad.
> I was able to make the skips occur by rapidly copy and pasting "meta.insert
> title='metadata'" over and over again into the telnet session. When skips
> occurred they were quite noticeable.
> I noticed this in top:
> Under normal conditions:
> CPU: 35.2% user, 0.0% nice, 2.2% system, 3.7% interrupt, 58.8% idle
> During metadata updates:
> CPU: 98.9% user, 0.0% nice, 0.7% system, 0.4% interrupt, 0.0% idle
> (It took me awhile to be able to copy-paste this from top as the CPU quickly
> spiked up and then went right back down)
> Interestingly enough, I performed the same tests on an Intel(R) Pentium(R) 4
> CPU 3.00GHz with 1GB of RAM, again running FreeBSD 7.1 i386. The skips also
> occurred on this machine but they were far less noticeable. The audio just
> had a little "blip" in it on metadata updates.
> So it appears that there is a quick spike in CPU usage that is happening on
> metadata updates, which is exemplified on slower hardware.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Savonet-devl mailing list
Savonet-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-devl
