Re: 'myisam_use_mmap' unstable like hell
Am 15.12.2011 08:47, schrieb Rob Wultsch: To be brutally honest, if you want stability you should not be using MyISAM this is bullshit without 'myisam_use_mmap' i never saw mysqld crashing in the past 10 years, independent of the storage engine much less a not particularly commonly used feature. mmap is not rocket science, so i do not understnd why this is not properly debugged and EFAULT on signature.asc Description: OpenPGP digital signature
Re: 'myisam_use_mmap' unstable like hell
When I had memory issues, with something relatively stable, mostly is due faulty ram... Can you use or less ram or change fisically the ram? On Thu, Dec 15, 2011 at 2:23 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 15.12.2011 08:47, schrieb Rob Wultsch: To be brutally honest, if you want stability you should not be using MyISAM this is bullshit without 'myisam_use_mmap' i never saw mysqld crashing in the past 10 years, independent of the storage engine much less a not particularly commonly used feature. mmap is not rocket science, so i do not understnd why this is not properly debugged and EFAULT on
Re: 'myisam_use_mmap' unstable like hell
this is NOT a memory issue 'myisam_use_mmap' in mysqld is buggy since a long time http://bugs.mysql.com/bug.php?id=48726 we are speaking of a HP ProLiant DL 380G7 in a VMware-Cluster with 36 GB ECC-RAM while there are machines using InnoDB with 'large-pages' and some GB buffer_pool_size on the same host and not about some customer hardware Am 15.12.2011 18:22, schrieb Andrés Tello: When I had memory issues, with something relatively stable, mostly is due faulty ram... Can you use or less ram or change fisically the ram? On Thu, Dec 15, 2011 at 2:23 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 15.12.2011 08:47, schrieb Rob Wultsch: To be brutally honest, if you want stability you should not be using MyISAM this is bullshit without 'myisam_use_mmap' i never saw mysqld crashing in the past 10 years, independent of the storage engine much less a not particularly commonly used feature. mmap is not rocket science, so i do not understnd why this is not properly debugged and DEFAULT on signature.asc Description: OpenPGP digital signature
Re: 'myisam_use_mmap' unstable like hell
On Dec 15, 2011, at 12:02 PM, Reindl Harald wrote: this is NOT a memory issue 'myisam_use_mmap' in mysqld is buggy since a long time http://bugs.mysql.com/bug.php?id=48726 This is fixed in 5.1.61, 5.5.20, 5.6.5: http://dev.mysql.com/doc/refman/5.6/en/news-5-6-5.html we are speaking of a HP ProLiant DL 380G7 in a VMware-Cluster with 36 GB ECC-RAM while there are machines using InnoDB with 'large-pages' and some GB buffer_pool_size on the same host and not about some customer hardware Am 15.12.2011 18:22, schrieb Andrés Tello: When I had memory issues, with something relatively stable, mostly is due faulty ram... Can you use or less ram or change fisically the ram? On Thu, Dec 15, 2011 at 2:23 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 15.12.2011 08:47, schrieb Rob Wultsch: To be brutally honest, if you want stability you should not be using MyISAM this is bullshit without 'myisam_use_mmap' i never saw mysqld crashing in the past 10 years, independent of the storage engine much less a not particularly commonly used feature. mmap is not rocket science, so i do not understnd why this is not properly debugged and DEFAULT on -- Paul DuBois Oracle Corporation / MySQL Documentation Team Madison, Wisconsin, USA www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: 'myisam_use_mmap' unstable like hell
Am 15.12.2011 19:48, schrieb Paul DuBois: On Dec 15, 2011, at 12:02 PM, Reindl Harald wrote: this is NOT a memory issue 'myisam_use_mmap' in mysqld is buggy since a long time http://bugs.mysql.com/bug.php?id=48726 This is fixed in 5.1.61, 5.5.20, 5.6.5: http://dev.mysql.com/doc/refman/5.6/en/news-5-6-5.html hopefully you understand that i do not trust here since it was buggy like hell more than two years and from one major-release to the next signature.asc Description: OpenPGP digital signature
Re: 'myisam_use_mmap' unstable like hell
To be brutally honest, if you want stability you should not be using MyISAM, much less a not particularly commonly used feature. On Thu, Nov 24, 2011 at 12:58 AM, Reindl Harald h.rei...@thelounge.net wrote: and the next one without memlock 24 09:50:30 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 24 09:50:35 mysqld_safe Starting mysqld daemon with databases from /Volumes/dune/mysql_data 24 9:50:35 [Note] Plugin 'InnoDB' is disabled. 24 9:50:35 [Note] Plugin 'FEDERATED' is disabled. 24 9:50:35 [Note] Plugin 'BLACKHOLE' is disabled. 24 9:50:35 [Note] Plugin 'ARCHIVE' is disabled. 24 9:50:35 [Note] Plugin 'partition' is disabled. 24 9:50:35 [Note] Event Scheduler: Loaded 0 events 24 9:50:35 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.18-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 thelounge.net build 24 9:53:12 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:12 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:17 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:17 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:22 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:22 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:32 [ERROR] Got error 127 when reading table './afi/cms1_sub2' 24 9:53:32 [ERROR] Got error 127 when reading table './afi/cms1_sub2' 24 9:55:02 [ERROR] Got error 127 when reading table './hurnaus/cms1_galerie_sub' 24 9:55:02 [ERROR] Got error 127 when reading table './hurnaus/cms1_galerie_sub' 24 9:55:14 - 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. 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. key_buffer_size=268435456 read_buffer_size=262144 max_used_connections=12 max_threads=200 thread_count=3 connection_count=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 418015 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x2ea7080 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 = 0x7ffd2ea39d40 thread_stack 0x4 /usr/libexec/mysqld(my_print_stacktrace+0x33)[0x7ab8f3] /usr/libexec/mysqld(handle_segfault+0x470)[0x50f190] /lib64/libpthread.so.0(+0xeeb0)[0x7ffdaae93eb0] /lib64/libc.so.6(+0x12ffa5)[0x7ffda920cfa5] /usr/libexec/mysqld(mi_mmap_pread+0x15a)[0x90880a] /usr/libexec/mysqld(_mi_read_dynamic_record+0x1fe)[0x90ac5e] /usr/libexec/mysqld(mi_rkey+0x378)[0x930f48] /usr/libexec/mysqld(_ZN9ha_myisam14index_read_mapEPhPKhm16ha_rkey_function+0x59)[0x8f1fe9] /usr/libexec/mysqld[0x5b3f35] /usr/libexec/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x61)[0x5a4721] /usr/libexec/mysqld[0x5b2c65] /usr/libexec/mysqld(_ZN4JOIN4execEv+0xbe1)[0x5c39b1] /usr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x152)[0x5bf182] /usr/libexec/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x184)[0x5c5074] /usr/libexec/mysqld[0x57df97] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x2438)[0x585808] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x186)[0x589ef6] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x15e5)[0x58b505] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x117)[0x61fff7] /usr/libexec/mysqld(handle_one_connection+0x50)[0x6200a0] /lib64/libpthread.so.0(+0x6ccb)[0x7ffdaae8bccb] /lib64/libc.so.6(clone+0x6d)[0x7ffda91bdc2d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ffd20021720): is an invalid pointer Connection ID (thread ID): 647 Status: NOT_KILLED Original-Nachricht Betreff: 'myisam_use_mmap' unstable like hell Datum: Thu, 24 Nov 2011 09:20:28 +0100 Von: Reindl Harald h.rei...@thelounge.net Organisation: the lounge interactive design An: Mailing-List mysql mysql@lists.mysql.com introduced with 5.1 myisam_use_mmap leads in 5.5.18 after some days to table crashes - will this be ever useful on servers with thousands of tables? 24 8:20:17 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one
Fwd: 'myisam_use_mmap' unstable like hell
and the next one without memlock 24 09:50:30 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 24 09:50:35 mysqld_safe Starting mysqld daemon with databases from /Volumes/dune/mysql_data 24 9:50:35 [Note] Plugin 'InnoDB' is disabled. 24 9:50:35 [Note] Plugin 'FEDERATED' is disabled. 24 9:50:35 [Note] Plugin 'BLACKHOLE' is disabled. 24 9:50:35 [Note] Plugin 'ARCHIVE' is disabled. 24 9:50:35 [Note] Plugin 'partition' is disabled. 24 9:50:35 [Note] Event Scheduler: Loaded 0 events 24 9:50:35 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.18-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 thelounge.net build 24 9:53:12 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:12 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:17 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:17 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:22 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:22 [ERROR] Got error 127 when reading table './aume/skefonds2009_ext_content' 24 9:53:32 [ERROR] Got error 127 when reading table './afi/cms1_sub2' 24 9:53:32 [ERROR] Got error 127 when reading table './afi/cms1_sub2' 24 9:55:02 [ERROR] Got error 127 when reading table './hurnaus/cms1_galerie_sub' 24 9:55:02 [ERROR] Got error 127 when reading table './hurnaus/cms1_galerie_sub' 24 9:55:14 - 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. 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. key_buffer_size=268435456 read_buffer_size=262144 max_used_connections=12 max_threads=200 thread_count=3 connection_count=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 418015 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x2ea7080 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 = 0x7ffd2ea39d40 thread_stack 0x4 /usr/libexec/mysqld(my_print_stacktrace+0x33)[0x7ab8f3] /usr/libexec/mysqld(handle_segfault+0x470)[0x50f190] /lib64/libpthread.so.0(+0xeeb0)[0x7ffdaae93eb0] /lib64/libc.so.6(+0x12ffa5)[0x7ffda920cfa5] /usr/libexec/mysqld(mi_mmap_pread+0x15a)[0x90880a] /usr/libexec/mysqld(_mi_read_dynamic_record+0x1fe)[0x90ac5e] /usr/libexec/mysqld(mi_rkey+0x378)[0x930f48] /usr/libexec/mysqld(_ZN9ha_myisam14index_read_mapEPhPKhm16ha_rkey_function+0x59)[0x8f1fe9] /usr/libexec/mysqld[0x5b3f35] /usr/libexec/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x61)[0x5a4721] /usr/libexec/mysqld[0x5b2c65] /usr/libexec/mysqld(_ZN4JOIN4execEv+0xbe1)[0x5c39b1] /usr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x152)[0x5bf182] /usr/libexec/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x184)[0x5c5074] /usr/libexec/mysqld[0x57df97] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x2438)[0x585808] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x186)[0x589ef6] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x15e5)[0x58b505] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x117)[0x61fff7] /usr/libexec/mysqld(handle_one_connection+0x50)[0x6200a0] /lib64/libpthread.so.0(+0x6ccb)[0x7ffdaae8bccb] /lib64/libc.so.6(clone+0x6d)[0x7ffda91bdc2d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ffd20021720): is an invalid pointer Connection ID (thread ID): 647 Status: NOT_KILLED Original-Nachricht Betreff: 'myisam_use_mmap' unstable like hell Datum: Thu, 24 Nov 2011 09:20:28 +0100 Von: Reindl Harald h.rei...@thelounge.net Organisation: the lounge interactive design An: Mailing-List mysql mysql@lists.mysql.com introduced with 5.1 myisam_use_mmap leads in 5.5.18 after some days to table crashes - will this be ever useful on servers with thousands of tables? 24 8:20:17 - 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. 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
