PDA

Voir la version complète : les serveurs RPS ne sont pas fiable au niveau de mysql


Afrolatino.net
02/04/2008, 02h31
Plantage de mysql
depuis vendredi 28 mars nous sommes passé en phase de production
et ceci plante 1 fois par jour sur Mysql et obliger de rebooter parce qu'il est impossible de relancer Mysql
avec aucune trace dans le log mysqld.err du crash

voici les topics
Serveur Mysql est tombé et ne redemarre malgre un reboot (http://forum.ovh.com/showthread.php?t=33237)
Serveur Mysql ne s'arrete pas sur les RPS (http://forum.ovh.com/showthread.php?t=33245)

Afrolatino.net
02/04/2008, 04h08
j'ai vu que le max_connexion de Mysql par défaut était de 100
cela fait beaucoup pour un
/home/log/mysql$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 220 @ 1.20GHz
stepping : 1
cpu MHz : 1200.063
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 2401.77
clflush size : 64

je l'ai paramétré max_connexion=20 pour l'instant
c'est bizarre crash de mysql sans aucune trace dans les log et impossible de le redemarrer, obliger de le rebooter
par contre le crash de mysql se fait toujours dans un pic traffic incoming de + 10mo

Afrolatino.net
02/04/2008, 04h23
Y atil possibilite de tracer le nombre de connection ?

pfoo
02/04/2008, 05h34
Commence par lancer un coup de tuning-primer pour analyser ta conf :
http://www.day32.com/MySQL/tuning-primer.sh

sum_fvm
02/04/2008, 09h36
les serveurs RPS ne sont pas fiable au niveau de mysql
depuis vendredi 28 mars nous sommes passé en phase de production
et ceci plante 1 fois par jour sur Mysql et obliger de rebooter parce qu'il est impossible de relancer Mysql
avec aucune trace dans le log mysqld.err du crash

voici les topics
Serveur Mysql est tombé et ne redemarre malgre un reboot (http://forum.ovh.com/showthread.php?t=33237)
Serveur Mysql ne s'arrete pas sur les RPS (http://forum.ovh.com/showthread.php?t=33245)

Moi je crois que tu es surtout victime de ton incompétence la plus totale...

D'où te permet de critiquer ce produit alors que tu en es la seule victime ?

T'as essayé avec un Superplan 2008 pour comparer ?

:rolleyes:

amapi
02/04/2008, 10h08
Rebooter parce que tu ne peux pas relancer mysql ?

Ca veux dire que tu n'accedes plus à ton serveur (complet, même plus en ssh) ou juste que c'est mysql qui ne se lance plus.

Car dans un cas, oui c'est un soucis (Linux plante) mais dans l'autre, c'est, comme dis un peu violemment ci-dessus, un manque de connaissance de Linux et de Mysql qui te bloques. Il est tout à fait possible "d'achever" mysql pour le relancer :)

$> man kill

N'oublie pas que tu n'a pas 2Go de ram et que tu n'as pas de swap. Limite donc le nombre de connexions mysql déjà.

Afrolatino.net
02/04/2008, 13h07
Moi je crois que tu es surtout victime de ton incompétence la plus totale...
D'où te permet de critiquer ce produit alors que tu en es la seule victime ?
T'as essayé avec un Superplan 2008 pour comparer ?
:rolleyes:
que dire :)
passe ton chemin et arrête de polluer mes posts

Bruno-KS
02/04/2008, 13h26
Moi je crois que tu es surtout victime de ton incompétence la plus totale...

D'où te permet de critiquer ce produit alors que tu en es la seule victime ?

+1 !!

saturne13
02/04/2008, 13h31
Moi je crois que tu es surtout victime de ton incompétence la plus totale...

D'où te permet de critiquer ce produit alors que tu en es la seule victime ?

T'as essayé avec un Superplan 2008 pour comparer ?

:rolleyes:

+2!!

Afrolatino.net
02/04/2008, 16h28
-3 .

amapi
02/04/2008, 16h37
-3 .


Ben réponds ...

C'est ton serveur complet (la machine) qui est planté et qui necessite un reboot ou juste mysql ?

Afrolatino.net
02/04/2008, 17h13
Rebooter parce que tu ne peux pas relancer mysql ?
Ca veux dire que tu n'accedes plus à ton serveur (complet, même plus en ssh) ou juste que c'est mysql qui ne se lance plus.
Car dans un cas, oui c'est un soucis (Linux plante) mais dans l'autre, c'est, comme dis un peu violemment ci-dessus, un manque de connaissance de Linux et de Mysql qui te bloques. Il est tout à fait possible "d'achever" mysql pour le relancer :)
$> man kill
N'oublie pas que tu n'a pas 2Go de ram et que tu n'as pas de swap. Limite donc le nombre de connexions mysql déjà.
Salut
Merci amapi de bien m'avoir repondu
j'accede tres bien au serveur Complet mais le start Mysql a partir de Webmin ne lance plus Mysql
la prochaine fois je ferais "ps aux | grep mysql " pour voir si il restait des process et un kill
j'ai limite max_connection à 20 mais a 13h mysql a encore plante par contre celui ci a pu redemarer

Afrolatino.net
02/04/2008, 17h24
J'ai aussi activer log = /tmp/mysqld.sql
Voici /etc/mysql/my.cnf
# /etc/mysql/my.cnf: The global mysql configuration file.
# $Header: /var/cvsroot/gentoo-x86/dev-db/mysql/files/my.cnf-4.1,v 1.3 2006/05/05 19:51:40 chtekk Exp $

# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /var/run/mysqld/mysqld.sock
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[php-cgi]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysql]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysqladmin]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysqlcheck]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysqldump]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysqlimport]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[mysqlshow]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=latin1

[myisamchk]
character-sets-dir=/usr/share/mysql/charsets

[myisampack]
character-sets-dir=/usr/share/mysql/charsets

# use [safe_mysqld] with mysql-3
[mysqld_safe]
err-log = /var/log/mysql/mysql.err

# add a section [mysqld-4.1] or [mysqld-5.0] for specific configurations
[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 = 16M
max_allowed_packet = 1M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
language = /usr/share/mysql/english

# security:
# using "localhost" in connects uses sockets by default
skip-networking
bind-address = 127.0.0.1

log-bin
server-id = 1

# point the following paths to different dedicated disks
tmpdir = /tmp/
#log-update = /path-to-dedicated-directory/hostname

# you need the debug USE flag enabled to use the following directives,
# if needed, uncomment them, start the server and issue
# #tail -f /tmp/mysqld.sql /tmp/mysqld.trace
# this will show you *exactly* what's happening in your server ;)

log = /tmp/mysqld.sql
#gdb
#debug = d:t:i:o,/tmp/mysqld.trace
#one-thread

# uncomment the following directives if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# the following is the InnoDB configuration
# if you wish to disable innodb instead
# uncomment just the next line
skip-innodb
#
# the rest of the innodb config follows:
# don't eat too much memory, we're trying to be safe on 64Mb boxes
# you might want to bump this up a bit on boxes with more RAM
innodb_buffer_pool_size = 16M
# this is the default, increase it if you have lots of tables
innodb_additional_mem_pool_size = 2M
#
# i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-(
# and upstream wants things to be under /var/lib/mysql/, so that's the route
# we have to take for the moment
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
# you may wish to change this size to be more suitable for your system
# the max is there to avoid run-away growth on your machine
innodb_data_file_path = ibdata1:10M:autoextend:max:128M
# we keep this at around 25% of of innodb_buffer_pool_size
# sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size)
innodb_log_file_size = 5M
# this is the default, increase it if you have very large transactions going on
innodb_log_buffer_size = 8M
# this is the default and won't hurt you
# you shouldn't need to tweak it
log-slow-queries = /var/log/mysql/mysql-slow-query.log # Log ou sera stocké requete depassant le "long_query_time"

# see the innodb config docs, the other options are not always safe
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
set-variable = max_connections=20


[mysqldump]
quick
max_allowed_packet = 16M
max_connections = 20

[mysql]
# uncomment the next directive if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

Afrolatino.net
02/04/2008, 17h27
un ps aux | grep mysql

/etc/mysql$ ps aux | grep mysql
mysql 24956 1.3 3.4 49188 16220 ? S 18:29 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 24957 1.3 3.4 49188 16220 ? S 18:29 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 24962 0.0 3.4 49188 16220 ? S 18:29 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 24976 24.0 3.4 49188 16220 ? R 18:29 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 24988 0.0 3.4 49188 16220 ? S 18:29 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 29623 0.0 3.4 49188 16220 ? Ss 15:31 0:03 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 29627 0.0 3.4 49188 16220 ? R 15:31 0:04 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 29628 0.0 3.4 49188 16220 ? S 15:31 0:05 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 29629 0.0 3.4 49188 16220 ? S 15:31 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock

Afrolatino.net
03/04/2008, 06h32
Voici le
/$ ./tuning-primer.sh

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.0.44-log i686

Uptime = 0 days 0 hrs 19 min 40 sec
Avg. qps = 12
Total Questions = 14591
Threads Connected = 1

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 10 sec.
You have 0 out of 14612 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is enabled
The expire_logs_days is not set.
The mysqld will retain the entire binary log until RESET MASTER or PURGE MASTER LOGS commands are run manually
Setting expire_log_days will allow you to remove old binary logs automatically
See http://dev.mysql.com/doc/refman/5.0/en/purge-master-logs.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 3
Historic threads_per_sec = 1
Threads created per/sec are overrunning threads cached
You should raise thread_cache_size

MAX CONNECTIONS
Current max_connections = 20
Current threads_connected = 1
Historic max_used_connections = 7
The number of used connections is 35% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 53 M
Configured Max Per-thread Buffers : 31 M
Configured Max Global Buffers : 42 M
Configured Max Memory Limit : 73 M
Physical Memory : 463.46 M
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 22 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 11838
Key buffer fill ratio = 3.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 512 K
Current read_rnd_buffer_size = 508 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 93 tables
You have 64 open tables.
Current table_cache hit rate is 9%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 1525 temp tables, 2% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 252 K
Current table scan ratio = 892 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 195
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.



Qu'est ce que vous en pensez?

amapi
03/04/2008, 06h46
Bon, à vu d'oeil t'as un lock sur une table (et apriori une requete coincée dessus) :

1- comme j'imagine que c'est systématiquement la même requête qui bloque, elle va le faire à chaque connexion (je parle de connexion sql , hein, pas web) ou presque, et ainsi "bloquer" une a une tes 20 threads de connexion, ce qui explique que ton mysql ne réponde plus, donc que ce soit 1 ou 500 connexion autorisé, ca plantera quand même.

2- je ne vais pas trop entrer dans les détails, mais tes tables sont en MyISAM qui a une particularité, il lock la table "ENTIERE" pour faire ses update/delete/insert. Et dans certain cas, la faute a mysql, ou la faute a ta requetes ca dépend, quand la table est locké, et qu'une deuxieme requete arrive, ca la bloque, (forcement la table est locké) mais ça ne la débloque plus. ainsi dessuite. C'est plein de cas particulier dont on pourrait débattre avec les pro/cons mysql :)

3- la solution :p (tu l'attendasis je pense :p) transforme tes table en InnoDB au lieu de MyISAM, je suis presque certain qu'on peut le faire avec phpMyAdmin,

Sinon tu peux le faire à la main :)
http://dev.mysql.com/doc/refman/5.0/fr/converting-tables-to-innodb.html

Par contre, ton titre est faux, le soucis que tu rencontres, je l'ai rencontrée sur des Machine Quadri Pro avec 4Go de Ram, ça ne vient pas du RPS mais d'une mauvaise gestion lié a requetes/processus qui lance la requetes/MyISAM

Afrolatino.net
05/04/2008, 16h21
Bon, à vu d'oeil t'as un lock sur une table (et apriori une requete coincée dessus) :

1- comme j'imagine que c'est systématiquement la même requête qui bloque, elle va le faire à chaque connexion (je parle de connexion sql , hein, pas web) ou presque, et ainsi "bloquer" une a une tes 20 threads de connexion, ce qui explique que ton mysql ne réponde plus, donc que ce soit 1 ou 500 connexion autorisé, ca plantera quand même.

2- je ne vais pas trop entrer dans les détails, mais tes tables sont en MyISAM qui a une particularité, il lock la table "ENTIERE" pour faire ses update/delete/insert. Et dans certain cas, la faute a mysql, ou la faute a ta requetes ca dépend, quand la table est locké, et qu'une deuxieme requete arrive, ca la bloque, (forcement la table est locké) mais ça ne la débloque plus. ainsi dessuite. C'est plein de cas particulier dont on pourrait débattre avec les pro/cons mysql :)

3- la solution :p (tu l'attendasis je pense :p) transforme tes table en InnoDB au lieu de MyISAM, je suis presque certain qu'on peut le faire avec phpMyAdmin,

Sinon tu peux le faire à la main :)
http://dev.mysql.com/doc/refman/5.0/fr/converting-tables-to-innodb.html

Par contre, ton titre est faux, le soucis que tu rencontres, je l'ai rencontrée sur des Machine Quadri Pro avec 4Go de Ram, ça ne vient pas du RPS mais d'une mauvaise gestion lié a requetes/processus qui lance la requetes/MyISAM

