Re: [RDD] Too long to save VTs

[Cowboy]

On Sunday 23 February 2014 09:06:07 am ad...@linspireos.co.uk wrote:
> 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.

 OK, the fundamental question

 Does this happen on CentOS, or SuSE, 
 or is this confined to "unsupported" OS ?

-- 
Cowboy

http://cowboy.cwf1.com

Everything is worth precisely as much as a belch, the difference being
that a belch is more satisfying.
-- Ingmar Bergman

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[admin]

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  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

Re: [RDD] Too long to save VTs

[Pedro Picoto]

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  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

Re: [RDD] Too long to save VTs

[Cowboy]

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

Re: [RDD] Too long to save VTs

[Cowboy]

On Friday 21 February 2014 08:39:00 pm Wayne Merricks wrote:
>  Not really sure why 13.10 flipped to 1.1 but as they're effectively the same 
> in loopback terms I doubt it makes any difference.

 Depends on the application.
 As long as it's in the 127 Class A block, and it's NOT 0.0.1
 then it's an improvement.
 Yes, it's still the loopback, but it's not the same.
 ( in some cases )

-- 
Cowboy

http://cowboy.cwf1.com

"Being disintegrated makes me ve-ry an-gry!" 

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Lorne Tyndale]

Hi,

Another thing with MySQL, ensure that you've got hostname lookups turned
off in my.cnf

You're  my.cnf will either be at:

/etc/my.cnf

or

/etc/mysql/my.cnf

Add in the section:

[mysqld]
# Skip reverse DNS lookup of clients
skip-name-resolve



Restart Mysqld, restart the Rivendell daemons, and see if that fixes it.

Lorne Tyndale




>  Original Message 
> Subject: Re: [RDD] Too long to save VTs
> From: Pedro Picoto 
> Date: Fri, February 21, 2014 7:38 pm
> To: Cowboy 
> Cc: "rivendell-dev@lists.rivendellaudio.org"
> 
> 
> 
> Nope...  didn't fix...
> 
> (meanwhile thanks for your help)
> 
> 
> On Fri, Feb 21, 2014 at 11:09 PM, Cowboy  wrote:
> 
> > On Friday 21 February 2014 05:21:44 pm Pedro Picoto wrote:
> > > These are the settings that suposedely are messing the logedit...
> > > Due to the lack of knowledge I'm not comfortable dealing with this. It's
> > > being a challenge, actually.
> > > Having this, what should I tweak?
> >
> >  OK, for test...
> >
> >  As root, open a text editor on /etc/resolv.conf
> >  change
> >  nameserver 127.0.0.1
> >  to
> >  #nameserver 127.0.0.1
> >
> >  Restart Rivendell. DO NOT reboot !
> >  By having no nameserver to wait for, the timeout should be immediate.
> >
> >  I think you said you're running an Ubuntu of some stripe.
> >  I'm not familiar with that OS specifically, so I can't tell you
> >  how to restart Rivendell on that OS.
> >
> >  Let us know.
> >
> > --
> > Cowboy
> >
> > http://cowboy.cwf1.com
> >
> > "Being disintegrated makes me ve-ry an-gry!" 
> >
> > ___
> > 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

Re: [RDD] Too long to save VTs

[Wayne Merricks]

Hi,

As an aside nameserver 127.0.0.1 seems to be the default for Ubuntu 
12.04 and 127.0.1.1 in 13.10.  Not really sure why 13.10 flipped to 1.1 
but as they're effectively the same in loopback terms I doubt it makes 
any difference.


Apologies for not having any other suggestions mysql skip networking 
has always been my goto solution for weird db slow downs.


Regards,

Wayne

On 2014-02-22 00:38, Pedro Picoto wrote:

Nope...  didnt fix...

(meanwhile thanks for your help)

On Fri, Feb 21, 2014 at 11:09 PM, Cowboy  wrote:


On Friday 21 February 2014 05:21:44 pm Pedro Picoto wrote:
> These are the settings that suposedely are messing the logedit...
> Due to the lack of knowledge Im not comfortable dealing with
this. Its
> being a challenge, actually.
> Having this, what should I tweak?

 OK, for test...

 As root, open a text editor on /etc/resolv.conf
 change
 nameserver 127.0.0.1
 to
 #nameserver 127.0.0.1

 Restart Rivendell. DO NOT reboot !
 By having no nameserver to wait for, the timeout should be
immediate.

 I think you said youre running an Ubuntu of some stripe.
 Im not familiar with that OS specifically, so I cant tell you
 how to restart Rivendell on that OS.

 Let us know.

--
Cowboy

http://cowboy.cwf1.com [1]

"Being disintegrated makes me ve-ry an-gry!" 

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org [2]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[3]




Links:
--
[1] http://cowboy.cwf1.com
[2] mailto:Rivendell-dev@lists.rivendellaudio.org
[3] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[4] mailto:c...@cwf1.com


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Nope...  didn't fix...

(meanwhile thanks for your help)


