Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Crash Magento/MySQL pendant le cron
 
Sebastien P.
Jr. Member
 
Total Posts:  10
Joined:  2009-02-18
 

Bonjour à tous,

Nous avons depuis quelques jours un soucis Magento/MySQL qui crashe régulièrement la base de données lors de l’exécution du cron.

MySQL fait un Out of memory (dans le retour de dmesg), et nous donne ce retour dans le fichier log MySQL :

100110  0:00:03 mysqld got signal 6;
This could be because you hit a bugIt is also possible that this binary
or one of the libraries it was linked against is corruptimproperly built,
or 
misconfiguredThis 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 crashedsomething is definitely wrong
and this may fail.

key_buffer_size=536870912
read_buffer_size
=4190208
max_used_connections
=7
max_connections
=50
threads_connected
=1
It is possible that mysqld could 
use up to
key_buffer_size 
+ (read_buffer_size sort_buffer_size)*max_connections 933687 K
bytes of memory
Hope that
's ok; if not, decrease some variables in the equation.

thd=0x19b2d20
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=0x41488068, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x6d656972656c6167
New value of fp=0x19b2d20 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x1a9f860 = SELECT `base`.`customer_group_id`, MIN(value) AS `minimal_value` FROM `catalogindex_price` AS `base` WHERE (base.entity_id in ('
62')) AND (base.attribute_id in ('75', '60')) AND (base.website_id = '1') GROUP BY `base`.`customer_group_id`
thd->thread_id=97699
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.
pure virtual method called
terminate called without an active exception
100110  0:01:03 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '
--log-bin=/var/run/mysqld/mysqld-bin' to avoid this problem.
100110  0:01:03  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
100110  0:01:03  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 3632892917.
InnoDB: Doing recovery: scanned up to log sequence number 0 3634229625
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 13 row operations to undo
InnoDB: Trx id counter is 0 6030592
100110  0:01:03  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 227172770, file name /var/run/mysqld/mysqld-bin.000029
InnoDB: Starting in background the rollback of uncommitted transactions
100110  0:01:03  InnoDB: Rolling back trx with id 0 6030192, 13 rows to undo
100110  0:01:04  InnoDB: Started; log sequence number 0 3634229625
100110  0:01:04 [Note] Recovering after a crash using /var/run/mysqld/mysqld-bin

InnoDB: Rolling back of trx id 0 6030192 completed
100110  0:01:04  InnoDB: Rollback of non-prepared transactions completed
100110  0:01:07 [Note] Starting crash recovery...
100110  0:01:07 [Note] Crash recovery finished.
100110  0:01:07 [Note] /usr/sbin/mysqld: ready for connections.
Version: '
5.0.44-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.44-r2

Dans un premier temps nous avons tenté de modifier les paramètres MySQL en suivant les indications présentes ici, mais sans succès.

Voici le my.cnf que nous avons :

[mysqld]
character
-set-server                    latin1
init
-connect='SET NAMES  latin1'
default-character-set                   latin1
user                                    
mysql
port                                    
3306
socket                                  
= /var/run/mysqld/mysqld.sock
pid
-file                                = /var/run/mysqld/mysqld.pid
log
-error                               = /var/log/mysql/mysqld.err
basedir                                 
= /usr
datadir                                 
= /var/lib/mysql
skip
-locking
key_buffer                              
256M
max_allowed_packet                      
64M
table_cache                             
1024

query_cache_size                        
96M
query_cache_type                        
1
query_cache_limit                       
20M
thread_cache_size                       
8

join_buffer_size                        
10M

max_connections                         
50
wait_timeout                            
300

tmp_table_size                          
128M

open_files_limit                        
1024
sort_buffer_size                        
4M
net_buffer_length                       
8K
read_buffer_size                        
4M
read_rnd_buffer_size                    
2M
myisam_sort_buffer_size                   
64M
language                                
= /usr/share/mysql/english
log
-bin
server
-id                               1
tmpdir                                  
= /tmp/
#skip-innodb
innodb_buffer_pool_size                 16M
innodb_additional_mem_pool_size         
2M
innodb_data_file_path                     
ibdata1:10M:autoextend:max:1024M
innodb_log_file_size                     
5M
innodb_log_buffer_size                     
8M
set
-variable                             innodb_log_files_in_group=2
innodb_flush_log_at_trx_commit             
1
innodb_lock_wait_timeout                 
50

Depuis ce matin nous avons modifié la variable innodb_buffer_pool_size de 16 à 128Mo (cf. lien), ce qui a l’air de rendre le serveur plus stable.

Notre infrastructure : serveur OVH SP MINI (Core 2 Duo, 2Go de RAM, Gento Release 2 OVH).

Si vous aviez une idée de ce qui pourrait poser problème.

Merci de votre aide.
Sébastien

 
Magento Community Magento Community
Magento Community
Magento Community
 
coolio
Jr. Member
 
Total Posts:  18
Joined:  2010-02-10
 

Où avez-vous apportez les modifications à nnodb_buffer_pool_size? avez-vous fait des changements dans le fichier php.ini? grâce!

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top