This slow to make vt in log i have been trying to find out too,its not permissions or network as its also happening on stand along systems all running 1204 and above 1310 wheezy xbuntu etc all are doing this, with new databases or using old ones too, it started in 2,55 if i recal, its either an update / apache or some of the new database changes are causing these problems although on 10.04 all is fine new or old databases, seems not to be a permissions fault either.
enter vt link in 1004 3 seconds on networked systems and about same to save. 1204 and above 8 to 15 seconds and 30 + to save even on stand alone systems compiles or deb file setup. I have tested on 5 different pcs and all my stations and test systems are all back on 10.04 until we can sort the problems out so its not just you Pedro. Regards Les > Been out all day, while keeping this issue in mind. I came across a "what > if" > What happends if I create a small log manually? > Done that and the results were good. Tested on a full day log and the "issue" was back. > Tested old DBs and seems that the amount time to save VTs is proportional > to size of the log. > I think we can exclude the network from the equation. > Can this be resumed as an hardware issue? I'm running RD on a dual-core AMD > A6-5400K/4gb. > RIPCD is on the top 3, mostly in 1st place, of the cpu list while running > RD. Always > On Sat, Feb 22, 2014 at 11:16 AM, Cowboy <c...@cwf1.com> wrote: >> On Friday 21 February 2014 09:15:02 pm Lorne Tyndale wrote: >> > Another thing with MySQL, ensure that you've got hostname lookups >> turned >> > off in my.cnf >> Yeah, I thought about that, too. >> ( actually a better way than dinking with other things, like >> file system flags, and resolver settings that won't fix the problem, but merely hide it ) >> Except that none of that has been changed between >> problem and no problem. >> Pedro indicated that restoring an older database, no problem. >> Then, restoring the new database, problem. >> It seems that ideally, we could step back through time, restoring daily backups one at a time, until we find the point at which >> something changed. >> Somehow, I doubt we have that many backups, so the best we >> can do is try to determine what changes exist between problem >> and no problem, and try to isolate those changes. >> Especially in RDAdmin, what's different ? >> -- >> Cowboy >> http://cowboy.cwf1.com >> "Just once, I wish we would encounter an alien menace that wasn't immune to bullets" >> -- The Brigader, "Dr. Who" >> _______________________________________________ >> Rivendell-dev mailing list >> Rivendell-dev@lists.rivendellaudio.org >> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev > _______________________________________________ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
