xtradb constant cpu load / mariadb 5.2.12
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MariaDB |
Incomplete
|
Undecided
|
Elena Stepanova |
Bug Description
machine specs:
-------
CPU: Intel(R) Core(TM)2 CPU E8400, 3.00GHz
ram: 8GB
OS: debian 6.0.5 64bit
basic server installation, no X, no special hardware. only default debian packages and fully updated.
mariadb 5.2.12 source package
compiler: gcc version 4.4.5 (Debian 4.4.5-8)
gcc options: '-mssse3 -O3'
configure options: --without-docs --without-ndb-debug
so i went ahead and tried a completely vanilla installation. used the my-medium.cnf and the following commands to get started from within the inst. dir:
# ./bin/mysql_
# ./bin/mysqld_safe --defaults-
all fine so far. now to the actual
PROBLEM REPORT:
===============
as soon as i add the following to the cnf the db is constantly causing almost 50% cpu load on both cpus without me doing anything at all:
plugin-load = ha_xtradb.so
innodb doesn't work by default so i used that option. this is the only plugin i load in that cnf file. actually xtradb is the main reason why i picked mariadb. the second reason is i want to compile it with icc which i did after i encountered this very issue but just got the exact same problem. without xtradb everything seems fine.
following the processes and innodb status while the cpu load issue is present:
MariaDB [(none)]> SHOW PROCESSLIST;
+----+-
| Id | User | Host | db | Command | Time | State | Info |
+----+-
| 1 | root | localhost | NULL | Query | 0 | NULL | SHOW PROCESSLIST |
+----+-
1 row in set (0.00 sec)
MariaDB [(none)]> SHOW INNODB STATUS;
| InnoDB | |
=======
120810 5:08:52 INNODB MONITOR OUTPUT
=======
Per second averages calculated from the last 51 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1 1_second, 1 sleeps, 0 10_second, 1 background, 1 flush
srv_master_thread log flush and writes: 0
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 14, signal count 14
Mutex spin waits 196, rounds 2878, OS waits 11
RW-shared spins 2, OS waits 2; RW-excl spins 0, OS waits 0
Spin rounds per wait: 14.68 mutex, 30.00 RW-shared, 0.00 RW-excl
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
26 OS file reads, 3 OS file writes, 3 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 276671, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 45356
Log flushed up to 45356
Last checkpoint at 45356
Max checkpoint age 7782360
Checkpoint age target 7539162
Modified age 0
Checkpoint age 0
0 pending log writes, 0 pending chkp writes
8 log i/o's done, 0.00 log i/o's/second
-------
BUFFER POOL AND MEMORY
-------
Total memory allocated 137691136; in additional pool allocated 0
Internal hash tables (constant factor + variable factor)
Adaptive hash index 2217584 (2213368 + 4216)
Page hash 139112
Dictionary cache 592524 (554768 + 37756)
File system 83536 (82672 + 864)
Lock system 333248 (332872 + 376)
Recovery system 0 (0 + 0)
Threads 83200 (82696 + 504)
Dictionary memory allocated 37756
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 8176
Database pages 15
Old database pages 0
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 15, created 0, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 15, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 17920, id 140389157238528, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
------------
TRANSACTIONS
------------
Trx id counter 500
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started, process no 17920, OS thread id 140389631579904
MySQL thread id 1, query id 3 localhost root
SHOW INNODB STATUS
-------
END OF INNODB MONITOR OUTPUT
=======
then i tried the latest mariadb 5.1.x and encountered the exact same problem. also tried a bunch of other things like a different config, different already existing db files ... all without any success, still the same cpu load issue.
there are no operational errors, the db works fine except xtradb hogging my cpus.
Changed in maria: | |
status: | New → Incomplete |
assignee: | Axel Schwenke (ahel) → Elena Stepanova (elenst) |
Hi,
You mentioned that "innodb doesn't work by default", but that's only because you didn't add it to your configure options, you should have run it with --with- plugins= xtradb .
Could you please try and see whether you are also having the same problem when xtradb is built in statically?
That said, I've built 5.2.12 with the same exact configure options as you mentioned, and started it presumably the same way, and didn't have a problem with CPU; but I have a different version of gcc and ubuntu instead of debian, so it's not a clean experiment of course.
Does the same happen if you run a binary distribution, e.g. from a binary tarball?
If it does, we can probably rule out the compiler version or options.
Thanks.