Désolé je n'ai pu te répondre rapidement
je te reponds bientot

virgil
06/04/2008, 13h42
T'es sur un forum d'entraide entre utilisateur ... calme toi ils ont raisons

Afrolatino.net
07/04/2008, 22h13
Salut amapi
Désolé je n'ai pu te répondre rapidement, j'etais surbooké de mon coté, bref

J'ai bien lu ce que tu m'as dit :
je vais essayer de faire le transfert MyISAM2InnoDB sur un domaine test et copier mes bases sur le domaine principal

Pour info:
Ces bases ont toujours tourné en MyISAM sur mysql4 en hébergement mutualisé avec 5 connexions simultanées sans aucun problème a ce niveau la
Petite Question
Pourquoi cela planterais avec cette config RPS?

Autres Infos: Voici une Autopsie d'un plantage Mysql actuel sur le RPS 1

le Crash Mysql a eu lieu ~ à 12:40:30

Je vais sur mon site je tombe sur ma page de Maintenance:mad:
vite j'ouvre WinSCP pour analyse le problème
Je fait un ps sur le process mysql
/$ ps aux | grep mysql
root 5842 0.0 0.1 1792 604 ? D 14:54 0:00 grep mysql

Plus de process mysql :eek:

je fais un df
/$ df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/sda1 3099260 1601916 1339912 55% /
/dev/sda2 7218464 866060 5985724 13% /home
shm 237292 0 237292 0% /dev/shm

Pas de souci espace disque :)

j'essaye de démarré mysql

rXXXXX ~ # /etc/init.d/mysql start
* WARNING: "mysql" has already been started.


celui-ci me dit qu'il est demarré :confused:

Donc je fait un stop

rXXXXX ~ # /etc/init.d/mysql stop
* Stopping mysql ...
* Stopping mysqld (0)
start-stop-daemon: warning: failed to kill 10094: No such process [ ok ]

yes ça marche (pas de process à tuer :confused: donc c'etait un drapeau a initialisé je pense )

donc je fait un start

rXXXXX ~ # /etc/init.d/mysql start
* Starting mysql ...
* Strange, the socket file already exist in "/var/run/mysqld/mysqld.sock"
* it will be removed now and re-created by the MySQL server
* BUT please make your checks.
* Starting mysql (/etc/mysql/my.cnf)

Ok Ca roule ;)

je fait un ps sur Mysql


/root$ ps aux | grep mysql
mysql 8356 0.0 3.4 49816 16544 ? Ss 15:02 0:06 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 8371 0.0 3.4 49816 16544 ? S 15:02 0:08 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 8372 0.0 3.4 49816 16544 ? S 15:02 0:09 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
mysql 8374 0.0 3.4 49816 16544 ? S 15:02 0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock

Les process sont la :cool:

je fait un df
/$ df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/sda1 3099260 1601940 1339888 55% /
/dev/sda2 7218464 868516 5983268 13% /home
shm 237292 0 237292 0% /dev/shm

Tout est ok :D

Que pensez vous de ces process mysql qui disparaissent :confused:

ce plantage intervient plusieurs fois par semaine
la seule chose que j'ai remarque a chaque plantage il ya eu c'est un pic incomming voir http://img339.imageshack.us/img339/7282/graph1gi4.jpg , mais a chaque pic icomming il n'y a pas eu plantage
Mon Rps1 est souvent a 100% d'UC pendant + 10 minutes certaines fois dans les période de pointe (dommage qu'il n'a pas de graphique sur l'utilisation de l'uc de la ram)
aucun info sur les log mysqld.err
lors du plantage j'avais : set-variable = max_connections=40 (par defaut c'etait a 100 ça planté, j'ai mis a 20 ça a plante aussi)

question : si les 512 mo de ram sont occupé est ce que cela peut faire tomber mysql, puisqu'il n'y a pas de SWAP ?


Par contre, ton titre est faux, le soucis que tu rencontres, je l'ai rencontrée sur des Machine Quadri Pro avec 4Go de Ram, ça ne vient pas du RPS mais d'une mauvaise gestion lié a requetes/processus qui lance la requetes/MyISAM
PS: on ne peut change le titre desolé

T'es sur un forum d'entraide entre utilisateur ... calme toi ils ont raisons
Je suis calme et :cool: je sais que c'est un forum d'entraide d'utilisateur , et que le problème que je rencontre pourra servir a d'autres aussi

itanium
07/04/2008, 22h23
Bonsoir,

Quelle distribution? Gentoo R2 64?

La manque de ram pourrait planter le serveur mais effectivement, là, c'est assez étrange.

Afrolatino.net
07/04/2008, 22h28
Bonsoir,
Quelle distribution? Gentoo R2 64?
La manque de ram pourrait planter le serveur mais effectivement, là, c'est assez étrange.

Salut itanium

Manager OVH me dit
Informations distribution
Distribution : Gentoo Base System version 1.6.14
Kernel : 2.6.24.2-xxxx-std-ipv4-32
Date : 4 SMP Wed Feb 13 16:50:04 CET 2008

~ # uname -a
Linux rXXXXX.ovh.net 2.6.24.2-xxxx-std-ipv4-32 #4 SMP Wed Feb 13 16:50:04 CET 2008 i686 Intel(R) Celeron(R) CPU 220 @ 1.20GHz GenuineIntel GNU/Linux

itanium
07/04/2008, 23h58
Ok donc gentoo 32 bits. Ayant vu et connu des soucis avec mysql sous 64 bits je me demandais...

Sinon on dirait d'après les logs que mysql tourne en boucle sur une requête et se bloque. Enfin amapi devait être sur la bonne voie.

Combien de requête sur la page d'accueil du site? Serait-ce IPB 1.3?

Afrolatino.net
08/04/2008, 00h14
Sinon on dirait d'après les logs que mysql tourne en boucle sur une requête et se bloque.
Pourquoi cela plante pas en mutualise?

Serait-ce IPB 1.3?
Yes 1.3.1 avec MyibPortail :cool:


Combien de requête sur la page d'accueil du site?
Soit plus precis que veut tu dire par la ?
sur la page d'accueil j'ai en + 3 iframe qui attaque chacune d'elle la base mysql
certes mon code n'est pas trop optimisé

itanium
08/04/2008, 00h20
Pourquoi cela plante pas en mutualise?

Peut être que le serveur apache/mysql est mieux configuré.

Que dit les logs syslog et mysql au moment de problème?

Afrolatino.net
08/04/2008, 00h33
Peut être que le serveur apache/mysql est mieux configuré.
Que dit les logs syslog et mysql au moment de problème?
mysqld.err dit rien pas un mot (Ps: j'avais aussi arrête la réplication "qui etait active par default" j'avais un Warning
Syslog ??? euh c'est quel fichier et dans quel repertoire :confused:

itanium
08/04/2008, 00h36
Syslog se trouve dans /var/log ;)

