| Wednesday, October 31st, 2018, 00:28 UTC | ||
| [00:28:53] | iBDonC (iBDonC!~don@fw.star-c.com) has joined #mythtv-users | |
| [01:28:24] | amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!) | |
| [04:18:18] | [R] ([R]!~rbox@unaffiliated/rbox) has joined #mythtv-users | |
| [06:09:28] | [R] ([R]!~rbox@unaffiliated/rbox) has quit (Quit: Leaving) | |
| [07:05:44] | troyt (troyt!zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) has quit (Ping timeout: 250 seconds) | |
| [07:18:31] | Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has joined #mythtv-users | |
| [07:18:31] | Mode for #mythtv-users by ChanServ!ChanServ@services. : +v Steve-Goodey | |
| [07:51:58] | troyt (troyt!zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) has joined #mythtv-users | |
| [08:06:45] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 252 seconds) | |
| [09:16:06] | arrrghhh (arrrghhh!~arrrghhh@unaffiliated/arrrghhh) has quit (Ping timeout: 246 seconds) | |
| [09:18:10] | arrrghhh (arrrghhh!~arrrghhh@unaffiliated/arrrghhh) has joined #mythtv-users | |
| [09:30:38] | Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has quit (Quit: Konversation terminated!) | |
| [09:38:37] | gregbert (gregbert!~gregbert@unaffiliated/gregbert) has quit (Ping timeout: 246 seconds) | |
| [09:45:55] | gregbert (gregbert!~gregbert@unaffiliated/gregbert) has joined #mythtv-users | |
| [15:01:13] | psymin (psymin!~psymin@69.146.8.222) has joined #mythtv-users | |
| [15:01:13] | Mode for #mythtv-users by ChanServ!ChanServ@services. : +v psymin | |
| [15:07:14] | Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has joined #mythtv-users | |
| [15:07:14] | Mode for #mythtv-users by ChanServ!ChanServ@services. : +v Steve-Goodey | |
| [16:57:21] | louisdk (louisdk!~louisdk@static-5-103-138-205.ip.fibianet.dk) has joined #mythtv-users | |
| [17:26:35] | willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Quit: Do your hobbies) | |
| [17:47:54] | troyt (troyt!zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) has quit (Ping timeout: 264 seconds) | |
| [17:50:32] | troyt (troyt!zncsrv@2601:681:4100:8981:44dd:acff:fe85:9c8e) has joined #mythtv-users | |
| [18:02:36] | pragmaticenigma (pragmaticenigma!~pragmatic@50-253-82-20-static.hfc.comcastbusiness.net) has joined #mythtv-users | |
| [18:20:57] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv-users | |
| [18:20:57] | Mode for #mythtv-users by ChanServ!ChanServ@services. : +v natanojl | |
| [18:25:12] | pragmaticenigma: | Not sure where to place this. I'm currently experiencing issues with MySQL when running transcode jobs. When transcoding, commercial skipping or other heavy disk I/O operations, connections to MySQL timeout frequently. I notice this because Mythweb timesout when fetching records from the DB and I see timeouts being logged. Are there some tweaks or enhancements I could be making to optimize mysql to work along |
| [18:25:12] | pragmaticenigma: | side mythtv? |
| [18:34:56] | cspack (cspack!~cspack@65.35.147.101) has joined #mythtv-users | |
| [18:47:07] | pragmatic_enigma (pragmatic_enigma!~pragmatic@50-253-82-20-static.hfc.comcastbusiness.net) has joined #mythtv-users | |
| [18:51:21] | pragmaticenigma (pragmaticenigma!~pragmatic@50-253-82-20-static.hfc.comcastbusiness.net) has quit (Ping timeout: 260 seconds) | |
| [18:53:36] | cspack (cspack!~cspack@65.35.147.101) has quit (Quit: WeeChat 2.3) | |
| [18:53:41] | pragmatic_enigma is now known as pragmaticenigma | |
| [18:54:04] | cspack (cspack!~cspack@65.35.147.101) has joined #mythtv-users | |
| [18:54:23] | cspack (cspack!~cspack@65.35.147.101) has quit (Client Quit) | |
| [19:10:50] | cspack (cspack!cspack@gateway/vpn/privateinternetaccess/cspack) has joined #mythtv-users | |
| [19:23:16] | sutula: | pragmaticenigma: [disclaimer: I have little specific knowledge of mythtv-backend except as a user for lots of years] |
| [19:23:38] | sutula: | pragmaticenigma: If the timeout is coming from myth backend, I wonder if there's some sort of timeout setting? |
| [19:25:13] | sutula: | The reason I ask is that if the timeouts are due to heavy disk activity, it's not likely that raising MySQL priority will help...everything's blocking on a filesystem access. |
| [19:25:15] | pragmaticenigma: | I'm fairly certain it's a disk I/o issue. The hard part is from the previous instance to the current there were two changes. One is the version of ubuntu that I am running (and therefor version of MythTV) and the harddisk I was using was replaced (previous crashed hard) |
| [19:26:03] | sutula: | In the past, for example, deletes of large recordings (or other large files) would essentially take down the filesystem for periods of time, causing recording problems. |
| [19:26:04] | pragmaticenigma: | The thing is... the disk shouldn't be experiencing blocks. I used a much older (4+ year) drive for as long and never experienced a timeout issue like this. |
| [19:26:25] | sutula: | It may not be the disk itself, but the FS |
| [19:26:33] | sutula: | What type of FS? |
| [19:26:52] | pragmaticenigma: | ext4 |
| [19:27:23] | sutula: | I know deletes of large files were problems for ext3...I don't know much about the characteristics of ext4 but probably google does |
| [19:27:45] | pragmaticenigma: | this is happening during transcode and commercial skipping though |
| [19:27:53] | pragmaticenigma: | not file deletion |
| [19:28:52] | sutula: | I was wondering whether transcode deleted the original after it was done. |
| [19:29:01] | pragmaticenigma: | not currently |
| [19:29:36] | sutula: | Regardless, could you experiment with renice (just manually) and see whether boosting mysqld and lowering transcode process priorities changed anything? |
| [19:29:59] | pragmaticenigma: | I'm not using the built in transcode at this time. I am using a custom job with mythtranscode. The options for the builtin are significantly lacking some features, cheif amoung them is retaining closed captioning |
| [19:31:12] | sutula: | It experimenting with process priorities doesn't help, then that tends to point to a) FS lock somewhere, b) actual disk throughput problem, or c) maybe the myth MySQL timeout is on the ragged edge. |
| [19:31:21] | sutula: | s/It/If/ |
| [19:32:08] | sutula: | As I said, I haven't looked at the myth code...just trying to help you think through where to poke. |
| [19:33:32] | pragmaticenigma: | I honestly don't believe this is a disk i/o... just appears like one. The drive is brand new and is capable of higher throughput on SATA than the motherboard can leverage. this same motherboard has been in use for 4 years without this issue. i'm certain it's a tweak that the mythbuntu team added, that is no longer automatically applied since mythbuntu no longer writes their own ubuntu spin |
| [19:33:56] | pragmaticenigma: | i can't renice the process as I'm not always present at the machine during these operations. |
| [19:34:28] | pragmaticenigma: | where I experience it is when I check the status page of mythtv through mythweb and it times out querying the database |
| [19:35:35] | sutula: | RE renice, just thinking of manual debugging...if you can see errors happening, try the renice, and see if they stop. |
| [19:35:52] | sutula: | Once you figure out what solves it, you can automate it. |
| [19:36:06] | pragmaticenigma: | that doesn't make anysense |
| [19:37:09] | sutula: | Well, if it's transcoding and you can get it to time out, then run a renice, then do a bunch more mythweb queries to see if the timeout seems to go away? |
| [19:37:33] | pragmaticenigma: | renice is CPU bound |
| [19:37:38] | pragmaticenigma: | would have no impact |
| [19:38:25] | pragmaticenigma: | also, you wouldn't ever automate a renice... that could have drastic impacts elsewhere |
| [19:39:19] | tgm4883: | pragmaticenigma: the only database type changes that mythbuntu added were the tweaks I linked you and the cron job I mentioned |
| [19:39:51] | sutula: | pragmaticenigma: If renice somehow helped, you'd then start the offending process with a nice value. |
| [19:39:59] | pragmaticenigma: | tgm4883: tweaks are implemented, hopefully they help |
| [19:41:02] | pragmaticenigma: | sutula: Again, that still doesn't make any sense... the "nice" value of a process is for CPU usage... it is not the solution to this problem |
| [19:41:15] | sutula: | pragmaticenigma: Based on all that you've said, I'm wondering whether transcode is making the mysqld busy enough that it's not servicing other requests for periods of time. |
| [19:42:17] | pragmaticenigma: | no |
| [19:42:52] | pragmaticenigma: | sutula: I feel you are making blind guesses here |
| [19:43:36] | ** sutula shrugs ...just trying to offer ideas on where you can poke to better characterize your problem ** | |
| [19:45:16] | sutula: | If the CPU is busy (e.g. transcoding), then it's not running mysqld or potentially executing scsi stack code. Of course, this is way complicated by multiple CPUs, etc. |
| [19:46:25] | pragmaticenigma: | sutula: CPU usage during transcode barely hits 50% utilization |
| [19:46:37] | pragmaticenigma: | 8 cores, of which 3 are usually fully used |
| [19:47:42] | sutula: | OK, well, that's new info. |
| [19:48:07] | sutula: | Do you happen to know whether mysqld is set up to handle multiple connections? |
| [19:48:44] | sutula: | Could the transcode/commercial skip fill the mysql pipe such that the mythweb requests are having to wait? |
| [19:49:44] | pragmaticenigma: | sutula: the tweaks the tgm4883 mentioned earlier, that I've applied will hopefully address the connection pool being used up |
| [19:50:17] | sutula: | Good luck |
| [19:50:21] | pragmaticenigma: | the other reason I'm fairly certain it's not disk i/o, if I run apt update or apt upgrade at the same time as a transcode, it completes without issue |
| [19:50:52] | pragmaticenigma: | so while I might be appearing to withhold information, it's not intentionally. i'm answering questions as they're presented |
| [19:51:48] | sutula: | pragmaticenigma: No problem...just trying to help and I did disclaim early :) |
| [19:55:46] | pragmaticenigma: | appreciated |
| [20:26:03] | pragmaticenigma (pragmaticenigma!~pragmatic@50-253-82-20-static.hfc.comcastbusiness.net) has quit (Quit: Leaving) | |
| [20:36:18] | maarhart (maarhart!~Mutter@91-154-176-32.elisa-laajakaista.fi) has joined #mythtv-users | |
| [20:57:32] | maarhart (maarhart!~Mutter@91-154-176-32.elisa-laajakaista.fi) has quit (Quit: Mutter: www.mutterirc.com) | |
| [21:43:44] | psymin (psymin!~psymin@69.146.8.222) has quit (Quit: Leaving) | |
| [21:55:51] | louisdk (louisdk!~louisdk@static-5-103-138-205.ip.fibianet.dk) has quit (Ping timeout: 244 seconds) | |
| [22:09:22] | louisdk (louisdk!~louisdk@static-5-103-138-205.ip.fibianet.dk) has joined #mythtv-users | |
| [22:10:48] | Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has quit (Quit: Konversation terminated!) | |
| [22:26:13] | SteveGoodey (SteveGoodey!~steve@2a00:23c5:7da3:4501:7a24:afff:fe9d:c233) has quit (Quit: Konversation terminated!) | |
| [22:28:56] | louisdk (louisdk!~louisdk@static-5-103-138-205.ip.fibianet.dk) has quit (Ping timeout: 260 seconds) | |
| [23:37:46] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 260 seconds) | |
| [23:56:32] | louisdk (louisdk!~louisdk@static-5-103-138-205.ip.fibianet.dk) has joined #mythtv-users | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.