J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un
spécialiste ?
J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant +/- 500
sites différents dont la moitié à peu près en php/mysql.
Une autre (sur un réseau interne en 100M) est le serveur Mysql.
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les
connexions.
(un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par
minute]
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
# My.cnf
#
# inspiré de /usr/share/doc/mysql-server/examples/my-large.cnf.gz
#
# This is for a large system with memory = 512M where the system runs mainly
# MySQL.
#
# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /var/run/mysqld/mysqld.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
port = 3306
socket = /var/run/mysqld/mysqld.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log = /var/log/mysql.log
#log = /var/log/mysql/mysql.log
# Replication Master Server (default)
# binary logging is required for replication
#log-bin
# Uncomment the following if you are using BDB tables
#bdb_cache_size = 64M
#bdb_max_lock = 100000
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 256M
#innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 64M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
Le Tuesday 1 November 2005 14:24, Francois Sauterey(Francois Sauterey ) disait:
Salut,
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ?
Je ne suis pas un spécialiste, mais voici quelques pistes : - Ajouter une barette de RAM - Lire la page http://dev.mysql.com/doc/refman/4.1/en/optimization.html - Indexer les tables ; un coup de 'mysqlcheck --check' et sutout 'mysqlcheck --optimize' régulièrement - Utilser les logs de slowquery pour déterminer les requetes lentes et les ré écrire (en profiter aussi pour créer des indexes si besoin) - Optimiser les accès disks (utilisation hdparam si le disk ide)
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Essayez d'augementer sort_buffer_size, myisam_sort_buffer_size et query_cache_size. Ces paramètres sont expliqués sur le site de Mysql. La plupart du temps, l'optimisation est empirique : il faut essayer plusieurs paramètres avant de trouver le bon compromis ! A+
-- Glennie "La vie offre toujours deux pentes. On grimpe ou on se laisse glisser."
Le Tuesday 1 November 2005 14:24, Francois Sauterey(Francois Sauterey
<Francois@sauterey.org>) disait:
Salut,
J'ai un petit soucis avec un serveur Mysql, et peut-être y
aura-t-il ici un spécialiste ?
Je ne suis pas un spécialiste, mais voici quelques pistes :
- Ajouter une barette de RAM
- Lire la page
http://dev.mysql.com/doc/refman/4.1/en/optimization.html
- Indexer les tables ; un coup de 'mysqlcheck --check' et sutout
'mysqlcheck --optimize' régulièrement
- Utilser les logs de slowquery pour déterminer les requetes lentes
et les ré écrire (en profiter aussi pour créer des indexes si
besoin)
- Optimiser les accès disks (utilisation hdparam si le disk ide)
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Essayez d'augementer sort_buffer_size, myisam_sort_buffer_size et
query_cache_size. Ces paramètres sont expliqués sur le site de
Mysql.
La plupart du temps, l'optimisation est empirique : il faut essayer
plusieurs paramètres avant de trouver le bon compromis !
A+
--
Glennie
"La vie offre toujours deux pentes. On grimpe ou on se laisse
glisser."
Le Tuesday 1 November 2005 14:24, Francois Sauterey(Francois Sauterey ) disait:
Salut,
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ?
Je ne suis pas un spécialiste, mais voici quelques pistes : - Ajouter une barette de RAM - Lire la page http://dev.mysql.com/doc/refman/4.1/en/optimization.html - Indexer les tables ; un coup de 'mysqlcheck --check' et sutout 'mysqlcheck --optimize' régulièrement - Utilser les logs de slowquery pour déterminer les requetes lentes et les ré écrire (en profiter aussi pour créer des indexes si besoin) - Optimiser les accès disks (utilisation hdparam si le disk ide)
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Essayez d'augementer sort_buffer_size, myisam_sort_buffer_size et query_cache_size. Ces paramètres sont expliqués sur le site de Mysql. La plupart du temps, l'optimisation est empirique : il faut essayer plusieurs paramètres avant de trouver le bon compromis ! A+
-- Glennie "La vie offre toujours deux pentes. On grimpe ou on se laisse glisser."
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Michel OLTRA
bonjour,
Le mardi 01 novembre 2005, Francois Sauterey a écrit...
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Je regarderais :
back_log connect_timeout max_connections
tu peux démarrer le serveur avec --log-warnings pour avoir plus de logs. tu peux te pencher sur les variables du SHOW STATUS (SHOW STATUS LIKE 'Max%' pour le nombre maxi de connexions simultanées).
-- jm
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
bonjour,
Le mardi 01 novembre 2005, Francois Sauterey a écrit...
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les
connexions.
(un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par
minute]
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Je regarderais :
back_log
connect_timeout
max_connections
tu peux démarrer le serveur avec --log-warnings pour avoir plus de logs.
tu peux te pencher sur les variables du SHOW STATUS (SHOW STATUS LIKE
'Max%' pour le nombre maxi de connexions simultanées).
--
jm
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le mardi 01 novembre 2005, Francois Sauterey a écrit...
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Je regarderais :
back_log connect_timeout max_connections
tu peux démarrer le serveur avec --log-warnings pour avoir plus de logs. tu peux te pencher sur les variables du SHOW STATUS (SHOW STATUS LIKE 'Max%' pour le nombre maxi de connexions simultanées).
-- jm
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
G(P)L
Francois Sauterey a écrit :
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ? J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergean t +/- 500 sites différents dont la moitié à peu près en php/mysql. Une autre (sur un réseau interne en 100M) est le serveur Mysql. Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse réguliè rement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un ref us par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonsoir, Il faudrait voir pourquoi la base de données refuse les connexions , car si ce sont des sites webs "classiques", ca m'étonne que 500 tables mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la mémoire vive, des ressources processeurs, des accès disques, de la bande-passante, ... La machine ne semble pas répondre à un _ping_ et donc c'est que la machine sature sur une ressource et non suite à un timeout créé par un MySQL trop long à repondre. Il faut donc voir ce qui crée cette saturation matérielle : une requête php/MySQL, une machine sous-dimensionnée en RAM ou CPU ?
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une recherche plus rapide ou quelques commandes indiquées par les autres utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement interne), mais AMHA il faut regarder la conso moyenne (sous-dimensionnement de la machine) et ce qui provoque les saturations (peut-être une site web qui a une BD très importante, ou qui héberg e un script PHP CPUphage).
Bonne soirée Guillaume Lehmann
Francois Sauterey a écrit :
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un
spécialiste ?
J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergean t +/- 500
sites différents dont la moitié à peu près en php/mysql.
Une autre (sur un réseau interne en 100M) est le serveur Mysql.
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse réguliè rement les
connexions.
(un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un ref us par
minute]
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonsoir,
Il faudrait voir pourquoi la base de données refuse les connexions ,
car si ce sont des sites webs "classiques", ca m'étonne que 500 tables
mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la
mémoire vive, des ressources processeurs, des accès disques, de la
bande-passante, ...
La machine ne semble pas répondre à un _ping_ et donc c'est que la
machine sature sur une ressource et non suite à un timeout créé par un
MySQL trop long à repondre. Il faut donc voir ce qui crée cette
saturation matérielle : une requête php/MySQL, une machine
sous-dimensionnée en RAM ou CPU ?
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une
recherche plus rapide ou quelques commandes indiquées par les autres
utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement
interne), mais AMHA il faut regarder la conso moyenne
(sous-dimensionnement de la machine) et ce qui provoque les saturations
(peut-être une site web qui a une BD très importante, ou qui héberg e un
script PHP CPUphage).
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ? J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergean t +/- 500 sites différents dont la moitié à peu près en php/mysql. Une autre (sur un réseau interne en 100M) est le serveur Mysql. Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse réguliè rement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un ref us par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonsoir, Il faudrait voir pourquoi la base de données refuse les connexions , car si ce sont des sites webs "classiques", ca m'étonne que 500 tables mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la mémoire vive, des ressources processeurs, des accès disques, de la bande-passante, ... La machine ne semble pas répondre à un _ping_ et donc c'est que la machine sature sur une ressource et non suite à un timeout créé par un MySQL trop long à repondre. Il faut donc voir ce qui crée cette saturation matérielle : une requête php/MySQL, une machine sous-dimensionnée en RAM ou CPU ?
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une recherche plus rapide ou quelques commandes indiquées par les autres utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement interne), mais AMHA il faut regarder la conso moyenne (sous-dimensionnement de la machine) et ce qui provoque les saturations (peut-être une site web qui a une BD très importante, ou qui héberg e un script PHP CPUphage).
Bonne soirée Guillaume Lehmann
Francois Sauterey
Le Mercredi 02 Novembre 2005 19:03, G(P)L a écrit :
Francois Sauterey a écrit : > J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici > un spécialiste ? > J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant > +/- 500 sites différents dont la moitié à peu près en php/mysql. > Une autre (sur un réseau interne en 100M) est le serveur Mysql. > Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement > les connexions. > (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus > par minute] > Je cherche à optimiser les (nombreux) paramètres de MysqlServer. > > Ci-joint, mon my.cnf... > > @micalement,
Bonsoir, Il faudrait voir pourquoi la base de données refuse les connexions, car si ce sont des sites webs "classiques", ca m'étonne que 500 tables
heu... 500 bases x 50 tables = 25000 tables au total...
mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la mémoire vive, des ressources processeurs, des accès disques, de la bande-passante, ...
uptime: 8:49:40 up 12 days, 3:27, 8 users, load average: 0.26, 0.32, 0.23 vmstat (après plusieur étapes effacées): procs -----------memory---------- ---swap-- -----io---- --system------cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 32424 13004 21420 223624 0 0 0 4 265 319 0 1 99 0 Bref pas de swap... on reste dans les 512 Mo (je sais c'est un peu juste...)
La bande passante : réseau à 100Mbs
La machine ne semble pas répondre à un _ping_ et donc c'est que la machine sature sur une ressource et non suite à un timeout créé par un MySQL trop long à repondre. Il faut donc voir ce qui crée cette saturation matérielle : une requête php/MySQL, une machine sous-dimensionnée en RAM ou CPU ?
Machine: Serveyur Dell poweredge 1550 bi proc PIII / 512 Mo
Voilà les stats données par phpmyadmin: Trafic | ø par heure Reçu 186 514 Ko | 23 163 Ko Envoyé 1 156 Mo | 147 045 Ko Total 1 338 Mo | 170 208 Ko
Clairement ~14% des connexion échouent ;~{ Total | ø par heure | ø par minute | ø par seconde 1 259 190 | 156 377,95 | 2 606,30 | 43,44
pour un uptime-mysql de 0 jours, 8 heures, 3 minutes et 8 secondes
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une recherche plus rapide ou quelques commandes indiquées par les autres utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement interne), mais AMHA il faut regarder la conso moyenne (sous-dimensionnement de la machine) et ce qui provoque les saturations (peut-être une site web qui a une BD très importante, ou qui héberge un script PHP CPUphage).
En fait l'essentiel des sites tourne sous spip...
je peux aussi ajouter: Max used connections : 10 key buffer size : 402653184 Key blocks used : 142392 Key read requests : 12248752
En espérant que ces renseignements permettront un début de diagnostic ? @micalement, -- Francois Sauterey @: Francois_AT_Sauterey.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Mercredi 02 Novembre 2005 19:03, G(P)L a écrit :
Francois Sauterey a écrit :
> J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici
> un spécialiste ?
> J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant
> +/- 500 sites différents dont la moitié à peu près en php/mysql.
> Une autre (sur un réseau interne en 100M) est le serveur Mysql.
> Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement
> les connexions.
> (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus
> par minute]
> Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
>
> Ci-joint, mon my.cnf...
>
> @micalement,
Bonsoir,
Il faudrait voir pourquoi la base de données refuse les connexions,
car si ce sont des sites webs "classiques", ca m'étonne que 500 tables
heu... 500 bases x 50 tables = 25000 tables au total...
mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la
mémoire vive, des ressources processeurs, des accès disques, de la
bande-passante, ...
uptime:
8:49:40 up 12 days, 3:27, 8 users, load average: 0.26, 0.32, 0.23
vmstat (après plusieur étapes effacées):
procs -----------memory---------- ---swap-- -----io---- --system------cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 32424 13004 21420 223624 0 0 0 4 265 319 0 1 99 0
Bref pas de swap... on reste dans les 512 Mo (je sais c'est un peu juste...)
La bande passante : réseau à 100Mbs
La machine ne semble pas répondre à un _ping_ et donc c'est que la
machine sature sur une ressource et non suite à un timeout créé par un
MySQL trop long à repondre. Il faut donc voir ce qui crée cette
saturation matérielle : une requête php/MySQL, une machine
sous-dimensionnée en RAM ou CPU ?
Machine: Serveyur Dell poweredge 1550 bi proc PIII / 512 Mo
Voilà les stats données par phpmyadmin:
Trafic | ø par heure
Reçu 186 514 Ko | 23 163 Ko
Envoyé 1 156 Mo | 147 045 Ko
Total 1 338 Mo | 170 208 Ko
Clairement ~14% des connexion échouent ;~{
Total | ø par heure | ø par minute | ø par seconde
1 259 190 | 156 377,95 | 2 606,30 | 43,44
pour un uptime-mysql de 0 jours, 8 heures, 3 minutes et 8 secondes
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une
recherche plus rapide ou quelques commandes indiquées par les autres
utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement
interne), mais AMHA il faut regarder la conso moyenne
(sous-dimensionnement de la machine) et ce qui provoque les saturations
(peut-être une site web qui a une BD très importante, ou qui héberge un
script PHP CPUphage).
En fait l'essentiel des sites tourne sous spip...
je peux aussi ajouter:
Max used connections : 10
key buffer size : 402653184
Key blocks used : 142392
Key read requests : 12248752
En espérant que ces renseignements permettront un début de diagnostic ?
@micalement,
--
Francois Sauterey
@: Francois_AT_Sauterey.org
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Mercredi 02 Novembre 2005 19:03, G(P)L a écrit :
Francois Sauterey a écrit : > J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici > un spécialiste ? > J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant > +/- 500 sites différents dont la moitié à peu près en php/mysql. > Une autre (sur un réseau interne en 100M) est le serveur Mysql. > Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement > les connexions. > (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus > par minute] > Je cherche à optimiser les (nombreux) paramètres de MysqlServer. > > Ci-joint, mon my.cnf... > > @micalement,
Bonsoir, Il faudrait voir pourquoi la base de données refuse les connexions, car si ce sont des sites webs "classiques", ca m'étonne que 500 tables
heu... 500 bases x 50 tables = 25000 tables au total...
mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la mémoire vive, des ressources processeurs, des accès disques, de la bande-passante, ...
uptime: 8:49:40 up 12 days, 3:27, 8 users, load average: 0.26, 0.32, 0.23 vmstat (après plusieur étapes effacées): procs -----------memory---------- ---swap-- -----io---- --system------cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 32424 13004 21420 223624 0 0 0 4 265 319 0 1 99 0 Bref pas de swap... on reste dans les 512 Mo (je sais c'est un peu juste...)
La bande passante : réseau à 100Mbs
La machine ne semble pas répondre à un _ping_ et donc c'est que la machine sature sur une ressource et non suite à un timeout créé par un MySQL trop long à repondre. Il faut donc voir ce qui crée cette saturation matérielle : une requête php/MySQL, une machine sous-dimensionnée en RAM ou CPU ?
Machine: Serveyur Dell poweredge 1550 bi proc PIII / 512 Mo
Voilà les stats données par phpmyadmin: Trafic | ø par heure Reçu 186 514 Ko | 23 163 Ko Envoyé 1 156 Mo | 147 045 Ko Total 1 338 Mo | 170 208 Ko
Clairement ~14% des connexion échouent ;~{ Total | ø par heure | ø par minute | ø par seconde 1 259 190 | 156 377,95 | 2 606,30 | 43,44
pour un uptime-mysql de 0 jours, 8 heures, 3 minutes et 8 secondes
Ensuite on peut voir l'optimisation de MySQL (index des tables pour une recherche plus rapide ou quelques commandes indiquées par les autres utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement interne), mais AMHA il faut regarder la conso moyenne (sous-dimensionnement de la machine) et ce qui provoque les saturations (peut-être une site web qui a une BD très importante, ou qui héberge un script PHP CPUphage).
En fait l'essentiel des sites tourne sous spip...
je peux aussi ajouter: Max used connections : 10 key buffer size : 402653184 Key blocks used : 142392 Key read requests : 12248752
En espérant que ces renseignements permettront un début de diagnostic ? @micalement, -- Francois Sauterey @: Francois_AT_Sauterey.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
jerome
Francois Sauterey a écrit :
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ? J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant +/- 500 sites différents dont la moitié à peu près en php/mysql. Une autre (sur un réseau interne en 100M) est le serveur Mysql. Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonjour,
Lit la doc MySQL concernant l'optimisation : http://dev.mysql.com/doc/mysql/en/MySQL_Optimization.html et principalement la section 7.5 concernant l'optimisation du serveur : http://dev.mysql.com/doc/mysql/en/Optimizing_the_Server.html
Il y a un ou deux autres paramètres sur lesquels tu _doit_ jouer :
* key_buffer : il doit être entre 25 et 50 % du total de ta mémoire physique. Le key_buffer correspond à ce que mysql va charger en mémoire comme clés. Autrement dit, à chaque fois qu'il exécute un select avec clé, si la clé est en mémoire, il ne fera pas d'accès disque, et donc ça sera plus rapide et la machine chargeras moins.
La règle est : Key_reads / Key_read_request < 0.01
Donc tu ajuste ton key_buffer jusqu'à ce que cette règle soit ok.
Pour cela :
mysql> show status like 'Key%'; +--------------------+-----------+ | Variable_name | Value | +--------------------+-----------+ | Key_blocks_used | 610645 | | Key_read_requests | 117513865 | | Key_reads | 479580 | | Key_write_requests | 4322422 | | Key_writes | 776691 | +--------------------+-----------+ 5 rows in set (0.00 sec)
et tu fait la division : 479580 / 117513865 = 0.0040810503509522
Ca c'est les chiffres pour un serveur mysql où la taille du key_buffer est égale à 768Mo sur un total de 2Go. (Au passage, 2Go est un minimum, 512 c'est vraimment pas beaucoup).
Si ton résultat est > 0.01, tu augmente la valeur dans /etc/mysql/my.cnf, tu relance mysql, tu attend quelques minutes que des valeurs significatives soient enregistrées, et tu refait le calcul.
* Tu supprime les logs mysql, ça bouffe un max d'i/o. Pour cela, supprimer (ou commenter) les variables log* dans my.cnf.
* tu augmente le table_cache.
Pour cela :
mysql> status; -------------- ... < bla bla bla > ...
Uptime: 2 days 9 hours 34 min 45 sec
Threads: 5 Questions: 14035029 Slow queries: 2 Opens: 165920 Flush tables: 1 Open tables: 4096 Queries per second avg: 67.709 --------------
Il s'agit du rapport entre "Open tables" et "Opens".
Il ne faut pas pas que "Opens" augmente trop rapidement après que la valeur de "Open tables" ai été atteinte. Donc à surveiller lors du démarrage du serveur.
Ce paramètre est à corréller avec le nombre max de fichier ouvrables sur le système.
Pour connaitre cette valeur :
[ fs]# cat /proc/sys/fs/file-max 32768
pour l'augmenter, le package procps doit être installé, ajouter cette ligne dans /etc/sysctl.conf :
fs/file-max = 32768
puis :
/etc/init.d/procps.sh reload
Sur un serveur dont je m'occupe, 4096 pour mysql semble être un peu petit, mais la machine n'est pas chargée pour autant, donc on laisse cette valeur, car une valeur trop élevée pourrait ralentir le système. Avec un "Queries per second avg: 67.709" on a un load de "load average: 0.54, 0.58, 0.46", ce qui est acceptable.
La commande suivante te donne le nombre de fichier ouverts par mysql sur le système : lsof | grep mysqld | awk {'print $9'} | sort -u | wc -l
les deux paramêtre suivants peuvent également être positionnés :
* concernant spip, il faut vérifier que les versions utilisées ne font pas de INSERT DELAYED (http://dev.mysql.com/doc/refman/5.0/en/insert-delayed.html). Si oui, prévient tes utilisateurs et passe un cat/grep/sed sur tous les fichiers pour remplacer le INSERT DELAYED par un INSERT. Ce problème est présent dans des versions de spip d'il y a un ou deux ans.
Hope this help...
jerome
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Francois Sauterey a écrit :
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un
spécialiste ?
J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant +/- 500
sites différents dont la moitié à peu près en php/mysql.
Une autre (sur un réseau interne en 100M) est le serveur Mysql.
Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les
connexions.
(un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par
minute]
Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonjour,
Lit la doc MySQL concernant l'optimisation :
http://dev.mysql.com/doc/mysql/en/MySQL_Optimization.html et
principalement la section 7.5 concernant l'optimisation du serveur :
http://dev.mysql.com/doc/mysql/en/Optimizing_the_Server.html
Il y a un ou deux autres paramètres sur lesquels tu _doit_ jouer :
* key_buffer : il doit être entre 25 et 50 % du total de ta mémoire
physique. Le key_buffer correspond à ce que mysql va charger en mémoire
comme clés. Autrement dit, à chaque fois qu'il exécute un select avec
clé, si la clé est en mémoire, il ne fera pas d'accès disque, et donc ça
sera plus rapide et la machine chargeras moins.
La règle est : Key_reads / Key_read_request < 0.01
Donc tu ajuste ton key_buffer jusqu'à ce que cette règle soit ok.
Pour cela :
mysql> show status like 'Key%';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| Key_blocks_used | 610645 |
| Key_read_requests | 117513865 |
| Key_reads | 479580 |
| Key_write_requests | 4322422 |
| Key_writes | 776691 |
+--------------------+-----------+
5 rows in set (0.00 sec)
et tu fait la division :
479580 / 117513865 = 0.0040810503509522
Ca c'est les chiffres pour un serveur mysql où la taille
du key_buffer est égale à 768Mo sur un total de 2Go. (Au passage, 2Go
est un minimum, 512 c'est vraimment pas beaucoup).
Si ton résultat est > 0.01, tu augmente la valeur dans
/etc/mysql/my.cnf, tu relance mysql, tu attend quelques minutes que des
valeurs significatives soient enregistrées, et tu refait le calcul.
* Tu supprime les logs mysql, ça bouffe un max d'i/o. Pour cela,
supprimer (ou commenter) les variables log* dans my.cnf.
* tu augmente le table_cache.
Pour cela :
mysql> status;
--------------
...
< bla bla bla >
...
Uptime: 2 days 9 hours 34 min 45 sec
Threads: 5 Questions: 14035029 Slow queries: 2 Opens: 165920 Flush
tables: 1 Open tables: 4096 Queries per second avg: 67.709
--------------
Il s'agit du rapport entre "Open tables" et "Opens".
Il ne faut pas pas que "Opens" augmente trop rapidement après que la
valeur de "Open tables" ai été atteinte. Donc à surveiller lors du
démarrage du serveur.
Ce paramètre est à corréller avec le nombre max de fichier ouvrables sur
le système.
Pour connaitre cette valeur :
[root@fey fs]# cat /proc/sys/fs/file-max
32768
pour l'augmenter, le package procps doit être installé, ajouter cette
ligne dans /etc/sysctl.conf :
fs/file-max = 32768
puis :
/etc/init.d/procps.sh reload
Sur un serveur dont je m'occupe, 4096 pour mysql semble être un peu
petit, mais la machine n'est pas chargée pour autant, donc on laisse
cette valeur, car une valeur trop élevée pourrait ralentir le système.
Avec un "Queries per second avg: 67.709" on a un load de "load average:
0.54, 0.58, 0.46", ce qui est acceptable.
La commande suivante te donne le nombre de fichier ouverts par mysql sur
le système :
lsof | grep mysqld | awk {'print $9'} | sort -u | wc -l
les deux paramêtre suivants peuvent également être positionnés :
* concernant spip, il faut vérifier que les versions utilisées ne font
pas de INSERT DELAYED
(http://dev.mysql.com/doc/refman/5.0/en/insert-delayed.html). Si oui,
prévient tes utilisateurs et passe un cat/grep/sed sur tous les fichiers
pour remplacer le INSERT DELAYED par un INSERT. Ce problème est présent
dans des versions de spip d'il y a un ou deux ans.
Hope this help...
jerome
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici un spécialiste ? J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant +/- 500 sites différents dont la moitié à peu près en php/mysql. Une autre (sur un réseau interne en 100M) est le serveur Mysql. Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement les connexions. (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus par minute] Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
Ci-joint, mon my.cnf...
@micalement,
Bonjour,
Lit la doc MySQL concernant l'optimisation : http://dev.mysql.com/doc/mysql/en/MySQL_Optimization.html et principalement la section 7.5 concernant l'optimisation du serveur : http://dev.mysql.com/doc/mysql/en/Optimizing_the_Server.html
Il y a un ou deux autres paramètres sur lesquels tu _doit_ jouer :
* key_buffer : il doit être entre 25 et 50 % du total de ta mémoire physique. Le key_buffer correspond à ce que mysql va charger en mémoire comme clés. Autrement dit, à chaque fois qu'il exécute un select avec clé, si la clé est en mémoire, il ne fera pas d'accès disque, et donc ça sera plus rapide et la machine chargeras moins.
La règle est : Key_reads / Key_read_request < 0.01
Donc tu ajuste ton key_buffer jusqu'à ce que cette règle soit ok.
Pour cela :
mysql> show status like 'Key%'; +--------------------+-----------+ | Variable_name | Value | +--------------------+-----------+ | Key_blocks_used | 610645 | | Key_read_requests | 117513865 | | Key_reads | 479580 | | Key_write_requests | 4322422 | | Key_writes | 776691 | +--------------------+-----------+ 5 rows in set (0.00 sec)
et tu fait la division : 479580 / 117513865 = 0.0040810503509522
Ca c'est les chiffres pour un serveur mysql où la taille du key_buffer est égale à 768Mo sur un total de 2Go. (Au passage, 2Go est un minimum, 512 c'est vraimment pas beaucoup).
Si ton résultat est > 0.01, tu augmente la valeur dans /etc/mysql/my.cnf, tu relance mysql, tu attend quelques minutes que des valeurs significatives soient enregistrées, et tu refait le calcul.
* Tu supprime les logs mysql, ça bouffe un max d'i/o. Pour cela, supprimer (ou commenter) les variables log* dans my.cnf.
* tu augmente le table_cache.
Pour cela :
mysql> status; -------------- ... < bla bla bla > ...
Uptime: 2 days 9 hours 34 min 45 sec
Threads: 5 Questions: 14035029 Slow queries: 2 Opens: 165920 Flush tables: 1 Open tables: 4096 Queries per second avg: 67.709 --------------
Il s'agit du rapport entre "Open tables" et "Opens".
Il ne faut pas pas que "Opens" augmente trop rapidement après que la valeur de "Open tables" ai été atteinte. Donc à surveiller lors du démarrage du serveur.
Ce paramètre est à corréller avec le nombre max de fichier ouvrables sur le système.
Pour connaitre cette valeur :
[ fs]# cat /proc/sys/fs/file-max 32768
pour l'augmenter, le package procps doit être installé, ajouter cette ligne dans /etc/sysctl.conf :
fs/file-max = 32768
puis :
/etc/init.d/procps.sh reload
Sur un serveur dont je m'occupe, 4096 pour mysql semble être un peu petit, mais la machine n'est pas chargée pour autant, donc on laisse cette valeur, car une valeur trop élevée pourrait ralentir le système. Avec un "Queries per second avg: 67.709" on a un load de "load average: 0.54, 0.58, 0.46", ce qui est acceptable.
La commande suivante te donne le nombre de fichier ouverts par mysql sur le système : lsof | grep mysqld | awk {'print $9'} | sort -u | wc -l
les deux paramêtre suivants peuvent également être positionnés :
* concernant spip, il faut vérifier que les versions utilisées ne font pas de INSERT DELAYED (http://dev.mysql.com/doc/refman/5.0/en/insert-delayed.html). Si oui, prévient tes utilisateurs et passe un cat/grep/sed sur tous les fichiers pour remplacer le INSERT DELAYED par un INSERT. Ce problème est présent dans des versions de spip d'il y a un ou deux ans.
Hope this help...
jerome
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