Afrolatino.net
08/04/2008, 01h15
Syslog se trouve dans /var/log ;)

ok je te fais un lien par MP sur le fichier Syslog

MP pas possible
voici le lien http://www.afrolatino.net/syslog.tgz

Afrolatino.net
08/04/2008, 01h32
tiens j'ai des attaques sshd de
http://www.completewhois.com/cgi2/whois.cgi?query=91.121.199.84

Afrolatino.net
08/04/2008, 01h51
dans mail.log
j'ai de nombreuses erreurs
Apr 8 02:51:52 r11375 X-Qmail-Scanner-2.01st: [r11375.ovh.net120761591276727558] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2
Apr 8 02:52:04 r11375 X-Qmail-Scanner-2.01st: [r11375.ovh.net120761592476727600] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2
Apr 8 02:52:09 r11375 X-Qmail-Scanner-2.01st: [r11375.ovh.net120761592976727629] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2
Apr 8 02:52:14 r11375 X-Qmail-Scanner-2.01st: [r11375.ovh.net120761593276727693] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2
Apr 8 02:52:38 r11375 X-Qmail-Scanner-2.01st: [r11375.ovh.net120761595876727797] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2

Afrolatino.net
08/04/2008, 02h06
:eek::eek::eek::eek:
Voila j'ai trouvé UNE TRACE les process Mysqsl killed dans kern.log
Apr 6 12:40:48 r11375 php invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Apr 6 12:40:48 r11375 Pid: 30514, comm: php Not tainted 2.6.24.2-xxxx-std-ipv4-32 #4
Apr 6 12:40:48 r11375 [<c0142d98>] oom_kill_process+0x108/0x120
Apr 6 12:40:48 r11375 [<c0142f56>] out_of_memory+0xd6/0x110
Apr 6 12:40:48 r11375 [<c0144790>] __alloc_pages+0x250/0x340
Apr 6 12:40:48 r11375 [<c0114dcf>] try_to_wake_up+0x1bf/0x2e0
Apr 6 12:40:48 r11375 [<c01471df>] __do_page_cache_readahead+0xff/0x150
Apr 6 12:40:48 r11375 [<c01472f6>] do_page_cache_readahead+0x46/0x70
Apr 6 12:40:48 r11375 [<c0140726>] filemap_fault+0x266/0x330
Apr 6 12:40:48 r11375 [<c0116b2e>] __wake_up+0x3e/0x60
Apr 6 12:40:55 r11375 [<c014f8ce>] __do_fault+0x7e/0x3c0
Apr 6 12:40:55 r11375 [<c014ffa0>] handle_mm_fault+0x130/0x300
Apr 6 12:40:55 r11375 [<c0111afb>] do_page_fault+0x13b/0x790
Apr 6 12:40:55 r11375 [<c03598b7>] sis900_interrupt+0x107/0x110
Apr 6 12:40:55 r11375 [<c049a7f6>] net_tx_action+0xa6/0xf0
Apr 6 12:40:55 r11375 [<c01206a4>] __do_softirq+0xd4/0xf0
Apr 6 12:40:55 r11375 [<c01119c0>] do_page_fault+0x0/0x790
Apr 6 12:40:55 r11375 [<c055bc02>] error_code+0x72/0x78
Apr 6 12:40:55 r11375 =======================
Apr 6 12:40:55 r11375 Mem-info:
Apr 6 12:40:55 r11375 DMA per-cpu:
Apr 6 12:40:55 r11375 CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 6 12:40:55 r11375 Normal per-cpu:
Apr 6 12:40:55 r11375 CPU 0: Hot: hi: 186, btch: 31 usd: 181 Cold: hi: 62, btch: 15 usd: 60
Apr 6 12:40:55 r11375 Active:107957 inactive:382 dirty:0 writeback:0 unstable:0
Apr 6 12:40:55 r11375 free:1264 slab:4680 mapped:410 pagetables:1538 bounce:0
Apr 6 12:40:55 r11375 DMA free:1928kB min:92kB low:112kB high:136kB active:7124kB inactive:0kB present:16256kB pages_scanned:13797 all_unreclaimable? yes
Apr 6 12:40:55 r11375 lowmem_reserve[]: 0 459 459 459
Apr 6 12:40:55 r11375 Normal free:3128kB min:2692kB low:3364kB high:4036kB active:424704kB inactive:1528kB present:470408kB pages_scanned:871901 all_unreclaimable? yes
Apr 6 12:40:55 r11375 lowmem_reserve[]: 0 0 0 0
Apr 6 12:40:55 r11375 DMA: 2*4kB 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1928kB
Apr 6 12:40:55 r11375 Normal: 360*4kB 42*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 3152kB
Apr 6 12:40:55 r11375 Swap cache: add 0, delete 0, find 0/0, race 0+0
Apr 6 12:40:55 r11375 Free swap = 0kB
Apr 6 12:40:55 r11375 Total swap = 0kB
Apr 6 12:40:55 r11375 Free swap: 0kB
Apr 6 12:40:55 r11375 122624 pages of RAM
Apr 6 12:40:55 r11375 0 pages of HIGHMEM
Apr 6 12:40:55 r11375 3978 reserved pages
Apr 6 12:40:55 r11375 41328 pages shared
Apr 6 12:40:55 r11375 0 pages swap cached
Apr 6 12:40:55 r11375 0 pages dirty
Apr 6 12:40:55 r11375 0 pages writeback
Apr 6 12:40:55 r11375 410 pages mapped
Apr 6 12:40:55 r11375 4680 pages slab
Apr 6 12:40:55 r11375 1538 pages pagetables
Apr 6 12:40:55 r11375 Out of memory: kill process 30210 (mysqld) score 16002 or a child
Apr 6 12:40:55 r11375 Killed process 30210 (mysqld)

certes il doit y avoir des requêtes qui prennent trop de mémoire :( comment les trouver?
ou
comment les expulser by le my.cnf of mysql?:rolleyes:

Afrolatino.net
08/04/2008, 02h32
tiens un petit free
r11375 ~ # free
total used free shared buffers cached
Mem: 474584 260480 214104 0 29468 105920
-/+ buffers/cache: 125092 349492
Swap: 0 0 0

amapi
08/04/2008, 13h47
Alors:

1) Tu ne nous a pas dis si tout fonctionnait bien en utilisant des tables innoDB.

2) Pourquoi ça fonctionnerait mieux en innoDB alors que ça a toujours fonctionné tres bien en myIsam ?

C'est simple. Là ou tu as des temps d'accès et des taux de transfert avec quasiment aucune charge CPU sur un dédié, c'est tout l'inverse sur un RPS (latence importante, temps de transfert variable selon la bande passante partagé du SAN, sans compter le charge CPU bouffé par l'iScsi).

Comme je l'ai dis, en myIsam, c'est l'intégralité de la table qui est lockée à chaque modification.
Cmme les modifications prennent plus de temps (machine et disque plus lent sur un RPS) les chances qu'un process lock sur une table pendant qu'un autre veux aussi y accèder son largement plus grandes.

Tu va ensuite empiler les processus mysqls (et apache) et selon le type de requetes, tu vas faire un joli deadlock et là ... c'est la fin :p

Il n'y a donc strictement rien d'annormal à ce que les table myIsam pose soucis sur un serveur RPS.

Maintenant, mysql offre l'opportunité de palier à ce soucis, il suffit donc de s'en servir.

pmadfm
08/04/2008, 14h35
Bonjour,

As tu essayé les paramètres suivants :

concurrent_insert = 8

low_priority_updates = 1

...

Pour information, la configuration peut tout faire, il y a encore quelque jours je tournais avec un load moyen de 1.5 et en grattant un peu voilà ce que j'ai en période semi-creuse:

top - 15:52:09 up 3 days, 11:24, 1 user, load average: 0.45, 0.56, 0.58
Tasks: 318 total, 14 running, 303 sleeping, 0 stopped, 1 zombie
Cpu(s): 14.6% us, 4.7% sy, 0.0% ni, 80.6% id, 0.0% wa, 0.2% hi, 0.0% si
Mem: 2056596k total, 1996008k used, 60588k free, 194404k buffers
Swap: 2096472k total, 0k used, 2096472k free, 1032776k cached

Quand au table lock j'étais en moyenne à 750 et maintenant à 1/1180, on est encore loin des 5000 considérés comme optimum mais c'est déjà une belle évolution.

Le problème est que chaque configuration est différente selon les ressources et selon la fréquentation, le nombre de requête et la qualité des requêtes.

Même elles on peut les diminuer, en améliorant le paramétrage de mysql, je suis passé de 17 000 000 de requêtes par jour à 11 000 000.

Et je suis sur qu'en cherchant bien on pourrait encore faire mieux et sans peine.

C'est un travail de longue halène, alors bon courage.

Afrolatino.net
08/04/2008, 22h27
Bonjour,
As tu essayé les paramètres suivants :
concurrent_insert = 8
low_priority_updates = 1
...
Pour information, la configuration peut tout faire, il y a encore quelque jours je tournais avec un load moyen de 1.5 et en grattant un peu voilà ce que j'ai en période semi-creuse:
top - 15:52:09 up 3 days, 11:24, 1 user, load average: 0.45, 0.56, 0.58
Tasks: 318 total, 14 running, 303 sleeping, 0 stopped, 1 zombie
Cpu(s): 14.6% us, 4.7% sy, 0.0% ni, 80.6% id, 0.0% wa, 0.2% hi, 0.0% si
Mem: 2056596k total, 1996008k used, 60588k free, 194404k buffers
Swap: 2096472k total, 0k used, 2096472k free, 1032776k cached
Quand au table lock j'étais en moyenne à 750 et maintenant à 1/1180, on est encore loin des 5000 considérés comme optimum mais c'est déjà une belle évolution.
Le problème est que chaque configuration est différente selon les ressources et selon la fréquentation, le nombre de requête et la qualité des requêtes.
Même elles on peut les diminuer, en améliorant le paramétrage de mysql, je suis passé de 17 000 000 de requêtes par jour à 11 000 000.
Et je suis sur qu'en cherchant bien on pourrait encore faire mieux et sans peine.
C'est un travail de longue halène, alors bon courage.

Je suis d'accord avec toi chaque config a sa particularité

================================================== =======
J'ai un petit souci avec ton conseil sur /etc/mysql/my.cnf
concurrent_insert = 8

j'ai trouve ceci "on ne parle pas de metre une valeur decimale"
http://64.233.183.104/search?q=cache:x5uojPDJmcoJ:dev.mysql.com/doc/mysql/fr/server-system-variables.html+concurrent_insert&hl=fr&ct=clnk&cd=3&gl=fr&lr=lang_fr
concurrent_insert:
Si cette option vaut ON, MySQL va vous permettre de réaliser des commandes INSERT sur les tables MyISAM en même temps que d'autres commandes SELECT seront exécutées. Vous pouvez désactiver cette option en démarrant mysqld avec l'option --safe or --skip-new. Cette variable a été ajoutée en MySQL 3.23.7.

================================================== =========
ok pour:
low_priority_updates = 1
http://64.233.183.104/search?q=cache:x5uojPDJmcoJ:dev.mysql.com/doc/mysql/fr/server-system-variables.html+low_priority_updates&hl=fr&ct=clnk&cd=3&gl=fr&lr=lang_fr
low_priority_updates
Si cette option vaut 1, toutes les requêtes INSERT, UPDATE, DELETE et LOCK TABLE WRITE attendent qu'il n'y ait plus de SELECT ou de LOCK TABLE READ en attente pour cette table. Cette variable s'appelait avant sql_low_priority_updates. Cette variable a été ajoutée en MySQL 3.22.5.

Afrolatino.net
08/04/2008, 22h42
Alors:
1) Tu ne nous a pas dis si tout fonctionnait bien en utilisant des tables innoDB.
2) Pourquoi ça fonctionnerait mieux en innoDB alors que ça a toujours fonctionné tres bien en myIsam ?
C'est simple. Là ou tu as des temps d'accès et des taux de transfert avec quasiment aucune charge CPU sur un dédié, c'est tout l'inverse sur un RPS (latence importante, temps de transfert variable selon la bande passante partagé du SAN, sans compter le charge CPU bouffé par l'iScsi).
Comme je l'ai dis, en myIsam, c'est l'intégralité de la table qui est lockée à chaque modification.
Cmme les modifications prennent plus de temps (machine et disque plus lent sur un RPS) les chances qu'un process lock sur une table pendant qu'un autre veux aussi y accèder son largement plus grandes.
Tu va ensuite empiler les processus mysqls (et apache) et selon le type de requetes, tu vas faire un joli deadlock et là ... c'est la fin :p
Il n'y a donc strictement rien d'annormal à ce que les table myIsam pose soucis sur un serveur RPS.
Maintenant, mysql offre l'opportunité de palier à ce soucis, il suffit donc de s'en servir.

1) Je suis entrain d'entrain d'essayer et pour l'instant je n'y suis pas arrivé pas a les mettre en innoDB, c'est en cours .....

comment je fait:
je fait un export de mes tables Myisam en un fichier .sql

j'ai ajouté la ligne default-table-type=innodb dans la section [mysqld] du fichier my.cnf

J'ai aussi commenter
#skip-innodb

et ne pas oublier de redemmarer mysql pour qu'il prennent en compte les nouvel option my.cnf :rolleyes::rolleyes:


2) merci pour tes explications qui parraissent logique;)

Afrolatino.net
08/04/2008, 23h12
Myisam to InnoDB

J'ai des erreurs du type
Error at the line 358368: ) ENGINE=InnoDB AUTO_INCREMENT=25 DEFAULT CHARSET=latin1 AUTO_INCREMENT=25 ;

Query: CREATE TABLE IF NOT EXISTS `ipboard_avatars` (
`id` int(12) unsigned NOT NULL auto_increment,
`used_by` bigint(10) unsigned default NULL,
`name` varchar(128) NOT NULL default '',
`filename` varchar(128) NOT NULL default '',
`keywords` varchar(128) default NULL,
PRIMARY KEY (`id`),
KEY `name` (`name`),
FULLTEXT KEY `keywords` (`keywords`)
) ENGINE=InnoDB AUTO_INCREMENT=25 DEFAULT CHARSET=latin1 AUTO_INCREMENT=25 ;

MySQL: The used table type doesn't support FULLTEXT indexes

RaphAstronome
09/04/2008, 11h35
Tu as des indexs en FULLTEXT et c'est pas compatible avec InnoDB.

http://www.grafactory.net/blog/post/2007/09/07/Recherche-Fulltext-et-InnoDB-avec-Mysql
(pas testé)

pmadfm
10/04/2008, 14h51
Bonjour,


j'ai trouve ceci "on ne parle pas de metre une valeur decimale"
http://64.233.183.104/search?q=cache...=fr&lr=lang_fr
concurrent_insert:
Si cette option vaut ON, MySQL va vous permettre de réaliser des commandes INSERT sur les tables MyISAM en même temps que d'autres commandes SELECT seront exécutées. Vous pouvez désactiver cette option en démarrant mysqld avec l'option --safe or --skip-new. Cette variable a été ajoutée en MySQL 3.23.7.

Exact !

C'est une saisie involontaire à la volée par dessus la valeur ON.

Pu.. de clavier, ou alors c'est les lunnettes ou alors c'est l'age ou pire encore c'est les trois ensemble ;-)

Non allez, plus sérieusement, je crois en effet qu'en V3xx c'était ON, mais maintenant en V5, c'est sur que ON n'est plus reconnu et empêche même de lancer le serveur MySQL.

Donc cela dépend de ta version.

Je peux te fournir mes paramètres mais bien sur il faudra les adapter sachant que je suis sur un 100++L (pIV 3.0Ghz et 2Go de RAM) et que j'ai un annuaire de mesure d'audience qui bouffe pas mal en insert et en update environ 350 000 transactions par jour 01topsites.com pour ne pas le citer ;-)

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 = 80M
max_allowed_packet = 1M
table_cache = 4096
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 128K
read_rnd_buffer_size = 128K
myisam_sort_buffer_size = 8M
language = /usr/share/mysql/french

## PM AJOUT ##
long_query_time = 3
thread_cache_size = 8
join_buffer_size = 2M
concurrent_insert = 8
max_connections = 128

max_heap_table_size = 16M
tmp_table_size = 128M

query_cache_min_res_unit = 8K
query_cache_limit = 128K
query_cache_size = 256M

low_priority_updates = 1
log-slow-queries = /var/log/mysql/mysql-slow.log
log-queries-not-using-indexes = /var/log/mysql/log-queries-not-using-indexes.log

# security:
# using "localhost" in connects uses sockets by default
skip-networking
bind-address = 127.0.0.1

#log-bin = /var/log/mysql/mysql-bin.log
#expire_logs_days = 1
server-id = 1


Attention mon choix délibéré de tuer la log bin supprime la possibilité du recovery.

En fait je tape à environ 13 000 000 de TP par jour, il te faut adapter à ta consommation.

Autre chose amusante, la config d'origine done :
read_buffer_size = 256K
read_rnd_buffer_size = 512K

En fait cela dépend de tes applications, si elles font beaucoup de lectures et peu de mise à jour c'est positifs de les laisser comme ça sinon il faut les réduire.

L'impact est qu'on lit moins d'information à l'avance, mais si on en à pas besoin, par exemple accès sélectif, cela gagne des lectures inutiles.

read_buffer_size = 128K
read_rnd_buffer_size = 128K

Je les testerais même à l'occasion si j'ai un peu de temps avec 64K ... A voir

En synthèse, avec mysql, si on sort des paramètres par défaut, il faut bien connaitre mysql, mais également l'ensemble des applicatif qui tournent afin d'évaluer les meilleurs paramètres.

Un peu coton tout çà ...

Afrolatino.net
14/04/2008, 21h11
Ok merci pmadfm pour tes infos de tunning je les garde précieusement a mes futurs test
Merci à RaphAstronome et à amapi et aussi à itanium pour vos conseils pour passer en innoDB

