Re: [Maria-discuss] MariaDB server horribly slow on start

[jocelyn fournier]

Perhaps you should increase its side then, anyway PMM is great to see what’s a 
good setting! :)


> Le 27 juil. 2022 à 15:31, Cédric Counotte  a 
> écrit :
> 
> Considering the binlog files are 1GB and I get 144 of them per day, doesn't 
> it mean that my 1GB log file holds about 10 minutes only of logs?
>  
> I suppose I should make it 6GB then to follow that article 
>  
> Still using galera, I assume crashes are compensated by another node and 1GB 
> of log should be enough for now.
>  
> FWIW Servers are using NVMe from OVH, 4 of them are on ovh gen 2 NVMe 
> (whatever it means).
>  
>  
> -----Message d'origine-
> De : jocelyn fournier  
> Envoyé : mercredi 27 juillet 2022 15:26
> À : Gordan Bobic 
> Cc : Cédric Counotte ; Marko Mäkelä 
> ; Mailing-List mariadb 
> ; Pierre LAFON 
> Objet : Re: [Maria-discuss] MariaDB server horribly slow on start
>  
> It’s not that tiny, this article is a bit old, but still valid:
>  
> https://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/
>  
> If you don’t need a big redo log, reduce its side to avoid slow crash recovery
>  
> > Le 27 juil. 2022 à 15:23, Gordan Bobic  a écrit :
> > 
> > 10.5+ only uses a single log file, so that is 1x1GB.
> > And 1GB is tiny, IMO it should be a default these days.
> > I would only even consider something smaller if I was running on an
> > older Raspberry Pi or something similarly constrained.
> > 
> > 
> > On Wed, Jul 27, 2022 at 4:11 PM jocelyn fournier 
> >  wrote:
> >> 
> >> Hi Cédric!
> >> 
> >> Just to be sure, do you really need the 2x 1G log_file_size ?
> >> 
> >> BR,
> >>  Jocelyn Fournier
> >> 
> >>> Le 27 juil. 2022 à 14:36, Cédric Counotte  a 
> >>> écrit :
> >>> 
> >>> Reading this: https://jira.mariadb.org/browse/MDEV-27295
> >>> 
> >>> It's quite unclear when it is fixed or reverted.
> >>> 
> >>> That said I read that the following setting might fix it:
> >>>  SET GLOBAL innodb_max_dirty_pages_pct_lwm=0.001;
> >>> 
> >>> Is that correct and should I try that and see if that helps?
> >>> 
> >>> 
> >>> -Message d'origine-
> >>> De : Gordan Bobic  Envoyé : mercredi 27
> >>> juillet 2022 14:29 À : Marko Mäkelä  Cc :
> >>> Cédric Counotte ; Mailing-List mariadb
> >>> 
> >>> Objet : Re: [Maria-discuss] MariaDB server horribly slow on start
> >>> 
> >>> On Wed, Jul 27, 2022 at 3:08 PM Marko Mäkelä  
> >>> wrote:
> >>>> 
> >>>> On Wed, Jul 27, 2022 at 2:48 PM Gordan Bobic  
> >>>> wrote:
> >>>>> 
> >>>>> There is no supported downgrade path other than logical dump+restore.
> >>>>> There are also no packages built for distros where the major version is 
> >>>>> older than what ships with the distro.
> >>>>> 
> >>>>> Since your queries seem to end up stuck in commit stage, it could be 
> >>>>> related to redo log flushing, which behaves very erratically on 10.5+. 
> >>>>> If it leaves the log to fill up to 90% and the state transfer hits, it 
> >>>>> could be that with the checkpoint age already high, there just isn't 
> >>>>> enough headroom to avoid a massive stall. Purely guessing here without 
> >>>>> any telemetry.
> >>>> 
> >>>> I think that you may refer to InnoDB page flushing. There was some
> >>>> misunderstanding around that, and indeed some partly unintended or
> >>>> uninformed changes in behaviour (in 10.5.7 and 10.5.8) that were
> >>>> reverted later. It could be useful to read 
> >>>> https://jira.mariadb.org/browse/MDEV-27295.
> >>> 
> >>> What version was it reverted in?
> >>> I am still seeing the errant redo log flushing behaviour in 10.5.15.
> >>> It looks like no flushing happens until the hwm is reached at about
> >>> 85% full. It then tries to commit everything down to the lwm. And
> >>> inbetween it doesn't do anything, even while everything is idle and
> >>> it should be running down the 
> >>> ___
> >>> Mailing list: https://launchpad.net/~maria-discuss
> >>> Post to : maria-discuss@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~maria-discuss
> >>> More help   : https://help.launchpad.net/ListHelp
> >> 


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] MariaDB server horribly slow on start

[jocelyn fournier]

It’s not that tiny, this article is a bit old, but still valid:

https://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

If you don’t need a big redo log, reduce its side to avoid slow crash recovery

> Le 27 juil. 2022 à 15:23, Gordan Bobic  a écrit :
> 
> 10.5+ only uses a single log file, so that is 1x1GB.
> And 1GB is tiny, IMO it should be a default these days.
> I would only even consider something smaller if I was running on an
> older Raspberry Pi or something similarly constrained.
> 
> 
> On Wed, Jul 27, 2022 at 4:11 PM jocelyn fournier
>  wrote:
>> 
>> Hi Cédric!
>> 
>> Just to be sure, do you really need the 2x 1G log_file_size ?
>> 
>> BR,
>>  Jocelyn Fournier
>> 
>>> Le 27 juil. 2022 à 14:36, Cédric Counotte  a 
>>> écrit :
>>> 
>>> Reading this: https://jira.mariadb.org/browse/MDEV-27295
>>> 
>>> It's quite unclear when it is fixed or reverted.
>>> 
>>> That said I read that the following setting might fix it:
>>>  SET GLOBAL innodb_max_dirty_pages_pct_lwm=0.001;
>>> 
>>> Is that correct and should I try that and see if that helps?
>>> 
>>> 
>>> -Message d'origine-
>>> De : Gordan Bobic 
>>> Envoyé : mercredi 27 juillet 2022 14:29
>>> À : Marko Mäkelä 
>>> Cc : Cédric Counotte ; Mailing-List mariadb 
>>> 
>>> Objet : Re: [Maria-discuss] MariaDB server horribly slow on start
>>> 
>>> On Wed, Jul 27, 2022 at 3:08 PM Marko Mäkelä  
>>> wrote:
>>>> 
>>>> On Wed, Jul 27, 2022 at 2:48 PM Gordan Bobic  
>>>> wrote:
>>>>> 
>>>>> There is no supported downgrade path other than logical dump+restore.
>>>>> There are also no packages built for distros where the major version is 
>>>>> older than what ships with the distro.
>>>>> 
>>>>> Since your queries seem to end up stuck in commit stage, it could be 
>>>>> related to redo log flushing, which behaves very erratically on 10.5+. If 
>>>>> it leaves the log to fill up to 90% and the state transfer hits, it could 
>>>>> be that with the checkpoint age already high, there just isn't enough 
>>>>> headroom to avoid a massive stall. Purely guessing here without any 
>>>>> telemetry.
>>>> 
>>>> I think that you may refer to InnoDB page flushing. There was some
>>>> misunderstanding around that, and indeed some partly unintended or
>>>> uninformed changes in behaviour (in 10.5.7 and 10.5.8) that were
>>>> reverted later. It could be useful to read
>>>> https://jira.mariadb.org/browse/MDEV-27295.
>>> 
>>> What version was it reverted in?
>>> I am still seeing the errant redo log flushing behaviour in 10.5.15.
>>> It looks like no flushing happens until the hwm is reached at about 85% 
>>> full. It then tries to commit everything down to the lwm. And inbetween it 
>>> doesn't do anything, even while everything is idle and it should be running 
>>> down the
>>> ___
>>> Mailing list: https://launchpad.net/~maria-discuss
>>> Post to : maria-discuss@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~maria-discuss
>>> More help   : https://help.launchpad.net/ListHelp
>> 


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] MariaDB server horribly slow on start

[jocelyn fournier]

Hi Cédric!

Just to be sure, do you really need the 2x 1G log_file_size ?

BR,
  Jocelyn Fournier

> Le 27 juil. 2022 à 14:36, Cédric Counotte  a 
> écrit :
> 
> Reading this: https://jira.mariadb.org/browse/MDEV-27295
> 
> It's quite unclear when it is fixed or reverted.
> 
> That said I read that the following setting might fix it:
>   SET GLOBAL innodb_max_dirty_pages_pct_lwm=0.001;
> 
> Is that correct and should I try that and see if that helps?
> 
> 
> -Message d'origine-
> De : Gordan Bobic  
> Envoyé : mercredi 27 juillet 2022 14:29
> À : Marko Mäkelä 
> Cc : Cédric Counotte ; Mailing-List mariadb 
> 
> Objet : Re: [Maria-discuss] MariaDB server horribly slow on start
> 
> On Wed, Jul 27, 2022 at 3:08 PM Marko Mäkelä  wrote:
>> 
>> On Wed, Jul 27, 2022 at 2:48 PM Gordan Bobic  wrote:
>>> 
>>> There is no supported downgrade path other than logical dump+restore.
>>> There are also no packages built for distros where the major version is 
>>> older than what ships with the distro.
>>> 
>>> Since your queries seem to end up stuck in commit stage, it could be 
>>> related to redo log flushing, which behaves very erratically on 10.5+. If 
>>> it leaves the log to fill up to 90% and the state transfer hits, it could 
>>> be that with the checkpoint age already high, there just isn't enough 
>>> headroom to avoid a massive stall. Purely guessing here without any 
>>> telemetry.
>> 
>> I think that you may refer to InnoDB page flushing. There was some 
>> misunderstanding around that, and indeed some partly unintended or 
>> uninformed changes in behaviour (in 10.5.7 and 10.5.8) that were 
>> reverted later. It could be useful to read 
>> https://jira.mariadb.org/browse/MDEV-27295.
> 
> What version was it reverted in?
> I am still seeing the errant redo log flushing behaviour in 10.5.15.
> It looks like no flushing happens until the hwm is reached at about 85% full. 
> It then tries to commit everything down to the lwm. And inbetween it doesn't 
> do anything, even while everything is idle and it should be running down the
> ___
> Mailing list: https://launchpad.net/~maria-discuss
> Post to : maria-discuss@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Rocks, toku and some performance considerations.

[jocelyn fournier]

Hi!

> Le 17 sept. 2019 à 16:07, pslawek83  a écrit :
> 
> Hi Everyone, just some quick follow up on this topic about MyRocks i started. 
> It seems that there are some issues with debian9 and cfq scheduler when using 
> rocks. Tested this on VM, not sure how virtualization is affecting this. 
> Rocks is easily able to saturate 3 cpu cores with I/O wait and I/O throughput 
> is very low in this config, even on fast SSD.
> 
> This gets much better after switching to noop/deadline and best is to switch 
> to Debian10 with mq-deadline. Then I/O wait drops to 0% and performance 
> improves a lot.

Just curious, is mq-deadline faster than none, even on fast SSD / NVME?

Thanks!
  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Rocks, toku and some performance considerations.

[jocelyn fournier]

Hi!

It seems MariaDB is dropping TokuDB in 10.5.
See https://jira.mariadb.org/browse/MDEV-19780

BR,
  Jocelyn Fournier


> Le 12 sept. 2019 à 14:31, pslawek83  a écrit :
> 
> Hi Everyone, i got recently interested in rocks and have a couple of 
> questions if anyone else is doing/done some migrations to this engine:
> 
> 1. Noticed that compared to toku - I/O overhead for range SELECT's with cold 
> caches is much higher, especially on vmware I/O utilization (WAit) goes over 
> 50% of available CPU on standard cfq scheduler and 4 cores. Changing it to 
> noop helps and utilization drops around tenfold to 5-10%. It doesn't matter 
> if we're doing full table scan or range scan with index. Basically i thought 
> for LSM lists there'll be almost no IOPs and I/O utilization will be 
> non-existing because all you need to do is reading a long, continuous block 
> on disk (we're using SSDs). Any reason for that or am i doing something 
> incorrectly? (default config + 6gb rocks key cache) Any reason it's working 
> so badly with cfq and much better with noop?
> 
> 2. Now with keys 100% cached - rocks is still around 2-3 times slower than 
> toku for range scans, and even considerably slower than innodb. From what i 
> understand keycache for rocks stores uncompressed keys, so is there some 
> performance issue eg. with copying data from global keycache to local storage 
> and is it going to be fixed or that's something related to how rocks works 
> internally and there's no way of making it work better in the future?
> 
> 3. In general it was a huge surprise that toku which is (at least it seems) 
> so complicated to implement, and is based on very complex variation of b tree 
> is having so much better read performance and so much better i/o 
> characteristics... than "simple" (from what i understand) sorted list, which 
> could be probably just read in bulk like a simple log file...
> 
> 4. I found some info that having rocks databases which are over 100gb in size 
> is not recommended (and it seems this is tiny... we were able to work with 
> myisam tables which were close to 2TB). Also merging data could make the DB 
> to end up being twice as big for some time. Are there any plans of 
> implementing one-file-per-table like for inno?
> 
> 5. What's the future of toku? I understand that percona is considering 
> dropping it, will you take developement if that will happen or are you going 
> to obsolete it and focus on rocks? From what i saw it seems that rocks and 
> toku have totally different characteristics. So rocks is decent for 
> point-reads (seems faster than toku when number of row reads is low)... and 
> it seems to require less memory than toku, but for range scans it isn't going 
> nowhere close. So both engines may have completely different use cases (eg. 
> toku is great for long running statistical queries and servers with a lot of 
> memory)
> 
> Thanks
> ___
> Mailing list: https://launchpad.net/~maria-discuss
> Post to : maria-discuss@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] ERROR 1071 with mysql_upgrade

[jocelyn fournier]

Le 17 juil. 2019 à 11:22, Erik Cederstrand  a écrit :
> 
> Thanks!
> 
> I couldn't find the mysql_fix_privilege_tables.sql installed anywhere on my 
> system, so I ended up patching mysql_upgrade to print the SQL commands it's 
> executing. There are ca. 200 commands executed at once, so it took a while to 
> pinpoint the failing statement. It would be cool if triple-verbose 
> mysql_upgrade could print the exact statement that matches the error that it 
> prints in 
> https://github.com/MariaDB/server/blob/9a7d96e8326377b92406c09fdcb8bd60c45f901c/client/mysql_upgrade.c#L1063
> 
> Anyway, the failing query is:
> 
> alter table innodb_index_stats modify last_update timestamp not null default 
> current_timestamp on update current_timestamp, modify table_name varchar(199);
> 
> which throws "Specified key was too long; max key length is 1000 bytes".
> 
> Currently, my innodb_index_stats table is defined as:
> 
> CREATE TABLE `innodb_index_stats` (
>  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
>  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
>  `index_name` varchar(64) COLLATE utf8_bin NOT NULL,
>  `last_update` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE 
> current_timestamp(),
>  `stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
>  `stat_value` bigint(20) unsigned NOT NULL,
>  `sample_size` bigint(20) unsigned DEFAULT NULL,
>  `stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
>  PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;
> 
> Does that ring a bell?


Hi Erik!

It seems this table should be in InnoDB format, not MyISAM (same for 
innodb_table_stats).

HTH,
  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] MariaDB threads optimalization

[jocelyn fournier]

Hi!

> Le 7 févr. 2018 à 11:34, Reindl Harald <h.rei...@thelounge.net> a écrit :
> 
> 
> 
> Am 07.02.2018 um 11:28 schrieb Sergey Vojtovich:
>> I'm afraid query cache doesn't scale well. Try turning it off
> 
> well, the question is why on a read-bound workload because there is no valid 
> reason that it locks reads for other threads
> 
> and no remove query-cache like MySQL 8.0 is no solution because when you have 
> a few terrible optimized queries on your server which takes seconds to run 
> query-cache will save your ass while you can (and we did) write known fast 
> queries with "select SQL_NO_CACHE" to get the locking relaxed

You could also take a look at software like https://www.heimdalldata.com which 
tries to replace the query cache (and much more BTW)

HTH,

--
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] TokuDB performance hit after 10.0.25

[jocelyn fournier]

Hi Alessandro!


10.0.31 should be affected by https://jira.percona.com/browse/TDB-35 , 
do you think it could be related to your issue?



HTH,

Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications

Le 24/07/2017 à 17:41, Alessandro Ren a écrit :


 Even if a change the order by and the query to include all 3 fields 
on the index, it still selects the PRIMARY key to query the table.


   Do you think this is a bug?

   Tks.


On Mon, Jul 24, 2017 at 11:34 AM, Alessandro Ren <dirty@gmail.com 
<mailto:dirty@gmail.com>> wrote:



   Once cached, the query returns in 0s.

   The force index solved the problem:
MariaDB 10.0.31
 Force index:13 rows in set (2.31 sec)
 No force: 13 rows in set (12.97 sec)

   MariDB 10.0.25:
 Force index: 13 rows in set (1.46 sec)
 No force: 13 rows in set (1.70 sec)


Explains per version follows:

10.0.25
MariaDB [opperf]> show variables like '%version%';
+-+--+
| Variable_name   | Value|
+-+--+
| innodb_version  | 5.6.29-76.2  |
| protocol_version| 10   |
| slave_type_conversions  |  |
| tokudb_version  | 5.6.26-74.0  |
| version | 10.0.25-MariaDB  |
| version_comment | MariaDB Server   |
| version_compile_machine | x86_64   |
| version_compile_os  | Linux|
| version_malloc_library  | bundled jemalloc |
+-+--+
9 rows in set (0.09 sec)


+--+-+--+---+++-+--+---+--+
| id   | select_type | table| type  | possible_keys  
   | key| key_len | ref  | rows  | Extra  
   |


+--+-+--+---+++-+--+---+--+
|1 | SIMPLE  | service_perf_651 | range |
PRIMARY,service_perf_1_idx | service_perf_1_idx | 16| NULL |
17880 | Using where; Using temporary; Using filesort |

+--+-+--+---+++-+--+---+--+


10.0.31

MariaDB [opperf]> show variables like '%version%';
+-+--+
| Variable_name   | Value|
+-+--+
| innodb_version  | 5.6.36-82.0  |
| protocol_version| 10   |
| slave_type_conversions  |  |
| tokudb_version  | 5.6.36-82.0  |
| version | 10.0.31-MariaDB  |
| version_comment | MariaDB Server   |
| version_compile_machine | x86_64   |
| version_compile_os  | Linux|
| version_malloc_library  | bundled jemalloc |
+-+--+
9 rows in set (0.11 sec)



+--+-+--+---++-+-+--+--+--+
| id   | select_type | table| type  | possible_keys  
   | key | key_len | ref  | rows | Extra|


+--+-+--+---++-+-+--+--+--+
|1 | SIMPLE  | service_perf_651 | range |
PRIMARY,service_perf_1_idx | PRIMARY | 16  | NULL |1 |
Using where; Using temporary; Using filesort |

+--+-+--+---++-+-+--+--+--+


tks.





On Mon, Jul 24, 2017 at 11:10 AM, Reinis Rozitis <r...@roze.lv
<mailto:r...@roze.lv>> wrote:

MariaDB 10.0.25 - 13 rows in set (1.67 sec)
MariaDB 10.0.31 - 13 rows in set (29.06 sec)


+--+-+--+---++-+-+--+--+--+
| id   | select_type | table| type  |
possible_keys | key | key_len | ref  | rows | Extra |

+--+-+--+---++-+-+--+--+--+
|1 | SIMPLE  | service_perf_651 | range |

Re: [Maria-discuss] 10.2.7 and xtradb in changelog

[jocelyn fournier]

Hi Sergei, Reindl,

Le 13/07/2017 à 12:35, Sergei Golubchik a écrit :

Hi, Reindl!

On Jul 13, Reindl Harald wrote:

Am 13.07.2017 um 11:55 schrieb Sergei Golubchik:

On Jul 13, Reindl Harald wrote:

https://mariadb.com/kb/en/mariadb/mariadb-1027-changelog/

i thought xtradb is gone in 10.2.x

is it back now with 10.2.7 or is the changelog a random wild mix of
commits with no context to the version of the release?

Neither. Changelog is generated as "all commits that are present in the
10.2.7 history, but were not present in the 10.2.6 history". And all
commits in 10.1 are merged into 10.2 eventually (because many 10.1
bugfixes apply to 10.2 too).

So whatever was done to XtraDB in 10.1 it will be part of 10.2 revision
history, even though XtraDB itself is disabled in 10.2 (and does not
even compile there).

I agree that it's confusing, but what can we do? Manually filter out all
commits that contain the string "xtradb" from the changelog?

well, at least some filters make sense because things like "Update
xtradb and innodb version to 5.6.36" are pure nonsense when innodb in
10.2 AFAIK is 5.7 and so the complete changelog feels very useless and
instead beeing helpful it spreads doubt how that whole stuff works at
all when random pieces seems to get merged bewteen versions or at least
the changelog says so

Okay. https://jira.mariadb.org/browse/MDEV-13312


Perhaps it would make sense to squash merges from the 10.1 branch into 
one commit, and make a "merge 10.1.x branch" + url reference to the 
changelog of 10.1.x in the commit message?




  Jocelyn

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] Best place to report RocksDB issues?

[jocelyn fournier]

Hi all, Mark,


What's the best place to report RocksDB issues? MariaDB/Percona JIRA, 
https://github.com/facebook/rocksdb/issues , any other places?



Thanks!

  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Deadlocks in R/W phase of Sysbench

[jocelyn fournier]

Hi John,


It seems you have

autocommit = 0

in your my.cnf


  Jocelyn


Le 09/06/2017 à 17:46, J. Cassidy a écrit :

Stephane,

all of my directories, logs, spaces, tables etc. are in RAM. During 
the course of the benchmark there in ZERO I/O

which is my intention.

Here is a snippet from the MariaDB KB -


  autocommit

By default, MariaDB runs with autocommit 
 mode 
enabled. This means that as soon as you execute a statement that 
updates (modifies) a table, MariaDB stores the update on disk to make 
it permanent. To disable autocommit mode, use the following statement:


SET autocommit=0;
So it would seem that I am running with autocommit enabled.

Regards,


JC

Re,
Yep get this but just that io a supposed to be fast but still have to 
hit FS moved from PB to redo log to tblspace
In a perfect fast world all layer should have equal ressources so no 
reasons not giving as many threads to write io vs doing the work 
itself of modifying pages.
Disabling auto commit with sysbench is suspicious and intersting : 
never question myself on this topic before ?

/svar

Stéphane Varoqui, Senior Consultant

Phone: +33 695-926-401, skype: svaroqui
http://www.mariadb.com

Le 9 juin 2017 à 16:47, J. Cassidy s...@jdcassidy.eu> a écrit :
Salut Stephane,

I/O does not enter into the equation, the database is in memory (RAM).


Regards,


JC

Hello,
What IO scheduler are you using for FS and witch one ?
deadline or loop is a must do. Also mounting with noatime can help for 
write

Would you try such settings i found to make a difference
autocommit = 1
innodb_adaptive_hash_index=0
innodb_max_dirty_page_pct=20
innodb_write_io_threads =64
innodb_log_file_size = 1024M
innodb_log_file_in_group = 4
innodb_log_files_in_group = 4
innodb_thread_concurrency = 0
innodb_purge_threads = 8
innodb_change_buffering=none
innodb_open_files = 16384
innodb_file_per_table=1
innodb_autoinc_lock_mode = 2
And comment
# innodb_lru_scan_depth = 4096

Stéphane Varoqui, Senior Consultant

Phone: +33 695-926-401, skype: svaroqui
http://www.mariadb.com 
Le 9 juin 2017 à 16:22, J. Cassidy s...@jdcassidy.eu 
> a écrit :

Mark,


still scratching head...


Regards,


JC

Thanks. I was hoping there was an easy fix if you did something like 
used serializable isolation, but you haven't done that.
On Fri, Jun 9, 2017 at 12:27 AM, J. Cassidy s...@jdcassidy.eu 
> wrote:


All,


as discussed yesterday, here is my setup and configuration.


*
16 VCPU 64GB Memory, DB size 12 GB (In RAM), MariaDB 10.1.24*
Single Image. No clustering or outside network interaction *
SuSE SLES 12 SP2 using a 4.4.49-92 kernel *
*
### Sysbench R/W - 64 Threads

sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 64
Report intermediate results every 2 second(s)
Initializing random number generator from seed (42).


Threads started!

[ 2s] threads: 64, tps: 51141.62, reads: 717023.15, writes: 204757.48, 
response time: 4.72ms (99%), errors: 54.00, reconnects: 0.00
[ 4s] threads: 64, tps: 47938.19, reads: 671195.72, writes: 191759.28, 
response time: 4.65ms (99%), errors: 5.00, reconnects: 0.00
[ 6s] threads: 64, tps: 46908.41, reads: 656790.25, writes: 187640.64, 
response time: 4.65ms (99%), errors: 2.50, reconnects: 0.00
[ 8s] threads: 64, tps: 45940.12, reads: 643191.64, writes: 183781.47, 
response time: 4.44ms (99%), errors: 3.00, reconnects: 0.00
[ 10s] threads: 64, tps: 45789.91, reads: 641083.20, writes: 
183161.13, response time: 4.77ms (99%), errors: 2.00, reconnects: 0.00
[ 12s] threads: 64, tps: 45408.37, reads: 635825.16, writes: 
181672.97, response time: 4.80ms (99%), errors: 1.50, reconnects: 0.00
[ 14s] threads: 64, tps: 44319.93, reads: 620440.07, writes: 
177262.74, response time: 4.50ms (99%), errors: 0.50, reconnects: 0.00
[ 16s] threads: 64, tps: 44634.78, reads: 624843.97, writes: 
178523.13, response time: 4.71ms (99%), errors: 0.50, reconnects: 0.00

