On 10/23/05, Dave Sherohman <[EMAIL PROTECTED]> wrote: > On Sun, Oct 23, 2005 at 10:41:25AM -0700, [EMAIL PROTECTED] 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 _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