actuellement :
j'ai toujours des plantages de mysql a cause de Out Of Memory
voici 1 extrait du kern.log
Apr 14 20:30:45 r11375 printk: 1 messages suppressed.
Apr 14 20:30:45 r11375 php invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Apr 14 20:30:45 r11375 Pid: 27412, comm: php Not tainted 2.6.24.2-xxxx-std-ipv4-32 #4
Apr 14 20:30:45 r11375 [<c0142d98>] oom_kill_process+0x108/0x120
Apr 14 20:30:45 r11375 [<c0142f56>] out_of_memory+0xd6/0x110
Apr 14 20:30:45 r11375 [<c0144790>] __alloc_pages+0x250/0x340
Apr 14 20:30:45 r11375 [<c0114dcf>] try_to_wake_up+0x1bf/0x2e0
Apr 14 20:30:45 r11375 [<c01471df>] __do_page_cache_readahead+0xff/0x150
Apr 14 20:30:45 r11375 [<c01472f6>] do_page_cache_readahead+0x46/0x70
Apr 14 20:30:45 r11375 [<c0140726>] filemap_fault+0x266/0x330
Apr 14 20:30:46 r11375 [<c0116b2e>] __wake_up+0x3e/0x60
Apr 14 20:30:46 r11375 [<c014f8ce>] __do_fault+0x7e/0x3c0
Apr 14 20:30:46 r11375 [<c014ffa0>] handle_mm_fault+0x130/0x300
Apr 14 20:30:46 r11375 [<c0111afb>] do_page_fault+0x13b/0x790
Apr 14 20:30:46 r11375 [<c03598b7>] sis900_interrupt+0x107/0x110
Apr 14 20:30:46 r11375 [<c02b67c2>] copy_to_user+0x32/0x50
Apr 14 20:30:46 r11375 [<c01206a4>] __do_softirq+0xd4/0xf0
Apr 14 20:30:46 r11375 [<c01119c0>] do_page_fault+0x0/0x790
Apr 14 20:30:46 r11375 [<c055bc02>] error_code+0x72/0x78
Apr 14 20:30:46 r11375 [<c0550000>] sctp_addr_id2transport+0x0/0x70
Apr 14 20:30:46 r11375 =======================
Apr 14 20:30:46 r11375 Mem-info:
Apr 14 20:30:46 r11375 DMA per-cpu:
Apr 14 20:30:46 r11375 CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 14 20:30:46 r11375 Normal per-cpu:
Apr 14 20:30:46 r11375 CPU 0: Hot: hi: 186, btch: 31 usd: 184 Cold: hi: 62, btch: 15 usd: 49
Apr 14 20:30:46 r11375 Active:106482 inactive:133 dirty:0 writeback:0 unstable:0
Apr 14 20:30:46 r11375 free:1149 slab:4923 mapped:416 pagetables:1930 bounce:0
Apr 14 20:30:46 r11375 DMA free:1920kB min:92kB low:112kB high:136kB active:6992kB inactive:0kB present:16256kB pages_scanned:24078 all_unreclaimable? yes
Apr 14 20:30:46 r11375 lowmem_reserve[]: 0 459 459 459
Apr 14 20:30:46 r11375 Normal free:2676kB min:2692kB low:3364kB high:4036kB active:418936kB inactive:532kB present:470408kB pages_scanned:635814 all_unreclaimable? yes
Apr 14 20:30:46 r11375 lowmem_reserve[]: 0 0 0 0
Apr 14 20:30:46 r11375 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1920kB
Apr 14 20:30:46 r11375 Normal: 272*4kB 3*8kB 7*16kB 8*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2696kB
Apr 14 20:30:46 r11375 Swap cache: add 0, delete 0, find 0/0, race 0+0
Apr 14 20:30:46 r11375 Free swap = 0kB
Apr 14 20:30:46 r11375 Total swap = 0kB
Apr 14 20:30:46 r11375 Free swap: 0kB
Apr 14 20:30:46 r11375 122624 pages of RAM
Apr 14 20:30:46 r11375 0 pages of HIGHMEM
Apr 14 20:30:46 r11375 3978 reserved pages
Apr 14 20:30:46 r11375 54346 pages shared
Apr 14 20:30:46 r11375 0 pages swap cached
Apr 14 20:30:46 r11375 0 pages dirty
Apr 14 20:30:46 r11375 0 pages writeback
Apr 14 20:30:46 r11375 416 pages mapped
Apr 14 20:30:46 r11375 4923 pages slab
Apr 14 20:30:46 r11375 1930 pages pagetables
Apr 14 20:30:46 r11375 Out of memory: kill process 27127 (mysqld) score 14848 or a child
Apr 14 20:30:46 r11375 Killed process 27127 (mysqld)
Apr 14 20:30:46 r11375 php invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Apr 14 20:30:46 r11375 Pid: 27315, comm: php Not tainted 2.6.24.2-xxxx-std-ipv4-32 #4
Apr 14 20:30:46 r11375 [<c0142d98>] oom_kill_process+0x108/0x120
Apr 14 20:30:46 r11375 [<c0142f56>] out_of_memory+0xd6/0x110
Apr 14 20:30:46 r11375 [<c0144790>] __alloc_pages+0x250/0x340
Apr 14 20:30:46 r11375 [<c01471df>] __do_page_cache_readahead+0xff/0x150
Apr 14 20:30:46 r11375 [<c01472f6>] do_page_cache_readahead+0x46/0x70
Apr 14 20:30:46 r11375 [<c0140726>] filemap_fault+0x266/0x330
Apr 14 20:30:46 r11375 [<c0116b2e>] __wake_up+0x3e/0x60
Apr 14 20:30:46 r11375 [<c014f8ce>] __do_fault+0x7e/0x3c0
Apr 14 20:30:46 r11375 [<c014d7c2>] zap_pte_range+0x1e2/0x2e0
Apr 14 20:30:46 r11375 [<c014ffa0>] handle_mm_fault+0x130/0x300
Apr 14 20:30:46 r11375 [<c0111afb>] do_page_fault+0x13b/0x790
Apr 14 20:30:46 r11375 [<c02b67c2>] copy_to_user+0x32/0x50
Apr 14 20:30:46 r11375 [<c01281bd>] sys_rt_sigaction+0x8d/0xa0
Apr 14 20:30:46 r11375 [<c01119c0>] do_page_fault+0x0/0x790
Apr 14 20:30:46 r11375 [<c055bc02>] error_code+0x72/0x78
Apr 14 20:30:46 r11375 [<c0550000>] sctp_addr_id2transport+0x0/0x70
Apr 14 20:30:46 r11375 =======================
Apr 14 20:30:46 r11375 Mem-info:
Apr 14 20:30:46 r11375 DMA per-cpu:
Apr 14 20:30:46 r11375 CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 14 20:30:46 r11375 Normal per-cpu:
Apr 14 20:30:46 r11375 CPU 0: Hot: hi: 186, btch: 31 usd: 35 Cold: hi: 62, btch: 15 usd: 61
Apr 14 20:30:46 r11375 Active:106204 inactive:342 dirty:0 writeback:0 unstable:0
Apr 14 20:30:46 r11375 free:1148 slab:4896 mapped:425 pagetables:1930 bounce:0
Apr 14 20:30:46 r11375 DMA free:1924kB min:92kB low:112kB high:136kB active:7048kB inactive:0kB present:16256kB pages_scanned:16173 all_unreclaimable? yes
Apr 14 20:30:46 r11375 lowmem_reserve[]: 0 459 459 459
Apr 14 20:30:46 r11375 Normal free:2668kB min:2692kB low:3364kB high:4036kB active:417768kB inactive:1368kB present:470408kB pages_scanned:682843 all_unreclaimable? yes
Apr 14 20:30:46 r11375 lowmem_reserve[]: 0 0 0 0
Apr 14 20:30:46 r11375 DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1924kB
Apr 14 20:30:46 r11375 Normal: 269*4kB 2*8kB 5*16kB 8*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2644kB
Apr 14 20:30:46 r11375 Swap cache: add 0, delete 0, find 0/0, race 0+0
Apr 14 20:30:46 r11375 Free swap = 0kB
Apr 14 20:30:46 r11375 Total swap = 0kB
Apr 14 20:30:46 r11375 Free swap: 0kB
Apr 14 20:30:46 r11375 122624 pages of RAM
Apr 14 20:30:46 r11375 0 pages of HIGHMEM
Apr 14 20:30:46 r11375 3978 reserved pages
Apr 14 20:30:46 r11375 54776 pages shared
Apr 14 20:30:46 r11375 0 pages swap cached
Apr 14 20:30:46 r11375 0 pages dirty
Apr 14 20:30:46 r11375 0 pages writeback
Apr 14 20:30:46 r11375 425 pages mapped
Apr 14 20:30:46 r11375 4896 pages slab
Apr 14 20:30:46 r11375 1930 pages pagetables
Apr 14 20:30:46 r11375 Out of memory: kill process 27131 (mysqld) score 14848 or a child
Apr 14 20:30:46 r11375 Killed process 27131 (mysqld)

Afrolatino.net
14/04/2008, 21h15
voila le message que j'ai au redemarrage de mysql

r11375 ~ # /etc/init.d/mysql stop
* Stopping mysql ...
* Stopping mysqld (0)
start-stop-daemon: warning: failed to kill 4899: No such process [ ok ]
r11375 ~ # /etc/init.d/mysql start
* Starting mysql ...
* Strange, the socket file already exist in "/var/run/mysqld/mysqld.sock"
* it will be removed now and re-created by the MySQL server
* BUT please make your checks.
* Starting mysql (/etc/mysql/my.cnf) [ ok ]

J'ai solutionné mon problème de qmail que me saturait l'espace disque sda1
voir http://forum.ovh.com/showthread.php?p=170789#post170789

je mets en stand by le transfert des bases myIsam 2 InnoDB
je vais faire transférer mon site sur un kimsufi et voir si j'ai les même souci

Afrolatino.net
15/04/2008, 09h40
Comment empêcher au rps de faire un kill sur Mysql en cas de out of memory?
est ce que de prendre un rps avec 1go de memoire RAM resoudra le probleme ou un kimsufi avec 256Mo + swap??:cool::cool:

seedaumas
15/04/2008, 09h49
Je pense qu'un kimsuffi résoudrait ton kill de mysql, mais le problème avec le kimsuffie c'est les 256Mo de memoire et il va swaper en permanence et niveau perf ca pas etre terrible.

Afrolatino.net
15/04/2008, 12h55
Je pense qu'un kimsuffi résoudrait ton kill de mysql, mais le problème avec le kimsuffie c'est les 256Mo de memoire et il va swaper en permanence et niveau perf ca pas etre terrible.

Peut etre les perf a ces moments là seront lentes mais au moins cela ne mettra pas le site HORS SERVICES dans ce cas je prendrais une config au dessus
J'ai lance un nouveau thread omment eviter les temps de latence de 24h-72h des DNS en cas Changement de Serveur (http://forum.ovh.com/showthread.php?p=171760)

Afrolatino.net
15/04/2008, 12h56
...

Afrolatino.net
15/04/2008, 21h18
A mon Message au support ovh
De : xxxxxx-OVH
Pour : OVH Help desk
Date : 2008-04-15 10:42:09
actuellement :
j'ai toujours des plantages de mysql a cause de
Out Of Memory
Comment empêcher de faire au rps de faire un kill
en cas de out of memory?
est ce que de prendre un rps avec 1go de memoire
RAM resoudra le probleme ou un kimsufi avec 256Mo
+ swap??

voici leur reponse
De : Angie
Pour : xxxxxxxx-ovh
Date : 2008-04-15 17:17:54

Bonjour,

ces killers viennent d'un script qui consomme trop de resources:

top - 17:14:27 up 8:34, 1 user, load average: 1.76, 1.77,
1.55
Tasks: 132 total, 3 running, 129 sleeping, 0 stopped,
0 zombie
Cpu(s): 77.9% us, 17.1% sy, 0.0% ni, 5.0% id, 0.0% wa,
0.0% hi, 0.0% si
Mem: 474584k total, 423620k used, 50964k free,
26596k buffers
Swap: 0k total, 0k used, 0k free,
181248k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND


894 mysql 20 0 59568 24m 3396 R 6.0 5.3 0:00.18
/usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf
--basedir=/usr --datadir=/var/lib/mysql
--pid-file=/var/run/mysqld/mysqld.pid --socket=/var
891 afrolati 20 0 15888 7304 3336 S 2.7 1.5 0:00.08
/usr/local/php4/bin/php


893 afrolati 20 0 14072 5168 3112 S 1.3 1.1 0:00.04
/usr/local/php4/bin/php


593 nobody 20 0 7060 2532 1300 S 0.7 0.5 0:00.02
/usr/local/apache/bin/httpd -D SSL -k start


2144 named 20 0 18880 15m 1636 S 0.7 3.3 0:45.40
/usr/sbin/named -u named -n 1


2217 mysql 20 0 59568 24m 3396 S 0.7 5.3 0:13.70
/usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf
--basedir=/usr --datadir=/var/lib/mysql
--pid-file=/var/run/mysqld/mysqld.pid --socket=/var
2389 root 20 0 2892 788 592 S 0.7 0.2 0:24.38
/usr/sbin/collectd

Vous pourriez corriger ces problèmes ?
[Tue Apr 15 09:21:05 2008] [error] [client 87.98.145.134]
PHP Warning: mime_magic: type
search/400\t\\\\chapter\ttext/x-tex invalid in Unknown on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 87.98.145.134]
PHP Warning: mime_magic: type
search/400\t\\\\documentclass\ttext/x-tex invalid in Unknown
on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
regex\t\tBEGIN[[:space:]]*[{]\tapplication/x-awk invalid in
Unknown on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\input\t\ttext/x-tex invalid in Unknown on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\section\ttext/x-tex invalid in Unknown on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\setlength\ttext/x-tex invalid in Unknown on
line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\documentstyle\ttext/x-tex invalid in Unknown
on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\chapter\ttext/x-tex invalid in Unknown on line 0
[Tue Apr 15 09:21:05 2008] [error] [client 193.251.81.232]
PHP Warning: mime_magic: type
search/400\t\\\\documentclass\ttext/x-tex invalid in Unknown
on line 0
*

Laissez un top tourner sur la machine et vous allez
rapidement voir que votre php fait plein de defunct et que
le mysqld ainsi que le httpd chargent le serveur.
Vérifiez votre error_log d'apache.

Cordialement,
Angie


Comment trouver les problemes dont il parle "Vous pourriez corriger ces problèmes ?"
A quoi correspondent ces requetes [Tue Apr 15 09:21:05 2008] [error] [client 87.98.145.134]
PHP Warning: mime_magic: type
search/400\t\\\\chapter\ttext/x-tex invalid in Unknown on line 0