On Fri, Feb 21, 2014 at 11:09 PM, Cowboy  wrote:

> On Friday 21 February 2014 05:21:44 pm Pedro Picoto wrote:
> > These are the settings that suposedely are messing the logedit...
> > Due to the lack of knowledge I'm not comfortable dealing with this. It's
> > being a challenge, actually.
> > Having this, what should I tweak?
>
>  OK, for test...
>
>  As root, open a text editor on /etc/resolv.conf
>  change
>  nameserver 127.0.0.1
>  to
>  #nameserver 127.0.0.1
>
>  Restart Rivendell. DO NOT reboot !
>  By having no nameserver to wait for, the timeout should be immediate.
>
>  I think you said you're running an Ubuntu of some stripe.
>  I'm not familiar with that OS specifically, so I can't tell you
>  how to restart Rivendell on that OS.
>
>  Let us know.
>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> "Being disintegrated makes me ve-ry an-gry!" 
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Cowboy]

On Friday 21 February 2014 05:21:44 pm Pedro Picoto wrote:
> These are the settings that suposedely are messing the logedit...
> Due to the lack of knowledge I'm not comfortable dealing with this. It's
> being a challenge, actually.
> Having this, what should I tweak?
 
 OK, for test...

 As root, open a text editor on /etc/resolv.conf
 change
 nameserver 127.0.0.1
 to
 #nameserver 127.0.0.1

 Restart Rivendell. DO NOT reboot !
 By having no nameserver to wait for, the timeout should be immediate.

 I think you said you're running an Ubuntu of some stripe.
 I'm not familiar with that OS specifically, so I can't tell you
 how to restart Rivendell on that OS.

 Let us know.

-- 
Cowboy

http://cowboy.cwf1.com

"Being disintegrated makes me ve-ry an-gry!" 

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Here are the current files (it's a stand alone machine):

Hosts:
127.0.0.1localhost
127.0.0.2pedro-desktop

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

RD Hosts show 127.0.0.1
These are the settings that suposedely are messing the logedit...
Due to the lack of knowledge I'm not comfortable dealing with this. It's
being a challenge, actually.
Having this, what should I tweak?





On Fri, Feb 21, 2014 at 9:32 PM, Cowboy  wrote:

> On Friday 21 February 2014 04:14:09 pm Pedro Picoto wrote:
> > A dumb interrogation... Sooo?
>
>  Get rid of 127.0.0.1 anywhere and everywhere except for that single
>  entry in the hosts file.
>  127.0.0.1  localhost
>
>  In /etc/resolv.conf
>  give it a real DNS machine.
>  nameserver 8.8.8.8
>  nameserver 4.2.2.2
>
>  or the nameserver your LAN actually uses.
>
>  Alternatively, list the target machines, all of them, in the
>  /etc/hosts file.
>  The hosts file is ( usually ) consulted first, so then DNS won't matter.
>  If this is a stand alone, not on a network, then /etc/hosts
>  127.0.0.1   localhost
>  127.0.0.2   machine-name
>
>  By having the resolv.conf file point to the loopback address, the resolver
>  is waiting for BIND through the loopback on port 53,  to return the
> machine
>  address, if BIND is even running on the local machine.
>  When that doesn't happen, you're waiting for the resolver to time out,
>  usually about a minute or so.
>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Cowboy]

On Friday 21 February 2014 04:14:09 pm Pedro Picoto wrote:
> A dumb interrogation... Sooo?

 Get rid of 127.0.0.1 anywhere and everywhere except for that single
 entry in the hosts file.
 127.0.0.1  localhost

 In /etc/resolv.conf
 give it a real DNS machine.
 nameserver 8.8.8.8
 nameserver 4.2.2.2

 or the nameserver your LAN actually uses.

 Alternatively, list the target machines, all of them, in the
 /etc/hosts file.
 The hosts file is ( usually ) consulted first, so then DNS won't matter.
 If this is a stand alone, not on a network, then /etc/hosts
 127.0.0.1   localhost
 127.0.0.2   machine-name

 By having the resolv.conf file point to the loopback address, the resolver
 is waiting for BIND through the loopback on port 53,  to return the machine
 address, if BIND is even running on the local machine.
 When that doesn't happen, you're waiting for the resolver to time out,
 usually about a minute or so.

-- 
Cowboy

http://cowboy.cwf1.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

A dumb interrogation... Sooo?


On Fri, Feb 21, 2014 at 9:08 PM, Cowboy  wrote:

> On Friday 21 February 2014 03:46:58 pm Pedro Picoto wrote:
> > nameserver 127.0.0.1
>
>  BINGO !!
>
>  Unless and even if this is a stand-alone machine connected
>  to absolutely nothing else
>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Cowboy]

On Friday 21 February 2014 03:46:58 pm Pedro Picoto wrote:
> nameserver 127.0.0.1

 BINGO !!

 Unless and even if this is a stand-alone machine connected
 to absolutely nothing else

-- 
Cowboy

http://cowboy.cwf1.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

