PDA

View Full Version : 6.0 occassional high CPU usage for extended periods



Charles Stanton
2005-03-24, 19:50
3/23 Nightly

Charles Stanton
2005-03-24, 19:56
(We'll try this again).

I am using the 3/23 nighly and from time to time on start-up, slim.exe
will max out (96 - 99%) the CPU for 30 minutes or more before settling
down. No new music has been added. I don't think it should be
re-scanning.

Generally it settles down within 5 minutes or so.

The library is about 9K songs. The computer is PIII 933 MHz, 512 RAM, W2K Pro.
It is dedicated to the slimserver and musicmagic, which is also running.

Is this expected behaviour? Thx.


On Thu, 24 Mar 2005 21:50:32 -0500, Charles Stanton <shaboyi (AT) gmail (DOT) com> wrote:
> 3/23 Nightly
>

Daryle A. Tilroe
2005-03-24, 21:34
Charles Stanton wrote:
> (We'll try this again).
>
> I am using the 3/23 nighly and from time to time on start-up, slim.exe
> will max out (96 - 99%) the CPU for 30 minutes or more before settling
> down. No new music has been added. I don't think it should be
> re-scanning.
>
> Generally it settles down within 5 minutes or so.
>
> The library is about 9K songs. The computer is PIII 933 MHz, 512 RAM, W2K Pro.
> It is dedicated to the slimserver and musicmagic, which is also running.

I had something similar but possibly unrelated. For the last week and a half
I have been running the compiled 3/14 nightly under WinXPProSP1. Tonight I
noticed the service had gone "rogue" and was using all available cycles. This
was after a week of uptime and nowhere near a rescan and nothing was even
playing. I just killed the service and upgraded to 3/24. We shall see if it
crops up again.


--
Daryle A. Tilroe

Daryle A. Tilroe
2005-03-26, 08:42
Daryle A. Tilroe wrote:
> Charles Stanton wrote:
>
>> (We'll try this again).
>> I am using the 3/23 nighly and from time to time on start-up, slim.exe
>> will max out (96 - 99%) the CPU for 30 minutes or more before settling
>> down. No new music has been added. I don't think it should be
>> re-scanning.
>>
>> Generally it settles down within 5 minutes or so.
>>
>> The library is about 9K songs. The computer is PIII 933 MHz, 512 RAM,
>> W2K Pro.
>> It is dedicated to the slimserver and musicmagic, which is also running.
>
>
> I had something similar but possibly unrelated. For the last week and a
> half
> I have been running the compiled 3/14 nightly under WinXPProSP1.
> Tonight I noticed the service had gone "rogue" and was using all
> available cycles. This was after a week of uptime and nowhere near
> a rescan and nothing was even playing. I just killed the service
> and upgraded to 3/24. We shall see if it crops up again.

OK It did it again and much faster (less than 36 hours); also I don't
think I even fired up the player. I currently suspect the RSS plugin.
I turned it off and will wait a few days and see.

--
Daryle A. Tilroe

Healy
2005-04-08, 23:35
I've been having 99% CPU usage for long periods of time since switching
to 6.0. Currently using
the 4/7 nightly with the same issues. On start up it pegs at 99% CPU
for about 75 mins.
I have 26,000 songs on the server. I've removed all the plugins
except for:

Datetime Screensaver
Rescan Music Library
Shoutcast
Save Playlist
iTunes

It still seems to peg out....

Server is AMD 1.6ghz w/ 1.0gb ram, Debian Linux
Nothing else running except for sshd and basic init
functions.




On Mar 26, 2005, at 7:42 AM, Daryle A. Tilroe wrote:

> Daryle A. Tilroe wrote:
>> Charles Stanton wrote:
>>> (We'll try this again).
>>> I am using the 3/23 nighly and from time to time on start-up,
>>> slim.exe
>>> will max out (96 - 99%) the CPU for 30 minutes or more before
>>> settling
>>> down. No new music has been added. I don't think it should be
>>> re-scanning.
>>>
>>> Generally it settles down within 5 minutes or so.
>>>
>>> The library is about 9K songs. The computer is PIII 933 MHz, 512
>>> RAM, W2K Pro.
>>> It is dedicated to the slimserver and musicmagic, which is also
>>> running.
>> I had something similar but possibly unrelated. For the last week
>> and a half
>> I have been running the compiled 3/14 nightly under WinXPProSP1.
>> Tonight I noticed the service had gone "rogue" and was using all
>> available cycles. This was after a week of uptime and nowhere near
>> a rescan and nothing was even playing. I just killed the service and
>> upgraded to 3/24. We shall see if it crops up again.
>
> OK It did it again and much faster (less than 36 hours); also I don't
> think I even fired up the player. I currently suspect the RSS plugin.
> I turned it off and will wait a few days and see.
>

Mark Bennett
2005-04-09, 00:48
The library scanning is much more CPU intensive than it was before.

My collection of ~6k songs takes about 6 or 7 minutes to scan on
a P4, 3.4GHz with 1GB RAM. Scaling that up to your music library
size and CPU speed and it seems about right. This will happen
at startup the first time, but it shouldn't need to do it again
unless you've added music.

On Fri, 2005-04-08 at 23:35 -0700, Healy wrote:
> I've been having 99% CPU usage for long periods of time since switching
> to 6.0. Currently using
> the 4/7 nightly with the same issues. On start up it pegs at 99% CPU
> for about 75 mins.
> I have 26,000 songs on the server. I've removed all the plugins
> except for:
>
> Datetime Screensaver
> Rescan Music Library
> Shoutcast
> Save Playlist
> iTunes
>
> It still seems to peg out....
>
> Server is AMD 1.6ghz w/ 1.0gb ram, Debian Linux
> Nothing else running except for sshd and basic init
> functions.
>
>
>
>
> On Mar 26, 2005, at 7:42 AM, Daryle A. Tilroe wrote:
>
> > Daryle A. Tilroe wrote:
> >> Charles Stanton wrote:
> >>> (We'll try this again).
> >>> I am using the 3/23 nighly and from time to time on start-up,
> >>> slim.exe
> >>> will max out (96 - 99%) the CPU for 30 minutes or more before
> >>> settling
> >>> down. No new music has been added. I don't think it should be
> >>> re-scanning.
> >>>
> >>> Generally it settles down within 5 minutes or so.
> >>>
> >>> The library is about 9K songs. The computer is PIII 933 MHz, 512
> >>> RAM, W2K Pro.
> >>> It is dedicated to the slimserver and musicmagic, which is also
> >>> running.
> >> I had something similar but possibly unrelated. For the last week
> >> and a half
> >> I have been running the compiled 3/14 nightly under WinXPProSP1.
> >> Tonight I noticed the service had gone "rogue" and was using all
> >> available cycles. This was after a week of uptime and nowhere near
> >> a rescan and nothing was even playing. I just killed the service and
> >> upgraded to 3/24. We shall see if it crops up again.
> >
> > OK It did it again and much faster (less than 36 hours); also I don't
> > think I even fired up the player. I currently suspect the RSS plugin.
> > I turned it off and will wait a few days and see.
> >
>
>

Healy
2005-04-09, 08:27
Mine will peg out at 99% for 10-15 mins each time it does a rescan of
the itunes library. Even if I've just quit the iTunes and made no
changes
(IE: updates the time stamp of the xml file). It jumps up to 99% and
scans
through the whole library again.

Meanwhile while that is happening, more than half the time, the music
will
cut out & the squeezebox will state "Can't find slimserver". Sometimes
it will come back on and play for 1-2 seconds and they go dead for
another
2 minutes. After the CPU goes back down to normal levels, the music
comes
back on. This happens wired or wireless. I used to have it check for
iTunes
changes every hour, now I have it set to weeks to try and avoid that.

This happened once in a while in the 5.x series but seem to happen now
every
time it detects an iTunes change. It's getting to the point when I
can't even rely
on the squeezebox for a party anymore. Very disappointing.

Is this the norm for users with huge libraries of music from now on?

-Healy


On Apr 9, 2005, at 12:48 AM, Mark Bennett wrote:

> The library scanning is much more CPU intensive than it was before.
>
> My collection of ~6k songs takes about 6 or 7 minutes to scan on
> a P4, 3.4GHz with 1GB RAM. Scaling that up to your music library
> size and CPU speed and it seems about right. This will happen
> at startup the first time, but it shouldn't need to do it again
> unless you've added music.
>
> On Fri, 2005-04-08 at 23:35 -0700, Healy wrote:
>> I've been having 99% CPU usage for long periods of time since
>> switching
>> to 6.0. Currently using
>> the 4/7 nightly with the same issues. On start up it pegs at 99% CPU
>> for about 75 mins.
>> I have 26,000 songs on the server. I've removed all the plugins
>> except for:
>>
>> Datetime Screensaver
>> Rescan Music Library
>> Shoutcast
>> Save Playlist
>> iTunes
>>
>> It still seems to peg out....
>>
>> Server is AMD 1.6ghz w/ 1.0gb ram, Debian Linux
>> Nothing else running except for sshd and basic init
>> functions.
>>
>>
>>
>>
>> On Mar 26, 2005, at 7:42 AM, Daryle A. Tilroe wrote:
>>
>>> Daryle A. Tilroe wrote:
>>>> Charles Stanton wrote:
>>>>> (We'll try this again).
>>>>> I am using the 3/23 nighly and from time to time on start-up,
>>>>> slim.exe
>>>>> will max out (96 - 99%) the CPU for 30 minutes or more before
>>>>> settling
>>>>> down. No new music has been added. I don't think it should be
>>>>> re-scanning.
>>>>>
>>>>> Generally it settles down within 5 minutes or so.
>>>>>
>>>>> The library is about 9K songs. The computer is PIII 933 MHz, 512
>>>>> RAM, W2K Pro.
>>>>> It is dedicated to the slimserver and musicmagic, which is also
>>>>> running.
>>>> I had something similar but possibly unrelated. For the last week
>>>> and a half
>>>> I have been running the compiled 3/14 nightly under WinXPProSP1.
>>>> Tonight I noticed the service had gone "rogue" and was using all
>>>> available cycles. This was after a week of uptime and nowhere near
>>>> a rescan and nothing was even playing. I just killed the service
>>>> and
>>>> upgraded to 3/24. We shall see if it crops up again.
>>>
>>> OK It did it again and much faster (less than 36 hours); also I don't
>>> think I even fired up the player. I currently suspect the RSS
>>> plugin.
>>> I turned it off and will wait a few days and see.
>>>
>>
>>

kdf
2005-04-09, 09:28
Quoting Healy <slim (AT) nwgeeks (DOT) com>:

> Mine will peg out at 99% for 10-15 mins each time it does a rescan of
> the itunes library. Even if I've just quit the iTunes and made no
> changes
> (IE: updates the time stamp of the xml file). It jumps up to 99% and
> scans
> through the whole library again.
>
> Meanwhile while that is happening, more than half the time, the music
> will
> cut out & the squeezebox will state "Can't find slimserver". Sometimes
> it will come back on and play for 1-2 seconds and they go dead for
> another
> 2 minutes. After the CPU goes back down to normal levels, the music
> comes
> back on. This happens wired or wireless. I used to have it check for
> iTunes
> changes every hour, now I have it set to weeks to try and avoid that.
>
> This happened once in a while in the 5.x series but seem to happen now
> every
> time it detects an iTunes change. It's getting to the point when I
> can't even rely
> on the squeezebox for a party anymore. Very disappointing.
>
> Is this the norm for users with huge libraries of music from now on?

not at all. I have not seen anything like this with my system. Have you tried
watching the logs, using d_itunes and/or d_info? you could set your itunes
scan interval to something very high, and use rescan or the rescan plugin to
refresh the data every so often.

-kdf

healy
2005-04-09, 10:30
On Apr 9, 2005, at 9:28 AM, kdf wrote:

> Quoting Healy <slim (AT) nwgeeks (DOT) com>:
>
>> Mine will peg out at 99% for 10-15 mins each time it does a rescan of
>> the itunes library. Even if I've just quit the iTunes and made no
>> changes
>> (IE: updates the time stamp of the xml file). It jumps up to 99% and
>> scans
>> through the whole library again.
>>
>> Meanwhile while that is happening, more than half the time, the music
>> will
>> cut out & the squeezebox will state "Can't find slimserver".
>> Sometimes
>> it will come back on and play for 1-2 seconds and they go dead for
>> another
>> 2 minutes. After the CPU goes back down to normal levels, the music
>> comes
>> back on. This happens wired or wireless. I used to have it check for
>> iTunes
>> changes every hour, now I have it set to weeks to try and avoid that.
>>
>> This happened once in a while in the 5.x series but seem to happen now
>> every
>> time it detects an iTunes change. It's getting to the point when I
>> can't even rely
>> on the squeezebox for a party anymore. Very disappointing.
>>
>> Is this the norm for users with huge libraries of music from now on?
>
> not at all. I have not seen anything like this with my system. Have
> you tried
> watching the logs, using d_itunes and/or d_info? you could set your
> itunes
> scan interval to something very high, and use rescan or the rescan
> plugin to
> refresh the data every so often.
>

I'm currently doing the scan interval change to see if that fixes
matters. The
rescan will catch changes to itunes? I use iTunes exclusively.

I've tried all three logs that you mention, so far I have not seen a
common
thread to focus on.

-Healy

kdf
2005-04-09, 12:15
Quoting Healy <slim (AT) nwgeeks (DOT) com>:

>

>
> I'm currently doing the scan interval change to see if that fixes
> matters. The
> rescan will catch changes to itunes? I use iTunes exclusively.

it should rescan any and all active import modes, plus folder scan if you have a
music folder set.

> I've tried all three logs that you mention, so far I have not seen a
> common
> thread to focus on.
>
d_itunes will show when the server detects any change in the xml file. that
will maybe help you lock in on what might be changing. if you never see this
message, then you might want to look at events that lead up to the itunes
rescan that you have been seeing.

-kdf

radish
2005-04-09, 13:50
I just came home from a trip out for a few hours. Both my players were switched off the whole time I was out. When I got back, neither was responding and the web interface was dead. Turned out the server was taking 100% cpuand had been doing for some time (judging by the stats). I killed it and restarted and everything is fine now.

I don't use itunes, just regular files, it had no reason (that I know of) to be rescanning at that time.

Daryle A. Tilroe
2005-04-10, 05:31
Daryle A. Tilroe wrote:
> Daryle A. Tilroe wrote:
>
>> I had something similar but possibly unrelated. For the last week and
>> a half
>> I have been running the compiled 3/14 nightly under WinXPProSP1.
>> Tonight I noticed the service had gone "rogue" and was using all
>> available cycles. This was after a week of uptime and nowhere near
>> a rescan and nothing was even playing. I just killed the service and
>> upgraded to 3/24. We shall see if it crops up again.
>
>
> OK It did it again and much faster (less than 36 hours); also I don't
> think I even fired up the player. I currently suspect the RSS plugin.
> I turned it off and will wait a few days and see.

The resurrection of this tread prompted me to try the RSS screen saver
again with 6.0.1. Well it still seems to have the problem of making
slim.exe go rogue in short order (<12 hours). I don't have any
debugging to add at this point. I'm just going to turn it off
again for now.

--
Daryle A. Tilroe

Tourne
2005-04-10, 10:12
I'm getting exactly this behaviour. Periodic very high CPU activity from slim.exe that lasts up to 20 minutes and stops the player. My library is about 25k songs.
Having said that, although I'm trying to get it to use iTunes, I've not succeeded as yet, so I don't know if that is the issue, or not.

Tourne


Mine will peg out at 99% for 10-15 mins each time it does a rescan of
the itunes library. Even if I've just quit the iTunes and made no
changes
(IE: updates the time stamp of the xml file). It jumps up to 99% and
scans
through the whole library again.

Meanwhile while that is happening, more than half the time, the music
will
cut out & the squeezebox will state "Can't find slimserver". Sometimes
it will come back on and play for 1-2 seconds and they go dead for
another
2 minutes. After the CPU goes back down to normal levels, the music
comes
back on. This happens wired or wireless. I used to have it check for
iTunes
changes every hour, now I have it set to weeks to try and avoid that.

This happened once in a while in the 5.x series but seem to happen now
every
time it detects an iTunes change. It's getting to the point when I
can't even rely
on the squeezebox for a party anymore. Very disappointing.

Is this the norm for users with huge libraries of music from now on?

-Healy


On Apr 9, 2005, at 12:48 AM, Mark Bennett wrote:

> The library scanning is much more CPU intensive than it was before.
>
> My collection of ~6k songs takes about 6 or 7 minutes to scan on
> a P4, 3.4GHz with 1GB RAM. Scaling that up to your music library
> size and CPU speed and it seems about right. This will happen
> at startup the first time, but it shouldn't need to do it again
> unless you've added music.
>
> On Fri, 2005-04-08 at 23:35 -0700, Healy wrote:
>> I've been having 99% CPU usage for long periods of time since
>> switching
>> to 6.0. Currently using
>> the 4/7 nightly with the same issues. On start up it pegs at 99% CPU
>> for about 75 mins.
>> I have 26,000 songs on the server. I've removed all the plugins
>> except for:
>>
>> Datetime Screensaver
>> Rescan Music Library
>> Shoutcast
>> Save Playlist
>> iTunes
>>
>> It still seems to peg out....
>>
>> Server is AMD 1.6ghz w/ 1.0gb ram, Debian Linux
>> Nothing else running except for sshd and basic init
>> functions.
>>
>>
>>
>>
>> On Mar 26, 2005, at 7:42 AM, Daryle A. Tilroe wrote:
>>
>>> Daryle A. Tilroe wrote:
>>>> Charles Stanton wrote:
>>>>> (We'll try this again).
>>>>> I am using the 3/23 nighly and from time to time on start-up,
>>>>> slim.exe
>>>>> will max out (96 - 99%) the CPU for 30 minutes or more before
>>>>> settling
>>>>> down. No new music has been added. I don't think it should be
>>>>> re-scanning.
>>>>>
>>>>> Generally it settles down within 5 minutes or so.
>>>>>
>>>>> The library is about 9K songs. The computer is PIII 933 MHz, 512
>>>>> RAM, W2K Pro.
>>>>> It is dedicated to the slimserver and musicmagic, which is also
>>>>> running.
>>>> I had something similar but possibly unrelated. For the last week
>>>> and a half
>>>> I have been running the compiled 3/14 nightly under WinXPProSP1.
>>>> Tonight I noticed the service had gone "rogue" and was using all
>>>> available cycles. This was after a week of uptime and nowhere near
>>>> a rescan and nothing was even playing. I just killed the service
>>>> and
>>>> upgraded to 3/24. We shall see if it crops up again.
>>>
>>> OK It did it again and much faster (less than 36 hours); also I don't
>>> think I even fired up the player. I currently suspect the RSS
>>> plugin.
>>> I turned it off and will wait a few days and see.
>>>
>>
>>