0

The mysql daemon is getting killed because Linux is reaching out of memory:

Oct 24 07:41:23 <hostname> kernel: [82297.673701] Out of memory: kill process 13816 (mysqld) score 1839626 or a child

There is a link with some workaround on this.

That only happen when executing a query INSERT ... SELECT with a very huge resulset.

MySQLTuner script displays that maximum theorical memory is less than 8GB, but top and munim shows that is getting over all RAM and swap available:

[--] Total buffers: 560.0M global + 72.2M per thread (100 max threads)
[OK] Maximum possible memory usage: 7.6G (43% of installed RAM)

I'm tried to tune some options with not results, there are the relevant ones:

skip-locking
max_connections         = 100
key_buffer_size         = 512M
max_allowed_packet      = 32M
table_open_cache        = 2000
open_files_limit        = 3000
sort_buffer_size        = 16M
read_buffer_size        = 16M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
thread_cache_size       = 4
query_cache_size        = 16M
query_cache_limit       = 2M
thread_concurrency      = 4
join_buffer_size        = 32M
tmp_table_size          = 32M
max_heap_table_size     = 32M
query_cache_limit       = 8M
bulk_insert_buffer_size = 64M
myisam_max_sort_file_size = 50GB
myisam_mmap_size        = 10GB

And there is a system resume:

  • OS: Linux Debian "Squeeze" 6.0.8 (upgraded yesterday)
  • RAM: 18GB
  • Swap: 18GB
  • MySQL: 5.1.72-2 (official Debain release)

At this moment, update or change OS or MySQL version is not possible, there is any option that can help and i missed?

Sorry by my english, and thank you in advance!

Edit: I'm only using MyISAM tables, and cannot change to InnoDB.

1
  • Don't just go by system tuner settings, if you have a huge query, that involves joins or subqueries, then sorts, etc.. you can very easily exceed your theoretical memory usage. This query that sinks your machine, is it a daily thing?
    – NickW
    Oct 24, 2013 at 10:00

2 Answers 2

0

If no upgrade is availible, add more swap :)

1
  • Better to tune the query first...
    – squillman
    Oct 24, 2013 at 14:32
0

Finally I realized that the problem was on joining with a federated table (sorry, it's a really complex query and I found this while analyzing the SQL).

The federated table has only about 7000 rows but executing the same query with a native MyISAM table with the same data, runs much faster and consumes a normal amount of RAM. Seems that MySQL executes a SELECT * in the remote server for every local table row joined and the memory used for caching is not released until finish.

At least I learned that the federated tables should be used carefully and avoid using them on complex querys or big resultsets.

Thanks to all who have responded, I hope this can be usefull to anybody with the same problem!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .