web-dev-qa-db-fra.com

My.cnf pour MySQL 5.5 est-il approprié et bien réglé pour la spécification de matériel ci-dessous?

ma spécification matérielle 

Technology: Ivy Bridge
CPU: Intel Xeon E3 1245v2 
Intel Smart Cache: 8MB
Cores / Threads: 4 / 8
Frequency: 3.4GHz+ / 3.8GHz Turbo Boost
RAM: 32 GB DDR3
Hard disk: 2x 2TB SATA3
Raid 1 by software
Bandwidth: 100 Mbps guaranteed

OS [~ # ~] [~ # ~]

ubuntu 12.04.2 LTS 64 bits Server édition

mysql

version 5.5.29, 64 bits

Mon architecture d'application

https://stackoverflow.com/questions/11272776/Utilisation-phusion-passenger-nginx-Running-Same-Rails-app-with-multiples-Instance

Donc, mon serveur contient 100 Rails Applications avec 100 bases de données MySQL, chaque base de données ayant environ 100 tables

Mon trafic sur le serveur

10 à 200 (max) Demande par seconde

3000 à 10 000 (max) demande par jour

connectivité entre MySQL et les rails

J'utilise des sockets socket = /var/lib/mysql/data/mysql.sock

My.cnf généré par https://tools.percona.com/wizard pour la spécification matérielle ci-dessus

[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/lib/mysql/data/mysql.sock

[mysqld]

# GENERAL #
user                           = mysql
default_storage_engine         = InnoDB
socket                         = /var/lib/mysql/data/mysql.sock
pid_file                       = /var/lib/mysql/data/mysql.pid

# MyISAM #
key_buffer_size                = 32M
myisam_recover                 = FORCE,BACKUP

# SAFETY #
max_allowed_packet             = 16M
max_connect_errors             = 1000000
skip_name_resolve
innodb                         = FORCE
innodb_strict_mode             = 1

# DATA STORAGE #
datadir                        = /var/lib/mysql/data/

# BINARY LOGGING #
log_bin                        = /var/lib/mysql/data/mysql-bin
expire_logs_days               = 14
sync_binlog                    = 1

# CACHES AND LIMITS #
tmp_table_size                 = 32M
max_heap_table_size            = 32M
query_cache_type               = 0
query_cache_size               = 0
max_connections                = 500
thread_cache_size              = 50
open_files_limit               = 65535
table_definition_cache         = 4096
table_open_cache               = 10240

# INNODB #
innodb_flush_method            = O_DIRECT
innodb_log_files_in_group      = 2
innodb_log_file_size           = 512M
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table          = 1
innodb_buffer_pool_size        = 26G

# LOGGING #
log_error                      = /var/lib/mysql/data/mysql-error.log
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /var/lib/mysql/data/mysql-slow.log

J'ai vu ça innodb_buffer_pool_size = 26g , donc dans 32 gb RAM = 27 à 28 Go sera utilisé par MySQL , donc il n'y a que moins d'espace pour exécuter 100 Rails Apps, alors s'il vous plaît que quelqu'un va éditer et optimiser mon MySQL config my.cnf posté dans Pastebin , Pour obtenir suffisamment d'espace et de rapidité pour exécuter MySQL et Rails Application.

J'ai envisagé d'utiliser 100 bases de données reliant 100 Rails Application dans une seule machine, donc j'utilise des sockets MySQL pour la connectivité, que ce soit une amélioration des performances par rapport à la connexion à l'aide de MySQL avec des ports.

Mise à jour

Plus d'info sur l'application

Ma nécessité n'est pas une demande critique de la mission, il s'agit d'un système d'information d'étudiant pour les écoles. Sauvegarde MySQL à FTP distante programmée via Webmin à 2 fois par jour, j'ai donc prévu de mettre 100 écoles dans un seul serveur, donc 100 Rails applications + correspondant 100 mySQL Base de données

Actuellement, l'application ne fonctionne pas, maintenant je suis à la phase de configuration de la production, alors j'ai besoin de suggestions pour my.cnf Considérant une manipulation de ressources égale pour Rails= et mysql.

mysqlinnodbmysql-5.5database-tuningmy.cnf
4
Sam

Il y a quelques options que vous devrez envisager

Piscine Buffer InnoDB

La raison 26g a été choisie, c'est que vous avez 32 Go de RAM et 80% de celui-ci est de 25,6 G. Étant donné que vous avez mentionné que vous aurez 100 bases de données et 100 applications en faisant un serveur DB multi-entreprises, vous. vont devoir avoir l'innodub tampon piscine juste à droite.

Veuillez exécuter cette requête:

SELECT IFNULL(B.engine,'Total') "Storage Engine",
CONCAT(LPAD(REPLACE(FORMAT(B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size", CONCAT(LPAD(REPLACE(
FORMAT(B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size", CONCAT(LPAD(REPLACE(
FORMAT(B.TSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Table Size" FROM
(SELECT engine,SUM(data_length) DSize,SUM(index_length) ISize,
SUM(data_length+index_length) TSize FROM
information_schema.tables WHERE table_schema NOT IN
('mysql','information_schema','performance_schema') AND
engine IS NOT NULL GROUP BY engine WITH ROLLUP) B,
(SELECT 3 pw) A ORDER BY TSize;

Cela vous indiquera combien d'espace est actuellement occupé par votre instance MySQL. Quel que soit le total de la taille de la donnée et de la taille de l'index d'innoDB, c'est ce que vous utilisez. Si ce total est sur la limite de 80%, vous devez vous devez vous dire 80% (laissant - innodb_buffer_pool_size à 26G).

Puisque vous avez un serveur quadriculaire, définissez innodb_buffer_pool_instances à 4.

Fichiers journaux de transaction innodb

Depuis 26g a été sélectionné comme innodb_buffer_pool_size , vous aurez besoin des journaux de transaction les plus importants. La valeur 512m a probablement été cueillie pour innodb_log_file_size car il n'y a rien à suggérer la quantité de données de transaction (en octets) qui seront réellement traitées.

Pour redimensionner vos journaux de transaction

mysql -u... -p... -e"SET GLOBAL innodb_fast_shutdown = 0;"
service mysql stop

Suivant édition my.cnf, remplacer

innodb_log_file_size           = 512M

avec ça

innodb_log_file_size           = 2047M

Ensuite, remplacez les journaux de transaction comme celui-ci

mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
service mysql start

Après quelques mois d'activité de pointe, vous pouvez ensuite exécuter cette requête pendant un sommet:

SET @TimeInterval = 300;
SELECT variable_value INTO @num1 FROM information_schema.global_status
WHERE variable_name = 'Innodb_os_log_written';
SELECT SLEEP(@TimeInterval);
SELECT variable_value INTO @num2 FROM information_schema.global_status
WHERE variable_name = 'Innodb_os_log_written';
SET @ByteWrittenToLog = @num2 - @num1;
SET @KB_WL = @ByteWrittenToLog / POWER(1024,1) * 3600 / @TimeInterval;
SET @MB_WL = @ByteWrittenToLog / POWER(1024,2) * 3600 / @TimeInterval;
SET @GB_WL = @ByteWrittenToLog / POWER(1024,3) * 3600 / @TimeInterval;
SELECT @KB_WL,@MB_WL,@GB_WL;

Sur la base de ce qui revient, vous devez redimensionner à nouveau les journaux de transaction.

S'il vous plaît voir mes messages précédents pour ce faire:

Engagement multicœur

Lorsque le plug-in InnoDB a été introduit dans MySQL 5.1.38, il a défini le monde de MySQL en feu. Pourquoi? Parce que InnoDB était un seul fileté. Vous deviez installer le plugin pour avoir un nouveau paramètre permettant à INNODB d'utiliser plusieurs cœurs.

Plutôt que d'écrire quelque chose de long, veuillez lire mes postes antérieurs de modifier MySQL 5.5 pour avoir InnoDB Utilitze Plusieurs noyaux:

2
RolandoMySQLDBA
# BINARY LOGGING #
log_bin                        = /var/lib/mysql/data/mysql-bin
expire_logs_days               = 14
sync_binlog                    = 1

# LOGGING #
log_error                      = /var/lib/mysql/data/mysql-error.log
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /var/lib/mysql/data/mysql-slow.log

Vous ne voulez pas vos journaux dans votre répertoire de données. Cela montrera une base de données "mysql-bin" lorsque vous démarrez MySQL. Vous aurez probablement des erreurs inutiles dans le journal des erreurs au démarrage. Il est préférable de garder cela aussi propre que possible pour que vous puissiez faire attention lorsque quelque chose s'affiche là-bas.

Il s'agit de la Convention générale de mettre des journaux dans/var/log quand même. En outre, lorsque cela est possible, il est agréable d'avoir le système de fichiers de journalisation sur un ensemble de broches séparé que le répertoire de données. Bien que cela ne sonne pas comme si cela serait possible, il pourrait toujours y avoir des gains pour maintenir le répertoire de données et la journalisation sur différents systèmes de fichiers, même si toujours sur les mêmes disques sous-jacents.

Sachez que expire_logs_days purgera des journaux binaires, quelles que soient les esclaves météorologiques sont à jour. Certes Si vous avez une esclave cassée qui a été éteinte depuis plus de 14 jours, vous avez des problèmes plus importants. En général, vous voudrez conserver suffisamment de mémoire tampon de binlog afin que vous puissiez facilement faire tourner un nouvel esclave en fonction de votre calendrier de sauvegarde.

Vous pouvez envisager d'avoir un script d'archivage qui décharge les binlogs sur un serveur d'archives plus permanent et gère la purge.

1
atxdba