[wp-hackers] Mysql crash

[Stlib]

Hello !

I've turned of the Advanced Category Excluder, and we will see if the crash 
reappeared...

I guess if you have an idea without deactivate all plugins, cause I need its 
:(

Moreover, if Advanced Category Excluder is the problem, do you think I can 
use Simply Exclude plugin or it will provoque the same crash ?

Thanks.



----- Original Message ----- 
From: "Chris Jean" <gaarai at gaarai.com>
To: <wp-hackers at lists.automattic.com>
Sent: Friday, February 19, 2010 6:09 PM
Subject: Re: [wp-hackers] Mysql crash


> Have you tried turning off the plugins to determine the exact cause of the 
> issue?
>
> Chris Jean
> Coder for http://ithemes.com/
> http://gaarai.com/
> @chrisjean
>
>
> On 02/19/2010 10:31 AM, Stlib wrote:
>> Hello !
>>
>> I have recently moved a Wordpress blog into a new servor which has these 
>> caracteristics : debian, mysql 5.0.51a-24, 16GB of ram.
>>
>> The mysql crashed regularly with this log info:
>>
>> 100219 12:50:42 - mysqld got signal 6;
>> 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=134217728
>> read_buffer_size=131072
>> max_used_connections=40
>> max_connections=2000
>> threads_connected=7
>> It is possible that mysqld could use up to
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 
>> 4483056 K
>> bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> thd=0x153f280
>> 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...
>> Cannot determine thread, fp=0x153f280, backtrace may not be correct.
>> Bogus stack limit or frame pointer, fp=0x153f280, 
>> stack_bottom=0x44a20000, thread_stack=131072, aborting backtrace.
>> Trying to get some variables.
>> Some pointers may be invalid and cause the dump to abort...
>> thd->query at 0x145fc30 = SELECT SQL_CALC_FOUND_ROWS distinct wp_posts.* 
>> FROM wp_posts  LEFT JOIN wp_term_relationships ON (wp_posts.ID = 
>> wp_term_relationships.object_id)  LEFT JOIN wp_term_taxono$
>> thd->thread_id=6120
>> The manual page at http://www.mysql.com/doc/en/Crashing.html contains
>> information that should help you find out what is causing the crash.
>>
>>
>> Can anyone knows about this problem ? I found on wp-hackers that advanced 
>> category excluder plugin may be the source of the problem (here: 
>> http://lists.automattic.com/pipermail/wp-hackers/2009-October/027973.html 
>>  ).
>> If this plugin is the problem, why didn't the server crash on the old 
>> servor, before the migration, whereas the old servor is less powerful 
>> than the new ?
>>
>> Thanks for help, and sorry for my bad english, I'm from France ! ;)
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>