Quantcast
Channel: MySQL Forums - Performance
Viewing all 1203 articles
Browse latest View live

Low priority SELECT (1 reply)

$
0
0
I need to run some queries for statistics purposes that will likely take a long time.
I don't need immediate answer, as I would like to build a report to be accessed later.
I'm trying to understant the best approach, if there is one!
So far I came out with this:
- run the query on a slave
- execute the query in "batches" limiting the number of record with LIMIT r1,r2 or with condition on a primary key, implementing the batches management in some other language on the server.

I'd like to know if there is some better way, in practice what I would like to achieve is to limit the cpu time assigned to a particular mysql user, but I can't find a way of doing that.

Any suggestion welcome

Out of memory - on any moderate query (2 replies)

$
0
0
I inherited a quad core server with 42 GB of RAM on a centos 6.5

Since then, mysql gets killed every now and then due to "out of memory"

at times mysql PID gets up to 38 GB even though we don't have that much processing going on, but we do have big tables (average is 35 GB)

i tried fine tuning the previous config with the help of mysqltuner, but with no luck.


what am i missing?

this is the content of my.cnf



datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

default_storage_engine = MyISAM


# MyISAM #
default_storage_engine = MyISAM
key_buffer_size = 16G
myisam_recover = FORCE,BACKUP

# SAFETY #
max_allowed_packet = 16M
max_connect_errors = 1000000

# CACHES AND LIMITS #
tmp_table_size = 15G
max_heap_table_size = 7G
query_cache_type = 1
query_cache_size = 1G
max_connections = 50
thread_cache_size = 50
open_files_limit = 65535
table_definition_cache = 1024
table_open_cache = 2048

#UTF8
character-set-server=utf8
character-sets-dir=/usr/share/mysql/charsets
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
skip-character-set-client-handshake

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
default-character-set = utf8

[mysqldump]
default-character-set = utf8

[mysqlimport]
default-character-set = utf8

[client]
default-character-set = utf8

[mysql]
default-character-set = utf8

my.cnf file with mysql tuner (1 reply)

$
0
0
I am trying to tweak my server's my.cnf file because I have been receiving numerous "down server" warnings. I know I also need to tweak other aspects of my server as well.

Processor Name Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
The number of cores= 4
Level 2 cache size = 4 x 256 KB
Level 3 cache size = 6 MB shared cache
Hard Disk 1 2TB
>Running Cent os and the latest Directadmin Panel

Total Memory 32567976 kB
Free Memory 23768148 kB
Total Swap Memory 16351224 kB
Free Swap Memory 16351224 kB
Apache 2.4.7
DirectAdmin 1.45.0
Exim 4.82
MySQL 5.5.27
Named 9.8.2rc1
sshd
dovecot 2.2.12
pure-ftpd 1.0.36
Php 5.4.25

Here is my my.cnf

[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
#skip-external-locking
local-infile=0
#skip-grant-tables
#bind-address = *
table_open_cache = 3000
#table_cache = 3000
read_buffer_size = 1M
read_rnd_buffer_size = 1M
join_buffer_size= 1M
sort_buffer_size = 2M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 256M
myisam_repair_threads= 4
myisam_recover = BACKUP
thread_cache_size = 100
query_cache_type= 1
query_cache_size= 128M
query_cache_limit= 7M
thread_concurrency = 8
tmp_table_size= 128M
max_heap_table_size= 128M
#bulk_insert_buffer_size 1G
#old_passwords= 1
log-slow-queries=/var/lib/mysql/slow.log
#slow_query_log_file=mysql-slow.log
log_queries_not_using_indexes = 1
slow_query_log = 1
long_query_time= 0.1

#other vars
net_read_timeout = 120
#skip-locking
skip-name-resolve
back_log = 100
max_connect_errors = 100
concurrent_insert= 2
open_files_limit = 8192
thread_stack = 256K
interactive_timeout = 3600
wait_timeout = 1800
max_connections = 2000
#max_user_connections = 100
key_buffer_size= 1G
connect_timeout = 30

log-bin=mysql-bin
binlog_format=mixed
server-id = 1

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 12G
innodb_additional_mem_pool_size = 4M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 100M
#innodb_log_buffer_size = 8M
innodb_table_locks = 0
innodb_file_per_table
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 300
skip-innodb-doublewrite
innodb_support_xa = 0
innodb_commit_concurrency = 8
innodb_thread_concurrency= 8

[mysqldump]
quick
quote-names
max_allowed_packet = 128M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer = 384M
sort_buffer = 384M
read_buffer = 256M
write_buffer = 256M

[mysqlhotcopy]
interactive-timeout


Here is mysql tuner output

>> MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>
[OK] Currently running supported MySQL version 5.5.27-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 103M (Tables: 201)
[--] Data in InnoDB tables: 1G (Tables: 3076)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 7M (Tables: 119)
[!!] Total fragmented tables: 179

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 4d 23h 16m 1s (29M q [68.013 qps], 277K conn, TX: 78B, RX: 9B)
[--] Reads / Writes: 63% / 37%
[--] Total buffers: 13.3G global + 5.2M per thread (2000 max threads)
[OK] Maximum possible memory usage: 23.5G (75% of installed RAM)
[OK] Slow queries: 5% (1M/29M)
[OK] Highest usage of available connections: 1% (21/2000)
[OK] Key buffer size / total MyISAM indexes: 1.0G/38.6M
[OK] Key buffer hit rate: 99.8% (16M cached / 34K reads)
[OK] Query cache efficiency: 79.2% (17M cached / 22M selects)
[!!] Query cache prunes per day: 208318
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1M sorts)
[!!] Joins performed without indexes: 18586
[!!] Temporary tables created on disk: 31% (316K on disk / 1M total)
[OK] Thread cache hit rate: 99% (21 created / 277K connections)
[!!] Table cache hit rate: 7% (3K open / 40K opened)
[OK] Open file limit used: 3% (391/10K)
[OK] Table locks acquired immediately: 99% (13M immediate / 13M locks)
[OK] InnoDB buffer pool / data size: 12.0G/1.0G
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Read this before increasing table_cache over 64: http://bit.ly/1mi7c4C
Variables to adjust:
query_cache_size (> 128M)
join_buffer_size (> 1.0M, or always use indexes with joins)
tmp_table_size (> 128M)
max_heap_table_size (> 128M)
table_cache (> 3000)

Query slows down over time (8 replies)

$
0
0
Hi,

One of my queries on mysql (it joins 4 tables) tends to get slow after some days. It normally executes in about less than a second. However after some days it takes a long time and sometimes forever to execute. I have to restart mysql and then the query executes again normally in less than a second. At an average 2 of the 4 tables contain about 3 million rows. There are indexes on these tables.Any inputs from will be helpful as I cant keep restarting mysql every week or so.

Thanks.

Queriy taking long time in OTRS (4 replies)

$
0
0
Hi all,

I need some help in optimizing queries.Please help me out

CREATE TABLE `article` (
`id` bigint(20) NOT NULL auto_increment,
`ticket_id` bigint(20) NOT NULL,
`article_type_id` smallint(6) NOT NULL,
`article_sender_type_id` smallint(6) NOT NULL,
`a_from` text,
`a_reply_to` text,
`a_to` text,
`a_cc` text,
`a_subject` text,
`a_message_id` text,
`a_in_reply_to` text,
`a_references` text,
`a_content_type` varchar(250) default NULL,
`a_body` mediumtext NOT NULL,
`incoming_time` int(11) NOT NULL,
`content_path` varchar(250) default NULL,
`valid_id` smallint(6) NOT NULL,
`create_time` datetime NOT NULL,
`create_by` int(11) NOT NULL,
`change_time` datetime NOT NULL,
`change_by` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `article_article_sender_type_id` (`article_sender_type_id`),
KEY `article_article_type_id` (`article_type_id`),
KEY `article_message_id` (`a_message_id`(255)),
KEY `article_ticket_id` (`ticket_id`),
KEY `FK_article_create_by_id` (`create_by`),
KEY `FK_article_change_by_id` (`change_by`),
KEY `FK_article_valid_id_id` (`valid_id`),
FULLTEXT KEY `a_from` (`a_from`,`a_to`,`a_cc`,`a_subject`,`a_body`)
) ENGINE=MyISAM AUTO_INCREMENT=3009398 DEFAULT CHARSET=utf8


CREATE TABLE `ticket` (
`id` bigint(20) NOT NULL auto_increment,
`tn` varchar(50) NOT NULL,
`title` varchar(255) default NULL,
`queue_id` int(11) NOT NULL,
`ticket_lock_id` smallint(6) NOT NULL,
`ticket_answered` smallint(6) NOT NULL,
`type_id` smallint(6) default NULL,
`service_id` int(11) default NULL,
`sla_id` int(11) default NULL,
`user_id` int(11) NOT NULL,
`responsible_user_id` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
`ticket_priority_id` smallint(6) NOT NULL,
`ticket_state_id` smallint(6) NOT NULL,
`group_read` smallint(6) default NULL,
`group_write` smallint(6) default NULL,
`other_read` smallint(6) default NULL,
`other_write` smallint(6) default NULL,
`customer_id` varchar(150) default NULL,
`customer_user_id` varchar(250) default NULL,
`timeout` int(11) NOT NULL,
`until_time` int(11) NOT NULL,
`escalation_time` int(11) NOT NULL,
`escalation_update_time` int(11) NOT NULL,
`escalation_response_time` int(11) NOT NULL,
`escalation_solution_time` int(11) NOT NULL,
`valid_id` smallint(6) NOT NULL,
`archive_flag` smallint(6) NOT NULL default '0',
`create_time_unix` bigint(20) NOT NULL,
`create_time` datetime NOT NULL,
`create_by` int(11) NOT NULL,
`change_time` datetime NOT NULL,
`change_by` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ticket_tn` (`tn`),
KEY `ticket_answered` (`ticket_answered`),
KEY `ticket_archive_flag` (`archive_flag`),
KEY `ticket_create_time` (`create_time`),
KEY `ticket_create_time_unix` (`create_time_unix`),
KEY `ticket_customer_id` (`customer_id`),
KEY `ticket_customer_user_id` (`customer_user_id`),
KEY `ticket_escalation_response_time` (`escalation_response_time`),
KEY `ticket_escalation_solution_time` (`escalation_solution_time`),
KEY `ticket_escalation_time` (`escalation_time`),
KEY `ticket_escalation_update_time` (`escalation_update_time`),
KEY `ticket_queue_id` (`queue_id`),
KEY `ticket_queue_view` (`ticket_state_id`,`ticket_lock_id`,`group_id`),
KEY `ticket_responsible_user_id` (`responsible_user_id`),
KEY `ticket_ticket_lock_id` (`ticket_lock_id`),
KEY `ticket_ticket_priority_id` (`ticket_priority_id`),
KEY `ticket_ticket_state_id` (`ticket_state_id`),
KEY `ticket_timeout` (`timeout`),
KEY `ticket_title` (`title`),
KEY `ticket_type_id` (`type_id`),
KEY `ticket_until_time` (`until_time`),
KEY `ticket_user_id` (`user_id`),
KEY `FK_ticket_service_id_id` (`service_id`),
KEY `FK_ticket_sla_id_id` (`sla_id`),
KEY `FK_ticket_create_by_id` (`create_by`),
KEY `FK_ticket_change_by_id` (`change_by`),
KEY `FK_ticket_valid_id_id` (`valid_id`)
) ENGINE=MyISAM AUTO_INCREMENT=1691055 DEFAULT CHARSET=utf8


CREATE TABLE `queue` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(200) NOT NULL,
`group_id` int(11) NOT NULL,
`unlock_timeout` int(11) default NULL,
`first_response_time` int(11) default NULL,
`first_response_notify` smallint(6) default NULL,
`update_time` int(11) default NULL,
`update_notify` smallint(6) default NULL,
`solution_time` int(11) default NULL,
`solution_notify` smallint(6) default NULL,
`system_address_id` smallint(6) NOT NULL,
`calendar_name` varchar(100) default NULL,
`default_sign_key` varchar(100) default NULL,
`salutation_id` smallint(6) NOT NULL,
`signature_id` smallint(6) NOT NULL,
`follow_up_id` smallint(6) NOT NULL,
`follow_up_lock` smallint(6) NOT NULL,
`comments` varchar(250) default NULL,
`valid_id` smallint(6) NOT NULL,
`create_time` datetime NOT NULL,
`create_by` int(11) NOT NULL,
`change_time` datetime NOT NULL,
`change_by` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `queue_name` (`name`),
KEY `queue_group_id` (`group_id`),
KEY `FK_queue_follow_up_id_id` (`follow_up_id`),
KEY `FK_queue_salutation_id_id` (`salutation_id`),
KEY `FK_queue_signature_id_id` (`signature_id`),
KEY `FK_queue_system_address_id_id` (`system_address_id`),
KEY `FK_queue_create_by_id` (`create_by`),
KEY `FK_queue_change_by_id` (`change_by`),
KEY `FK_queue_valid_id_id` (`valid_id`)
) ENGINE=MyISAM AUTO_INCREMENT=119 DEFAULT CHARSET=utf8



Query

mysql> explain SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st INNER JOIN queue sq ON sq.id = st.queue_id INNER JOIN article art ON st.id = art.ticket_id WHERE 1=1 AND sq.group_id IN (8, 8, 14, 14, 15, 15, 18, 18, 19, 19, 24, 24, 25, 25, 26, 26, 28, 28, 29, 29, 30, 30, 31, 31, 35, 35, 36, 36, 40, 40, 41, 41, 42, 42, 43, 43, 46, 46, 47, 47, 52, 52, 53, 53, 55, 55, 56, 56, 62, 62, 63, 63, 64, 64, 66, 66, 68, 68, 70, 70, 71, 71, 72, 72, 73, 73, 74, 74, 75, 75, 76, 76, 78, 78, 80, 80, 81, 81, 82, 82, 83, 83) AND (((art.a_body LIKE '%Jayne' ) AND (art.a_body LIKE 'Twyford%' ) )) ORDER BY st.create_time_unix DESC LIMIT 20000000;
+----+-------------+-------+--------+-------------------------+---------+---------+--------------------+---------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+-------------------------+---------+---------+--------------------+---------+----------------------------------------------+
| 1 | SIMPLE | art | ALL | article_ticket_id | NULL | NULL | NULL | 2905614 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | st | eq_ref | PRIMARY,ticket_queue_id | PRIMARY | 8 | otrs.art.ticket_id | 1 | |
| 1 | SIMPLE | sq | eq_ref | PRIMARY,queue_group_id | PRIMARY | 4 | otrs.st.queue_id | 1 | Using where; Distinct |
+----+-------------+-------+--------+-------------------------+---------+---------+--------------------+---------+----------------------------------------------+
3 rows in set (0.00 sec)

Please help me to sort out "using temporary using filesort" by optimizing queries. I tried all methods but not able to get through

It would be great if someone helps me

Regards,
Rajkumar

Query attacks against read-only database (1 reply)

$
0
0
Hello,

Consider a set of static data of which I want people to run their own queries against (via Python).

What methods might be available to prevent someone from either purposely (or accidentally) DOS'ing the server via some sort of bad command? ie - a ton of joins on virtual tables. Monitoring the resources of Python online would not suffice, particularly if they have caused the mysql process to run away.

The data would actually be read-only and would not change.

Thank you.

concurrent_insert (no replies)

$
0
0
Hi,

Does anyone know that if 'concurrent_insert' being set to 'ALWAYS' has any negtive impact to mysql's performance?

Thanks!!

Delete slow... randomly (no replies)

$
0
0
Good evening all.
I'm fighting with a strange behaviour of my "MySQL 5.6.17 Community Edition" server running on a virtual machine with 1GB RAM (I know, it isn't too much, but is good for our tests).

[The Problem]
some DELETEs are too slow. Randomly! They take less then 1 second to run, but randomly take 3 or 7 seconds, slowing down the process.

[The running process]
I have a PHP process running periodically with crontab that executes some queries (2xSELECT and a bunch of DELETEs). In practice: I first do a SELECT of n elements and before using theme, I DELETE these elements so the next cronjob can use/select the next n elements of the queue. Yes: this process works as a queue manager.
Occasionally, one or two of these DELETEs slow down at 3-7 (and more) seconds to be completed.

[My question]
Can you help me to understand WHY these DELETEs run slowly in a random way?
Please ask me other info if you need for understanding better the context.


#################################### SOME DATA FROM LOG #################################

Here is a sample DELETE from slow-log:
----------------------------------
# Time: 140602 16:44:45
# User@Host: metest[metest] @ localhost [] Id: 168
# Query_time: 4.780873 Lock_time: 0.000084 Rows_sent: 0 Rows_examined: 1
SET timestamp=1401720285;
DELETE FROM myDB.myTABLE WHERE tetUID="283924a1b9771f1ae7b0edf342knbx1z" AND cudUID="2c9c1a5da29edda75d9848cd1dhmt9kr";
----------------------------------

And this is my.cnf (based on suggestions of Percona wizard):
----------------------------------------------
[mysqld]
server-id=20
log_bin=/var/log/mysqld/mysql-bin.log
relay-log=/var/log/mysqld/mysql-relay-bin.log
binlog_do_db=sisr2013
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
skip-name-resolve
skip_host_cach
slow-query-log = 1
slow-query-log-file = /var/log/mysqld/mysql-slow-query.log
long_query_time = 3

innodb-flush-method = O_DIRECT
innodb-log-files-in-group = 2
innodb-log-file-size = 64M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 592M

tmp-table-size = 32M
max-heap-table-size = 32M
query-cache-type = 0
query-cache-size = 0
max-connections = 500
thread-cache-size = 50
open-files-limit = 65535
table-definition-cache = 1024
table-open-cache = 2048
----------------------------------------------

Using "htop" the Memory and CPU load "seems" good.

[The table structure]

Field Type Collation Null Key Default Extra Privileges Comment
------------------- ------------ ----------------- ------ ------ ------- ------ ------------------------------- ---------
tetUID varchar(32) latin1_swedish_ci NO PRI (NULL) select,insert,update,references
cudUID varchar(32) latin1_swedish_ci NO PRI (NULL) select,insert,update,references
cEmailAddress varchar(255) latin1_swedish_ci NO (NULL) select,insert,update,references
msgWeight int(11) (NULL) NO (NULL) select,insert,update,references
msgCreateDate datetime (NULL) YES (NULL) select,insert,update,references

PRIMARY KEY= tetUID + cudUID

'Compound' INDEXes (no replies)

$
0
0
Dear Rick,

I am referring to following url that suggested by you =)
http://mysql.rjweb.org/doc.php/index1

I have some questions..
(A) "Covering": INDEX(last_name, first_name, term)" is new to me.
Previously I thought only fields used in WHERE condition need to be indexed.
(QA1) What if I have the query as following:
SELECT term, seq
FROM Presidents
WHERE last_name = 'Johnson'
AND first_name = 'Andrew';
Would you recommend me to have an index key (last_name, first_name, term, seq)?
Same question if "seq" is not a primary key.

(QA2) If I have more than 5 fields to be selected, is it convenient to create a long index key with multiple fields?
SELECY term, age, dob, father_name, mother_name, wife_name
FROM Presidents
WHERE last_name = 'Johnson'
AND first_name - 'Andrew';
INDEX KEY: (last_name, first_name, term, age, dob, father_name, mother_name, wife_name)


(B) Not quite understand with following terms:
⚈ What would happen if you shuffled the fields in the WHERE clause?
Answer: The order of ANDed things does not matter.
⚈ What would happen if you shuffled the fields in the INDEX?
Answer: It may make a huge difference. More in a minute.

(QB1) No matter how i shuffle the fields in the WHERE clause, it should depend on the fields order of the INDEX that I created, is this correct?

DML operations slow down (no replies)

$
0
0
our application is developed with hibernate,spring and db as mysql and its deployed in JBoss

When server is restarted, application & DB performance are good. After 5 days, all the DML operations are getting slowdown. each query(DML) execution is getting increased by 15ms to 25 ms.

Can you please help me out on resolving the issue

Thanks in advance

how to configure my.cnf for mysql 5.1, using too much cpu? (no replies)

$
0
0
I am new Database engineer. I am having trouble in my server which is using too much CPU on database query(simple count statement). I have googled about it, so i found out it depends on system configuration. So I am posting the same. Here are the following stats of my server:

32 GB Ram
2.7 TB hard drive
150 GB database size(with 2 myisam tables contains billions of record)
mysql version 5.1
Centos
And here's my my.cnf file:

#datadir=/var/lib/mysql
datadir=/home/mysql
socket=/var/lib/mysql/mysql.sock
#socket=/home/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
There is not much details I think my.cnf is not configured according to system configuration.

Please let me know what is the best way I can set parameters in my.cnf so mysql works properly.

Output of Show variable;
SHOW VARIABLES;

| Variable_name | Value |
+-----------------------------------------+-------------------------------------------------------------------------------------------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
| autocommit | ON |
| automatic_sp_privileges | ON |
| back_log | 50 |
| basedir | / |
| big_tables | OFF |
| binlog_cache_size | 32768 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_format | STATEMENT |
| bulk_insert_buffer_size | 8388608 |
| character_sets_dir | /usr/share/mysql/charsets/|
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
| completion_type | 0 |
| concurrent_insert | 1 |
| connect_timeout | 10 |
| datadir | /home/mysql/ |
| default_week_format | 0 |
| delay_key_write | ON |
| delayed_insert_limit | 100 |
| delayed_insert_timeout | 300 |
| delayed_queue_size | 1000 |
| div_precision_increment | 4 |
| engine_condition_pushdown | ON |
| error_count | 0
| event_scheduler | OFF
| expire_logs_days | 0
| flush | OFF
| flush_time | 0
| foreign_key_checks | ON
| general_log | OFF
| general_log_file | /home/mysql/localhost.log |
| group_concat_max_len | 1024
| identity | 0
| ignore_builtin_innodb | OFF
| innodb_adaptive_hash_index | ON
| innodb_additional_mem_pool_size | 1048576
| innodb_autoextend_increment | 8
| innodb_autoinc_lock_mode | 1
| innodb_buffer_pool_size | 8388608
| innodb_checksums | ON
| innodb_commit_concurrency | 0
| innodb_concurrency_tickets | 500
| innodb_data_file_path | ibdata1:10M:autoextend
| innodb_doublewrite | ON
| innodb_fast_shutdown | 1
| innodb_file_io_threads | 4
| innodb_file_per_table | OFF
| innodb_flush_log_at_trx_commit | 1
| innodb_flush_method |
| innodb_force_recovery | 0
| innodb_lock_wait_timeout | 50
| innodb_locks_unsafe_for_binlog | OFF
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880
| innodb_log_files_in_group | 2
| innodb_log_group_home_dir | ./
| innodb_max_dirty_pages_pct | 90
| innodb_max_purge_lag | 0
| innodb_mirrored_log_groups | 1
| innodb_open_files | 300
| innodb_rollback_on_timeout | OFF
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON
| innodb_support_xa | ON
| innodb_sync_spin_loops | 20
| innodb_table_locks | ON |
| innodb_thread_concurrency | 8
| innodb_thread_sleep_delay | 10000
| innodb_use_legacy_cardinality_algorithm | ON
| insert_id | 0
| interactive_timeout | 28800
| join_buffer_size | 131072
| keep_files_on_create | OFF
| key_buffer_size | 8384512
| key_cache_age_threshold | 300
| key_cache_block_size | 1024
| key_cache_division_limit | 100
| long_query_time | 10.000000 |
| max_allowed_packet | 1048576 |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_connect_errors | 10 |
| max_connections | 151 |
| max_delayed_threads | 20 |
| max_error_count | 64 |
| max_heap_table_size | 16777216 |
| max_insert_delayed_threads | 20 |
| max_join_size | 18446744073709551615 |
| max_length_for_sort_data | 1024 |
| max_long_data_size | 1048576 |
| max_prepared_stmt_count | 16382 |
| max_relay_log_size | 0 |
| max_seeks_for_key | 18446744073709551615 |
| max_sort_length | 1024 |
| max_sp_recursion_depth | 0 |
| max_tmp_tables | 32 |
| max_user_connections | 0 |
| max_write_lock_count | 18446744073709551615 |
| min_examined_row_limit | 0 |
| multi_range_count | 256 |
| myisam_data_pointer_size | 6 |
| myisam_max_sort_file_size | 9223372036853727232 |
| myisam_mmap_size | 18446744073709551615 |
| myisam_recover_options | OFF |
| myisam_repair_threads | 1 |
| myisam_sort_buffer_size | 8388608 |
| myisam_stats_method | nulls_unequal |
| myisam_use_mmap | OFF |
| net_buffer_length | 16384 |
| net_read_timeout | 30 |
| net_retry_count | 10 |
| net_write_timeout | 60 |
| open_files_limit | 1024 |
| optimizer_prune_level | 1 |
| optimizer_search_depth | 62 |
| optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on |
| pid_file | /home/mysql/localhost.localdomain.pid |
| plugin_dir | /usr/lib64/mysql/plugin |
| port | 3306 |
| preload_buffer_size | 32768 |
| profiling | OFF |
| profiling_history_size | 15 |
| protocol_version | 10 |
| pseudo_thread_id | 18 |
| query_alloc_block_size | 8192 |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 0 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
| query_prealloc_size | 8192 |
| range_alloc_block_size | 4096 |
| read_buffer_size | 131072 |
| read_only | OFF |
| read_rnd_buffer_size | 262144 |
| rpl_recovery_rank | 0 |
| secure_auth | OFF | |skip_external_locking | ON |
| slow_launch_time | 2 |
| slow_query_log | OFF |
| slow_query_log_file | /home/mysql/localhost-slow.log |
| socket | /var/lib/mysql/mysql.sock |
| sort_buffer_size | 2097144 |
| sql_auto_is_null | ON |
| sql_big_selects | ON |
| sql_big_tables | OFF |
| sql_buffer_result | OFF |
| sql_log_bin | ON |
| sql_log_off | OFF |
| sql_log_update | ON |
| sql_low_priority_updates | OFF |
| sql_max_join_size | 18446744073709551615 |
| sql_mode | |
| sql_notes | ON |
| sql_quote_show_create | ON |
| sql_safe_updates | OFF |
| sql_select_limit | 18446744073709551615 |
| sql_slave_skip_counter | |
| sql_warnings | |
| storage_engine | MyISAM |
| table_definition_cache | 256 |
| table_lock_wait_timeout | 50 |
| table_open_cache | 64 |
| table_type | MyISAM |
| thread_cache_size | 0 |
| thread_handling | one-thread-per-connection |
| thread_stack | 262144 |
|
| timestamp | 1401967364 |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
| transaction_alloc_block_size | 8192 |
| transaction_prealloc_size | 4096 |
| tx_isolation | REPEATABLE-READ

Superkey vs Primary Key (3 replies)

$
0
0
What's the best Way in this case?

I've a Example Database Table:

+-------+---------+
| name | phone |
+-------+---------+
| Mario | 01345 |
| Hans | 02231 |
+-------+---------+

Here, i've 2 ways.
First way is to create a Superkey with name and phone.
The second way is to create a fake id as Primary Key with a new Column id.
What's better from performence or memory view?

Slow query when joining 2 very large tables with Group and Order (no replies)

$
0
0
Hello everyone.

I would like to ask for help in optimizing a query for a social network project of mine.

Short explanation:
The users in this network are specified by the following attributes:
- weight
- height
- interests and
- roles

Interests and roles are many to many relationships. Interests are all topics a user is interested in (e.g. hiking, cars, ...). Roles define the user's role on the network (e.g. being married, being divorced, ...). There are 32 roles, hence I mapped them in a column via bitmasks.
Interests on the other hand are more manifold, hence I need a mapping table, that maps user profiles to interests.

I am trying to query over all users, given height and weight ranges, and several preferred roles and interests. The results shall be sorted by the number of role matches or interest matches.

My current query looks like this:

SELECT SQL_NO_CACHE map.profile_id, COUNT(map.profile_id) as num_matches_interests, profile.num_matches_roles
FROM tbl_profile_interest_map map

INNER JOIN
(
SELECT id, BIT_COUNT(role&14) AS num_matches_roles
FROM tbl_profile
WHERE weight>=60 AND weight<=90
AND height>=120 AND height<=190
AND (role & 14) != 0
) AS profile ON profile.id=map.profile_id


WHERE map.interest_id IN (24, 25, 26, 27, 28)
GROUP BY map.profile_id
ORDER BY num_matches_roles DESC


I filled the tables with random sample data. The scheme in detail is as follows:

tbl_profile (10.499.307 rows):
------------------------------
id mediumint(8)
gender_id tinyint(3)
weight tinyint(3)
height tinyint(3)
role bigint(20)


tbl_profile_interest_map (262.482.675 rows):
--------------------------------------------
id int(10)
profile_id mediumint(8)
interest_id smallint(5)


The query itself runs for ages (several minutes) on a Cloud-server @Digital Ocean with 2GB RAM, 2 CPUs (2,4 GHz each).

Here is the explain output:

id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2422568
Extra: Using temporary; Using filesort
***************************************
id: 2
select_type: PRIMARY
table: map
type: ref
possible_keys: idx_profileID_interestID (unique), idx_profileID, idx_interestID
key: idx_profileID_interestID
key_len: 3
ref: profile.id
rows: 12
Extra: Using where; Using index
***************************************
id: 3
select_type: DERIVED
table: tbl_profile
type: range
possible_keys: idx_weight_height_role
key: idx_weight_height_role
key_len: 10
ref: NULL
rows: 5249710
Extra: Using where; Using index



I reckon I have the following problems:
- querying over profiles is fast, but loading all rows takes too long
- querying over the relation mapping table tbl_profile_interest_map also takes ages because of loading that many rows, grouping and ordering them

I think I could speed things up, if I paginated the results correctly with indexes - of course, simply limiting and offsetting the results is not the best shot. But how can I do that efficiently, when ordering needs to be done by the dynamically computed values num_matches_roles or num_matches_interests, for which I have no index for?

Or do you guys recommend other optimizations?

I really appreciate your tips. I can't get my head around this silly issue.

sync_binlog=1 and innodb_flush_log_at_trx_commit = 1 killing write performance (no replies)

$
0
0
setup: mariadb 10 (latest stable from their debian repo)
debian 7.5 64 bit
filesystem: ext3 with relatime


Replicating from one master to one slave. Slave is in total standby (not a read slave). If master fails for any
kind of reason (network outage, mysqld crashes, etc.) we switch to slave which is located at another physical
location (east coast vs west coast). Whatever did not reach slave at that point is discarded. Slave becomes the
new master. Slave db is dumped to restore old master to new slave.


We currently use the recommended settings:

sync-binlog = 1
innodb_flush_log_at_trx_commit = 1

But performance is TERRIBLE. Disabling BOTH settings gives us an order of magnitude improvement in writes.

We have done no tuning of kernel based caches or HDD caches. We use software RAID 1 (2 disks).

$ hdparm /dev/sda

/dev/sda:
multcount = 16 (on)
IO_support = 0 (default)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30400/255/63, sectors = 488390625, start = 0
$ cat /proc/sys/vm/drop_caches
0
$ cat /proc/sys/vm/dirty_expire_centisecs
3000
$ cat /proc/sys/vm/dirty_writeback_centisecs
500

The question we have is, considering our replication strategy, would it be safe to run with sync-binlog = 0
(or a high number like 100) AND innodb_flush_log_at_trx_commit = 0?

Are there any other NEWER settings worth trying to make the disk flushing less of a performance killer? I was
under the impression that 5.6 and newer mysql drastically improved these sorts of issues.

GLOBAL VARS and STATUS FOLLOWS
=====================================

aria_block_size 8192
aria_checkpoint_interval 30
aria_checkpoint_log_activity 1048576
aria_force_start_after_recovery_failures 0
aria_group_commit none
aria_group_commit_interval 0
aria_log_file_size 1073741824
aria_log_purge_type immediate
aria_max_sort_file_size 9223372036853727232
aria_page_checksum ON
aria_pagecache_age_threshold 300
aria_pagecache_buffer_size 134217728
aria_pagecache_division_limit 100
aria_recover NORMAL
aria_repair_threads 1
aria_sort_buffer_size 268434432
aria_stats_method nulls_unequal
aria_sync_log_dir NEWFILE
aria_used_for_temp_tables ON
auto_increment_increment 1
auto_increment_offset 1
autocommit ON
automatic_sp_privileges ON
back_log 65
basedir /usr
big_tables OFF
binlog_annotate_row_events OFF
binlog_cache_size 32768
binlog_checksum NONE
binlog_commit_wait_count 0
binlog_commit_wait_usec 100000
binlog_direct_non_transactional_updates OFF
binlog_format STATEMENT
binlog_optimize_thread_scheduling ON
binlog_stmt_cache_size 32768
bulk_insert_buffer_size 16777216
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_filesystem binary
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection latin1_swedish_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci
completion_type NO_CHAIN
concurrent_insert AUTO
connect_timeout 5
datadir /var/lib/mysql/
date_format %Y-%m-%d
datetime_format %Y-%m-%d %H:%i:%s
deadlock_search_depth_long 15
deadlock_search_depth_short 4
deadlock_timeout_long 50000000
deadlock_timeout_short 10000
debug_no_thread_alarm OFF
default_regex_flags
default_storage_engine InnoDB
default_week_format 0
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
div_precision_increment 4
event_scheduler OFF
expensive_subquery_limit 100
expire_logs_days 0
extra_max_connections 1
extra_port 0
flush OFF
flush_time 0
foreign_key_checks ON
ft_boolean_syntax + -><()~*:""&|
ft_max_word_len 84
ft_min_word_len 4
ft_query_expansion_limit 20
ft_stopword_file (built-in)
general_log OFF
group_concat_max_len 1024
gtid_binlog_pos 0-2-8061682
gtid_binlog_state 0-2-8061682
gtid_current_pos 0-2-8061682
gtid_domain_id 0
gtid_ignore_duplicates OFF
gtid_slave_pos 0-1-5800710
gtid_strict_mode OFF
have_compress YES
have_crypt YES
have_dynamic_loading YES
have_geometry YES
have_openssl YES
have_profiling YES
have_query_cache YES
have_rtree_keys YES
have_ssl DISABLED
have_symlink YES
histogram_size 0
histogram_type SINGLE_PREC_HB
host_cache_size 128
ignore_builtin_innodb OFF
ignore_db_dirs
init_connect
init_file
init_slave
innodb_adaptive_flushing ON
innodb_adaptive_flushing_lwm 10
innodb_adaptive_hash_index ON
innodb_adaptive_hash_index_partitions 1
innodb_adaptive_max_sleep_delay 150000
innodb_additional_mem_pool_size 20971520
innodb_api_bk_commit_interval 5
innodb_api_disable_rowlock OFF
innodb_api_enable_binlog OFF
innodb_api_enable_mdl OFF
innodb_api_trx_level 0
innodb_autoextend_increment 64
innodb_autoinc_lock_mode 1
innodb_buffer_pool_dump_at_shutdown OFF
innodb_buffer_pool_dump_now OFF
innodb_buffer_pool_filename ib_buffer_pool
innodb_buffer_pool_instances 8
innodb_buffer_pool_load_abort OFF
innodb_buffer_pool_load_at_startup OFF
innodb_buffer_pool_load_now OFF
innodb_buffer_pool_populate OFF
innodb_buffer_pool_size 536870912
innodb_change_buffer_max_size 25
innodb_change_buffering all
innodb_checksum_algorithm innodb
innodb_checksums ON
innodb_cleaner_lsn_age_factor high_checkpoint
innodb_cmp_per_index_enabled OFF
innodb_commit_concurrency 0
innodb_compression_failure_threshold_pct 5
innodb_compression_level 6
innodb_compression_pad_pct_max 50
innodb_concurrency_tickets 5000
innodb_corrupt_table_action assert
innodb_data_file_path ibdata1:12M:autoextend
innodb_data_home_dir
innodb_disable_sort_file_cache OFF
innodb_doublewrite ON
innodb_empty_free_list_algorithm backoff
innodb_fake_changes OFF
innodb_fast_shutdown 1
innodb_file_format Antelope
innodb_file_format_check ON
innodb_file_format_max Antelope
innodb_file_per_table ON
innodb_flush_log_at_timeout 1
innodb_flush_log_at_trx_commit 1
innodb_flush_method O_DIRECT
innodb_flush_neighbors 1
innodb_flushing_avg_loops 30
innodb_force_load_corrupted OFF
innodb_force_recovery 0
innodb_foreground_preflush exponential_backoff
innodb_ft_aux_table
innodb_ft_cache_size 8000000
innodb_ft_enable_diag_print OFF
innodb_ft_enable_stopword ON
innodb_ft_max_token_size 84
innodb_ft_min_token_size 3
innodb_ft_num_word_optimize 2000
innodb_ft_result_cache_limit 2000000000
innodb_ft_server_stopword_table
innodb_ft_sort_pll_degree 2
innodb_ft_total_cache_size 640000000
innodb_ft_user_stopword_table
innodb_io_capacity 400
innodb_io_capacity_max 2000
innodb_kill_idle_transaction 0
innodb_large_prefix OFF
innodb_lock_wait_timeout 50
innodb_locking_fake_changes ON
innodb_locks_unsafe_for_binlog OFF
innodb_log_arch_dir ./
innodb_log_arch_expire_sec 0
innodb_log_archive OFF
innodb_log_block_size 512
innodb_log_buffer_size 4194304
innodb_log_checksum_algorithm innodb
innodb_log_compressed_pages ON
innodb_log_file_size 67108864
innodb_log_files_in_group 2
innodb_log_group_home_dir ./
innodb_lru_scan_depth 1024
innodb_max_bitmap_file_size 104857600
innodb_max_changed_pages 1000000
innodb_max_dirty_pages_pct 75
innodb_max_dirty_pages_pct_lwm 0
innodb_max_purge_lag 0
innodb_max_purge_lag_delay 0
innodb_mirrored_log_groups 1
innodb_monitor_disable
innodb_monitor_enable
innodb_monitor_reset
innodb_monitor_reset_all
innodb_old_blocks_pct 37
innodb_old_blocks_time 1000
innodb_online_alter_log_max_size 134217728
innodb_open_files 400
innodb_optimize_fulltext_only OFF
innodb_page_size 16384
innodb_print_all_deadlocks OFF
innodb_purge_batch_size 300
innodb_purge_threads 1
innodb_random_read_ahead OFF
innodb_read_ahead_threshold 56
innodb_read_io_threads 4
innodb_read_only OFF
innodb_replication_delay 0
innodb_rollback_on_timeout OFF
innodb_rollback_segments 128
innodb_sched_priority_cleaner 19
innodb_show_locks_held 10
innodb_show_verbose_locks 0
innodb_sort_buffer_size 1048576
innodb_spin_wait_delay 6
innodb_stats_auto_recalc ON
innodb_stats_method nulls_equal
innodb_stats_on_metadata OFF
innodb_stats_persistent ON
innodb_stats_persistent_sample_pages 20
innodb_stats_sample_pages 8
innodb_stats_transient_sample_pages 8
innodb_status_output OFF
innodb_status_output_locks OFF
innodb_strict_mode OFF
innodb_support_xa ON
innodb_sync_array_size 1
innodb_sync_spin_loops 30
innodb_table_locks ON
innodb_thread_concurrency 0
innodb_thread_sleep_delay 10000
innodb_track_changed_pages OFF
innodb_undo_directory .
innodb_undo_logs 128
innodb_undo_tablespaces 0
innodb_use_atomic_writes OFF
innodb_use_fallocate OFF
innodb_use_global_flush_log_at_trx_commit ON
innodb_use_native_aio ON
innodb_use_stacktrace OFF
innodb_use_sys_malloc ON
innodb_version 5.6.17-65.0
innodb_write_io_threads 4
interactive_timeout 120
join_buffer_size 262144
join_buffer_space_limit 2097152
join_cache_level 2
keep_files_on_create OFF
key_buffer_size 67108864
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
key_cache_segments 0
large_files_support ON
large_page_size 0
large_pages OFF
lc_messages en_US
lc_messages_dir /usr/share/mysql
lc_time_names en_US
license GPL
local_infile ON
lock_wait_timeout 31536000
locked_in_memory OFF
log_bin ON
log_bin_trust_function_creators ON
log_error
log_output FILE
log_queries_not_using_indexes OFF
log_slave_updates OFF
log_slow_filter admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk
log_slow_rate_limit 1
log_slow_verbosity query_plan
log_warnings 2
long_query_time 2.000000
low_priority_updates OFF
lower_case_file_system OFF
lower_case_table_names 0
master_verify_checksum OFF
max_allowed_packet 16777216
max_binlog_cache_size 18446744073709547520
max_binlog_size 104857600
max_binlog_stmt_cache_size 18446744073709547520
max_connect_errors 100
max_connections 65
max_delayed_threads 20
max_error_count 64
max_heap_table_size 33554432
max_insert_delayed_threads 20
max_join_size 18446744073709551615
max_length_for_sort_data 1024
max_long_data_size 16777216
max_prepared_stmt_count 16382
max_relay_log_size 104857600
max_seeks_for_key 4294967295
max_sort_length 1024
max_sp_recursion_depth 0
max_tmp_tables 32
max_user_connections 60
max_write_lock_count 4294967295
metadata_locks_cache_size 1024
metadata_locks_hash_instances 8
min_examined_row_limit 0
mrr_buffer_size 262144
multi_range_count 256
myisam_block_size 1024
myisam_data_pointer_size 6
myisam_max_sort_file_size 9223372036853727232
myisam_mmap_size 18446744073709551615
myisam_recover_options BACKUP
myisam_repair_threads 1
myisam_sort_buffer_size 67108864
myisam_stats_method nulls_unequal
myisam_use_mmap OFF
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 30
old OFF
old_alter_table OFF
old_mode
old_passwords OFF
open_files_limit 1024
optimizer_prune_level 1
optimizer_search_depth 62
optimizer_selectivity_sampling_limit 100
optimizer_switch index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=off
optimizer_use_condition_selectivity 1
performance_schema ON
performance_schema_accounts_size 10
performance_schema_digests_size 1000
performance_schema_events_stages_history_long_size 100
performance_schema_events_stages_history_size 5
performance_schema_events_statements_history_long_size 100
performance_schema_events_statements_history_size 5
performance_schema_events_waits_history_long_size 100
performance_schema_events_waits_history_size 5
performance_schema_hosts_size 20
performance_schema_max_cond_classes 80
performance_schema_max_cond_instances 645
performance_schema_max_file_classes 50
performance_schema_max_file_handles 32768
performance_schema_max_file_instances 1556
performance_schema_max_mutex_classes 200
performance_schema_max_mutex_instances 2995
performance_schema_max_rwlock_classes 40
performance_schema_max_rwlock_instances 1628
performance_schema_max_socket_classes 10
performance_schema_max_socket_instances 84
performance_schema_max_stage_classes 150
performance_schema_max_statement_classes 180
performance_schema_max_table_handles 445
performance_schema_max_table_instances 445
performance_schema_max_thread_classes 50
performance_schema_max_thread_instances 128
performance_schema_session_connect_attrs_size 512
performance_schema_setup_actors_size 100
performance_schema_setup_objects_size 100
performance_schema_users_size 5
pid_file /var/run/mysqld/mysqld.pid
plugin_dir /usr/lib/mysql/plugin/
plugin_maturity unknown
port 3306
preload_buffer_size 32768
profiling OFF
profiling_history_size 15
progress_report_time 5
protocol_version 10
query_alloc_block_size 8192
query_cache_limit 262144
query_cache_min_res_unit 4096
query_cache_size 33554432
query_cache_strip_comments OFF
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192
range_alloc_block_size 4096
read_buffer_size 262144
read_only OFF
read_rnd_buffer_size 524288
relay_log /var/log/mysql/relay-bin
relay_log_index /var/log/mysql/relay-bin.index
relay_log_info_file /var/log/mysql/relay-bin.info
relay_log_purge ON
relay_log_recovery OFF
relay_log_space_limit 0
replicate_annotate_row_events OFF
replicate_do_db
replicate_do_table
replicate_events_marked_for_skip replicate
replicate_ignore_db
replicate_ignore_table
replicate_wild_do_table
replicate_wild_ignore_table
report_host
report_password
report_port 3306
report_user
rowid_merge_buff_size 8388608
rpl_recovery_rank 0
secure_auth OFF
secure_file_priv
server_id 2
skip_external_locking ON
skip_name_resolve OFF
skip_networking OFF
skip_show_database OFF
slave_compressed_protocol OFF
slave_ddl_exec_mode IDEMPOTENT
slave_domain_parallel_threads 0
slave_exec_mode STRICT
slave_load_tmpdir /tmp
slave_max_allowed_packet 1073741824
slave_net_timeout 3600
slave_parallel_max_queued 131072
slave_parallel_threads 0
slave_skip_errors OFF
slave_sql_verify_checksum ON
slave_transaction_retries 10
slave_type_conversions
slow_launch_time 2
slow_query_log ON
slow_query_log_file /var/log/mysql/mysql-slow.log
socket /var/run/mysqld/mysqld.sock
sort_buffer_size 2097152
sql_auto_is_null OFF
sql_big_selects ON
sql_buffer_result OFF
sql_log_bin ON
sql_log_off OFF
sql_mode
sql_notes ON
sql_quote_show_create ON
sql_safe_updates OFF
sql_select_limit 18446744073709551615
sql_slave_skip_counter 0
sql_warnings OFF
ssl_ca
ssl_capath
ssl_cert
ssl_cipher
ssl_crl
ssl_crlpath
ssl_key
storage_engine InnoDB
stored_program_cache 256
sync_binlog 1
sync_frm ON
sync_master_info 0
sync_relay_log 0
sync_relay_log_info 0
system_time_zone PDT
table_definition_cache 400
table_open_cache 128
thread_cache_size 32
thread_concurrency 8
thread_handling one-thread-per-connection
thread_pool_idle_timeout 60
thread_pool_max_threads 500
thread_pool_oversubscribe 3
thread_pool_size 4
thread_pool_stall_limit 500
thread_stack 196608
time_format %H:%i:%s
time_zone SYSTEM
timed_mutexes OFF
tmp_table_size 33554432
tmpdir /tmp
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
tx_isolation REPEATABLE-READ
tx_read_only OFF
unique_checks ON
updatable_views_with_limit YES
use_stat_tables NEVER
userstat OFF
version 10.0.11-MariaDB-1~wheezy-log
version_comment mariadb.org binary distribution
version_compile_machine x86_64
version_compile_os debian-linux-gnu
version_malloc_library bundled jemalloc
wait_timeout 15

GLOBAL STATUS
==================================================

Aborted_clients 53
Aborted_connects 2981
Access_denied_errors 1
Aria_pagecache_blocks_not_flushed 0
Aria_pagecache_blocks_unused 15737
Aria_pagecache_blocks_used 2
Aria_pagecache_read_requests 4064
Aria_pagecache_reads 520
Aria_pagecache_write_requests 592
Aria_pagecache_writes 0
Aria_transaction_log_syncs 0
Binlog_commits 388754
Binlog_group_commits 380721
Binlog_snapshot_file mariadb-bin.000717
Binlog_snapshot_position 102400030
Binlog_bytes_written 181612989
Binlog_cache_disk_use 1
Binlog_cache_use 388761
Binlog_stmt_cache_disk_use 0
Binlog_stmt_cache_use 0
Busy_time 0.000000
Bytes_received 490713275
Bytes_sent 5297754877
Com_admin_commands 7
Com_alter_db 0
Com_alter_db_upgrade 0
Com_alter_event 0
Com_alter_function 0
Com_alter_procedure 0
Com_alter_server 0
Com_alter_table 0
Com_alter_tablespace 0
Com_analyze 0
Com_assign_to_keycache 0
Com_begin 139167
Com_binlog 0
Com_call_procedure 0
Com_change_db 263
Com_change_master 0
Com_check 0
Com_checksum 261
Com_commit 139153
Com_create_db 0
Com_create_event 0
Com_create_function 0
Com_create_index 0
Com_create_procedure 0
Com_create_role 0
Com_create_server 0
Com_create_table 0
Com_create_trigger 0
Com_create_udf 0
Com_create_user 0
Com_create_view 0
Com_dealloc_sql 0
Com_delete 9944
Com_delete_multi 4
Com_do 0
Com_drop_db 0
Com_drop_event 0
Com_drop_function 0
Com_drop_index 0
Com_drop_procedure 0
Com_drop_role 0
Com_drop_server 0
Com_drop_table 0
Com_drop_trigger 0
Com_drop_user 0
Com_drop_view 0
Com_empty_query 0
Com_execute_sql 0
Com_flush 8
Com_get_diagnostics 0
Com_grant 0
Com_grant_role 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_help 0
Com_insert 45177
Com_insert_select 0
Com_install_plugin 0
Com_kill 0
Com_load 0
Com_lock_tables 0
Com_optimize 0
Com_preload_keys 0
Com_prepare_sql 0
Com_purge 0
Com_purge_before_date 1
Com_release_savepoint 3
Com_rename_table 0
Com_rename_user 0
Com_repair 0
Com_replace 0
Com_replace_select 0
Com_reset 0
Com_resignal 0
Com_revoke 0
Com_revoke_all 0
Com_revoke_role 0
Com_rollback 11
Com_rollback_to_savepoint 216
Com_savepoint 3
Com_select 1331400
Com_set_option 23013
Com_show_authors 0
Com_show_binlog_events 0
Com_show_binlogs 597
Com_show_charsets 0
Com_show_client_statistics 0
Com_show_collations 0
Com_show_contributors 0
Com_show_create_db 0
Com_show_create_event 0
Com_show_create_func 3
Com_show_create_proc 0
Com_show_create_table 602
Com_show_create_trigger 0
Com_show_databases 4
Com_show_engine_logs 0
Com_show_engine_mutex 0
Com_show_engine_status 613
Com_show_errors 0
Com_show_events 0
Com_show_explain 0
Com_show_fields 296
Com_show_function_status 0
Com_show_grants 0
Com_show_index_statistics 0
Com_show_keys 20
Com_show_master_status 0
Com_show_open_tables 0
Com_show_plugins 0
Com_show_privileges 0
Com_show_procedure_status 0
Com_show_processlist 0
Com_show_profile 0
Com_show_profiles 11
Com_show_relaylog_events 0
Com_show_slave_hosts 0
Com_show_slave_status 1194
Com_show_status 652
Com_show_storage_engines 0
Com_show_table_statistics 0
Com_show_table_status 216
Com_show_tables 11
Com_show_triggers 222
Com_show_user_statistics 0
Com_show_variables 623
Com_show_warnings 0
Com_shutdown 0
Com_signal 0
Com_start_all_slaves 0
Com_start_slave 0
Com_stmt_close 1567132
Com_stmt_execute 1567132
Com_stmt_fetch 0
Com_stmt_prepare 1567132
Com_stmt_reprepare 0
Com_stmt_reset 0
Com_stmt_send_long_data 0
Com_stop_all_slaves 0
Com_stop_slave 447015
Com_truncate 0
Com_uninstall_plugin 0
Com_unlock_tables 3
Com_update 365053
Com_update_multi 0
Com_xa_commit 0
Com_xa_end 0
Com_xa_prepare 0
Com_xa_recover 0
Com_xa_rollback 0
Com_xa_start 0
Compression OFF
Connection_errors_accept 0
Connection_errors_internal 0
Connection_errors_max_connections 0
Connection_errors_peer_address 0
Connection_errors_select 0
Connection_errors_tcpwrap 0
Connections 451580
Cpu_time 0.000000
Created_tmp_disk_tables 557
Created_tmp_files 13
Created_tmp_tables 95668
Delayed_errors 0
Delayed_insert_threads 0
Delayed_writes 0
Empty_queries 326408
Executed_events 0
Executed_triggers 0
Feature_dynamic_columns 0
Feature_fulltext 0
Feature_gis 0
Feature_locale 0
Feature_subquery 166933
Feature_timezone 3
Feature_trigger 0
Feature_xml 0
Flush_commands 5
Handler_commit 1481805
Handler_delete 12085
Handler_discover 0
Handler_external_lock 0
Handler_icp_attempts 412884
Handler_icp_match 229663
Handler_mrr_init 0
Handler_mrr_key_refills 0
Handler_mrr_rowid_refills 0
Handler_prepare 730949
Handler_read_first 4687
Handler_read_key 2827569
Handler_read_last 271
Handler_read_next 6265552
Handler_read_prev 17163099
Handler_read_rnd 949454
Handler_read_rnd_deleted 5
Handler_read_rnd_next 66999805
Handler_rollback 331
Handler_savepoint 6
Handler_savepoint_rollback 432
Handler_tmp_update 52
Handler_tmp_write 794786
Handler_update 187721
Handler_write 45178
Innodb_available_undo_logs 128
Innodb_background_log_sync 174887
Innodb_buffer_pool_bytes_data 497696768
Innodb_buffer_pool_bytes_dirty 966656
Innodb_buffer_pool_dump_status not started
Innodb_buffer_pool_load_status not started
Innodb_buffer_pool_pages_data 30377
Innodb_buffer_pool_pages_dirty 59
Innodb_buffer_pool_pages_flushed 219751
Innodb_buffer_pool_pages_free 1024
Innodb_buffer_pool_pages_lru_flushed 0
Innodb_buffer_pool_pages_made_not_young 7802825
Innodb_buffer_pool_pages_made_young 111036
Innodb_buffer_pool_pages_misc 1366
Innodb_buffer_pool_pages_old 11193
Innodb_buffer_pool_pages_total 32767
Innodb_buffer_pool_read_ahead 46582
Innodb_buffer_pool_read_ahead_evicted 0
Innodb_buffer_pool_read_ahead_rnd 0
Innodb_buffer_pool_read_requests 108881491
Innodb_buffer_pool_reads 102472
Innodb_buffer_pool_wait_free 0
Innodb_buffer_pool_write_requests 1815500
Innodb_checkpoint_age 14294
Innodb_checkpoint_max_age 108005254
Innodb_data_fsyncs 331128
Innodb_data_pending_fsyncs 1
Innodb_data_pending_reads 0
Innodb_data_pending_writes 0
Innodb_data_read 2470580224
Innodb_data_reads 150873
Innodb_data_writes 503833
Innodb_data_written 7447897088
Innodb_dblwr_pages_written 219751
Innodb_dblwr_writes 25874
Innodb_deadlocks 9
Innodb_have_atomic_builtins ON
Innodb_history_list_length 3284
Innodb_ibuf_discarded_delete_marks 0
Innodb_ibuf_discarded_deletes 0
Innodb_ibuf_discarded_inserts 0
Innodb_ibuf_free_list 143
Innodb_ibuf_merged_delete_marks 3383
Innodb_ibuf_merged_deletes 1866
Innodb_ibuf_merged_inserts 2124
Innodb_ibuf_merges 2091
Innodb_ibuf_segment_size 145
Innodb_ibuf_size 1
Innodb_log_waits 0
Innodb_log_write_requests 232924
Innodb_log_writes 236506
Innodb_lsn_current 60890507015
Innodb_lsn_flushed 60890506525
Innodb_lsn_last_checkpoint 60890492721
Innodb_master_thread_active_loops 80742
Innodb_master_thread_idle_loops 94160
Innodb_max_trx_id 181302712
Innodb_mem_adaptive_hash 31235792
Innodb_mem_dictionary 2745710
Innodb_mem_total 549453824
Innodb_mutex_os_waits 45236
Innodb_mutex_spin_rounds 7714968
Innodb_mutex_spin_waits 340407
Innodb_oldest_view_low_limit_trx_id 0
Innodb_os_log_fsyncs 249496
Innodb_os_log_pending_fsyncs 1
Innodb_os_log_pending_writes 0
Innodb_os_log_written 236351488
Innodb_page_size 16384
Innodb_pages_created 618
Innodb_pages_read 150787
Innodb_pages_written 219751
Innodb_purge_trx_id 181302710
Innodb_purge_undo_no 0
Innodb_read_views_memory 552
Innodb_row_lock_current_waits 0
Innodb_row_lock_time 42761
Innodb_row_lock_time_avg 90
Innodb_row_lock_time_max 1150
Innodb_row_lock_waits 474
Innodb_rows_deleted 12085
Innodb_rows_inserted 44260
Innodb_rows_read 93001360
Innodb_rows_updated 187721
Innodb_s_lock_os_waits 23138
Innodb_s_lock_spin_rounds 699885
Innodb_s_lock_spin_waits 23671
Innodb_truncated_status_writes 0
Innodb_x_lock_os_waits 2877
Innodb_x_lock_spin_rounds 88806
Innodb_x_lock_spin_waits 169
Key_blocks_not_flushed 0
Key_blocks_unused 53583
Key_blocks_used 2
Key_blocks_warm 0
Key_read_requests 1560
Key_reads 8
Key_write_requests 0
Key_writes 0
Last_query_cost 0.000000
Max_used_connections 18
Memory_used 242496560
Not_flushed_delayed_rows 0
Open_files 17
Open_streams 0
Open_table_definitions 74
Open_tables 124
Opened_files 40476
Opened_plugin_libraries 0
Opened_table_definitions 240
Opened_tables 609
Opened_views 0
Performance_schema_accounts_lost 0
Performance_schema_cond_classes_lost 0
Performance_schema_cond_instances_lost 0
Performance_schema_digest_lost 0
Performance_schema_file_classes_lost 1
Performance_schema_file_handles_lost 0
Performance_schema_file_instances_lost 0
Performance_schema_hosts_lost 0
Performance_schema_locker_lost 0
Performance_schema_mutex_classes_lost 0
Performance_schema_mutex_instances_lost 0
Performance_schema_rwlock_classes_lost 0
Performance_schema_rwlock_instances_lost 0
Performance_schema_session_connect_attrs_lost 0
Performance_schema_socket_classes_lost 0
Performance_schema_socket_instances_lost 0
Performance_schema_stage_classes_lost 0
Performance_schema_statement_classes_lost 0
Performance_schema_table_handles_lost 0
Performance_schema_table_instances_lost 0
Performance_schema_thread_classes_lost 0
Performance_schema_thread_instances_lost 0
Performance_schema_users_lost 1
Prepared_stmt_count 0
Qcache_free_blocks 5234
Qcache_free_memory 18581136
Qcache_hits 967185
Qcache_inserts 283158
Qcache_lowmem_prunes 38515
Qcache_not_cached 77005
Qcache_queries_in_cache 13744
Qcache_total_blocks 32764
Queries 6092219
Questions 2954038
Rows_read 92962071
Rows_sent 15134564
Rows_tmp_read 815425
Rpl_status AUTH_MASTER
Select_full_join 3
Select_full_range_join 2
Select_range 73422
Select_range_check 60
Select_scan 11567
Slave_heartbeat_period 1800.000
Slave_open_temp_tables 0
Slave_received_heartbeats 0
Slave_retried_transactions 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 42
Sort_merge_passes 3
Sort_range 185365
Sort_rows 1010314
Sort_scan 19624
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_server_not_after
Rpl_status AUTH_MASTER
Select_full_join 3
Select_full_range_join 2
Select_range 73422
Select_range_check 60
Select_scan 11567
Slave_heartbeat_period 1800.000
Slave_open_temp_tables 0
Slave_received_heartbeats 0
Slave_retried_transactions 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 42
Sort_merge_passes 3
Sort_range 185365
Sort_rows 1010314
Sort_scan 19624
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_server_not_after
Ssl_server_not_before
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_sessions_reused 0
Ssl_used_session_cache_entries 0
Ssl_verify_depth 0
Ssl_verify_mode 0
Ssl_version
Subquery_cache_hit 172108
Subquery_cache_miss 16734
Syncs 177196
Table_locks_immediate 926927
Table_locks_waited 0
Tc_log_max_pages_used 0
Tc_log_page_size 0
Tc_log_page_waits 0
Threadpool_idle_threads 0
Threadpool_threads 0
Threads_cached 14
Threads_connected 4
Threads_created 18
Threads_running 3
Uptime 178882
Uptime_since_flush_status 178882

MySQL hangs due to large delete (1 reply)

$
0
0
Hello!
We are currently using MySQL 5.5 running on Ubuntu 12.04.
We have quite a big table and we are doing several large deletes on this table in one batch (We use the executeBatch() method from our JDBC connector). Surprisingly, this causes MySQL to hang completely and not perform any reads or writes for 10-20s.
Its not just the db that is blocking as we have 2 dbs on the same MySQL instance and they both are hanging.

The table itself is an InnoDB table and these are the relevant variables:

| ignore_builtin_innodb | OFF |
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_lwm | 10 |
| innodb_adaptive_hash_index | ON |
| innodb_adaptive_max_sleep_delay | 150000 |
| innodb_additional_mem_pool_size | 8388608 |
| innodb_api_bk_commit_interval | 5 |
| innodb_api_disable_rowlock | OFF |
| innodb_api_enable_binlog | OFF |
| innodb_api_enable_mdl | OFF |
| innodb_api_trx_level | 0 |
| innodb_autoextend_increment | 64 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_dump_at_shutdown | OFF |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | OFF |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 47689236480 |
| innodb_change_buffer_max_size | 25 |
| innodb_change_buffering | all |
| innodb_checksum_algorithm | innodb |
| innodb_checksums | ON |
| innodb_cmp_per_index_enabled | OFF |
| innodb_commit_concurrency | 0 |
| innodb_compression_failure_threshold_pct | 5 |
| innodb_compression_level | 6 |
| innodb_compression_pad_pct_max | 50 |
| innodb_concurrency_tickets | 5000 |
| innodb_data_file_path | ibdata1:12M:autoextend |
| innodb_data_home_dir | |
| innodb_disable_sort_file_cache | OFF |
| innodb_doublewrite | ON |
| innodb_fast_shutdown | 0 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | ON |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | |
| innodb_flush_neighbors | 1 |
| innodb_flushing_avg_loops | 30 |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_ft_aux_table | |
| innodb_ft_cache_size | 8000000 |
| innodb_ft_enable_diag_print | OFF |
| innodb_ft_enable_stopword | ON |
| innodb_ft_max_token_size | 84 |
| innodb_ft_min_token_size | 3 |
| innodb_ft_num_word_optimize | 2000 |
| innodb_ft_result_cache_limit | 2000000000 |
| innodb_ft_server_stopword_table | |
| innodb_ft_sort_pll_degree | 2 |
| innodb_ft_total_cache_size | 640000000 |
| innodb_ft_user_stopword_table | |
| innodb_io_capacity | 200 |
| innodb_io_capacity_max | 2000 |
| innodb_large_prefix | OFF |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 8388608 |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 1073741824 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_lru_scan_depth | 1024 |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_dirty_pages_pct_lwm | 0 |
| innodb_max_purge_lag | 0 |
| innodb_max_purge_lag_delay | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_monitor_disable | |
| innodb_monitor_enable | |
| innodb_monitor_reset | |
| innodb_monitor_reset_all | |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 1000 |
| innodb_online_alter_log_max_size | 134217728 |
| innodb_open_files | 16384 |
| innodb_optimize_fulltext_only | OFF |
| innodb_page_size | 16384 |
| innodb_print_all_deadlocks | OFF |
| innodb_purge_batch_size | 300 |
| innodb_purge_threads | 1 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_read_only | OFF |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_sort_buffer_size | 1048576 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_auto_recalc | ON |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | OFF |
| innodb_stats_persistent | ON |
| innodb_stats_persistent_sample_pages | 20 |
| innodb_stats_sample_pages | 8 |
| innodb_stats_transient_sample_pages | 8 |
| innodb_status_output | OFF |
| innodb_status_output_locks | OFF |
| innodb_strict_mode | OFF |
| innodb_support_xa | ON |
| innodb_sync_array_size | 1 |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_undo_directory | . |
| innodb_undo_logs | 128 |
| innodb_undo_tablespaces | 0 |
| innodb_use_native_aio | ON |
| innodb_use_sys_malloc | ON |
| innodb_version | 5.6.17 |
| innodb_write_io_threads | 4 |


| binlog_cache_size | 32768 |
| binlog_stmt_cache_size | 32768 |
| have_query_cache | YES |
| host_cache_size | 654 |
| key_cache_age_threshold | 300 |
| key_cache_block_size | 1024 |
| key_cache_division_limit | 100 |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| metadata_locks_cache_size | 1024 |
| query_cache_limit | 67108864 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 0 |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
| stored_program_cache | 256 |
| table_definition_cache | 16384 |
| table_open_cache | 16384 |
| table_open_cache_instances | 1 |
| thread_cache_size | 18


Any help with this would be appreciated!

Where to look for server freezes (1 reply)

$
0
0
We are running 5.5.37-0ubuntu0.12.04.1-log on a Dell PowerEdge with 64GB of real memory and eight cores. The server will occasionally freeze and we have to restart it. It froze this morning and while it was frozen, the error and slow query logs were empty. I tried a simple query "select count(*) from master;" and I saw the query was added to the msyql.log but nothing else happened. The mysqld process showed zero CPU usage. We have a traffic monitor on the NFS-mounted Synology disk system and it was showing zero traffic. I am at a loss to find something broken to be fixed.

The Oracle at Google tells me that query caching may be a problem. Here's the cache variables:

mysql> show global status like "Qc%";
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 1883827656 |
| Qcache_hits | 92 |
| Qcache_inserts | 692 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 293 |
| Qcache_queries_in_cache | 691 |
| Qcache_total_blocks | 1679 |
+-------------------------+------------+

We have hundreds of ~100MB tables and tens of simultaneous users.

Any suggestions about where to look for the problem(s) will be appreciated.

Performance problem with outer join (3 replies)

$
0
0
I am hoping to get some advice on how to optimize the performance of this query I have with an outer join. First I will explain what I am trying to do and then I'll show the code and results. I am using mySQL 5.6.13-2+debphp.org~raring+2-log.

I have an Accounts table that has a list of all customer accounts. And I have a datausage table which keeps track of how much data each customer is using. A backend process running on multiple servers inserts records into the datausage table each day to keep track of how much usage occurred that day for each customer on that server.

The backend process works like this - if there is no activity on that server for an account on that day, no records are written for that account. If there is activity, one record is written with a "LogDate" of that day. This is happening on multiple servers. So collectively the datausage table winds up with no rows (no activity at all for that customer each day), one row (activity was only on one server for that day), or multiple rows (activity was on multiple servers for that day).

We need to run a report that lists ALL customers, along with their usage for a specific date range. Some customers may have no usage at all (nothing whatsoever in the datausage table). Some customers may have no usage at all for the current period (but usage in other periods).

Regardless of whether there is any usage or not (ever, or for the selected period) we need EVERY customer in the Accounts table to be listed in the report, even if they show no usage. Therefore it seems this required an outer join.

Here is the query I am using:
SELECT
Accounts.accountID as AccountID,
IFNULL(Accounts.name,Accounts.accountID) as AccountName,
AccountPlans.plantype as AccountType,
Accounts.status as AccountStatus,
date(Accounts.created_at) as Created,
sum(IFNULL(datausage.Core,0) + (IFNULL(datausage.CoreDeluxe,0) * 3)) as 'CoreData'
FROM `Accounts`
LEFT JOIN `datausage` on `Accounts`.`accountID` = `datausage`.`accountID`
LEFT JOIN `AccountPlans` on `AccountPlans`.`PlanID` = `Accounts`.`PlanID`
WHERE
(
(`datausage`.`LogDate` >= '2014-06-01' and `datausage`.`LogDate` < '2014-07-01')
or `datausage`.`LogDate` is null
)
GROUP BY Accounts.accountID
ORDER BY `AccountName` asc

The challenge is that this query takes about 2 seconds to run. However it only takes 0.3 seconds to run if the "or datausage.LogDate is NULL" is removed. However, it seems I must have that clause in there, because accounts with no usage are excluded from the result set if that does not appear, and that would be a problem since all accounts are needed regardless of if there is any usage.

This is the EXPLAIN output:
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------------+--------+---------------------------------------------------------+---------+---------+----------------------+------- +----------------------------------------------------+
| 1 | SIMPLE | Accounts | ALL | PRIMARY,accounts_planid_foreign,accounts_cardid_foreign | NULL | NULL | NULL | 57 | Using temporary; Using filesort |
| 1 | SIMPLE | datausage | ALL | NULL | NULL | NULL | NULL | 96805 | Using where; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | AccountPlans | eq_ref | PRIMARY | PRIMARY | 4 | mydb.Accounts.planID | 1 | NULL |

Here are my indexes on Accounts table:
TABLE NON_UNIQUE KEY_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULL INDEX_TYPE COMMENT INDEX_COMMENT
accounts 0 PRIMARY 1 accountID A 5 (null) (null) BTREE
accounts 1 accounts_planid_foreign 1 planID A 5 (null) (null) BTREE
accounts 1 acctname_id_ndx 1 name A 5 (null) (null) YES BTREE
accounts 1 acctname_id_ndx 2 accountID A 5 (null) (null) BTREE

Here are my indexes on datausage table:
TABLE NON_UNIQUE KEY_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULL INDEX_TYPE COMMENT INDEX_COMMENT
datausage 0 PRIMARY 1 UsageID A 16 (null) (null) BTREE
datausage 1 acctusage 1 AccountID A 16 (null) (null) YES BTREE
datausage 1 acctusage 2 LogDate A 16 (null) (null) BTREE

Here are my indexes from AccountPlans:
TABLE NON_UNIQUE KEY_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULL INDEX_TYPE COMMENT INDEX_COMMENT
accountplans 0 PRIMARY 1 planID A 2 (null) (null) BTREE
accountplans 1 acctplans_id_type_ndx 1 planID A 2 (null) (null) BTREE
accountplans 1 acctplans_id_type_ndx 2 plantype A 2 (null) (null) BTREE

Others from online help have suggested I try queries like the following. However ALL of these have the same query EXPLAIN plan and have the same performance problem (they all take about 2 seconds vs 0.1 seconds without the outer join).

SELECT a.accountID as AccountID, coalesce(a.name, a.accountID) as AccountName,
ap.plantype as AccountType, a.status as AccountStatus,
date(a.created_at) as Created,
sum(coalesce(du.Core, 0) + (coalesce(du.CoreDeluxe, 0) * 3)) as CoreData
FROM Accounts a LEFT JOIN
datausage du
on a.accountID = du.`accountID` AND
du.`LogDate` >= '2014-06-01' and du.`LogDate` < '2014-07-01'
LEFT JOIN
AccountPlans ap
on ap.`PlanID` = a.`PlanID`
GROUP BY a.accountID
ORDER BY AccountName asc ;


and a query like this:


SELECT a.accountID as AccountID, coalesce(a.name, a.accountID) as AccountName,
ap.plantype as AccountType, a.status as AccountStatus,
date(a.created_at) as Created,
sum(coalesce(du.Core, 0) + (coalesce(du.CoreDeluxe, 0) * 3)) as CoreData
FROM Accounts a LEFT JOIN
datausage du
on a.accountID = du.`accountID` AND
du.LogDate >= '2014-06-01' and du.LogDate < '2014-07-01'LEFT JOIN
AccountPlans ap
on ap.PlanID = a.PlanID
GROUP BY a.accountID
ORDER BY a.name, a.accountID ;

but again - all these queries, including mine, have the same exact EXPLAIN output and performance problem.

Here is the code to build the schema for testing to easily reproduce the query plan and issue. Note that this only has a few rows so you won't see the performance problem, but with 100,000 rows like I have in datausage the performance issue can easily be seen.

CREATE TABLE `Accounts` (
`accountID` varchar(25) COLLATE utf8_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`status` int(11) NOT NULL,
`planID` int(10) unsigned NOT NULL DEFAULT '1',
PRIMARY KEY (`accountID`),
KEY `accounts_planid_foreign` (`planID`),
KEY `acctname_id_ndx` (`name`,`accountID`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `datausage` (
`UsageID` int(11) NOT NULL AUTO_INCREMENT,
`Core` int(11) DEFAULT NULL,
`CoreDeluxe` int(11) DEFAULT NULL,
`AccountID` varchar(25) DEFAULT NULL,
`LogDate` date NOT NULL,
PRIMARY KEY (`UsageID`),
KEY `acctusage` (`AccountID`,`LogDate`)
) ENGINE=Innodb AUTO_INCREMENT=104303 DEFAULT CHARSET=latin1 ;

CREATE TABLE `AccountPlans` (
`planID` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(150) COLLATE utf8_unicode_ci NOT NULL,
`params` text COLLATE utf8_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`plantype` varchar(25) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`planID`),
KEY `acctplans_id_type_ndx` (`planID`,`plantype`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

INSERT INTO Accounts (accountID, name, created_at, status, planID) values ('asdfad','abc company', now(), 1, 1);
INSERT INTO Accounts (accountID, name, created_at, status, planID) values ('uiadjf','xyz company', now(), 1, 1);
INSERT INTO Accounts (accountID, name, created_at, status, planID) values ('349ajf','test company', now(), 1, 1);
INSERT INTO Accounts (accountID, name, created_at, status, planID) values ('huf7sd','zeebar co', now(), 1, 1);
INSERT INTO Accounts (accountID, name, created_at, status, planID) values ('bah38c','testing 123', now(), 1, 1);

INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (3, 1, 'asdfad', '2014-06-20');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (23, 11, 'asdfad', '2014-06-21');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (14, 3, 'asdfad', '2014-06-22');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (22, 41, 'asdfad', '2014-06-23');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (8, 2, 'asdfad', '2014-06-24');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (1, 0, 'asdfad', '2014-06-25');

INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (32, 71, 'uiadjf', '2014-06-20');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (233, 81, 'uiadjf', '2014-06-21');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (52, 51, 'uiadjf', '2014-06-22');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (23, 21, 'uiadjf', '2014-06-23');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (80, 4, 'uiadjf', '2014-06-24');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (0, 20, 'uiadjf', '2014-06-25');

INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (9, 17, '349ajf', '2014-06-20');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (51, 61, '349ajf', '2014-06-21');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (7, 3, '349ajf', '2014-06-22');
INSERT INTO datausage (Core, CoreDeluxe, AccountID, LogDate) values (253, 18, '349ajf', '2014-06-23');

INSERT INTO AccountPlans (planID, name, params, created_at, plantype) values (1, 'Plan 1', 'abc', now(), 'typexyz');
INSERT INTO AccountPlans (planID, name, params, created_at, plantype) values (2, 'Plan 2', 'def', now(), 'typexyz');


I have been trying to solve this now for a full month and would GREATLY appreciate some help.

I have a SQL fiddle online that I can reference but I did not know if it was OK to post a link to it here.

Thank you in advance for your help!

Slow response in MY SQL 5.5.1.8 (no replies)

$
0
0
Highly Slowness response received from mysql db. SQL Quarries are coming through application server to DB (3 tier architecture) there is no network, hardware or Operating system latency. Below is the environment uses. Appreciate your experience comment for identify the issue

DB Server:
MY SQL Version: 5.5.1.8
OS: RHEL 5.6
APP Server:
Jboss: 4.0.4
Glashfish: 3.1
Client:
MS windows 7

Help in tuning MySQL 5.6 database (no replies)

$
0
0
We're developing an enterprise product that uses MySQL 5.6 on Windows to store reports generated by multiple clients. Our database contains approximately 20 tables, each table containing ranging from a few hundred thousand to some million records. All tables have more than 10 columns with a combination of numeric and textual data. All tables use innodb engine with numeric field as primary key. The tables are indexed on another numeric field, different than the primary key.
There are about 10 connections used to merge new data into the database. The data is viewed via a web console. There is as such no limit on the number of instances on viewing the data. We also don't have any reference/foreign key in tables so we don't use joins.
We haven't created stored procedure for fetching data. Does the store procedure really improve performance?
While searching solution on the internet, I found that if we changes the values of innodb_buffer_pool_size, read_rnd_buffer_size, sort_buffer_size etc fields in my.ini/my.cnf files, then we can improve performance as well as minimize memory requirements of mysql. But I am not confident about it because I don't know what should be the proper values of it and what are the side effect of it. Currently I kept the default configuration. Please let me know which values can be changed in the configuration file to improve performance and minimize memory requirements without any side effect.
I would also like to know some other ways to optimize & fine tune MySQL engine that would boost the performance & use optimum resources.
Minimum software/hardware requirement of our product is :
OS : Windows 2000 SP4 Professional / Server and later.
RAM : 1 GB
CPU : 1 GHz.

GROUP causing Using Temporary Using Filesort (7 replies)

$
0
0
I am using mySQL 5.6.13.2 and have a query that involves 150,000 rows in a parent table with over 1M rows in a child table. The query takes 2 seconds if I remove the GROUP BY (just as a test) and over 6 seconds if I have the GROUP BY, which is needed.

I've read other posts about how to remove using temporary; using filesort but these do not address the issue. I'm hoping to get some help here please.

A SQL fiddle that demonstrates all this is available here: http://sqlfiddle.com/#!9/edeb6/1


CREATE TABLE `summary` (
`RunID` int(10) unsigned NOT NULL AUTO_INCREMENT,
`LastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`FileName` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
`XCount` int(11) DEFAULT NULL,
`YCount` int(11) DEFAULT NULL,
`AccountID` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`RunID`),
KEY `acct-lastupdate` (`AccountID`,`LastUpdate`),
KEY `acct-lastupdate-counts` (`AccountID`,`LastUpdate`,`XCount`,`YCount`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


CREATE TABLE `detail` (
`DetailID` int(10) unsigned NOT NULL AUTO_INCREMENT,
`LastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`RunID` int(10) unsigned DEFAULT NULL,
`TestID` varchar(80) COLLATE utf8_unicode_ci DEFAULT NULL,
`ResultCode` int(11) DEFAULT NULL,
PRIMARY KEY (`DetailID`),
KEY `detail_runid` (`RunID`),
KEY `detail_testid` (`TestID`),
KEY `detail_runid_testid_result` (`RunID`,`TestID`,`ResultCode`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


Here is the explain output...


EXPLAIN select
testid as 'TestID',
sum(case when resultcode = 1 then 1 else 0 end) as Category1,
sum(case when resultcode = 2 then 1 else 0 end) as Category2,
sum(case when resultcode = 0 then 1 else 0 end) as Category3
from detail d, summary s
where s.accountid = 'xyz'
and s.lastupdate >= '2014-05-26 00:00:00'
and s.lastupdate < '2014-07-27 00:00:00'
and s.runid = d.runid
and s.runid <= 9999999999
GROUP BY testid;

1 SIMPLE s ref PRIMARY,acct-lastupdate,acct-lastupdate-counts acct-lastupdate 78 const 2 Using where; Using index; Using temporary; Using filesort
1 SIMPLE d ref detail_runid,detail_runid_testid_result detail_runid 5 db_9_edeb6.s.RunID 1 (null)

If I remove the GROUP BY then the EXPLAIN says Using where; Using index with no temporary or file sort and the query runs in 2 seconds instead of 6 seconds.

Having these results grouped by the Test ID is mandatory. Also the Test ID values are arbitrary and not known in advance, so there would be no way to write the query with subqueries against hardcoded known test IDs.

Is it possible to define other indexes that may stop the temporary and file sort? If not, is there a more creative way to rewrite this query that would be more efficient and perhaps resolve that?

Note that after the GROUP BY my query really has some HAVING and ORDER BY conditions (specifically it goes ... GROUP BY testid having Category1 OR Category2 OR Category3 order by Category1 desc, Category2 desc;" - however I left this out of the examples here because I get the same performance and EXPLAIN output with or without that expanded clause and I wanted to keep the sample as simple as possible. I mention it here because in case you have a creative way to rewrite the query if you can please include that it would be good.

As noted, there is an SQL fiddle here http://sqlfiddle.com/#!9/edeb6/1 that demonstrates the issue (so you can see the EXPLAIN output and experiment).

Thank you!
Viewing all 1203 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>