[mythtv-users] Frontend freeze when deleting recording

[Cymen Vig]

On 10/23/05, Dave Sherohman <esper at sherohman.org> wrote:
> On Sun, Oct 23, 2005 at 10:41:25AM -0700, chris at cpr.homelinux.net wrote:
> > On Sun, Oct 23, 2005 at 10:34:33AM -0500, Mercury Morris wrote:
> > > My guess is that there are quite few MythTV folks that are not aware of the
> > > "delete-a-recording-while-recording" I/O bottleneck.  They, and I, will be most
> > > interested in the results you might observe regarding filesystem stability and
> > > how fast XFS can delete a recording concurrent with recording a program.
> >
> > I converted my system to XFS on (software) RAID-5 when I
> > installed MythTV and it's been rock-solid.  The box also
> > hosts IMAP, SMB, VNC and Apache2 servers, and has never
> > seemed to have any problem deleting large files while
> > recording.
>
> I had my first hang of this sort in quite a while earlier today and
> it has me suspecting that delete-while-recording may not have
> anything to do with it (or at least may not be the only cause)...
>
> Like chris, I use XFS, but no RAID.  My hang this morning took place
> while I was half-watching low priority shows on my TV while also
> going through movie listings via mythweb on my laptop.  The delete
> hang occurred when I issued the delete order while waiting for
> mythweb to return from scheduling a recording.  There was no
> recording in progress at the time and I have my mysql database on a
> separate physical hard drive (and separate SATA channel) from my
> stored recordings, so it seems extremely unlikely that an I/O
> bottleneck would have been involved.  With no knowledge of the actual
> code involved, the circumstances of this loss of contact between
> mythbackend and the database suggests to me that the actual issue may
> be related to deleting a recording while another database update is
> in progress.  The apparent link to recording may instead be due to
> the database being updated when recordings begin/end.

In my experience it is the database and not the file system causing
the delays. I copied a few 2.2 GB shows during testing and found that
deleting them was practically instantaneous on my XFS file system.
Meanwhile, deleting shows in the Mythfrontend would cause at least 2-4
seconds of freezing.

After tweaking MySQL's my.cnf file I have almost instantaneous
deletes. Now, if I select delete on a 30 minute show, the control
returns immediately and I can go up and down in the list. The show
remains in the list for a second or two and then disappears.

My my.cnf (changes from Gentoo default):

Disable binary logging (remove binary logs from data dir which look
like *.0001, etc):
--
#log-bin
--

Increase limits:
--
key_buffer                  = 64M  # increased from 32M
max_allowed_packet          = 1M
table_cache                 = 256
sort_buffer_size            = 4M   # was 512K
net_buffer_length           = 8K
read_buffer_size            = 1M   # was 512K
read_rnd_buffer_size        = 1M
myisam_sort_buffer_size     = 16M
language                    = /usr/share/mysql/english

#tmp_table_size             = 64M
tmp_table_size              = 128M
--

Increase more limits (adjusting log file and buffer requires stopping
db, removing files, starting db as far as I can tell):
--
innodb_buffer_pool_size     = 64M
innodb_additional_mem_pool_size = 8M
innodb_data_file_path       = ibdata1:10M:autoextend
innodb_log_file_size        = 5M
innodb_log_buffer_size      = 8M
--

More limits that shouldn't come into play:
--
[isamchk]
key_buffer                  = 20M
sort_buffer_size            = 20M
read_buffer                 = 2M
write_buffer                = 2M

[myisamchk]
key_buffer                  = 20M
sort_buffer_size            = 20M
read_buffer                 = 2M
write_buffer                = 2M
--

This has resulted in a dramatic improvment for me but my combination
frontend/backend has 1 GB of RAM. The memory usage isn't too drastic:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
5681 mysql     15   0  194m  39m 4244 S  0.0  3.9   0:00.11 mysqld