Karlesnine.com

Aller au contenu Aller au menu Aller à la recherche

Tag - DC2

Fil des billets - Fil des commentaires

mardi, février 16 2010

MySQL Innodb nouvelle notes de configuration et d'optimisation

Par Charles-Christian Croix le mardi, février 16 2010, 10:23 - Technologic

Pour compléter une note précédente sur Innodb et UTF8 et le billet sur les premières notes de configuration et d'optimisation de MySQL Innodb voici quelques notes de configuration de MySQL supplémentaire et complémentaire avec le moteur de base de donnée Innodb. Note toujours valable _ pour toute solution d'hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

INNODB_BUFFER_POOL_SIZE

  • Espace mémoire de mise en cache des bases de données.
  • Ne pas hésiter à allouer 80 ~ 90% de la mémoire disponible sur le serveur si celui ci est dédier DB
  • Dans la mesure du possible doit être légèrement supérieur en taille à /var/lib/mysql

INNODB_FLUSH_METHOD

  • Instruction de gestion des accès disque
  • CODE_FS par défaut, laisse à l'OS toute possibilité de gérer les accès selon ces principes. L'OS peux donc utilisé son propre cache qui viendrais ce superposer à celui de innodb
  • O_DIRECT informe l'OS d'écrire sans délai sans tenir compte de son cache.
  • A rapprocher de l'instruction gérant le scheduler de l'OS cf: /sys/block/sda/queue/scheduler

QUERY-CACHE

  • Concerne les instructions query_cache_limit, query_cache_size, query_cache_type
  • A utilise seulement en cas de requêtes uniforme et répétitive, inutile si celle ci sont déporter sur un memcache
  • Effacer dans ce cache et y réécrire impose un MUTEX et donc un lock de tout les thread.
  • A utilisé seulement si le gain d'utilisation VS lock mutex est positif, rarement le cas sur une architecture qui utilise du memcache

SINGLE-TRANSACTION

  • mysqldump single-transaction all-databases > dump.sql
  • Instruction --single-transaction determine que le dump est a réaliser dans le contexte de l'instant T (snapshot style)
  • Ne génère pas de lock, lecture, écriture toujours possible
  • Génère une charge en lecture. Charge quasi nul sur tout le contenue de base dumper est en mémoire
  • Génère une charge en écriture. Penser à écrire sur une FileSystem non sollicité.

12 commentaires

mercredi, décembre 16 2009

MySQL Innodb notes de configuration et d'optimisation

Par Charles-Christian Croix le mercredi, décembre 16 2009, 14:07 - Technologic

Pour compléter une note précédente sur Innodb et UTF8 voici quelques notes de configuration de MySQL avec le moteur de base de donnée Innodb sous forme de checklist pour toute solution d'hébergement ou architecture MySQL est dédier eZ Publish, Dotclear 2 et autre CMS.

Utilisez le moteur Innodb

Forcer le moteur par defaut de stokage en InnoDB pour la création de toute nouvelle table sans spécification du moteur souhaité.

#
# Moteur par defaut de stokage, ici InnoDB parce que  Ez publish
#
default-storage-engine  = InnoDB

UTF8

Prévoir dès le départ l'encodage des base en UFT8

#
# Encodage UTF8
#
default-character-set=utf8
default-collation=utf8
collation_server=utf8_general_ci
character_set_server=utf8
skip-character-set-client-handshake

Configurer l'écoute sur toute les interfaces réseaux

Ouvrir à un utilisation via le réseau sans limitation d'interface ou d'adresse.

#
# Instead of skip-networking you can listen only on
# localhost which is more compatible and is not less secure.
bind-address            =
#skip-networking

Optimisation tablespace

Prévoir le lancement du moteur innodb avec comme configuration un fichier tablespace par table. Cela va créé un fichier tablespace pour chaque table innodb et vous évitera d'avoir dans quelque mois un unique fichier tablespace de plusieurs giga octet impossible à manipuler.

#skip-innodb
innodb_file_per_table

Optimisation Log

Bloquer les log binaire qui consomme beaucoup d'espace disque et n'apporte pas de sécurité sur une plate-forme qui n'a pas de réplication Master / Slave MySQL.

#log_bin                        = /var/log/mysql/mysql-bin.log

Optimisation innodb_buffer_pool_size

innodb_buffer_pool_size définie la taille de buffer mémoire que InnoDB utilise pour mettre en cache les données et les index de tables. Plus cette valeur est grand, et moins vous ferez d'accès disques. Sur un serveur dédiés, vous pouvez monter cette valeur jusqu'à 80% de la mémoire physique de la machine. Ne lui donnez pas une valeur trop grande, car cela peut engendrer l'utilisation de mémoire sur le disque par votre serveur (swap).

10 commentaires

jeudi, décembre 10 2009

Configurer le niveau de compression du Mode_deflate de Apache2 et utiliser les logs pour en connaitre l'efficacité

Par Charles-Christian Croix le jeudi, décembre 10 2009, 11:08 - Technologic

Pour compléter mon billet sur l'utilisation du mod_deflate pour un hébergement apache 2 de Dotclear2 et celui sur Optimisation d'un hébergement eZ Publish 4 pour l'utilisation des caches web ou je parle du mod_gzip de apache 1.3 je vous invite à consulter le billet use mod_deflate to compress web content delivered by apache sur g-loaded.eu. Cette recommandation est valable quelque soit le CMS ou application web du moment que votre solution de web hosting repose sur apache 2. Vous en apprendrez plus sur les points suivants :

Configurer le niveau de compression de mod_deflate

L'algorithme deflate est assez rapide et il est possible de modifier le niveau de compression. Le mettre au maximum ne pose pas de problème si vous vous contentez de compresser du texte (css, Js, xml etc) [1]

DeflateCompressionLevel 9

Surveiller la compression via les logs

Vous pouvez avoir une trace log de la compression effectué par le mod_deflate de votre serveur apache 2.[2]

Le directive suivant définissent quelque variable :

  • instream : La taille en Bytes (Octet) en entré de DEFLATE.
  • outstream : La taille en Bytes (Octet) en sortie de DEFLATE.
  • ratio : Le ratio de compression, (Sortie/Entré)x100
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

Les variables définie vous pouvez ajouter une Format de log à votre vhost:

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflatelog

N'oubliez par d'utiliser de format de log en l'écrivant dans un fichier de log.

CustomLog /path/to/vhost/logs/deflate_log deflatelog

Vous obtenez un log pour deflate qui ce présente comme cela. Pratique pour étudier l'utilité de la compression de donner en fonction du type de fichier dans votre architecture d'hébergement ou des efforts de Minification, toujours important en web hosting.

"GET /dotclear/themes/default/js/jquery.cookie.js HTTP/1.1" 451/994 (45%)

Notes

[1] Attention comprimer au maximum des fichiers trop gros ou déjà compressé comme les images est contre productif !!

[2] Attention écrire des logs sur le disque ralenti apache !!

2 commentaires

- page 1 de 2