No prob.
Custom installed on Ubuntu 12.04 lts. Meanwhile I've googled adding some
variables. The resolv.conf file shows:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Brian McKelvey]

Remind me again which linux distro you're using?  Is this the Rivendell 
appliance, or a custom install?  Sorry if you already shared this info, I'm on 
my phone and can't seem to find the older emails in this thread.

Brian

Sent from my iPhone

> On Feb 21, 2014, at 12:05 PM, Pedro Picoto  wrote:
> 
> Tks for the hint. Now I need a path to an "How to" since I don't have any 
> kind of knowledge even doing a google search...
> 
> 
>> On Fri, Feb 21, 2014 at 3:36 PM, Fred Gleason  
>> wrote:
>> On Feb 20, 2014, at 17:15 08, Pedro Picoto  wrote:
>> 
>> > Id'like to read some suggestions from Fred regarding my case...
>> > Seems to be a one in a million issue...
>> 
>> Indeed, sounds like a local configuration issue.  I tend to agree with Brian 
>> — it sounds like it’s sitting on a timeout somewhere.  DNS resolver 
>> configuration is the first thing I’d check.
>> 
>> Cheers!
>> 
>> 
>> |-|
>> | Frederick F. Gleason, Jr. |   Chief Developer   |
>> |   |   Paravel Systems   |
>> |-|
>> |  A room without books is like a body without a soul.|
>> | -- Cicero   |
>> |-|
>> 
>> ___
>> 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

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Tks for the hint. Now I need a path to an "How to" since I don't have any
kind of knowledge even doing a google search...


On Fri, Feb 21, 2014 at 3:36 PM, Fred Gleason wrote:

> On Feb 20, 2014, at 17:15 08, Pedro Picoto  wrote:
>
> > Id'like to read some suggestions from Fred regarding my case...
> > Seems to be a one in a million issue...
>
> Indeed, sounds like a local configuration issue.  I tend to agree with
> Brian -- it sounds like it's sitting on a timeout somewhere.  DNS resolver
> configuration is the first thing I'd check.
>
> Cheers!
>
>
> |-|
> | Frederick F. Gleason, Jr. |   Chief Developer   |
> |   |   Paravel Systems   |
> |-|
> |  A room without books is like a body without a soul.|
> | -- Cicero   |
> |-|
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Fred Gleason]

On Feb 20, 2014, at 17:15 08, Pedro Picoto  wrote:

> Id'like to read some suggestions from Fred regarding my case...
> Seems to be a one in a million issue...

Indeed, sounds like a local configuration issue.  I tend to agree with Brian — 
it sounds like it’s sitting on a timeout somewhere.  DNS resolver configuration 
is the first thing I’d check.

Cheers!


|-|
| Frederick F. Gleason, Jr. |   Chief Developer   |
|   |   Paravel Systems   |
|-|
|  A room without books is like a body without a soul.|
| -- Cicero   |
|-|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Id'like to read some suggestions from Fred regarding my case...
Seems to be a one in a million issue...


On Thu, Feb 20, 2014 at 12:13 PM, Pedro Picoto wrote:

>
> Ths SQL is used just for RD.
> The db is already using MyISAM because the Grid Editor wasn't saving the
> changes and I was adviced
> to change from InnoDB to MyISAM, wich fixed the that problem.
>
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Ths SQL is used just for RD.
The db is already using MyISAM because the Grid Editor wasn't saving the
changes and I was adviced
to change from InnoDB to MyISAM, wich fixed the that problem.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Brian]

If I recall correctly, Rivendell expects its tables to be MyISAM for the
time being.  There are some fundamental differences between the way MyISAM
and InnoDB work, including different features available for querying,
transactions, etc.

I'd say setting the default storage engine to MyISAM should be perfectly
fine if you're only going to be using this MySQL server for Rivendell.
 Otherwise, make sure to go through and convert all the tables to MyISAM
manually.  If you don't change the default, make sure to go through and
verify the storage engine on any new tables potentially created by an
upgrade to the database schema if/when you install newer versions of
Rivendell.

In an ideal world, Rivendell should explicitly specify MyISAM as the engine
for the tables it creates until it's ready to move to InnoDB, to allow for
the sensible default of InnoDB as the storage engine of choice to stand.

Brian



On Wed, Feb 19, 2014 at 5:22 PM, Marius Radiokæll Qtronix <
qtro...@halden.net> wrote:

>  I read something earlier about someone changing all their Rivendell
> tables to using the MyISAM engine instead of InnoDB to fix the problem. So
> I tried that now. This fixed the long delay for me.
> Don't really know how or why, but it solved it. Adding, changing and
> removing VT's works in a snap now. Tho, the data on this system is just
> setup as a local test, so it's not very important.
>
> Also worth noting is I'm running MySQL bound to 127.0.0.01 and have
> skip-networking and skip-external-locking in my.cnf. After converting to
> MyISAM, I also defined default-storage-engine to MyISAM in my.cnf.
> Is this a safe thing to do, or is this just a quick and potentially unsafe
> hack?
>
> Marius
>
> On 02/20/2014 02:07 AM, Pedro Picoto wrote:
>
>  The only apparent variable is that the early february DB was free from
> consecutive playback during a week.
>  The issue occurs only on the RDLogedit.
> Any operation regarding moving, adding, copy on the RDAirplay runs quick
> and flawlessly
>  Updating an on air log takes while but I consider normal.
>  Is there a way to purge the DB regarding old logs?
>
>
> On Thu, Feb 20, 2014 at 12:12 AM, Cowboy  wrote:
>
>> On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
>> >  Isn't this a DB problem instead of a device
>> > config one?
>>
>>   Not necessarily.
>>  It would probably be handy to compare various settings
>>  from one database to the other.
>>
>> --
>> Cowboy
>>
>> http://cowboy.cwf1.com
>>
>> Feel disillusioned?  I've got some great new illusions ...
>>
>> ___
>> Rivendell-dev mailing list
>> Rivendell-dev@lists.rivendellaudio.org
>> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>>
>
>
>
> ___
> Rivendell-dev mailing 
> listRivendell-dev@lists.rivendellaudio.orghttp://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

Re: [RDD] Too long to save VTs

[Brian]

Bizarre.  I've been working with Linux servers for the last 15 years and
I've never encountered the kind of behavior you're describing from other
products.

Brian



On Wed, Feb 19, 2014 at 5:34 PM, Karl Koscher  wrote:

> In my experience, it certainly wasn't a network thing, nor was it waiting
> for a request to time out. The hard drive activity light was solid, and
> mysqld and/or some kernel disk process would be consuming all available
> cycles.
>
> I do not know exactly why, but adding the noatime significantly sped
> things up. It still takes a second or so, but it's orders of magnitude
> better than it was.
>
>
> On Wed, Feb 19, 2014 at 4:53 PM, Brian McKelvey wrote:
>
>> I have a hard time believing this has anything to do with the file system
>> mount configuration on a stock Linux distro.  For NFS, sure.  But for
>> local?  Not likely.  Almost certainly something else is up.
>>
>> I might be inclined to start investigating network related things.  DNS,
>> the "hosts" file (making sure the machine's local hostname maps to
>> 127.0.0.1), etc., even if the machine isn't connected to a network.
>>
>> I suspect there's some kind of request timeout somewhere.
>>
>> Brian
>>
>> Sent from my iPhone
>>
>> > On Feb 19, 2014, at 4:12 PM, Cowboy  wrote:
>> >
>> >> On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
>> >> Isn't this a DB problem instead of a device
>> >> config one?
>> >
>> > Not necessarily.
>> > It would probably be handy to compare various settings
>> > from one database to the other.
>> >
>> > --
>> > Cowboy
>> >
>> > http://cowboy.cwf1.com
>> >
>> > Feel disillusioned?  I've got some great new illusions ...
>> >
>> > ___
>> > 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

Re: [RDD] Too long to save VTs

[Karl Koscher]

In my experience, it certainly wasn't a network thing, nor was it waiting
for a request to time out. The hard drive activity light was solid, and
mysqld and/or some kernel disk process would be consuming all available
cycles.

I do not know exactly why, but adding the noatime significantly sped things
up. It still takes a second or so, but it's orders of magnitude better than
it was.


On Wed, Feb 19, 2014 at 4:53 PM, Brian McKelvey wrote:

> I have a hard time believing this has anything to do with the file system
> mount configuration on a stock Linux distro.  For NFS, sure.  But for
> local?  Not likely.  Almost certainly something else is up.
>
> I might be inclined to start investigating network related things.  DNS,
> the "hosts" file (making sure the machine's local hostname maps to
> 127.0.0.1), etc., even if the machine isn't connected to a network.
>
> I suspect there's some kind of request timeout somewhere.
>
> Brian
>
> Sent from my iPhone
>
> > On Feb 19, 2014, at 4:12 PM, Cowboy  wrote:
> >
> >> On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
> >> Isn't this a DB problem instead of a device
> >> config one?
> >
> > Not necessarily.
> > It would probably be handy to compare various settings
> > from one database to the other.
> >
> > --
> > Cowboy
> >
> > http://cowboy.cwf1.com
> >
> > Feel disillusioned?  I've got some great new illusions ...
> >
> > ___
> > 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

Re: [RDD] Too long to save VTs

[Marius Radiokæll Qtronix]

I read something earlier about someone changing all their Rivendell 
tables to using the MyISAM engine instead of InnoDB to fix the problem. 
So I tried that now. This fixed the long delay for me.
Don't really know how or why, but it solved it. Adding, changing and 
removing VT's works in a snap now. Tho, the data on this system is just 
setup as a local test, so it's not very important.


Also worth noting is I'm running MySQL bound to 127.0.0.01 and have 
skip-networking and skip-external-locking in my.cnf. After converting to 
MyISAM, I also defined default-storage-engine to MyISAM in my.cnf.
Is this a safe thing to do, or is this just a quick and potentially 
unsafe hack?


Marius

On 02/20/2014 02:07 AM, Pedro Picoto wrote:
The only apparent variable is that the early february DB was free from 
consecutive playback during a week.

The issue occurs only on the RDLogedit.
Any operation regarding moving, adding, copy on the RDAirplay runs 
quick and flawlessly

Updating an on air log takes while but I consider normal.
Is there a way to purge the DB regarding old logs?


On Thu, Feb 20, 2014 at 12:12 AM, Cowboy > wrote:


On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
>  Isn't this a DB problem instead of a device
> config one?

 Not necessarily.
 It would probably be handy to compare various settings
 from one database to the other.

--
Cowboy

http://cowboy.cwf1.com

Feel disillusioned?  I've got some great new illusions ...

___
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

Re: [RDD] Too long to save VTs

[Pedro Picoto]

The only apparent variable is that the early february DB was free from
consecutive playback during a week.
The issue occurs only on the RDLogedit.
Any operation regarding moving, adding, copy on the RDAirplay runs quick
and flawlessly
Updating an on air log takes while but I consider normal.
Is there a way to purge the DB regarding old logs?


On Thu, Feb 20, 2014 at 12:12 AM, Cowboy  wrote:

> On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
> >  Isn't this a DB problem instead of a device
> > config one?
>
>  Not necessarily.
>  It would probably be handy to compare various settings
>  from one database to the other.
>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> Feel disillusioned?  I've got some great new illusions ...
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Brian McKelvey]

I have a hard time believing this has anything to do with the file system mount 
configuration on a stock Linux distro.  For NFS, sure.  But for local?  Not 
likely.  Almost certainly something else is up.

I might be inclined to start investigating network related things.  DNS, the 
"hosts" file (making sure the machine's local hostname maps to 127.0.0.1), 
etc., even if the machine isn't connected to a network.

I suspect there's some kind of request timeout somewhere.

Brian

Sent from my iPhone

> On Feb 19, 2014, at 4:12 PM, Cowboy  wrote:
> 
>> On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
>> Isn't this a DB problem instead of a device
>> config one?
> 
> Not necessarily.
> It would probably be handy to compare various settings
> from one database to the other.
> 
> -- 
> Cowboy
> 
> http://cowboy.cwf1.com
> 
> Feel disillusioned?  I've got some great new illusions ...
> 
> ___
> 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

Re: [RDD] Too long to save VTs

[Cowboy]

On Wednesday 19 February 2014 06:53:44 pm Pedro Picoto wrote:
>  Isn't this a DB problem instead of a device
> config one?

 Not necessarily.
 It would probably be handy to compare various settings
 from one database to the other.

-- 
Cowboy

http://cowboy.cwf1.com

Feel disillusioned?  I've got some great new illusions ...

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Nope, either.
Just on a atempt to narrow the problem I've restored a previous DB backup
from early february, about 1.2 mb and tested the RDLogedit. It worked
like a champ just as I was used to. Then I restored the current DB (3 megs)
and the problem returned. Isn't this a DB problem instead of a device
config one?


On Wed, Feb 19, 2014 at 10:56 PM, Glenn Hickman wrote:

>  Try the async option.
>
> This should not be an issue for a local file system but we had huge
> latency issues on a nfs share with sync set.
>
> The fstab entry should look like:
>
> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
> async,noatime,errors=remount-ro 0   1
>
> Glenn
>
>  Glenn L. Hickman Jr.
> Sr. RF Engineer
>
> WHRO
> 5200 Hampton Boulevard  |  Norfolk, VA 23508
> P: 757.575.5064  |  F: 757.489.0007
> gle...@whro.org
> whro.org
>   --
> *From:* rivendell-dev-boun...@lists.rivendellaudio.org [
> rivendell-dev-boun...@lists.rivendellaudio.org] on behalf of Pedro Picoto
> [pedro.pic...@gmail.com]
> *Sent:* Wednesday, February 19, 2014 17:44
> *To:* Karl Koscher
> *Cc:* rivendell-dev@lists.rivendellaudio.org
> *Subject:* Re: [RDD] Too long to save VTs
>
>   I just edited the file on gedit under root.
>
> mount / -o remount,noatime... no improvement...
>
>
>
> On Wed, Feb 19, 2014 at 10:29 PM, Karl Koscher  wrote:
>
>> Have you rebooted and/or remounted the root file system?
>>
>>  You can try it instantly without rebooting by doing:
>>
>>  mount / -o remount,noatime
>>
>>
>> On Wed, Feb 19, 2014 at 2:10 PM, Pedro Picoto wrote:
>>
>>>  Looking like this now:
>>>
>>> # /etc/fstab: static file system information.
>>> #
>>> # Use 'blkid' to print the universally unique identifier for a
>>> # device; this may be used with UUID= as a more robust way to name
>>> devices
>>> # that works even if disks are added and removed. See fstab(5).
>>> #
>>> #   
>>> 
>>>  proc/proc   procnoatime,nodev,noexec,nosuid
>>> 0 0
>>>
>>> # / was on /dev/sda1 during installation
>>>  UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>> noatime,errors=remount-ro 0   1
>>>
>>> # swap was on /dev/sda5 during installation
>>> UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
>>> sw  0   0
>>>
>>>  Still having troubles. CPU goes from 25% to 80% while RDLogedit
>>> performs VT operations, taking about 1' to Save and 1.30' to Do Over...
>>>
>>>
>>>
>>>
>>> On Wed, Feb 19, 2014 at 9:54 PM, Karl Koscher  wrote:
>>>
>>>> Just to be clear: it should look like this after:
>>>>
>>>>  UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>>>  noatime,errors=remount-ro 0   1
>>>>
>>>>
>>>>  On Wed, Feb 19, 2014 at 1:09 PM, Cowboy  wrote:
>>>>
>>>>>  On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
>>>>> > Here's why I have on the Fstab file:
>>>>> >
>>>>> > # /etc/fstab: static file system information.
>>>>> > #
>>>>> > # Use 'blkid' to print the universally unique identifier for a
>>>>> > # device; this may be used with UUID= as a more robust way to name
>>>>> devices
>>>>> > # that works even if disks are added and removed. See fstab(5).
>>>>> > #
>>>>> > #  
>>>>>  
>>>>> > proc/proc   procnodev,noexec,nosuid 0   0
>>>>> > # / was on /dev/sda1 during installation
>>>>> > UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>>>> > errors=remount-ro 0   1
>>>>> > # swap was on /dev/sda5 during installation
>>>>> > UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
>>>>> > sw  0   0
>>>>> >
>>>>> > Where should I place the noatime flag?
>>>>> >
>>>>>
>>>>>   In the options column.
>>>>>
>>>>> --
>>>>> Cowboy
>>>>>
>>>>> http://cowboy.cwf1.com
>>>>>
>>>>> Feel disillusioned?  I've got some great new illusions ...
>>>>>
>>>>> ___
>>>>> 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

Re: [RDD] Too long to save VTs

[Glenn Hickman]

Try the async option.

This should not be an issue for a local file system but we had huge latency 
issues on a nfs share with sync set.

The fstab entry should look like:

UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
async,noatime,errors=remount-ro 0   1

Glenn

Glenn L. Hickman Jr.
Sr. RF Engineer

WHRO
5200 Hampton Boulevard  |  Norfolk, VA 23508
P: 757.575.5064  |  F: 757.489.0007
gle...@whro.org
whro.org

From: rivendell-dev-boun...@lists.rivendellaudio.org 
[rivendell-dev-boun...@lists.rivendellaudio.org] on behalf of Pedro Picoto 
[pedro.pic...@gmail.com]
Sent: Wednesday, February 19, 2014 17:44
To: Karl Koscher
Cc: rivendell-dev@lists.rivendellaudio.org
Subject: Re: [RDD] Too long to save VTs

I just edited the file on gedit under root.

mount / -o remount,noatime... no improvement...



On Wed, Feb 19, 2014 at 10:29 PM, Karl Koscher 
mailto:super...@uwave.fm>> wrote:
Have you rebooted and/or remounted the root file system?

You can try it instantly without rebooting by doing:

mount / -o remount,noatime


On Wed, Feb 19, 2014 at 2:10 PM, Pedro Picoto 
mailto:pedro.pic...@gmail.com>> wrote:
Looking like this now:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# 

proc/proc   procnoatime,nodev,noexec,nosuid0
 0

# / was on /dev/sda1 during installation
UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
noatime,errors=remount-ro 0   1

# swap was on /dev/sda5 during installation
UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswapsw
  0   0

Still having troubles. CPU goes from 25% to 80% while RDLogedit performs VT 
operations, taking about 1' to Save and 1.30' to Do Over...




On Wed, Feb 19, 2014 at 9:54 PM, Karl Koscher 
mailto:super...@uwave.fm>> wrote:
Just to be clear: it should look like this after:

UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
noatime,errors=remount-ro 0   1


On Wed, Feb 19, 2014 at 1:09 PM, Cowboy mailto:c...@cwf1.com>> 
wrote:
On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
> Here's why I have on the Fstab file:
>
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #
> proc/proc   procnodev,noexec,nosuid 0   0
> # / was on /dev/sda1 during installation
> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
> errors=remount-ro 0   1
> # swap was on /dev/sda5 during installation
> UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
> sw  0   0
>
> Where should I place the noatime flag?
>

 In the options column.

--
Cowboy

http://cowboy.cwf1.com

Feel disillusioned?  I've got some great new illusions ...

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org<mailto:Rivendell-dev@lists.rivendellaudio.org>
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org<mailto: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

Re: [RDD] Too long to save VTs

[Pedro Picoto]

I just edited the file on gedit under root.

mount / -o remount,noatime... no improvement...



On Wed, Feb 19, 2014 at 10:29 PM, Karl Koscher  wrote:

> Have you rebooted and/or remounted the root file system?
>
> You can try it instantly without rebooting by doing:
>
> mount / -o remount,noatime
>
>
> On Wed, Feb 19, 2014 at 2:10 PM, Pedro Picoto wrote:
>
>> Looking like this now:
>>
>> # /etc/fstab: static file system information.
>> #
>> # Use 'blkid' to print the universally unique identifier for a
>> # device; this may be used with UUID= as a more robust way to name devices
>> # that works even if disks are added and removed. See fstab(5).
>> #
>> #   
>> 
>> proc/proc   procnoatime,nodev,noexec,nosuid
>> 0 0
>>
>> # / was on /dev/sda1 during installation
>> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>> noatime,errors=remount-ro 0   1
>>
>> # swap was on /dev/sda5 during installation
>> UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
>> sw  0   0
>>
>> Still having troubles. CPU goes from 25% to 80% while RDLogedit performs
>> VT operations, taking about 1' to Save and 1.30' to Do Over...
>>
>>
>>
>>
>> On Wed, Feb 19, 2014 at 9:54 PM, Karl Koscher  wrote:
>>
>>> Just to be clear: it should look like this after:
>>>
>>> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>>  noatime,errors=remount-ro 0   1
>>>
>>>
>>> On Wed, Feb 19, 2014 at 1:09 PM, Cowboy  wrote:
>>>
 On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
 > Here's why I have on the Fstab file:
 >
 > # /etc/fstab: static file system information.
 > #
 > # Use 'blkid' to print the universally unique identifier for a
 > # device; this may be used with UUID= as a more robust way to name
 devices
 > # that works even if disks are added and removed. See fstab(5).
 > #
 > #
 > proc/proc   procnodev,noexec,nosuid 0   0
 > # / was on /dev/sda1 during installation
 > UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
 > errors=remount-ro 0   1
 > # swap was on /dev/sda5 during installation
 > UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
 > sw  0   0
 >
 > Where should I place the noatime flag?
 >

  In the options column.

 --
 Cowboy

 http://cowboy.cwf1.com

 Feel disillusioned?  I've got some great new illusions ...

 ___
 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

Re: [RDD] Too long to save VTs

[Karl Koscher]

Have you rebooted and/or remounted the root file system?

You can try it instantly without rebooting by doing:

mount / -o remount,noatime


On Wed, Feb 19, 2014 at 2:10 PM, Pedro Picoto wrote:

> Looking like this now:
>
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #   
> 
> proc/proc   procnoatime,nodev,noexec,nosuid
> 0 0
>
> # / was on /dev/sda1 during installation
> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
> noatime,errors=remount-ro 0   1
>
> # swap was on /dev/sda5 during installation
> UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
> sw  0   0
>
> Still having troubles. CPU goes from 25% to 80% while RDLogedit performs
> VT operations, taking about 1' to Save and 1.30' to Do Over...
>
>
>
>
> On Wed, Feb 19, 2014 at 9:54 PM, Karl Koscher  wrote:
>
>> Just to be clear: it should look like this after:
>>
>> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>  noatime,errors=remount-ro 0   1
>>
>>
>> On Wed, Feb 19, 2014 at 1:09 PM, Cowboy  wrote:
>>
>>> On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
>>> > Here's why I have on the Fstab file:
>>> >
>>> > # /etc/fstab: static file system information.
>>> > #
>>> > # Use 'blkid' to print the universally unique identifier for a
>>> > # device; this may be used with UUID= as a more robust way to name
>>> devices
>>> > # that works even if disks are added and removed. See fstab(5).
>>> > #
>>> > #
>>> > proc/proc   procnodev,noexec,nosuid 0   0
>>> > # / was on /dev/sda1 during installation
>>> > UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>>> > errors=remount-ro 0   1
>>> > # swap was on /dev/sda5 during installation
>>> > UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
>>> > sw  0   0
>>> >
>>> > Where should I place the noatime flag?
>>> >
>>>
>>>  In the options column.
>>>
>>> --
>>> Cowboy
>>>
>>> http://cowboy.cwf1.com
>>>
>>> Feel disillusioned?  I've got some great new illusions ...
>>>
>>> ___
>>> 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

Re: [RDD] Too long to save VTs

[Pedro Picoto]

Looking like this now:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#   

proc/proc   procnoatime,nodev,noexec,nosuid
0 0
# / was on /dev/sda1 during installation
UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
noatime,errors=remount-ro 0   1
# swap was on /dev/sda5 during installation
UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
sw  0   0

Still having troubles. CPU goes from 25% to 80% while RDLogedit performs VT
operations, taking about 1' to Save and 1.30' to Do Over...




On Wed, Feb 19, 2014 at 9:54 PM, Karl Koscher  wrote:

> Just to be clear: it should look like this after:
>
> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>  noatime,errors=remount-ro 0   1
>
>
> On Wed, Feb 19, 2014 at 1:09 PM, Cowboy  wrote:
>
>> On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
>> > Here's why I have on the Fstab file:
>> >
>> > # /etc/fstab: static file system information.
>> > #
>> > # Use 'blkid' to print the universally unique identifier for a
>> > # device; this may be used with UUID= as a more robust way to name
>> devices
>> > # that works even if disks are added and removed. See fstab(5).
>> > #
>> > #
>> > proc/proc   procnodev,noexec,nosuid 0   0
>> > # / was on /dev/sda1 during installation
>> > UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
>> > errors=remount-ro 0   1
>> > # swap was on /dev/sda5 during installation
>> > UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
>> > sw  0   0
>> >
>> > Where should I place the noatime flag?
>> >
>>
>>  In the options column.
>>
>> --
>> Cowboy
>>
>> http://cowboy.cwf1.com
>>
>> Feel disillusioned?  I've got some great new illusions ...
>>
>> ___
>> 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

Re: [RDD] Too long to save VTs

[Karl Koscher]

Just to be clear: it should look like this after:

UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
 noatime,errors=remount-ro 0   1


On Wed, Feb 19, 2014 at 1:09 PM, Cowboy  wrote:

> On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
> > Here's why I have on the Fstab file:
> >
> > # /etc/fstab: static file system information.
> > #
> > # Use 'blkid' to print the universally unique identifier for a
> > # device; this may be used with UUID= as a more robust way to name
> devices
> > # that works even if disks are added and removed. See fstab(5).
> > #
> > #
> > proc/proc   procnodev,noexec,nosuid 0   0
> > # / was on /dev/sda1 during installation
> > UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
> > errors=remount-ro 0   1
> > # swap was on /dev/sda5 during installation
> > UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
> > sw  0   0
> >
> > Where should I place the noatime flag?
> >
>
>  In the options column.
>
> --
> Cowboy
>
> http://cowboy.cwf1.com
>
> Feel disillusioned?  I've got some great new illusions ...
>
> ___
> 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

Re: [RDD] Too long to save VTs

[Cowboy]

On Wednesday 19 February 2014 03:53:13 pm Pedro Picoto wrote:
> Here's why I have on the Fstab file:
> 
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #
> proc/proc   procnodev,noexec,nosuid 0   0
> # / was on /dev/sda1 during installation
> UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
> errors=remount-ro 0   1
> # swap was on /dev/sda5 during installation
> UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
> sw  0   0
> 
> Where should I place the noatime flag?
> 

 In the options column.

-- 
Cowboy

http://cowboy.cwf1.com

Feel disillusioned?  I've got some great new illusions ...

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] Too long to save VTs

[Pedro Picoto]

Here's why I have on the Fstab file:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
proc/proc   procnodev,noexec,nosuid 0   0
# / was on /dev/sda1 during installation
UUID=129403c9-1c93-4391-be12-8c529a6656e9 /   ext4
errors=remount-ro 0   1
# swap was on /dev/sda5 during installation
UUID=c70ea169-fd8f-4e0f-aa55-f3a5d9a9c100 noneswap
sw  0   0

Where should I place the noatime flag?
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Too long to save VTs

[Karl Koscher]

I believe it should be in the [mysqld] section.

That being said, it didn't fix the problem for me. I had to add the
"noatime" flag to the fstab entry for the partition the DB was on. Once I
did that, it was pretty fast.


On Tue, Feb 18, 2014 at 5:47 PM, Pedro Picoto wrote:

> I've been running Rivendell in a 24/24 basis for about a week. Today I
> stopped it to record some Vts.
>
> I getting the same problem that I stated here a few months ago:
>
>-
>
>It takes about 50'' to save VT, another to Do Over, ie, any operation
>regarding VT is taking about 50''.
>
> I've backup the database and noticed that it grew from 1.2mb to 3mb in a
> week, wich corresponds roughly to the period that RD was running 24/24.
>
>
>  My setup is a single pc. No network, audio files in the same HD as the
> DB.
>
>
>  Someone answered me the last time giving this possible fix:
> *Added : innodb-flush-log-at-trx-commit=2  to my.cnf**Now the voicetracker 
> responds in less than a second to the save button.*
> Question: where in the my.cnf file should I paste this? I've pasted it as the 
> last line and had no effect.
>
>
> ___
> 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

[RDD] Too long to save VTs

[Pedro Picoto]

I've been running Rivendell in a 24/24 basis for about a week. Today I
stopped it to record some Vts.

I getting the same problem that I stated here a few months ago:

   -

   It takes about 50'' to save VT, another to Do Over, ie, any operation
   regarding VT is taking about 50''.

I've backup the database and noticed that it grew from 1.2mb to 3mb in a
week, wich corresponds roughly to the period that RD was running 24/24.


 My setup is a single pc. No network, audio files in the same HD as the DB.


 Someone answered me the last time giving this possible fix:
*Added : innodb-flush-log-at-trx-commit=2  to my.cnf**Now the
voicetracker responds in less than a second to the save button.*
Question: where in the my.cnf file should I paste this? I've pasted it
as the last line and had no effect.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev