Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-5395

after 2+ weeks server crashed; several tables injured

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Incomplete
    • Affects Version/s: 5.5.34
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      After working more than 15 days the MariaDB crashed, several tables injuried.
      The mysqld was restarted. It happened only about 7-8 hours ago, but now I see that mysqld eat all 32 Gb RAM and all the swap (memory leak??).

      Here is pieces from error log:

      131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2011' is marked as crashed and last (automatic?) repair failed
      131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2012_' is marked as crashed and last (automatic?) repair failed
      131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2010' is marked as crashed and last (automatic?) repair failed
      131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2011' is marked as crashed and last (automatic?) repair failed
      131205  9:21:01 [ERROR] mysqld: Table './gtk1h/main2012_' is marked as crashed and last (automatic?) repair failed
      131205  9:40:07 [ERROR] mysqld got signal 11 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
      
      To report this bug, see http://kb.askmonty.org/en/reporting-bugs
      
      We will try our best to scrape up some info that will hopefully help
      diagnose the problem, but since we have already crashed, 
      something is definitely wrong and this may fail.
      
      Server version: 5.5.34-MariaDB-1~precise
      key_buffer_size=25769803776
      read_buffer_size=131072
      max_used_connections=13
      max_threads=52
      thread_count=5
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 26025358 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
      
      Thread pointer: 0x0x7f56d24a9000
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x7f5ce3d54e10 thread_stack 0x30000
      (my_addr_resolve failure: fork)
      /usr/sbin/mysqld(my_print_stacktrace+0x2b) [0x7f5ce64d58cb]
      /usr/sbin/mysqld(handle_fatal_signal+0x471) [0x7f5ce60fc1d1]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f5ce4fa1cb0]
      /usr/sbin/mysqld(Query_cache::unlink_table(Query_cache_block_table*)+0x6a) [0x7f5ce5f7ec9a]
      /usr/sbin/mysqld(Query_cache::register_all_tables(THD*, Query_cache_block*, TABLE_LIST*, unsigned int)+0x6a) [0x7f5ce5f816aa]
      /usr/sbin/mysqld(Query_cache::store_query(THD*, TABLE_LIST*)+0x413) [0x7f5ce5f829e3]
      /usr/sbin/mysqld(+0x380a82) [0x7f5ce5fb0a82]
      /usr/sbin/mysqld(mysql_execute_command(THD*)+0xe85) [0x7f5ce5fb8685]
      /usr/sbin/mysqld(+0x38e9c7) [0x7f5ce5fbe9c7]
      /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x2276) [0x7f5ce5fc1626]
      /usr/sbin/mysqld(do_handle_one_connection(THD*)+0x133) [0x7f5ce607e693]
      /usr/sbin/mysqld(handle_one_connection+0x51) [0x7f5ce607e7f1]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f5ce4f99e9a]
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5ce40913fd]
      
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x7f56d4c0e018): is an invalid pointer
      Connection ID (thread ID): 129320
      Status: NOT_KILLED
      
      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=off
      
      The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
      information that should help you find out what is causing the crash.
      131205 09:40:08 mysqld_safe Number of processes running now: 0
      131205 09:40:08 mysqld_safe mysqld restarted
      131205  9:40:11 [Note] Plugin 'InnoDB' is disabled.
      131205  9:40:11 [Note] Plugin 'FEEDBACK' is disabled.
      131205  9:40:11 [Note] Server socket created on IP: '127.0.0.1'.
      131205  9:40:12 [Note] Event Scheduler: Loaded 1 event
      131205  9:40:12 [Note] /usr/sbin/mysqld: ready for connections.
      Version: '5.5.34-MariaDB-1~precise'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
      131205  9:40:12 [ERROR] mysqld: Table './gtk1/customs_audit2013' is marked as crashed and should be repaired
      131205  9:40:12 [Warning] Checking table:   './gtk1/customs_audit2013'
      ....
      

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            Hi,

            according to the log fragment, you have a very big value for key_buffer_size. Like, really huge: key_buffer_size=25769803776. It's 24 Gb, right?
            Was it intentional? How much memory total do you have in your system so that you can afford that?
            With this level of generosity, it doesn't seem really surprising that MariaDB takes 32 Gb in total, there are other buffers as well.

            Otherwise, we do have one open bug with a suspected memory leak, MDEV-4974, which is currently being investigated, but at this point it's impossible to say if you encountered the same problem.

            For the crash, did it happen again? You don't have general log enabled by any chance, do you?

            Show
            elenst Elena Stepanova added a comment - Hi, according to the log fragment, you have a very big value for key_buffer_size. Like, really huge: key_buffer_size=25769803776. It's 24 Gb, right? Was it intentional? How much memory total do you have in your system so that you can afford that? With this level of generosity, it doesn't seem really surprising that MariaDB takes 32 Gb in total, there are other buffers as well. Otherwise, we do have one open bug with a suspected memory leak, MDEV-4974 , which is currently being investigated, but at this point it's impossible to say if you encountered the same problem. For the crash, did it happen again? You don't have general log enabled by any chance, do you?
            Hide
            elenst Elena Stepanova added a comment -

            Closing for now as incomplete, please comment if you have more information to re-open the bug

            Show
            elenst Elena Stepanova added a comment - Closing for now as incomplete, please comment if you have more information to re-open the bug

              People

              • Assignee:
                elenst Elena Stepanova
                Reporter:
                shestero Michael Shestero
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: