Performance questions after Migrating from MariaDB 5.5.68 to 10.11.6 (and 9)
Dear MariaDB List Readers, I hope formatting will survive...i tried to make this as readable as possible. Due to our ongoing migration from RHEL7 to RHEL9, we are also upgrading some databases from MariaDB 5.5.68 (on RHEL7) to MariaDB 10.11.6 (on RHEL9). During this process, we've noticed a significant performance drop, particularly with UPDATE and DELETE operations. To investigate this further and rule out external factors, I created a single RHEL9 VM and downloaded both the x86_64/systemd versions of MariaDB 5.5.68 and 10.11.9 from MariaDB Downloads. (https://mariadb.org/download) I installed both versions on the same VirtualBox VM, using default configurations, and placed them on the same partition (/usr/local). I followed the installation instructions in the INSTALL-BINARY file. I then ran a benchmark on both versions using a variation of this PHP benchmark script: https://github.com/sergix44/php-benchmark-script. Here are the results: *MariaDB 5.5.68*: Server version: 5.5.68-MariaDB MariaDB Server mysql::ping,0.0002 mysql::select_version,0.1299 mysql::select_all,0.6270 mysql::select_cursor,0.8542 mysql::seq_insert,2.0182 mysql::bulk_insert,0.0204 mysql::update,0.0005 mysql::update_with_index,0.0005 mysql::transaction_insert,0.0014 mysql::indexes,0.0000 mysql::delete,0.0005 mysql::select_version::q/s,15403 mysql::select_all::q/s,3190 mysql::seq_insert::q/s,991 mysql::update::q/s,3895386 mysql::update_with_index::q/s,4105436 mysql::transaction_insert::t/s,1460821 mysql::delete::q/s,4436065 Total time: 13.2027 s Peak memory usage: 23.82 MiB *MariaDB 10.11.9*: Server version: 10.11.9-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1268 mysql::select_all,0.6435 mysql::select_cursor,0.8352 mysql::seq_insert,2.2696 mysql::bulk_insert,0.6556 mysql::update,1.4104 mysql::update_with_index,0.3981 mysql::transaction_insert,2.5425 mysql::indexes,0.2353 mysql::delete,2.2246 mysql::select_version::q/s,15772 mysql::select_all::q/s,3108 mysql::seq_insert::q/s,881 mysql::update::q/s,1418 mysql::update_with_index::q/s,8963 mysql::transaction_insert::t/s,787 mysql::delete::q/s,899 Total time: 20.9426 s Peak memory usage: 23.82 MiB The key observations: - **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s I also tested MariaDB 10.11.6, and the results were similar to 10.11.9. Our web application feels noticeably slower, and the benchmark results seem to confirm this. Is this drastic performance drop expected with newer MariaDB versions? While we are aware of tuning options (like `innodb_buffer_pool_size`, file system mount options, `innodb_flush_log_at_trx_commit`, etc.), both versions were run with default settings and no tuning. How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Best regards, MJ To end, and to be complete: find below the actual script used to create the stats: <?php $initialRowCount = 1000; $mysqli = null; setup(function ($args) use (&$mysqli, $initialRowCount) { if (!extension_loaded('mysqli')) { print('The mysqli extension is not loaded' . PHP_EOL); return; } if ($args['mysql_host'] === null || $args['mysql_user'] === null || $args['mysql_password'] === null) { print('The --mysql_host=, --mysql_user=, and --mysql_password= arguments are required' . PHP_EOL); return; } $mysqli = new mysqli($args['mysql_host'], $args['mysql_user'], $args['mysql_password'], null, isset($args['mysql_port']) ? $args['mysql_port'] : 3306); if ($mysqli->connect_error) { printf("Mysql Connect Error (%s) %s\n", $mysqli->connect_errno, $mysqli->connect_error); return; } // drop database $mysqli->query("DROP DATABASE IF EXISTS `bench_test`"); // create database $mysqli->query("CREATE DATABASE IF NOT EXISTS `bench_test`"); $mysqli->select_db('bench_test'); $mysqli->query("CREATE TABLE IF NOT EXISTS `bench_test`.`test` (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255))"); for ($i = 0; $i < $initialRowCount; $i++) { $values[] = "('test$i')"; } $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES " . implode(',', $values)); }); teardown(function () use (&$mysqli) { if ($mysqli === null) { return; } $mysqli->query("DROP DATABASE IF EXISTS `bench_test`"); $mysqli->close(); }); return [ 'ping' => function () use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->ping(); return 1; }, 'select_version' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("SELECT VERSION()"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'select_all' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("SELECT * FROM `bench_test`.`test`"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'select_cursor' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; for ($i = 0; $i < $count; $i++) { $result = $mysqli->query("SELECT * FROM `bench_test`.`test`"); while ($row = $result->fetch_assoc()) { } $result->close(); } return $i; }, 'seq_insert' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES ('test')"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'bulk_insert' => function ($multiplier = 1, $count = 100000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $values = []; for ($i = 0; $i < $count; $i++) { $values[] = "('test$i')"; } $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES " . implode(',', $values)); return $i; }, 'update' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("UPDATE `bench_test`.`test` SET name = 'test' WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'update_with_index' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->query("CREATE INDEX idx ON `bench_test`.`test` (id)"); $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("UPDATE `bench_test`.`test` SET name = 'test' WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); $mysqli->query("DROP INDEX idx ON `bench_test`.`test`"); return $i; }, 'transaction_insert' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->begin_transaction(); $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES ('test')"); $mysqli->commit(); } extraStat('t/s', round($count / (StopWatch::time() - $time))); return $i; }, 'indexes' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->query("CREATE INDEX idx_name ON `bench_test`.`test` (name)"); $mysqli->query("DROP INDEX idx_name ON `bench_test`.`test`"); return 1; }, 'delete' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("DELETE FROM `bench_test`.`test` WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, ];
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations?
Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055 Which while marked Closed, point to different issues/problems where situation is still unclear .. I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x p.s. sorry for not answering your questions and possibly increasing the load :) wbr rr
Hi Reinis, No apologies needed! Thanks you very much for your suggestion and insights, and I will definitely give 10.4.34 a try and update findings here! MJ On 10/7/24 16:41, Reinis Rozitis via discuss wrote:
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server: Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB So to update the "key observations": - **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68 This is all very strange. On 10/7/24 16:41, Reinis Rozitis via discuss wrote:
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration. Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings. I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe. On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, <discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote:
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
I'm going to take my best guess here and assume that the 5.5 benchmark results are false results, which I am honestly surprised that nobody noticed before. 4M inserts or updates per second is completely unrealistic in real life scenarios. I gave a quick look to that benchmark script; it's single threaded and does no error checking at all. There is just no way such a script could reach 4M inserts per second, so I'm concluding you're just benchmarking errors here and nothing gets written to the DB. If you want to corroborate my theory just look at SHOW GLOBAL STATUS LIKE 'Com_Insert' and SHOW GLOBAL STATUS LIKE 'Com_Update' counters on this DB. It should tell you how many inserts/updates have been recorded. I don't want to criticize the PHP script author's work, because his script might be perfectly fine for most situations, but if you want to do accurate DB benchmarking you should give a try to Sysbench. GL Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss < discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, < discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote:
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss < discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, < discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote:
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Because I had a bit of time I ran the script against two fresh MariaDB containers on my workstation and here are the numbers, which look more realistic 5.5.36 mysql::select_version::q/s....................... 43227 mysql::select_all::q/s........................... 21382 mysql::seq_insert::q/s............................. 165 mysql::update::q/s................................. 157 mysql::update_with_index::q/s...................... 161 mysql::transaction_insert::t/s..................... 157 mysql::delete::q/s................................. 159 10.11.6 mysql::select_version::q/s....................... 65544 mysql::select_all::q/s............................ 5134 mysql::seq_insert::q/s............................. 116 mysql::update::q/s................................. 161 mysql::update_with_index::q/s.................... 18419 mysql::transaction_insert::t/s..................... 155 mysql::delete::q/s................................. 122 As you can see some interesting differences: - SELECT * being way slower on 10.11 on this benchmark - UPDATE with index much faster on 10.11 the rest looks quite similar (benchmarking select version is without much interest...) Le lun. 7 oct. 2024 à 23:49, Guillaume Lefranc <guillaume@adishatz.net> a écrit :
I'm going to take my best guess here and assume that the 5.5 benchmark results are false results, which I am honestly surprised that nobody noticed before. 4M inserts or updates per second is completely unrealistic in real life scenarios. I gave a quick look to that benchmark script; it's single threaded and does no error checking at all. There is just no way such a script could reach 4M inserts per second, so I'm concluding you're just benchmarking errors here and nothing gets written to the DB.
If you want to corroborate my theory just look at SHOW GLOBAL STATUS LIKE 'Com_Insert' and SHOW GLOBAL STATUS LIKE 'Com_Update' counters on this DB. It should tell you how many inserts/updates have been recorded.
I don't want to criticize the PHP script author's work, because his script might be perfectly fine for most situations, but if you want to do accurate DB benchmarking you should give a try to Sysbench.
GL
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss < discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, < discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss < discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, < discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Hello, if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared
https://jira.mariadb.org/browse/MDEV-30501#comment-272740 https://jira.mariadb.org/browse/MDEV-29988 https://jira.mariadb.org/browse/MDEV-26055
Which while marked Closed, point to different issues/problems where situation is still unclear ..
I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x
p.s. sorry for not answering your questions and possibly increasing
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: the load :)
wbr rr
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Hi Guillaume Lefranc, I was out of the office yesterday. Thanks very much for your replies and your tests. I will checkout your findings on my side using Sysbench, and check Com_Insert' and 'Com_Update' counters as well. Best, MJ On 10/8/24 00:20, Guillaume Lefranc wrote:
Because I had a bit of time I ran the script against two fresh MariaDB containers on my workstation and here are the numbers, which look more realistic
5.5.36 mysql::select_version::q/s....................... 43227 mysql::select_all::q/s........................... 21382 mysql::seq_insert::q/s............................. 165 mysql::update::q/s................................. 157 mysql::update_with_index::q/s...................... 161 mysql::transaction_insert::t/s..................... 157 mysql::delete::q/s................................. 159
10.11.6 mysql::select_version::q/s....................... 65544 mysql::select_all::q/s............................ 5134 mysql::seq_insert::q/s............................. 116 mysql::update::q/s................................. 161 mysql::update_with_index::q/s.................... 18419 mysql::transaction_insert::t/s..................... 155 mysql::delete::q/s................................. 122
As you can see some interesting differences: - SELECT * being way slower on 10.11 on this benchmark - UPDATE with index much faster on 10.11
the rest looks quite similar (benchmarking select version is without much interest...)
Le lun. 7 oct. 2024 à 23:49, Guillaume Lefranc <guillaume@adishatz.net> a écrit :
I'm going to take my best guess here and assume that the 5.5 benchmark results are false results, which I am honestly surprised that nobody noticed before. 4M inserts or updates per second is completely unrealistic in real life scenarios. I gave a quick look to that benchmark script; it's single threaded and does no error checking at all. There is just no way such a script could reach 4M inserts per second, so I'm concluding you're just benchmarking errors here and nothing gets written to the DB.
If you want to corroborate my theory just look at SHOW GLOBAL STATUS LIKE 'Com_Insert' and SHOW GLOBAL STATUS LIKE 'Com_Update' counters on this DB. It should tell you how many inserts/updates have been recorded.
I don't want to criticize the PHP script author's work, because his script might be perfectly fine for most situations, but if you want to do accurate DB benchmarking you should give a try to Sysbench.
GL
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss <discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, <discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: >> How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? > Hello, > if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared > > https://jira.mariadb.org/browse/MDEV-30501#comment-272740 > https://jira.mariadb.org/browse/MDEV-29988 > https://jira.mariadb.org/browse/MDEV-26055 > > Which while marked Closed, point to different issues/problems where situation is still unclear .. > > I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x > > > p.s. sorry for not answering your questions and possibly increasing the load :) > > wbr > rr > > > > _______________________________________________ > discuss mailing list -- discuss@lists.mariadb.org > To unsubscribe send an email to discuss-leave@lists.mariadb.org _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss <discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, <discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: >> How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? > Hello, > if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared > > https://jira.mariadb.org/browse/MDEV-30501#comment-272740 > https://jira.mariadb.org/browse/MDEV-29988 > https://jira.mariadb.org/browse/MDEV-26055 > > Which while marked Closed, point to different issues/problems where situation is still unclear .. > > I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x > > > p.s. sorry for not answering your questions and possibly increasing the load :) > > wbr > rr > > > > _______________________________________________ > discuss mailing list -- discuss@lists.mariadb.org > To unsubscribe send an email to discuss-leave@lists.mariadb.org _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Hi Guillaume Lefranc, Thanks for testing the script. I will contact the original author with the bug.
Hi Guillaume and the others, Just to follow-up this issue: We ended up adding another 6G RAM to the machine, enlarging innodb settings accordingly, and now performance is good. (innodb_buffer_pool_size = 8G innodb_log_file_size = 512M innodb_log_buffer_size = 64M tmp_table_size = 64M max_heap_table_size = 64M) We are still surprised to see that on rhel7/mariadb 5.5 6G RAM is what the machine needed to run quickly. Now, RHEL9, with double the amount RAM and mariadb tweaking, performance is also good. Anyway, doing it like this allowed us to proceed with our project. Thanks for the vivid discussion and reactions here! Much appreciated! MJ On 10/8/24 00:20, Guillaume Lefranc wrote:
Because I had a bit of time I ran the script against two fresh MariaDB containers on my workstation and here are the numbers, which look more realistic
5.5.36 mysql::select_version::q/s....................... 43227 mysql::select_all::q/s........................... 21382 mysql::seq_insert::q/s............................. 165 mysql::update::q/s................................. 157 mysql::update_with_index::q/s...................... 161 mysql::transaction_insert::t/s..................... 157 mysql::delete::q/s................................. 159
10.11.6 mysql::select_version::q/s....................... 65544 mysql::select_all::q/s............................ 5134 mysql::seq_insert::q/s............................. 116 mysql::update::q/s................................. 161 mysql::update_with_index::q/s.................... 18419 mysql::transaction_insert::t/s..................... 155 mysql::delete::q/s................................. 122
As you can see some interesting differences: - SELECT * being way slower on 10.11 on this benchmark - UPDATE with index much faster on 10.11
the rest looks quite similar (benchmarking select version is without much interest...)
Le lun. 7 oct. 2024 à 23:49, Guillaume Lefranc <guillaume@adishatz.net> a écrit :
I'm going to take my best guess here and assume that the 5.5 benchmark results are false results, which I am honestly surprised that nobody noticed before. 4M inserts or updates per second is completely unrealistic in real life scenarios. I gave a quick look to that benchmark script; it's single threaded and does no error checking at all. There is just no way such a script could reach 4M inserts per second, so I'm concluding you're just benchmarking errors here and nothing gets written to the DB.
If you want to corroborate my theory just look at SHOW GLOBAL STATUS LIKE 'Com_Insert' and SHOW GLOBAL STATUS LIKE 'Com_Update' counters on this DB. It should tell you how many inserts/updates have been recorded.
I don't want to criticize the PHP script author's work, because his script might be perfectly fine for most situations, but if you want to do accurate DB benchmarking you should give a try to Sysbench.
GL
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss <discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, <discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: >> How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? > Hello, > if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared > > https://jira.mariadb.org/browse/MDEV-30501#comment-272740 > https://jira.mariadb.org/browse/MDEV-29988 > https://jira.mariadb.org/browse/MDEV-26055 > > Which while marked Closed, point to different issues/problems where situation is still unclear .. > > I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x > > > p.s. sorry for not answering your questions and possibly increasing the load :) > > wbr > rr > > > > _______________________________________________ > discuss mailing list -- discuss@lists.mariadb.org > To unsubscribe send an email to discuss-leave@lists.mariadb.org _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
Le lun. 7 oct. 2024 à 17:38, Gordan Bobic via discuss <discuss@lists.mariadb.org> a écrit :
The only way there can be that big a difference is if there is a flushing discrepancy in cofiguration.
Have you verified your settings are actually the same, particularly the ones containing "flush" and "sync" substrings.
I seem to recall there was also a flush bug fixed since 5.5 that makes things slower since then but made 5.5 not entirely crash-safe.
On Mon, 7 Oct 2024, 18:33 cyusedfzfb via discuss, <discuss@lists.mariadb.org> wrote:
Ok, tested just now with Server version: 10.4.34-MariaDB MariaDB Server:
Server version: 10.4.34-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1368 mysql::select_all,0.7346 mysql::select_cursor,0.9662 mysql::seq_insert,4.4442 mysql::bulk_insert,0.6946 mysql::update,2.5573 mysql::update_with_index,0.3629 mysql::transaction_insert,4.7147 mysql::indexes,0.2814 mysql::delete,4.3666 mysql::select_version::q/s,14616 mysql::select_all::q/s,2723 mysql::seq_insert::q/s,450 mysql::update::q/s,782 mysql::update_with_index::q/s,9248 mysql::transaction_insert::t/s,424 mysql::delete::q/s,458 Total time,29.3222 s Peak memory usage,23.82 MiB
So to update the "key observations":
- **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - 10.4.34: *782* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - 10.4.34: *9,248* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s - 10.4.34: *458* q/s
Hmm. 10.4.34 behaves much like 10.11.6, and very unlike the speedy gonzalez 5.5.68
This is all very strange.
On 10/7/24 16:41, Reinis Rozitis via discuss wrote: >> How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? > Hello, > if you have means, could you test 10.4.34 which while EOL is the last version based on 5.5/5.6 MySQL and issues like these appeared > > https://jira.mariadb.org/browse/MDEV-30501#comment-272740 > https://jira.mariadb.org/browse/MDEV-29988 > https://jira.mariadb.org/browse/MDEV-26055 > > Which while marked Closed, point to different issues/problems where situation is still unclear .. > > I haven't tried the 10.11.x nor 11.x but none of the short-term release branches after 10.4 have performed even close (though not that dramatically) at least for our workload, so currently stuck on 10.4.x > > > p.s. sorry for not answering your questions and possibly increasing the load :) > > wbr > rr > > > > _______________________________________________ > discuss mailing list -- discuss@lists.mariadb.org > To unsubscribe send an email to discuss-leave@lists.mariadb.org _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
_______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
participants (5)
-
cyusedfzfb
-
Gordan Bobic
-
Guillaume Lefranc
-
r.vandruten@ru.nl
-
Reinis Rozitis