On 7.11.2015 18:26, Phil Stracchino wrote:
>
> The index over JobId alone is redundant with the index over
> (JobId,PathId,FilenameId) present as well. I also had the redundant
> index at one point, and dropped it with no ill effects.
Thanks, I dropped it also.
--
jarif.bit
On 5.10.2015 20.32, Stephen Thompson wrote:
>
> mysql> show indexes from File;
> +---++--+--+-+---+-+--++--++-+
> | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation
> |
On 11/07/15 11:18, Jari Fredriksson wrote:
> On 5.10.2015 20.32, Stephen Thompson wrote:
>>
>> mysql> show indexes from File;
>> +---++--+--+-+---+-+--++--++-+
>> | Table | Non_unique |
Yes, we've tuned the database a number of times and believe it's the
best we can do.
On 10/14/15 3:17 AM, Alex Domoradov wrote:
> The same thing as for me. I'm trying do not use mysql shipped with
> CentOS 6 and replace it with Percona 5.5/5.6 whenever it's possible
>
> 2 Stephen
> Have you
On 14/10/15 10:49, Uwe Schuerkamp wrote:
>
> you might also try giving MariaDB a shot which has been performing
> fine as a drop-in mysql replacement for us for the last few years with
> catalogs of similar size.
>
Speaking as a mysql affectionado and one who's using both DBs regularly
in
On Mon, Oct 12, 2015 at 07:33:46AM -0700, Stephen Thompson wrote:
>
> update...
>
> After adding more RAM, we are back to getting a about 3 queries a day
> that run longer than 15 minutes. This was our norm before upgrading.
> No job errors since the first couple days from this month (Oct).
The same thing as for me. I'm trying do not use mysql shipped with CentOS 6
and replace it with Percona 5.5/5.6 whenever it's possible
2 Stephen
Have you tried to run mysqltunner?
On Mon, Oct 12, 2015 at 07:33:46AM -0700, Stephen Thompson wrote:
> >
> > update...
> >
> > After adding more RAM,
update...
After adding more RAM, we are back to getting a about 3 queries a day
that run longer than 15 minutes. This was our norm before upgrading.
No job errors since the first couple days from this month (Oct). Not
sure if the reduction in long running queries was actually from
Eric,
I appreciate all the feedback. We went through a few iterations of
tuning awhile back and have not generally had any significant issues
over the years with database responsiveness.
Back to the original post, it's only been since our upgrade that we
started having database lock
Hello Stephen,
Le 05. 10. 15 19:17, Stephen Thompson a écrit :
>
> Eric,
>
> Thanks for the reply.
>
> I've heard the postgres recommendation a fair number of times. A couple
> years back, we setup a parallel instance but even after tuning still
> wound up with _worse_ performance than with
Thanks Ana!
Something such as
SELECT ClientId, SUM(JobFiles) AS NB FROM Job GROUP BY ClientId ORDER BY
NB DESC;
should also do the trick a bit more faster ;-)
Best Regards,
Eric
Le 07. 10. 15 15:23, Ana Emília M. Arruda a écrit :
> Hello Stephen,
>
> On Mon, Oct 5, 2015 at 2:17 PM, Stephen
mysql> SELECT ClientId, SUM(JobFiles) AS NB FROM Job WHERE PurgedFiles=0
GROUP BY ClientId ORDER BY NB DESC;
+--++
| ClientId | NB |
+--++
| 10 | 2239841562 |
| 68 | 636728984 |
| 157 | 291057196 |
| 198 | 138969710 |
|
Hello Eric!
Thank you. I thought that you were looking for the number of filename per
Client that had not been pruned yet :).
Best regards,
Ana
On Fri, Oct 9, 2015 at 3:17 AM, Eric Bollengier <
eric.bolleng...@baculasystems.com> wrote:
> Thanks Ana!
>
> Something such as
>
> SELECT ClientId,
Very good point Ana,
So, you might want to add to the query "AND PurgedFiles = 0"
Thanks,
Eric
Le 09. 10. 15 14:24, Ana Emília M. Arruda a écrit :
> Hello Eric!
>
> Thank you. I thought that you were looking for the number of filename
> per Client that had not been pruned yet :).
>
> Best
Hello Stephen,
On Mon, Oct 5, 2015 at 2:17 PM, Stephen Thompson <
step...@seismo.berkeley.edu> wrote:
>
> Regarding:
> > Would be nice also if you can give the number of Filename per Client
> (from the job table).
>
> Do you have a sample SQL to retrieve this stat?
>
select Client.Name,
Thanks for the help. Though, this is giving me a syntax error.
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'select Client.Name, count(distinct
Filename.FilenameId) from Client,
Hello Stephen,
I cheked that "select count(distinct) is available in MySQL 5.X versions.
Could you try the bellow?
mysql> select count(distinct MediaId) from Media;
+-+
| count(distinct MediaId) |
+-+
| 60 |
On 10/05/15 13:17, Stephen Thompson wrote:
> At any rate, the only thing that's changed was the upgrade from 7.0.5 to
> 7.2.0. The table involved is definitely the File table. We do have
> jobs with 20-30 million records, so those jobs can be slow when it comes
> time for attribute insertion
mysql> show indexes from File;
+---++--+--+-+---+-+--++--++-+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation
| Cardinality | Sub_part | Packed | Null | Index_type
Nevermind about question concerning Snapshot table. I see what happened
there.
On 10/05/2015 10:17 AM, Stephen Thompson wrote:
>
> Eric,
>
> Thanks for the reply.
>
> I've heard the postgres recommendation a fair number of times. A couple
> years back, we setup a parallel instance but even
Phil,
Good question. I vaguely recollect doing that a few years back, but I
don't immediately see any additional indexing. Where can I reference
what the default indexes are supposed to be?
thanks,
Stephen
On 10/05/2015 10:28 AM, Phil Stracchino wrote:
> On 10/05/15 13:17, Stephen
On 10/05/15 13:32, Stephen Thompson wrote:
> show indexes from File;
OK, you have all of the important indexes I have. I actually have one
more but it's redundant and should probably be dropped.
--
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
p...@co.ordinate.org
On Saturday 2015-10-03 14:32:04 Phil Stracchino wrote:
> For what it's worth, I am running Bacula 7.2.0 against MySQL
5.6.27 and
> I am experiencing no Bacula performance problems.
Phil, what storage engine are you using, myisam or innodb?
Stephen is using innodb. This might be the important
On 10/05/15 04:37, Josip Deanovic wrote:
> On Saturday 2015-10-03 14:32:04 Phil Stracchino wrote:
>> For what it's worth, I am running Bacula 7.2.0 against MySQL 5.6.27 and
>> I am experiencing no Bacula performance problems.
>
> Phil, what storage engine are you using, myisam or innodb?
>
On 10/05/15 06:54, Phil Stracchino wrote:
> On 10/05/15 04:37, Josip Deanovic wrote:
>> On Saturday 2015-10-03 14:32:04 Phil Stracchino wrote:
>>> For what it's worth, I am running Bacula 7.2.0 against MySQL 5.6.27 and
>>> I am experiencing no Bacula performance problems.
>>
>> Phil, what storage
Eric,
Thanks for the reply.
I've heard the postgres recommendation a fair number of times. A couple
years back, we setup a parallel instance but even after tuning still
wound up with _worse_ performance than with mysql. I could not figure
out what to attribute this to (because it was in
Hello Stephen,
On 10/03/2015 12:00 AM, Stephen Thompson wrote:
>
>
> All,
>
> I believe I'm having mysql database issues since upgrading to 7.2 (from
> 7.0.2). I run mysql innodb with 900Gb database that's largely the File
> table.
For large catalog, we usually advise to use PostgreSQL
All,
I believe I'm having mysql database issues since upgrading to 7.2 (from
7.0.2). I run mysql innodb with 900Gb database that's largely the File
table.
Since upgrading, I lose a few jobs a night due to database locking
timeouts, which I have set to 3600. I also log slow queries.
It
28 matches
Mail list logo
