prefect47 at gmail
Apr 4, 2011, 11:58 AM
Post #12 of 20
(1268 views)
Permalink
|
|
Re: "Watch Recordings" slow - disable thumbnail/preview generation, or big SQL queries?
[In reply to]
|
|
On 4 April 2011 19:38, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 04/04/2011 12:42 PM, Niklas Brunlid wrote:
> > On 2 April 2011 20:46, Michael T. Dean wrote:
> > ...
> >> To see if you're having data-access problems, try running:
> >>
> >> wget 'http://<masterbackendip>:6544/Myth/GetRecorded' -O /dev/null
> >>
> >> (but change "<masterbackendip>" to the IP address of your master
> >> backend). After, you should see something like (probably about 2x as
> >> large as since I have 1469 recordings):
> >>
> >> 100%[======================================>] 1,263,278 --.-K/s in
> 0.1s
> >>
> >> If so--if you're getting the results in, say, 0.2s or 0.3s--the problem
> >> is likely the mythfrontend sorting/processing of those recordings.
> >> FWIW, with half as many recordings as you have, my system brings up the
> >> Watch Recordings screen in (seemingly a lot less than) 0.5s (I'd guess
> >> 0.2 to 0.3s, but can't say for sure). So, either you've surpassed some
> >> performance ceiling, have an underpowered frontend (mine is not an
> >> Atom--it's a real computer--but trying to load that screen with 3K
> >> recordings on an Atom-based system *should* take a long time), or have
> >> some other misconfiguration, such as...
> >>
> >> Often previews /are/ a problem for users with some MythTV system
> >> misconfigurations--but, as Raymond mentioned, won't be a problem on a
> >> properly-configured system.
> >>
> >> Off the top of my head, reasons I can remember that cause previews to
> >> slow Watch Recordings include:
> >> a) having your (frontend user) $HOME/.mythtv directory on NFS and
> >> disabling file-attribute caching
> >> b) having a broken/not-writable $HOME/.mythtv/{remote,theme}cache
> >> directory
> >> c) having a time difference on your frontend and backend machines
> >> (you should use NTP on all mythtv machines)
> >>
> >> There are probably others, too, but this is a good start of a list of
> >> things to look at.
> >
> --------------------------------------------------------------------------------------------------------
> > $ time wget 'http://<address>:6544/Myth/GetRecorded' -O /dev/null
> > --2011-04-04 18:28:38-- http://<address>:6544/Myth/GetRecorded
> > Connecting to<address>:6544... connected.
> > HTTP request sent, awaiting response... 200 OK
> > Length: 2956015 (2.8M) [text/xml]
> > Saving to: /dev/null
> >
> > 100%[======================================>] 2,956,015 --.-K/s in
> 0.01s
> >
> > 2011-04-04 18:28:44 (291 MB/s) - /dev/null
> >
> > real 0m5.801s
> > user 0m0.001s
> > sys 0m0.007s
> >
> --------------------------------------------------------------------------------------------------------
> >
> > So the actual download goes by quickly, but it takes a few seconds before
> it
> > starts to receive data.
>
> Yeah, on my system, I get my ~1500 recordings with a real time of about
> 1s. Some of that 1s is due to the use of HTTP versus the
> already-connected MythTV protocol, which explains why my Watch
> Recordings screen comes up much faster than 1s.
>
> > System specs: Fedora 13 on an Asus K8V with an AMD64 3000+ and a Sparkle
> > GeForce 9400 GT PCI card, with OpenGL painter and VDPAU output, using
> > DVI->HDMI to a FullHD LCD TV and the SP/DIF of the mainboard directly to
> the
> > amplifier. The system is somewhat regularly updated against the Fedora
> and
> > ATrpms repos. MythTV version is release-0-22-fixes 22973.
>
Small error creeping in here (text was copied from another older mail),
mythtv version should of course be 0.24 (v0.24-231-gc2baf1b to be precise).
>
> This is the mythbackend system, too? Since it's now looking like your
> mythbackend and/or MySQL host are causing much of the slowness, their
> specs come into play. If this is a combined frontend/backend/mysql
> host, or if your master backend/mysql host(s) have similar specs, you
> should be able to get good performance.
>
> > Everything runs on the same computer,
>
> Ah, yeah, then it should be sufficiently-powerful hardware.
>
> > no external file systems, everything
> > on ext3. Recording drives have "rw,data=writeback" flags, used to have
> > noatime and nodiratime but those were removed since I suspected they
> > interfered with thumbnail generation.
> >
> >
> > Is $HOME in (b) above for mythfrontend or mythbackend? The frontend runs
> as
> > my normal user, the backend runs as root. In the user home remotecache
> and
> > themecache are writable by user and group, in root:s home I only have
> > themecache and it's writable by root only.
>
> Yeah, remotecache is only created for frontend systems. As long as the
> user running the program can access the $HOME/.mythtv/* stuff
> appropriate for its environment, all is good. So, if your frontned is
> run as your normal user in an environment where
> HOME=/home/<yourusername> , and $HOME/.mythtv/*cache are writable by
> your user, you're good.
>
> Since it may well be backend data access or processing causing the slow
> down, I recommend trying something like:
>
> wget mysqltuner.pl
>
> and then running it against your database to see if it has any
> recommendations.
Thanks, this had some good tips. The database is obviously old and was last
optimized more than a year ago... :)
> Also, what kind of RAM do you have in the system? I
> could see it being slow with too-little RAM causing paging (maybe
> 512MB), but you should be good with 2GB, and might be OK with 1GB (lower
> RAM may require usage of lower-resource themes, too, since it's a
> combined frontend/backend system).
>
The system has 2GB RAM which until recently was eaten by the nVidia driver
VDPAU memory leak through mythfrontend. Besides MythTV the second biggest
memory hog is Firefox 3.5, I guess.
/ Niklas
|
