[mythtv-users] combined myth/server

[Daniel Kristjansson]

On Thu, 2010-04-22 at 09:19 -0600, Travis Tabbal wrote:
> I did. XFS set per the wiki. The problem is made worse by MythBackend
> doing sync calls once a second or so, so the filesystem isn't really
> able to optimize write seeks. It's forced to seek once per second per
> recording, minimum. Add in DB and general system overhead, and it can
> use up too much time. I was able to patch that sync call out and
> improve the situation significantly, but I got tired of compiling my
> own Myth packages and the multi-drive setup was simpler.

The fsync calls are intentional. They prevent starvation on reads when
the OS decides to write out a very large block of disk buffers. The
default elevator algorithms used by Linux disto's are optimized for
maximum throughput, not real time response. But if you are watching
a recording you want to see your video frames at regular intervals
and don't really care if the operating system can decode more of them
if it only does so every few seconds (high throughput).

The discussions had to do with how fsync was implemented on ext3 for
a long time. For a while it was doing almost a full sync which was
very slow, this has been optimized in the latest kernels and was never
a problem with XFS. Unfortunately the ext4 implementation recently
regressed in it's default fsync performance. This isn't so much a
problem for writing the recording to disk, but it absolutely kills
mysql performance, so fsync handling is an ongoing problem. Fortunately,
XFS remains a very good filesystem for MythTV, with both good fsync
performance and good file metadata handling. It has also become a good
filesystem for /var (i.e. mysql) in recent years, which it wasn't
always.

Unless you have a very large number of recorders or a very old hard
disk, mythbackend performance problems are at heart mysql performance
problems. First make sure you are not using ext4 for the mysql storage
(/var), second look for examples of tuned my.cnf files. The defaults
save memory at the cost of performance at best, and at worst are
configured for replicated mysql server farms.

-- Daniel