Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5
  1. #1
    Junior Member
    Join Date
    Aug 2020
    Posts
    3

    Server Load During Idle Periods of LMS 7.9.3 Docker Image

    First of all, thanks to all of you for your effort and dedication to keep LMS running and prepare it for today's software deployment habits.

    I have installed the 7.9.3 version of the docker image for the purpose of easier debugging of a problem that I am facing with LMS on Intel architectures.
    During "idle periods" (no database scan, no music listening), LMS on my Debian installations (Linux Mint to be precise) is consuming considerable
    amounts of resources (around 48% according to "top" on an Intel i5, or 90% on an older Pentium-based NUC). I admittedly have a rather large
    collection (>13.400 albums - collecting CDs for more than 30 years now), but I do not see this behavior on a Raspberry Pi 3 installation based on
    PiCorePlayer (when idle almost no load from LMS on the Raspberry).

    On my NUCs, the squeezeserver sometimes even spikes to almost 100% CPU load, even though there is nothing actually supposed to happen on it,
    causing the fan to become rather active and noisy.

    I have read in some other posts to try deleting cache.db, but this usually only leads to a temporary improvement, with the load going back
    to the levels mentioned above after one or two days.

    I have disabled most plugins except the ones by Erland Isaksson for which I bought a perpetual license a couple of years ago, and some others like
    Qobuz, Additional Browse Modes, DSDPlayer, and Logitech Service handler (before deactivating most other default installed plugins, the load
    situation was quite similar).

    In my server log there are entries like:
    "[20-09-01 09:06:55.2096] Slim::Networking::SqueezeNetwork::_error (500) Unable to login to SN: 503 Service Temporarily Unavailable
    [20-09-01 09:06:55.2099] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: 503 Service Temporarily Unavailable, retrying in 59400 seconds
    [20-09-01 09:07:27.1647] Slim::Networking::SqueezeNetwork::_error (500) Unable to login to SN: Timed out waiting for data
    [20-09-01 09:07:27.1649] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 60300 seconds
    [20-09-01 09:07:56.8439] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 61200 seconds
    [20-09-01 09:11:05.1582] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 900 seconds
    [20-09-01 09:11:36.1557] Slim::Networking::SqueezeNetwork::_error (500) Unable to login to SN: Timed out waiting for data
    [20-09-01 09:11:36.1559] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 1800 seconds
    [20-09-01 09:12:07.1633] Slim::Networking::SqueezeNetwork::_error (500) Unable to login to SN: Timed out waiting for data
    [20-09-01 09:12:07.1635] Slim::Networking::SqueezeNetwork::Players::_player s_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 2700 seconds"

    If there is any more information you need for investigating the problem, I would be happy to receive further instructions on how to obtain
    and provide them.

    Thanks in advance for considering my issue.

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,452

    Server Load During Idle Periods of LMS7.9.3 Docker Image

    > amounts of resources (around 48% according to "top" on an Intel i5, or
    > 90% on an older Pentium-based NUC). I admittedly have a rather large
    > collection (>13.400 albums - collecting CDs for more than 30 years now),


    That should be ok.

    > but I do not see this behavior on a Raspberry Pi 3 installation based


    With the same collection? And same configuration and plugins?

    > On my NUCs, the squeezeserver sometimes even spikes to almost 100% CPU
    > load, even though there is nothing actually supposed to happen on it,
    > causing the fan to become rather active and noisy.


    Is there anything in server.log?

    > I have disabled most plugins except the ones by Erland Isaksson for


    Erland's plugins are known to be pretty heavy. That said: are you
    running the same on the Pi?

    > In my server log there are entries like:
    > "[20-09-01 09:06:55.2096] Slim::Networking::SqueezeNetwork::_error (500)
    > Unable to login to SN: 503 Service Temporarily Unavailable


    This could be caused by your system sending too many sign-in attempts to
    the backend services. I know there must be a bug in LMS somewhere which
    triggers this misbehaviour. But it's not common, and while I've
    experienced it myself, I've never been able to reproduce it :-(.

    As I've seen installations sending millions(!) of requests in a single
    day, this could potentially put quite some strain on a system...

    --

    Michael

  3. #3
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,452

    Server Load During Idle Periods of LMS7.9.3 Docker Image

    $>> In my server log there are entries like:
    >> "[20-09-01 09:06:55.2096] Slim::Networking::SqueezeNetwork::_error (500)
    >> Unable to login to SN: 503 Service Temporarily Unavailable

    >
    > This could be caused by your system sending too many sign-in attempts to


    I checked our systems, and I "only" see a few thousand requests coming
    from your IP address. I'd suggest you shut down your LMS for an hour,
    then try again. This should allow the rate limiter to reset your count.

    --

    Michael

  4. #4
    Junior Member
    Join Date
    Aug 2020
    Posts
    3
    [QUOTE=mherger;987037]$>> In my server log there are entries like:
    >> "[20-09-01 09:06:55.2096] Slim::Networking::SqueezeNetwork::_error (500)
    >> Unable to login to SN: 503 Service Temporarily Unavailable

    >
    > This could be caused by your system sending too many sign-in attempts to


    I checked our systems, and I "only" see a few thousand requests coming
    from your IP address. I'd suggest you shut down your LMS for an hour,
    then try again. This should allow the rate limiter to reset your count.

    Dear Michael,

    thank you very much for your response and care.

    I have just shut down all instances (I am currently running multiple instances in my LAN
    which quite probably appear with the same IP-address in your logs) and will keep them
    shut down for the next hour.

    Can this "sign-in behavior" be somehow somehow switched off? I have already tentatively
    set the server to not synchronize player status with mysqueezebox.com, but this did
    not change anything.

    I will restart one of the servers in around 80 minutes and check the load level, and
    then report back here.

  5. #5
    Junior Member
    Join Date
    Aug 2020
    Posts
    3
    Quote Originally Posted by gs06 View Post

    I will restart one of the servers in around 80 minutes and check the load level, and
    then report back here.
    After giving my LMS servers a break and restarting them after about 90 minutes, the load problem
    is gone. The squeezeboxserver is consuming only between 0.7% and 3% CPU time
    according to "top" even when playing music on one of my SB Touch devices. There are no
    new complaints about not being able to connect to SN in the server log, so the problem
    apparently was connected to my server sending too many requests when being ignored
    by Logitech's servers due to sending too many requests.

    So, it seems there is a simple solution/workaround to this type of problem:
    When the server load is too high and messages of the type

    "Slim::Networking::SqueezeNetwork::Players::_playe rs_error (377) Unable to get players from SN: Timed out waiting for data, retrying in 2700 seconds
    Slim::Networking::SqueezeNetwork::_error (500) Unable to login to SN: Timed out waiting for data"

    do appear in the server log, then one simply needs to shut down all his squeezeboxserver instances for more than 60 minutes
    in order for Logitech's servers to "forgive" them. Then they can be restarted and are able to properly connect
    to the SqueezeNetwork again and do not cause high CPU load anymore.

    Thank you very much Michael, for your swift replies and your precise diagnosis of the issue.

    I would like to use this occasion to also thank Logitech to keep supporting the LMS ecosystem. It is now
    about 8 years since I started using LMS with various SB Touch, Duo, Radio, and Boom devices
    (some bought new, some bought used) and already about 7 years since Logitech decided
    to stop this product line. In the beginning after this decision I was concerned that the support
    for the LMS ecosystem would end soon after the warranty period of my newly bought products was over.
    Fortunately, this did not happen and I am still a happy user. This continued support by enthusiastic individuals
    who can not be thanked enough, and who are apparently are also backed up in their efforts by the company
    Logitech running the servers gives me also a very good feeling about the company. So, in order to
    support/thank Logitech for this I keep buying their other products (which btw. so far have also proven to be of
    good quality).

    With best regards,

    Guenter

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •