# NEED help,there was a crush issue when importing big  data  into Percona cluster

**URL:** https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641
**Category:** Percona XtraDB Cluster 5.x
**Created:** [May 27, 2017, 8:56pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641 "2017-05-27T20:56:51Z")
**Posts on this page:** 16
**Page:** 1

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 27, 2017, 8:56pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/1 "2017-05-27T20:56:51Z")

</div>

yesterday,we have builded percona cluster which has three nodes in test box.and then we using mysqldump to backup one database data from mysql 5.5 in production box.after we got the sql file,it was 11G and have 30000 lines.we use command “mysql -uroot -p123456 dbname \< mysql\_dump.sql” to load the database file into percona cluster.actually,we have created a same dbname in percona cluster。

“CREATE DATABASE dbname DEFAULT CHARSET utf8 ".

ok,we run this command “mysql -uroot -p123456 dbname \< mysql\_dump.sql” in node1 ,Unluckily we got a crush issue in middle of it,and node1’s mysql service was crush,need start.we try to run command many times ,so we wonder that if the percona cluster not be allown import sql file which more than 1GB???but if we decide to use percona cluster in our production box,the first step it load the currentlly db data into percona cluster to keep moving our data.did someone help us??thx very much in advance !!

---

<div class="post-metadata">

### Author: ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)
#### Post date: [May 30, 2017, 5:52am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/2 "2017-05-30T05:52:17Z")

</div>

You didn’t specify what kind of crash was it. Primary source of information for that is MySQL error log btw.  
There is no limit in how big SQL dumps can be imported in PXC node, however long imports may affect the cluster performance or even cause cluster interruptions if nodes are using slow disks, network, etc.  
Btw, I would recommend using mydumper/myloader rather, as in case of any problem in the middle would be easier to resume later.  
Also, as Galera doesn’t really support table locks, better to use options in mysqldump that do not put the LOCK TABLE clauses in the dump.

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 30, 2017, 8:14pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/3 "2017-05-30T20:14:51Z")

</div>

> [@przemek;48576](#):
>
> You didn’t specify what kind of crash was it. Primary source of information for that is MySQL error log btw.  
> There is no limit in how big SQL dumps can be imported in PXC node, however long imports may affect the cluster performance or even cause cluster interruptions if nodes are using slow disks, network, etc.  
> Btw, I would recommend using mydumper/myloader rather, as in case of any problem in the middle would be easier to resume later.  
> Also, as Galera doesn’t really support table locks, better to use options in mysqldump that do not put the LOCK TABLE clauses in the dump.

today i try to import more than 600MB sql file into pxc cluster,still got crush.and the err log doesn’t have more details.  
only got :error 2013 ,lost connections to mysql server during query

---

<div class="post-metadata">

### Author: ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)
#### Post date: [May 30, 2017, 8:17pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/4 "2017-05-30T20:17:26Z")

</div>

try enabling wsrep\_debug=1 on the crashing server, also check if you have relevant logs pertaining to the mysql crash from the system log (/var/log/messages or /var/log/syslog) and/or from dmesg.

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 30, 2017, 8:18pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/5 "2017-05-30T20:18:24Z")

</div>

> [@przemek;48576](#):
>
> You didn’t specify what kind of crash was it. Primary source of information for that is MySQL error log btw.  
> There is no limit in how big SQL dumps can be imported in PXC node, however long imports may affect the cluster performance or even cause cluster interruptions if nodes are using slow disks, network, etc.  
> Btw, I would recommend using mydumper/myloader rather, as in case of any problem in the middle would be easier to resume later.  
> Also, as Galera doesn’t really support table locks, better to use options in mysqldump that do not put the LOCK TABLE clauses in the dump.

today i try to import sql file into pxc cluster ,the sql file only 700MB,but still got crush.i cant got more details from err log.only got :ERROR 2013,lost connection to mysql server during query

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 30, 2017, 8:35pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/6 "2017-05-30T20:35:32Z")

</div>

i worder that the import time is long will made the node1 crush.

 ![photoid=48591](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/2/239e7a7239bfa4b49bf5c215e35169da4317d5cb.jpeg)

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 31, 2017, 1:01am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/7 "2017-05-31T01:01:28Z")

</div>

Last login: Wed May 31 13:10:06 2017 from 172.29.36.198  
[ftpuser@osspclu1 ~]$ su - root  
密码：  
[root@osspclu1 ~]# mysql -uroot -pmysql bpmtest1 \<sys\_message\_doto.sql  
-bash: sys\_message\_doto.sql: 没有那个文件或目录  
[root@osspclu1 ~]# cd /data/export/  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<sys\_message\_doto.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<bpm\_exe\_stack\_executor.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<biz\_statement\_bill\_detail.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<bpm\_def\_data.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<act\_ru\_variable.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<bpm\_pro\_inst.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<bpm\_pro\_inst\_hi.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<biz\_edit\_record.sql  
Warning: Using a password on the command line interface can be insecure.  
[root@osspclu1 export]# mysql -uroot -pmysql bpmtest1 \<act\_hi\_identitylink.sql  
Warning: Using a password on the command line interface can be insecure.  
ERROR 2013 (HY000) at line 125: Lost connection to MySQL server during query

still got crush,when i continue to load sql file into pxc cluster,seems plenty query will made mysql service crush  
and err log was nothing even i set the wsrep\_debug = 1.  
only this:  
170531 13:29:18 mysqld\_safe Number of processes running now: 0  
170531 13:29:18 mysqld\_safe WSREP: not restarting wsrep node automatically  
170531 13:29:18 mysqld\_safe mysqld from pid file /data/mysql/osspclu1.pid ended

---

<div class="post-metadata">

### Author: ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)
#### Post date: [May 31, 2017, 1:04am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/8 "2017-05-31T01:04:58Z")

</div>

this looks like an OOM, check your system log (/var/log/messages or /var/log/syslog) also check dmesg if mysql was killed by oom (out-of-memory).

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 31, 2017, 2:22am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/9 "2017-05-31T02:22:41Z")

</div>

thx Jrivera  
i saw /var/log/messages has these error msg  
May 31 13:29:16 osspclu1 kernel: mysqld invoked oom-killer: gfp\_mask=0x201da, order=0, oom\_adj=0, oom\_score\_adj=0  
May 31 13:29:16 osspclu1 kernel: mysqld cpuset=/ mems\_allowed=0  
May 31 13:29:16 osspclu1 kernel: Pid: 19848, comm: mysqld Tainted: G --------------- H 2.6.32-358.el6.x86\_64 #1  
May 31 13:29:16 osspclu1 kernel: Call Trace:  
May 31 13:29:16 osspclu1 kernel: [] ? cpuset\_print\_task\_mems\_allowed+0x91/0xb0  
May 31 13:29:16 osspclu1 kernel: [] ? dump\_header+0x90/0x1b0  
May 31 13:29:16 osspclu1 kernel: [] ? security\_real\_capable\_noaudit+0x3c/0x70  
May 31 13:29:16 osspclu1 kernel: [] ? oom\_kill\_process+0x82/0x2a0  
May 31 13:29:16 osspclu1 kernel: [] ? select\_bad\_process+0xe1/0x120  
May 31 13:29:16 osspclu1 kernel: [] ? out\_of\_memory+0x220/0x3c0  
May 31 13:29:16 osspclu1 kernel: [] ? \_\_alloc\_pages\_nodemask+0x8ac/0x8d0  
May 31 13:29:16 osspclu1 kernel: [] ? alloc\_pages\_current+0xaa/0x110  
May 31 13:29:16 osspclu1 kernel: [] ? \_\_page\_cache\_alloc+0x87/0x90  
May 31 13:29:16 osspclu1 kernel: [] ? find\_get\_page+0x1e/0xa0  
May 31 13:29:16 osspclu1 kernel: [] ? filemap\_fault+0x1a7/0x500  
May 31 13:29:16 osspclu1 kernel: [] ? \_\_do\_fault+0x54/0x530  
May 31 13:29:16 osspclu1 kernel: [] ? handle\_pte\_fault+0xf7/0xb50  
May 31 13:29:16 osspclu1 kernel: [] ? \_\_sb\_end\_write+0x3d/0x70  
May 31 13:29:16 osspclu1 kernel: [] ? generic\_file\_aio\_write+0xba/0x100  
May 31 13:29:16 osspclu1 kernel: [] ? handle\_mm\_fault+0x23a/0x310  
May 31 13:29:16 osspclu1 kernel: [] ? \_\_do\_page\_fault+0x139/0x480  
May 31 13:29:16 osspclu1 kernel: [] ? do\_page\_fault+0x3e/0xa0  
May 31 13:29:16 osspclu1 kernel: [] ? page\_fault+0x25/0x30  
May 31 13:29:16 osspclu1 kernel: Mem-Info:  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA per-cpu:  
May 31 13:29:16 osspclu1 kernel: CPU 0: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 1: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 2: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 3: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 4: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 5: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 6: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 7: hi: 0, btch: 1 usd: 0  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA32 per-cpu:  
May 31 13:29:16 osspclu1 kernel: CPU 0: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 1: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 2: hi: 186, btch: 31 usd: 31  
May 31 13:29:16 osspclu1 kernel: CPU 3: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 4: hi: 186, btch: 31 usd: 30  
May 31 13:29:16 osspclu1 kernel: CPU 5: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 6: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 7: hi: 186, btch: 31 usd: 14  
May 31 13:29:16 osspclu1 kernel: Node 0 Normal per-cpu:  
May 31 13:29:16 osspclu1 kernel: CPU 0: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 1: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 2: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 3: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 4: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 5: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 6: hi: 186, btch: 31 usd: 0  
May 31 13:29:16 osspclu1 kernel: CPU 7: hi: 186, btch: 31 usd: 32

May 31 13:29:16 osspclu1 kernel: active\_anon:1647254 inactive\_anon:324046 isolated\_anon:32  
May 31 13:29:16 osspclu1 kernel: active\_file:124 inactive\_file:742 isolated\_file:0  
May 31 13:29:16 osspclu1 kernel: unevictable:0 dirty:0 writeback:24 unstable:0  
May 31 13:29:16 osspclu1 kernel: free:25701 slab\_reclaimable:3960 slab\_unreclaimable:11205  
May 31 13:29:16 osspclu1 kernel: mapped:380 shmem:223 pagetables:13946 bounce:0  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA free:15688kB min:124kB low:152kB high:184kB active\_anon:0kB inactive\_anon:0kB active\_file:0kB inactive\_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15296kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab\_reclaimable:0kB slab\_unreclaimable:0kB kernel\_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:0 all\_unreclaimable? yes  
May 31 13:29:16 osspclu1 kernel: lowmem\_reserve: 0 3000 8050 8050  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA32 free:44816kB min:25140kB low:31424kB high:37708kB active\_anon:2296016kB inactive\_anon:580660kB active\_file:20kB inactive\_file:1824kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3072160kB mlocked:0kB dirty:0kB writeback:0kB mapped:896kB shmem:212kB slab\_reclaimable:1740kB slab\_unreclaimable:1096kB kernel\_stack:40kB pagetables:6584kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:2016 all\_unreclaimable? yes  
May 31 13:29:16 osspclu1 kernel: lowmem\_reserve: 0 0 5050 5050  
May 31 13:29:16 osspclu1 kernel: Node 0 Normal free:42300kB min:42316kB low:52892kB high:63472kB active\_anon:4293000kB inactive\_anon:715524kB active\_file:476kB inactive\_file:1144kB unevictable:0kB isolated(anon):128kB isolated(file):0kB present:5171200kB mlocked:0kB dirty:0kB writeback:96kB mapped:624kB shmem:680kB slab\_reclaimable:14100kB slab\_unreclaimable:43724kB kernel\_stack:3720kB pagetables:49200kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:2560 all\_unreclaimable? yes  
May 31 13:29:16 osspclu1 kernel: lowmem\_reserve: 0 0 0 0  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA: 4_4kB 3_8kB 2_16kB 0_32kB 2_64kB 1_128kB 0_256kB 0_512kB 1_1024kB 1_2048kB 3_4096kB = 15688kB  
May 31 13:29:16 osspclu1 kernel: Node 0 DMA32: 432_4kB 407_8kB 328_16kB 274_32kB 162_64kB 45_128kB 14_256kB 3_512kB 4_1024kB 0_2048kB 0_4096kB = 44344kB  
May 31 13:29:16 osspclu1 kernel: Node 0 Normal: 1079_4kB 692_8kB 457_16kB 271_32kB 143_64kB 47_128kB 6_256kB 0_512kB 0_1024kB 0_2048kB 0\*4096kB = 42540kB  
May 31 13:29:16 osspclu1 kernel: 5623 total pagecache pages  
May 31 13:29:16 osspclu1 kernel: 4444 pages in swap cache  
May 31 13:29:16 osspclu1 kernel: Swap cache stats: add 3838714, delete 3834270, find 708177/738093  
May 31 13:29:16 osspclu1 kernel: Free swap = 0kB  
May 31 13:29:16 osspclu1 kernel: Total swap = 2097144kB  
May 31 13:29:16 osspclu1 kernel: 2097136 pages RAM  
May 31 13:29:16 osspclu1 kernel: 48900 pages reserved  
May 31 13:29:16 osspclu1 kernel: 2023 pages shared  
May 31 13:29:16 osspclu1 kernel: 2015620 pages non-shared

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 31, 2017, 2:24am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/10 "2017-05-31T02:24:07Z")

</div>

May 31 13:29:16 osspclu1 kernel: [24735] 0 24735 57333 681 4 0 0 mysql  
May 31 13:29:16 osspclu1 kernel: Out of memory: Kill process 19792 (mysqld) score 952 or sacrifice child  
May 31 13:29:16 osspclu1 kernel: Killed process 19792, UID 496, (mysqld) total-vm:28389780kB, anon-rss:7822640kB, file-rss:460kB

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [May 31, 2017, 2:27am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/11 "2017-05-31T02:27:31Z")

</div>

[root@osspclu1 export]# free -m  
total used free shared buffers cached  
Mem: 8001 7824 176 0 84 3085  
-/+ buffers/cache: 4655 3346  
Swap: 2047 161 1886

---

<div class="post-metadata">

### Author: ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)
#### Post date: [June 1, 2017, 2:46am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/12 "2017-06-01T02:46:37Z")

</div>

OK, so if your server runs out of memory, triggering OOMK, you should double check relevant MySQL settings as well as how much other processes use.  
Can you post full my.cnf here?

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [June 1, 2017, 7:44pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/13 "2017-06-01T19:44:26Z")

</div>

[mysqld]

datadir=/data/mysql

socket=/data/mysql/mysql.sock

user=mysql

lower\_case\_table\_names=1

max\_connections=1000

log-bin=/data/mysql-bin/mysql-bin

max\_binlog\_size=50M

expire\_logs\_days=3

log-error=/data/mysqld.err

max\_allowed\_packet = 500M

skip-name-resolve

innodb\_buffer\_pool\_size = 14G

query\_cache\_type=1

query\_cache\_size=1024M

wsrep\_provider\_options=“gcache.size=2G”

# Path to Galera library

wsrep\_provider=/usr/lib64/libgalera\_smm.so

# Cluster connection URL contains the IPs of node#1,node#2 and node#3

wsrep\_cluster\_address=gcomm://172.29.9.41,172.29.9.42,172.29.9.43

# In order for Galera to work correctly binlog formatshould be ROW

binlog\_format=ROW

# MyISAM storage engine has only experimental support

default\_storage\_engine=InnoDB

# This changes how InnoDB autoincrement locks are managedand is a requirement for Galera

innodb\_autoinc\_lock\_mode=2

# Node #3 address

wsrep\_node\_address=172.29.9.41 # 本机IP地址

# SST method

wsrep\_sst\_method=xtrabackup-v2

# Cluster name

wsrep\_cluster\_name=my\_centos\_cluster

# Authentication for SST method

wsrep\_sst\_auth=“sstuser:s3cret”

wsrep\_slave\_threads = 8  
wsrep\_on = ON  
wsrep\_causal\_reads = ON  
#wsrep\_certify\_nonPK = ON  
[client]

socket=/data/mysql/mysql.sock

yesterday,we have added memory for node1,node2,node3,

[root@osspclu1 ~]# free -m  
total used free shared buffers cached  
Mem: 20121 19906 214 0 160 3853  
-/+ buffers/cache: 15892 4228  
Swap: 2047 875 1172  
[root@osspclu1 ~]#

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [June 20, 2017, 2:48am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/14 "2017-06-20T02:48:28Z")

</div>

> [@przemek;48621](#):
>
> OK, so if your server runs out of memory, triggering OOMK, you should double check relevant MySQL settings as well as how much other processes use.  
> Can you post full my.cnf here?

i have posted it,can u help me check to improve performance

---

<div class="post-metadata">

### Author: ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)
#### Post date: [June 25, 2017, 4:01pm UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/15 "2017-06-25T16:01:20Z")

</div>

Sorry, missed that update.  
So you have:  
innodb\_buffer\_pool\_size = 14G  
query\_cache\_size=1024M

So when fully populated, these may easily contribute to about 16GB of mem usage. Plus session buffers depending on number of connections and others. On top of that, large transaction cause memory overhead on Galera side for certification.  
Though I can see pretty small RSS size from OOMk report - what else was running on this server?

---

<div class="post-metadata">

### Author: ![dixon](https://avatars.discourse-cdn.com/v4/letter/d/c0e974/32.png) [@dixon](https://forums.percona.com/u/dixon)
#### Post date: [June 26, 2017, 1:07am UTC](https://forums.percona.com/t/need-help-there-was-a-crush-issue-when-importing-big-data-into-percona-cluster/5641/16 "2017-06-26T01:07:42Z")

</div>

> [@przemek;48833](#):
>
> Sorry, missed that update.  
> So you have:  
> innodb\_buffer\_pool\_size = 14G  
> query\_cache\_size=1024M
> 
> So when fully populated, these may easily contribute to about 16GB of mem usage. Plus session buffers depending on number of connections and others. On top of that, large transaction cause memory overhead on Galera side for certification.  
> Though I can see pretty small RSS size from OOMk report - what else was running on this server?

thx,actually we have added more memory on this box ,now we have 48 GB.and not OMMk happen.thx  
but i need u help me to check the parameter for this DB.if these are someting can improve the DB performance