.
.
.
[ 572s] threads: 64, tps: 24980.71, reads: 349707.39, writes: 
99924.32, response time: 5.92ms (99%), errors: 0.00, reconnects: 0.00
[ 574s] threads: 64, tps: 25337.03, reads: 354796.98, writes: 
101355.13, response time: 6.19ms (99%), errors: 0.00, reconnects: 0.00
[ 576s] threads: 64, tps: 25196.31, reads: 352683.33, writes: 
100777.24, response time: 6.49ms (99%), errors: 0.00, reconnects: 0.00
[ 578s] threads: 64, tps: 25235.61, reads: 353317.05, writes: 
100941.94, response time: 5.94ms (99%), errors: 0.00, reconnects: 0.00
[ 580s] threads: 64, tps: 25241.11, reads: 353395.59, writes: 
100956.96, response time: 6.09ms (99%), errors: 0.00, reconnects: 0.00
[ 582s] threads: 64, tps: 25146.18, reads: 352056.04, writes: 
100599.73, response time: 5.96ms (99%), errors: 0.00, 

Re: [Maria-discuss] thank you for getting MyRocks into MariaDB 10.2

[jocelyn fournier]

Hi Mark!


Thanks for your hard work on MyRocks too :) Do you know if TokuDB 
hotbackup works for MyRocks? Or if there's an easy way to hotbackup with 
both TokuDB and MyRocks tables? I'm planning to convert a few TokuDB 
tables to test MyRocks in production...



  Jocelyn


Le 23/05/2017 à 19:40, MARK CALLAGHAN a écrit :

I look forward to trying it out.

--
Mark Callaghan
mdcal...@gmail.com 


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Are some MyISAM settings used for Aria

[jocelyn fournier]

Le 24/04/2017 à 23:05, Sales a écrit :
On Apr 24, 2017, at 3:04 PM, jocelyn fournier 
<jocelyn.fourn...@gmail.com <mailto:jocelyn.fourn...@gmail.com>> wrote:




You should search read_rnd_buff_size, it's used in sql/records.cc 
<http://records.cc> to compute the size of the cache_records in the 
READ_RECORD struct.





But, the original link implied use with mrr, however, this page:

https://mariadb.com/kb/en/mariadb/multi-range-read-optimization/

Says:

"MariaDB uses mrr_buffer_size as a limit of MRR buffer size 
for range access, while MySQL uses read_rnd_buffer_size.”


So, I guess it is still used, but, not for mrr.

Yes it's not anymore mrr specific.
The doc from the MariaDB source code is great to understand what it does :

rr_from_cache:
--
  This is a special variant of rr_from_tempfile that can be used for
  handlers that is not using the HA_FAST_KEY_READ table flag. Instead
  of reading the references one by one from the temporary file it reads
  a set of them, sorts them and reads all of them into a buffer which
  is then used for a number of subsequent calls to rr_from_cache.
  It is only used for SELECT queries and a number of other conditions
  on table size.

and

  init_read_record is used to scan by using a number of different methods.
  Which method to use is set-up in this call so that later calls to
  the info->read_record will call the appropriate method using a function
  pointer.

  There are five methods that relate completely to the sort function
  filesort. The result of a filesort is retrieved using read_record
  calls. The other two methods are used for normal table access.

  The filesort will produce references to the records sorted, these
  references can be stored in memory or in a temporary file.

  The temporary file is normally used when the references doesn't fit into
  a properly sized memory buffer. For most small queries the references
  are stored in the memory buffer.


https://raw.githubusercontent.com/MariaDB/server/bb2c1a52c61706dde8c525a8887f2d364c0db1eb/sql/records.cc


  Jocelyn



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Are some MyISAM settings used for Aria

[jocelyn fournier]

Hi Federico!


Le 24/04/2017 à 18:56, Sales a écrit :

On Apr 24, 2017, at 8:14 AM, Federico Razzoli  wrote:

Hi Jocelyn,

The article you linked is quite old, so I wanted to check the source code to 
find if something changed.
I didn't investigate much but I searched in MariaDB's master branch via GitHub. 
The search strings were 'read_rnd_buffer_size' and 'read-rnd-buffer-size'. I 
found nothing except for some test files and the variable initialization at 
server startup.
I repeated the same searches in MySQL master branch, and again, I found only 
tests and initialization.
Can you explain this? The variable is unused now?
You should search read_rnd_buff_size, it's used in sql/records.cc to 
compute the size of the cache_records in the READ_RECORD struct.



  Jocelyn

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Are some MyISAM settings used for Aria

[jocelyn fournier]

Hi Steve,

Le 24 avr. 2017 3:28 AM, "Sales" <i...@smallbusinessconsultingexperts.com>
a écrit :


On Apr 23, 2017, at 4:12 PM, jocelyn fournier <jocelyn.fourn...@gmail.com>
wrote:

Hi Steve,


Le 23/04/2017 à 19:32, Sales a écrit :

On our system, Mariadb 10.1.22, with aria_used_for_temp_tables = ON, we
have a set of MyISAM settings carried over from an earlier setup. Those
settings are:

key_buffer_size=256M
myisam_sort_buffer_size = 64M
join_buffer_size=512K
bulk_insert_buffer_size=512M
read_rnd_buffer_size = 1M

read_rnd_buffer_size and join_buffer_size are not MyISAM specific settings,
did you try to modify/not modify only those ones ?

HTH,
 Jocelyn


Really? So, the doc is wrong?

https://mariadb.com/kb/en/mariadb/server-system-variables/#read_rnd_buffer_
size

Says, MyISAM. So, are you saying that is mistaken? If so, that would make
sense


At least according to
https://www.percona.com/blog/2007/07/24/what-exactly-is-read_rnd_buffer_size/
it's not.
BTW it has been updated in the mysql manual to mention it optimizes mrr for
any engine :
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_read_rnd_buffer_size

MariaDB KB would need an update as well.


  Jocelyn
___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] Enabling Github integration with JIRA

[jocelyn fournier]

Hi all,


Currently there's no way when a JIRA ticket is closed to have a direct 
access to the associated commits in Github.


GitHub integration with JIRA is available, and quite easy to configure, 
so it would be great to have it enabled on MariaDB Server.


Do you think it's possible?


Thanks!

--
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Critical Update for CVE-2016-6662

[jocelyn fournier]

Hi Reindl,

Le 12/09/2016 à 23:18, Reindl Harald a écrit :



Am 12.09.2016 um 22:53 schrieb Reinis Rozitis:
how should that be possible from a daemon runnign with a restricted 
user?


Some distros run mysqld_safe under root which also reads the *.cnf files
(cowered in advisory)


mysqld_safe != mysqld != something a client interacts with
which distribution out there is running *mysqld* as root?



The mysqld flaw (running as mysql) allows changes to the my.cnf to add a 
LD_PRELOAD which will load the mysql_hookandroot.so as root thanks to 
mysqld_safe, at the next mysql restart.



  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

Hi Kristian,


Just FYI I confirm the "Lock wait timeout exceeded; try restarting 
transaction" behaviour you described.


I've duplicated & modified the rpl_parallel_optimistic.test and run it 
into storage/tokudb/mysql-test/tokudb_rpl/t/rpl_parallel_optimistic.test :


./mtr --suite=tokudb_rpl <1:33:48
Logging: ./mtr  --suite=tokudb_rpl
vardir: /home/joce/mariadb-10.1.16/mysql-test/var
Checking leftover processes...
Removing old var directory...
Creating var directory '/home/joce/mariadb-10.1.16/mysql-test/var'...
Checking supported features...
MariaDB Version 10.1.16-MariaDB-debug
 - SSL connections supported
 - binaries are debug compiled
Using suites: tokudb_rpl
Collecting tests...
Installing system database...
==

TEST  RESULT   TIME (ms) or COMMENT
--

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
worker[1] mysql-test-run: WARNING: running this script as _root_ will 
cause some tests to be skipped

tokudb_rpl.rpl_parallel_optimistic 'innodb_plugin,mix' [ fail ]
Test ended at 2016-08-08 01:26:34

CURRENT_TEST: tokudb_rpl.rpl_parallel_optimistic
mysqltest: In included file "./include/sync_with_master_gtid.inc":
included from 
/home/joce/mariadb-10.1.16/storage/tokudb/mysql-test/tokudb_rpl/t/rpl_parallel_optimistic.test 
at line 59:

At line 50: Failed to sync with master

The result from queries just before the failure was:
< snip >
DELETE FROM t1 WHERE a=2;
INSERT INTO t1 VALUES (2,5);
DELETE FROM t1 WHERE a=3;
INSERT INTO t1 VALUES(3,2);
DELETE FROM t1 WHERE a=1;
INSERT INTO t1 VALUES(1,2);
DELETE FROM t1 WHERE a=3;
INSERT INTO t1 VALUES(3,3);
DELETE FROM t1 WHERE a=2;
INSERT INTO t1 VALUES (2,6);
include/save_master_gtid.inc
SELECT * FROM t1 ORDER BY a;
ab
12
26
33
include/start_slave.inc
include/sync_with_master_gtid.inc
Timeout in master_gtid_wait('0-1-20', 120), current slave GTID position 
is: 0-1-3.
Slave state : Waiting for master to send event127.0.0.1 root
160001master-bin.013468 slave-relay-bin.02796
master-bin.01YesNo 1205Lock wait 
timeout exceeded; try restarting transaction07723790
None0 NoNo01205Lock 
wait timeout exceeded; try restarting transaction1 Slave_Pos
0-1-20optimistic



I've no explanation so far for the DUPLICATE KEY error I've seen.


  Jocelyn


Le 15/07/2016 à 17:09, Kristian Nielsen a écrit :

jocelyn fournier <jocelyn.fourn...@gmail.com> writes:


Thanks for the quick answer! I wonder if it would be possible the
automatically disable the optimistic parallel replication for an
engine if it does not implement it ?

That would probably be good - though it would be better to just implement
the necessary API, it's a very small change (basically TokuDB just needs to
inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to deadlocks,
but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If transactions T1 and
T2 run in parallel, it's possible that they have a row conflict. But if T2
deleted a row expected by T1, I would expect T1 to wait on a row lock held
by T2, not get a duplicate key error. And if T1 has not yet inserted a row
expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to cause
duplicate error.

Maybe TokuDB is doing something special with locks around replication, or
something else goes wrong. I guess TokuDB just hasn't been tested much with
parallel replication.

Does it work ok when running in conservative parallel mode?

  - Kristian.



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

I'll try to extract from the binlog operations applied to only one 
table, and see if I can reproduce easily the issue.


Did you try to run the replication test with the tokudb engine instead 
of innodb ? (just in case it could be easily reproduced with the 
existing tests)



  Jocelyn


Le 15/07/2016 à 17:45, Kristian Nielsen a écrit :

Do you have a test case that can be used to repeat the bug?

  - Kristian.



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

Le 15/07/2016 à 17:27, jocelyn fournier a écrit :



Le 15/07/2016 à 17:09, Kristian Nielsen a écrit :

jocelyn fournier <jocelyn.fourn...@gmail.com> writes:


Thanks for the quick answer! I wonder if it would be possible the
automatically disable the optimistic parallel replication for an
engine if it does not implement it ?
That would probably be good - though it would be better to just 
implement
the necessary API, it's a very small change (basically TokuDB just 
needs to

inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to 
deadlocks,

but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If 
transactions T1 and
T2 run in parallel, it's possible that they have a row conflict. But 
if T2
deleted a row expected by T1, I would expect T1 to wait on a row 
lock held
by T2, not get a duplicate key error. And if T1 has not yet inserted 
a row

expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to 
cause

duplicate error.

Maybe TokuDB is doing something special with locks around 
replication, or
something else goes wrong. I guess TokuDB just hasn't been tested 
much with

parallel replication.

Does it work ok when running in conservative parallel mode?

So far conservative parallel mode seems to work properly as well.
My first thought was that this issue was cause by the Read Free 
Replication not locking rows in the expected way, although it's 
advertised to be 100% compatible with parallel replication.
I'll try the optimistic mode without the Read Free Replication to 
check if it could be related.



Well same issue without RFR :

Could not execute Delete_rows_v1 event on table sc_2.sc_product_genre; 
Can't find record in 'sc_product_genre', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008420, 
end_log_pos 77519956


(and it didn't succeed in recovering this one, I had to skip it).



Actually it has definitly corrupted the state of the slave, I have to 
rebuild the replication from a backup.


  Jocelyn

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

Le 15/07/2016 à 17:27, jocelyn fournier a écrit :



Le 15/07/2016 à 17:09, Kristian Nielsen a écrit :

jocelyn fournier <jocelyn.fourn...@gmail.com> writes:


Thanks for the quick answer! I wonder if it would be possible the
automatically disable the optimistic parallel replication for an
engine if it does not implement it ?
That would probably be good - though it would be better to just 
implement
the necessary API, it's a very small change (basically TokuDB just 
needs to

inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to 
deadlocks,

but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If transactions 
T1 and
T2 run in parallel, it's possible that they have a row conflict. But 
if T2
deleted a row expected by T1, I would expect T1 to wait on a row lock 
held
by T2, not get a duplicate key error. And if T1 has not yet inserted 
a row

expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to cause
duplicate error.

Maybe TokuDB is doing something special with locks around 
replication, or
something else goes wrong. I guess TokuDB just hasn't been tested 
much with

parallel replication.

Does it work ok when running in conservative parallel mode?

So far conservative parallel mode seems to work properly as well.
My first thought was that this issue was cause by the Read Free 
Replication not locking rows in the expected way, although it's 
advertised to be 100% compatible with parallel replication.
I'll try the optimistic mode without the Read Free Replication to 
check if it could be related.



Well same issue without RFR :

Could not execute Delete_rows_v1 event on table sc_2.sc_product_genre; 
Can't find record in 'sc_product_genre', Error_code: 1032; handler error 
HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008420, 
end_log_pos 77519956


(and it didn't succeed in recovering this one, I had to skip it).

  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] Include TokuDB Hot Backup in the bundled plugin list

[jocelyn fournier]

Hi,


In MariaDB, TokuDB is bundled as a plugin, but it's not the case for the 
Hot Backup plugin (https://github.com/percona/tokudb-backup-plugin).


I have to compile it manually against the server source code to have it 
working properly.


Would it be possible to include it in the bundled plugins ?


Thanks!

  Jocelyn


--
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
https://www.softizy.com
Softizy - At your side to Optimize your PHP / MySQL applications


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Fwd: Re: Performace issue with insert

[jocelyn fournier]

Hi,

According to your CREATE TABLE, your engine is not InnoDB but MyISAM ?

BR,
  Jocelyn Fournier

Le 27/01/2016 13:32, walter harms a écrit :

Am 27.01.2016 11:33, schrieb Peter Laursen:

"We have notice that the write performance decreases with
time, start of the month good, end of the month bad."

Do you happen to partition BY MONTH? if so it looks like the more the
latest partition grows the slower it becomes.I am no expert in this but I
think you should post the CREATE TABLE for this table. You should also tell
the exact MariaDB and MySQL versions you have tried ("SELECT version();").

yes, sorry the partitons are by month
the mariadb version we tried were 5.1.62 and 10.1.10 compared with mysql 5.1.53

I do not think that will be helpful since the table is simple and exactly equal 
in
both cases:

2 primaries + ~30 Entries

Partition are created like this:
  ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci
/*!50100 PARTITION BY RANGE (TO_DAYS(time_stamp))
(PARTITION im1_199801 VALUES LESS THAN (729786) ENGINE = MyISAM,
  PARTITION im1_199802 VALUES LESS THAN (729814) ENGINE = MyISAM,
  PARTITION im1_199803 VALUES LESS THAN (729845) ENGINE = MyISAM,
  PARTITION im1_199804 VALUES LESS THAN (729875) ENGINE = MyISAM,
  PARTITION im1_199805 VALUES LESS THAN (729906) ENGINE = MyISAM,
  PARTITION im1_199806 VALUES LESS THAN (729936) ENGINE = MyISAM,

and many more ...

my guess:
The difference is considerable. I suspect that mysql does cache a number
of inserts while maria is writing every entry, something on that line.

re,
  wh


-- Peter
-- not a MariaDB person

On Wed, Jan 27, 2016 at 11:27 AM, walter harms <wha...@bfs.de> wrote:


Hello list,
i have a strange problem with inserts.
The tables is large (time series data) and has a
lot of partitions, engine is IMMODB.
We have notice that the write performance decreases with
time, start of the month good, end of the month bad.

The same behavier is the lasted version of mariadb.
But when i replace mariadb with mysql the problems vanishes
(so its not a hardware issue). I suspect that it is a caching
problem but a comparison of the configs did not give a hint.
Anyone an idea what may cause the effect ?


re,
  wh

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] InnoDB: slow insert (too many fsyncs ?)

[jocelyn fournier]

Hi,

You should try to enable innodb_file_per_table (and recreate the table), 
to avoid filling the ibdata file.
Try also to increase the innodb_log_buffer_size to 16M (your 
Innodb_log_waits is increasing).
How much memory do you have on your system ? The innodb_buffer_pool_size 
of 1G seems to be a little bit low.
Try also to use the Barracuda file_format instead of Antelope : 
innodb_file_format = Barracuda  innodb_file_format_max = Barracuda.
For such a big amount of data to import, you could also try to increase 
the innodb_log_file_size.
On prod, depending on the speed of your disk (what is your disk / cpu 
setup on prod ?), you can also increase the innodb_io_capacity.


Depending on your usage, you could also benefit from switching to TokuDB 
(fast insert and much better compression)


HTH,
  Jocelyn Fournier

Le 26/04/2015 19:29, Julien Muchembled a écrit :

Hello,

I am trying to optimize the insertion of 124 GB of data into InnoDB and it 
takes much more time than I expected.
For the moment this is only a test before migrating prod, using a USB HDD. Prod 
has much faster storage but I prefer to check if there's anything wrong in my 
MariaDB setup.

The source DB is read as less than 1MB/s with less than 20% CPU usage (10% for 
mysqld and 10% for the client app doing the migration).

I know that several unsafe settings can be used to import data but I won't be 
able to use them for the migration of prod. This is because the migration will 
be done transparently in background, the old db being accessed for not yet 
migrated data. For the same reason, indexes can't be disabled.

Anyway, it was slow that for the moment, I only did a full test with unsafe 
settings:
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = nosync
innodb_doublewrite = 0
sync_frm = 0

It took exactly 19.8 hours to import all the data.
See attached file for all parameters and detailed statistics.
(Sorry for the 'show status' outputs, no idea what I expected to get when I 
tried 'flush status', whereas 21G were already processed. So 'show 
status.20941778944' is the output just before the flush, and 'show status' is 
after everything was finished)

The schema of tables can be found here:
http://git.erp5.org/gitweb/neoppod.git/blob/HEAD:/neo/storage/database/mysqldb.py?js=1#l142

1. fsync

Not sure if I read 'show status' correctly, but I'd say it's actually 6 fsyncs 
per second, and this matches what I see with strace.
Why not 0 whereas I disabled them ?

There's also less than 1 COMMIT per second, so even without disabling fsyncs I 
was surprised to see so many in the middle of transactions.

2. Write amplification

During my first tests, I saw with iotop that mysqld wrote at 10MB/s. Which 
means a factor 10.
With doublewrite disabled, it's rather a factor 5.

These ratios are probably underestimated. For better interpretation of the 
statistics, I should add that:
- source DB is uncompressed but the file format is very compact
- most of the imported data ends up in the 'data.value' column, and most values 
are zlib-compressed, with also deduplication
The resulting ibdata is only 70GB.

Is this write amplification only caused by indexes  doublewrite ?

Thanks,
Julien


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] mariadb 10.0.17 keeps crashing

[jocelyn fournier]

Hi,

No variables to tweak the tokudb memory allocation ?
By default tokudb_cache_size takes half of the total system memory.
With 6G allocated to InnoDB buffer pool, and 1G to the MyISAM key 
buffer, are you sure you have enough memory for TokuDB ?


  Jocelyn


Le 03/03/2015 17:37, Gabriel Sosa a écrit :

@joocelyn Here is the my.cfg file

@justin I will check that post. Thanks

[mysqld]

# 
---

#  General
# 
---

datadir   = /var/lib/mysql/data
pid-file= /var/run/mysqld/mysqld.pid
socket= /var/lib/mysql/mysql.sock
tmpdir= /var/lib/mysql/tmp
port= 3306

# 
---

#  Logging
# 
---

log-error   = /var/lib/mysql/log/mysqld-error.log
long_query_time   = 10
slow-query-log-file   = /var/lib/mysql/log/mysqld-queries_slow.log
log-slave-updates
log-bin   = /var/lib/mysql/log/bin/slave-bin
log-warnings= 1

max_relay_log_size= 200M
relay_log_space_limit   = 25000M

# 
---

#  Network
# 
---

max_connections   = 3000
max_connect_errors= 1000
wait_timeout= 120
connect_timeout   = 30
interactive_timeout   = 3600
slave_net_timeout   = 120
back_log= 50
max_allowed_packet= 128M


# 
---

#  Misc
# 
---

# Text Searchs
ft_min_word_len= 2
plugin-load = ha_tokudb

# 
---

#  Threads
# 
---

thread_concurrency= 8
thread_cache= 64

# 
---

#  Memory
# 
---

# Tables
table_cache   = 4096
tmp_table_size= 256M
# Memory per Thread
sort_buffer_size= 8M
read_buffer_size= 4M
read_rnd_buffer_size= 16M
# Query Cache
query_cache_type= 1
query_cache_limit   = 2M
query_cache_size= 64M

# 
---

#  MyISAM Parameters
# 
---

key_buffer_size   = 1024M
myisam_sort_buffer_size   = 64M
myisam_recover= FORCE,BACKUP

# 
---

#  InnoDB Parameters
# 
---

# General
innodb_data_home_dir= /var/lib/mysql/innodb
innodb_log_group_home_dir   = /var/lib/mysql/innodblogs
innodb_file_per_table
innodb_data_file_path   = ibdata1:100M:autoextend
innodb_status_file= ib_status
innodb_autoextend_increment = 10M
innodb_support_xa   = 0
innodb_thread_concurrency   = 8
innodb_flush_method   = O_DIRECT
innodb_flush_log_at_trx_commit  = 2
# Memory
innodb_buffer_pool_size   = 6G
innodb_additional_mem_pool_size = 8M
innodb_open_files   = 512
# Logging
innodb_log_buffer_size= 8M
innodb_log_file_size= 256M
innodb_log_files_in_group   = 2


# 
---

#  Replication : SLAVE Profile
# 
---

#skip-slave-start
server-id   = 124388
relay-log   = /var/lib/mysql/log/replication/slave-bin
relay-log-info-file   = 
/var/lib/mysql/log/replication/slave-log.info http://slave-log.info
master-info-file= 
/var/lib/mysql/log/replication/master-log.info http://master-log.info

max_binlog_size   = 20971520

read-only   = 1

[mysqldump]
quick
max_allowed_packet= 128M

[isamchk]
key_buffer= 256M
sort_buffer_size= 256M
read_buffer   = 2M
write_buffer= 2M

[myisamchk]
key_buffer= 256M
sort_buffer_size= 256M
read_buffer   = 2M
write_buffer= 2M

[mysqlhotcopy]
interactive-timeout

On Tue, Mar 3, 2015 at 12:56 PM, Justin Swanhart greenl...@gmail.com 
mailto:greenl...@gmail.com wrote:


Hi,

You might try to find the source of the termination with this:

http://www.percona.com/blog/2014/07/18/systemtap-solves-phantom-mysqld-sigterm-sigkill-issue/

On Tue, Mar 3, 2015 at 8:45 AM, jocelyn fournier
jocelyn.fourn...@gmail.com

Re: [Maria-discuss] mariadb 10.0.17 keeps crashing

[jocelyn fournier]

Well, you can actually choose to either lower the tokudb_cache_size 
value to avoid to eat all the memory, or convert your other innodb 
tables to tokudb, if it makes sense :)
(you can have the master on InnoDB, and start converting the tables to 
TokuDB on the slave to check all is working properly)


  Jocelyn



Le 03/03/2015 22:26, Gabriel Sosa a écrit :

using systemtap I got

[Tue Mar  3 18:48:46 2015] SIGKILL was sent to ps (pid:9763) by 
processes uid:0
[Tue Mar  3 18:49:46 2015] SIGKILL was sent to ps (pid:9824) by 
processes uid:0
*[Tue Mar  3 18:50:44 2015] SIGKILL was sent to mysqld (pid:7597) by 
mysqld uid:498*
[Tue Mar  3 18:50:46 2015] SIGKILL was sent to ps (pid:9890) by 
processes uid:0
[Tue Mar  3 18:51:46 2015] SIGKILL was sent to ps (pid:9997) by 
processes uid:0
[Tue Mar  3 18:52:35 2015] SIGKILL was sent to cdm (pid:10045) by cdm 
uid:0



I saw this several times but I wasn't able to find (in this case) 
which process has the PID 498. @jocelyn, you are right...to tweaks at 
all for tokudb (my bad here), although I wasn't expecting such /naive/ 
approach, I mean, I could have not enable the tokudb plugin and all 
other tables using the other engines would work just fine (maybe just 
slow though)


free -m returns about 47M free...which isn't much...

the issue is that if I need to provide tokudb more RAM I will need to 
take if from the InnoDB buffer pool, which we use a lot...the main 
reason to use tokudb was to compress some huge tables that are not 
transactional nor readed all the time.




On Tue, Mar 3, 2015 at 4:06 PM, Justin Swanhart greenl...@gmail.com 
mailto:greenl...@gmail.com wrote:


Hi,

Presumably, if the server is using too much ram it will a) crash
and leave a stack trace (not happening) or b) invoke the OOMPK
which leaves a trace in syslog, which also, presumably, is not
happening, since she can find no trace of OOMPK activity.

So memory is a good guess (output of free -m would be useful) I
doubt it is memory related do to lack of evidence for it.

--Justin

On Tue, Mar 3, 2015 at 9:58 AM, jocelyn fournier
jocelyn.fourn...@gmail.com mailto:jocelyn.fourn...@gmail.com
wrote:

Hi,

No variables to tweak the tokudb memory allocation ?
By default tokudb_cache_size takes half of the total system
memory.
With 6G allocated to InnoDB buffer pool, and 1G to the MyISAM
key buffer, are you sure you have enough memory for TokuDB ?

  Jocelyn


Le 03/03/2015 17:37, Gabriel Sosa a écrit :

@joocelyn Here is the my.cfg file

@justin I will check that post. Thanks

[mysqld]

#

---
#  General
#

---
datadir = /var/lib/mysql/data
pid-file= /var/run/mysqld/mysqld.pid
socket  = /var/lib/mysql/mysql.sock
tmpdir  = /var/lib/mysql/tmp
port= 3306

#

---
#  Logging
#

---
log-error   =
/var/lib/mysql/log/mysqld-error.log
long_query_time = 10
slow-query-log-file =
/var/lib/mysql/log/mysqld-queries_slow.log
log-slave-updates
log-bin =
/var/lib/mysql/log/bin/slave-bin
log-warnings= 1

max_relay_log_size  = 200M
relay_log_space_limit   = 25000M

#

---
#  Network
#

---
max_connections = 3000
max_connect_errors  = 1000
wait_timeout= 120
connect_timeout = 30
interactive_timeout = 3600
slave_net_timeout   = 120
back_log= 50
max_allowed_packet  = 128M


#

---
#  Misc
#

---
# Text Searchs
ft_min_word_len  = 2
plugin-load = ha_tokudb

#

---
#  Threads

Re: [Maria-discuss] new mdev about better explain

[jocelyn fournier]

Hi Roberto,

What are the cardinalities of the index in this table ? (SHOW INDEXES 
FROM est_mov).
As a DBA, if cardinalities are wrong, I would first try to run an 
ANALYZE TABLE command (and if it's InnoDB check if the 
innodb_stats_sample_pages is enough).
As a dev, if I'm sure of what I'm doing, I would use STRAIGHT_JOIN / USE 
INDEX.


HTH,
  Jocelyn




Le 01/12/2014 13:50, Roberto Spadim a écrit :

Hi guys, any help is wellcome here

the problem:   why optimizer chose a bad index?

an example about this problem is MDEV-7125
i have this EXPLAIN output:

id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra
1|SIMPLE|c|const|PRIMARY,NewIndex|PRIMARY|265|const,const|1|Distinct;
Using temporary
1|SIMPLE|b|range|PRIMARY,id,plano_conta_numero,cod_busca|cod_busca|265|(NULL)|49|Using
index condition; Distinct
*1|SIMPLE|a|ref|cfop,item,transferencias,rendimento,estoque,giro|item|6|const,19_org.b.plano_conta_id_red|3347|Using
where; Distinct*
1|SIMPLE|d|eq_ref|PRIMARY,NewIndex|PRIMARY|265|19_org.a.estoque_entrada_org,const|1|Using
index condition; Using where; Distinct

---
check the row from table a
1|SIMPLE|a|ref|*cfop,item,transferencias,rendimento,estoque,giro*|item|6|const,19_org.b.plano_conta_id_red|3347|Using
where; Distinct

optimizer found 5 possible index, and chose the item index, instead of
rendimento index, it's not the best index, but i don't know why
optimizer prefer item instead of rendimento

to solve (explain) this optimizer choise i execute force index in each
index and get output from explain... example

EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (cfop) ...
EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (item) ...
EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (transferencias) ...
EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (rendimento) ...
EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (estoque) ...
EXPLAIN SELECT ... FROM est_mov AS a FORCE INDEX (giro) ...

and compare each output to know why it chose the index 'item' as 'best'
option

could be possible a better explain from optimizer?
something like

{
   'item': {'key_len':1234, 'ref rows':'blablalba', 'filtered'  99,
'extra':'blabla'},
   'transferencias': {'key_len':1234, 'ref rows':'blablalba', 'filtered'
  99, 'extra':'blabla'},
   'rendimento': {'key_len':1234, 'ref rows':'blablalba', 'filtered'
  99, 'extra':'blabla'},
   'giro': {'key_len':1234, 'ref rows':'blablalba', 'filtered'  99,
'extra':'blabla'}
}

i don't know if optimizer have this information, but it's relevant?
could we implement a better explain?
what others users (dba/developer) do when they have this problem
(optimizer selecting the wrong index)?

thanks guys

--
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] MariaDB for OpenSuSE 12.3

[jocelyn fournier]

Hi,

Perhaps try to grep mariadb instead of mysql ?

HTH,
  Jocelyn


Le 25/11/2014 14:00, Peter Laursen a écrit :
wrong again .. the server. clients, and CONNCT engine are installed. 
and sever is running




peter@linux-hwpu:~ mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.0.15-MariaDB MariaDB Server

Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.


MariaDB [(none)] show databases
- ;
++
| Database   |
++
| information_schema |
| test   |
++
2 rows in set (0,01 sec)

MariaDB [(none)] show engines;
++-++--+--++
| Engine | Support | Comment   
 | Transactions | XA   | Savepoints |

++-++--+--++
| MEMORY | YES | Hash based, stored in memory, useful 
for temporary tables  | NO   | NO   | NO |
| CSV| YES | CSV storage engine   
| NO   | NO   | NO |
| MyISAM | YES | MyISAM storage engine| NO 
  | NO   | NO |
| BLACKHOLE  | YES | /dev/null storage engine (anything 
you write to it disappears) | NO   | NO   | NO |
| MRG_MyISAM | YES | Collection of identical MyISAM tables 
 | NO   | NO   | NO |
| CONNECT| YES | Management of External Data 
(SQL/MED), including many file formats | NO   | NO   | NO 
|
| FEDERATED  | YES | FederatedX pluggable storage engine   
 | YES  | NO   | YES|
| ARCHIVE| YES | Archive storage engine   | NO 
  | NO   | NO |
| InnoDB | DEFAULT | Percona-XtraDB, Supports 
transactions, row-level locking, and foreign keys | YES  | YES 
 | YES|
| PERFORMANCE_SCHEMA | YES | Performance Schema   
| NO   | NO   | NO |
| Aria   | YES | Crash-safe tables with MyISAM 
heritage | NO   | NO   | NO |

++-++--+--++
11 rows in set (0,00 sec)

MariaDB [(none)]



-- Peter

MariaDB [(none)]



.. but therpm command does not return it?


-- Peter

On Tue, Nov 25, 2014 at 1:38 PM, Peter Laursen 
peter_laur...@webyog.com mailto:peter_laur...@webyog.com wrote:


oops .. it seems that I am wrong!


peter@linux-hwpu:~ rpm -qa | grep mysql
libmysqld18-10.0.13-2.3.2.x86_64
libqt4-sql-mysql-4.8.6-4.4.1.x86_64
libreoffice-base-drivers-mysql-4.3.3.2-4.1.x86_64
libmysqlcppconn6-1.1.2-6.2.2.x86_64
libmysqlclient18-10.0.13-2.3.2.x86_64
php5-mysql-5.6.1-4.1.x86_64
peter@linux-hwpu:~ rpm -qa | grep maria
mariadb-errormessages-10.0.13-2.3.2.x86_64
peter@linux-hwpu:~ ^C
peter@linux-hwpu:~


.. so no server is installed now, it seems!


-- Peter

On Tue, Nov 25, 2014 at 1:37 PM, Peter Laursen
peter_laur...@webyog.com mailto:peter_laur...@webyog.com wrote:

I did a fresh install of SuSe 1.3 with only XFCE desktop. I
installed the LAMP Server from the Installation menu.  next
I installed Amarok and its dependencies (and it was not a
showstpper if not installed with the full KDE).


Problems still occurring
1) I had to uninstall
2) the command line yast2 command syntax failed, but  I was
able to isntall the packages one-by-one in te order specified
3) after rinstallation the service does no appear in YaST
'Service management' GUI. It definitely shold on SuSE.

(detals of the error in 1) above

3 nye pakker der installeres.
Samlet downloadstørrelse: 95,3 MiB. Allerede cachet: 0 B
 Efter transaktionen
vil yderligere 522,2 MiB blive brugt.
Vil du fortsætte? [j/n/? vis alle tilvalg] (j): j
Henter pakke MariaDB-common-10.0.15-1.x86_64
 (1/3),  19,9 KiB (173,9 KiB udpakket)
Henter pakke MariaDB-client-10.0.15-1.x86_64
 (2/3),  24,3 MiB (147,7 MiB udpakket)
Henter pakke MariaDB-server-10.0.15-1.x86_64
 (3/3),  71,0 MiB (374,4 MiB udpakket)
Tjekker for filkonflikter:
...[fejl]
Fandt 1 filkonflikt:

File /usr/lib64/libmysqld.so.18
  from install of

Re: [Maria-discuss] MariaDB for OpenSuSE 12.3

[jocelyn fournier]

oups, sorry, I missed your

peter@linux-hwpu:~ rpm -qa | grep maria

line


Le 25/11/2014 14:07, jocelyn fournier a écrit :

Hi,

Perhaps try to grep mariadb instead of mysql ?

HTH,
  Jocelyn


Le 25/11/2014 14:00, Peter Laursen a écrit :
wrong again .. the server. clients, and CONNCT engine are installed. 
and sever is running




peter@linux-hwpu:~ mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.0.15-MariaDB MariaDB Server

Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.


MariaDB [(none)] show databases
- ;
++
| Database   |
++
| information_schema |
| test   |
++
2 rows in set (0,01 sec)

MariaDB [(none)] show engines;
++-++--+--++
| Engine | Support | Comment| Transactions | XA   | 
Savepoints |

++-++--+--++
| MEMORY | YES | Hash based, stored in memory, useful 
for temporary tables  | NO   | NO   | NO |
| CSV| YES | CSV storage engine   | NO   
| NO   | NO |
| MyISAM | YES | MyISAM storage engine  | NO 
  | NO   | NO |
| BLACKHOLE  | YES | /dev/null storage engine (anything 
you write to it disappears)   | NO   | NO   | NO |
| MRG_MyISAM | YES | Collection of identical MyISAM 
tables| NO   | NO   | NO |
| CONNECT| YES | Management of External Data 
(SQL/MED), including many file formats   | NO   | NO   | 
NO |
| FEDERATED  | YES | FederatedX pluggable storage engine 
 | YES  | NO   | YES|
| ARCHIVE| YES | Archive storage engine | NO 
  | NO   | NO |
| InnoDB | DEFAULT | Percona-XtraDB, Supports 
transactions, row-level locking, and foreign keys | YES  | 
YES  | YES|
| PERFORMANCE_SCHEMA | YES | Performance Schema   | NO   
| NO   | NO |
| Aria   | YES | Crash-safe tables with MyISAM 
heritage   | NO   | NO   | NO |

++-++--+--++
11 rows in set (0,00 sec)

MariaDB [(none)]



-- Peter

MariaDB [(none)]



.. but therpm command does not return it?


-- Peter

On Tue, Nov 25, 2014 at 1:38 PM, Peter Laursen 
peter_laur...@webyog.com mailto:peter_laur...@webyog.com wrote:


oops .. it seems that I am wrong!


peter@linux-hwpu:~ rpm -qa | grep mysql
libmysqld18-10.0.13-2.3.2.x86_64
libqt4-sql-mysql-4.8.6-4.4.1.x86_64
libreoffice-base-drivers-mysql-4.3.3.2-4.1.x86_64
libmysqlcppconn6-1.1.2-6.2.2.x86_64
libmysqlclient18-10.0.13-2.3.2.x86_64
php5-mysql-5.6.1-4.1.x86_64
peter@linux-hwpu:~ rpm -qa | grep maria
mariadb-errormessages-10.0.13-2.3.2.x86_64
peter@linux-hwpu:~ ^C
peter@linux-hwpu:~


.. so no server is installed now, it seems!


-- Peter

On Tue, Nov 25, 2014 at 1:37 PM, Peter Laursen
peter_laur...@webyog.com mailto:peter_laur...@webyog.com wrote:

I did a fresh install of SuSe 1.3 with only XFCE desktop. I
installed the LAMP Server from the Installation menu.  next
I installed Amarok and its dependencies (and it was not a
showstpper if not installed with the full KDE).


Problems still occurring
1) I had to uninstall
2) the command line yast2 command syntax failed, but  I was
able to isntall the packages one-by-one in te order specified
3) after rinstallation the service does no appear in YaST
'Service management' GUI. It definitely shold on SuSE.

(detals of the error in 1) above

3 nye pakker der installeres.
Samlet downloadstørrelse: 95,3 MiB. Allerede cachet: 0 B
 Efter transaktionen
vil yderligere 522,2 MiB blive brugt.
Vil du fortsætte? [j/n/? vis alle tilvalg] (j): j
Henter pakke MariaDB-common-10.0.15-1.x86_64
 (1/3),  19,9 KiB (173,9 KiB udpakket)
Henter pakke MariaDB-client-10.0.15-1.x86_64
 (2/3),  24,3 MiB (147,7 MiB udpakket)
Henter pakke MariaDB-server-10.0.15-1.x86_64
 (3/3),  71,0 MiB (374,4 MiB udpakket)
Tjekker for filkonflikter:
...[fejl]
Fandt 1 filkonflikt:

File /usr/lib64/libmysqld.so.18
  from install of
 MariaDB-server-10.0.15-1.x86_64(Cache for rene RPM

Re: [Maria-discuss] PERFORMANCE_SCHEMA to be disabled in 10.0 (10.0.12)

[Jocelyn Fournier]

Hi,

Never used it on production. From my point of view, it should be 
disabled by default, but included.


The whole purpose of this variable is to have a way to analyze/optimize 
performances easily, when needed; if it's enable by default, we have a 
perf hit, so that's counterproductive.
I assume it should be possible to work to remove the performance hit 
when disabled but included ?



Thanks,
  Jocelyn

Le 03/06/2014 10:20, Colin Charles a écrit :

Hi all,

Recently there was chat about how PERFORMANCE_SCHEMA was enabled by mistake and 
it should be disabled in the 10.0 series. I'm curious - how many of you are 
using PERFORMANCE_SCHEMA? Is it a problem to turn it on, if you use it?

I'm referring to:
https://mariadb.atlassian.net/browse/MDEV-6249

Looking from the webscalesql list, there are examples of performance 
degradation:
https://groups.google.com/d/msg/webscalesql/B-4bPIb8mHI/eUNsl0lSfbMJ
https://groups.google.com/d/msg/webscalesql/B-4bPIb8mHI/-YZMMCuPw3QJ

quote: Our perf testing agrees with your assessment (we see about a 5%-6% perf hit 
when it's included and on, and a 2%-3% hit when it's included but off)

Please discuss this, either here or on MDEV-6249

Thanks

cheers,
-colin

--
Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company
blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] Glibc 2.3 support in MariaDB builds ?

[Jocelyn Fournier]

Hi,

I'm trying to push my company to adopt MariaDB 5.2. Unfortunately, the 
currently available binaries (at least for the x86-64 version) requires 
a glibc 2.4, where we have only a 2.3 version (debian etch) installed on 
our server.
MySQL 5.5 standard binaries, as well as Percona's one perfectly support 
glibc 2.3, so is there any plan to provide glibc 2.3 compatible binaries 
for MariaDB ?


Thanks and regards,
  Jocelyn Fournier

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Glibc 2.3 support in MariaDB builds ?

[Jocelyn Fournier]

Hi Kristian,

We are actually planning to upgrade some of our servers, but my feeling 
is it's too bad the supported glibc doesn't match what is supported in 
standard MySQL binaries : MariaDB is not anymore just a drop-in replacement.
In my case, it's more difficult to convince my company to move to 
MariaDB 5.2 if they have to upgrade the OS in more than 100 servers ! ;)
But yes, I indeed have the alternative to compile myself MariaDB, I was 
used to do this a few years ago :)


  Jocelyn

Le 19/12/10 15:09, Kristian Nielsen a écrit :

Jocelyn Fournierj...@doctissimo.fr  writes:


I'm trying to push my company to adopt MariaDB 5.2. Unfortunately, the
currently available binaries (at least for the x86-64 version)
requires a glibc 2.4, where we have only a 2.3 version (debian etch)
installed on our server.
MySQL 5.5 standard binaries, as well as Percona's one perfectly
support glibc 2.3, so is there any plan to provide glibc 2.3
compatible binaries for MariaDB ?

We used to have Debian etch binaries, however I removed them at some point
since Debian etch support ended half a year ago or so and there did not seem
much interest.

(If you want to help sponsor resurrecting binaries supporting such older
systems you could try contacting sa...@askmonty.org.)

Alternatively, you can build the binaries yourself, it is not hard. You
basically need to run these two commands:

 BUILD/compile-bintar
 scripts/make_binary_distribution

  - Kristian.

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp