Torlax

Je n'y manquerais pas

Bonjour à tous ! Bon, j'ai une question que peut être certains d'entre vous se sont déjà posé... Il se trouve que je manipule depuis longtemps ESX, d'ailleurs toutes mes infra sont virtualisées... Comme chacun le sait, les avantages sont énormes à tous point de vue. Par contre cela fait un petit moment que je me pose une question, et mes multiples recherches dans le domaine ne m’ont apportés aucunes réponses valable... Plusieurs prestataire proposent des offre "Private Cloud" (comme OVH par exemple, mais aucuns ne propose ce type de service... d'ailleurs je trouve la définition du "Cloud" particulièrement nébuleuse...) bon, je sais qu'on peu partir sur du Load balancing, de la HA, etc... mais : Est-il possible de mutualiser les ressources de plusieurs hôtes (de manière privé) pour envoyer la "purée" que sur une seule VM ? Exemple : J'ai mon Vsphere Server avec 4 hôtes dedans qui disposent chacun d'un CPU de 2GHz, et de 2 Go de ram... Est ce qu'une des licence de type "vCloud" permet par exemple de créer un pool de ressources émanant de mes 4 hôtes et de créer une seule et unique VM, puis de lui allouer 4x2Ghz et 4x2 Go de ram ? Je sais qu'on peu faire des clusters sous Linux, mais bon... ça serais pas mal un truc du genre sous Vmware !

Bonjour a tous ! Stéphane, 32 ans, informaticien depuis plus de 10 ans (je sais, ca englobe beaucoup de choses, mais c'est parce que c'est réellement le cas pour ma part, en effet, nous touchons réellement a tout...) dans une boite privé. Nous bossons exclusivement pour des clients professionnels (hôpitaux, mairies, gros bahuts, cabinets avocats/comptables,archis). Je suis webmaster et web-designer a mes heures perdu, et en particulier pour l'un des plus gros site francophone de vidéos insolite :-) Voila voila, content de me joindre a vous ! :-)

Ouais, c'est chelou on dirais qu'il m'ignore toute la partie innodb le sagouin... Bah, je finirais bien par trouvé ou ça coince... Merci pour ton aide en tt cas encore une fois :-)

Non, je suis sur de moi pour le coup Voilà ma config brut de fonderie à l'instant même : [mysqld] port = 3306 socket = /var/run/mysqld/mysqld.sock bind-address = xxx.xxx.xxx.xxx skip-external-locking max_connections = 500 key_buffer_size = 10G max_allowed_packet = 1M table_open_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K read_rnd_buffer_size = 256K net_buffer_length = 2K thread_stack = 128K table_cache = 2048 query_cache_limit = 30M query_cache_size = 128M thread_cache_size = 20 max_heap_table_size = 128M #skip-networking server-id = 1 # Uncomment the following if you want to log updates #log-bin=mysql-bin log_error = /var/log/mysql/error.log log-slow-queries = /var/log/mysql/slowww.log long_query_time = 1 log-queries-not-using-indexes # binary logging format - mixed recommended #binlog_format=mixed # Causes updates to non-transactional engines using statement format to be # written directly to binary log. Before using this option make sure that # there are no dependencies between transactional and non-transactional # tables such as in the statement INSERT INTO t_myisam SELECT * FROM # t_innodb; otherwise, slaves may diverge from the master. #binlog_direct_non_transactional_updates=TRUE # Uncomment the following if you are using InnoDB tables # (using the "enable-named-pipe" option) will render mysqld useless! # #skip-networking server-id = 1 # Uncomment the following if you want to log updates #log-bin=mysql-bin log_error = /var/log/mysql/error.log log-slow-queries = /var/log/mysql/slowww.log long_query_time = 1 log-queries-not-using-indexes # binary logging format - mixed recommended #binlog_format=mixed # Causes updates to non-transactional engines using statement format to be # written directly to binary log. Before using this option make sure that # there are no dependencies between transactional and non-transactional # tables such as in the statement INSERT INTO t_myisam SELECT * FROM # t_innodb; otherwise, slaves may diverge from the master. #binlog_direct_non_transactional_updates=TRUE innodb_data_home_dir = /var/lib/mysql innodb_data_file_path = ibdata1:50M:autoextend innodb_log_group_home_dir = /var/lib/mysql innodb_buffer_pool_size = 20G innodb_additional_mem_pool_size = 32M innodb_file_per_table innodb_flush_method = O_DIRECT innodb_file_format = barracuda innodb_log_file_size = 256M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 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 [myisamchk] key_buffer_size = 8M sort_buffer_size = 8M [mysqlhotcopy] interactive-timeout On dirais qu'il prend les valeurs par défaut... Aurais-je fait une erreur de placement dans ma config ? J’apprécie bcp ton aide en tout cas !

Mon log de démarrage Innodb : 130401 21:03:19 mysqld_safe mysqld from pid file /var/lib/mysql/Srvxxxxxx.pid ended 130401 21:04:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 130401 21:04:45 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-que$ 130401 21:04:46 [Note] Plugin 'FEDERATED' is disabled. 130401 21:04:46 InnoDB: The InnoDB memory heap is disabled 130401 21:04:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins 130401 21:04:46 InnoDB: Compressed tables use zlib 1.2.3.4 130401 21:04:46 InnoDB: Using Linux native AIO 130401 21:04:46 InnoDB: Initializing buffer pool, size = 128.0M 130401 21:04:46 InnoDB: Completed initialization of buffer pool 130401 21:04:46 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 130401 21:04:46 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... 130401 21:04:46 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 130401 21:04:46 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 130401 21:04:46 InnoDB: Waiting for the background threads to start 130401 21:04:47 InnoDB: 5.5.30 started; log sequence number 2170520588 130401 21:04:47 [Note] Server hostname (bind-address): 'xxx.xxx.xxx.xxx'; port: 3306 130401 21:04:47 [Note] Server socket created on IP: 'xxx.xxx.xxx.xxx'. 130401 21:04:47 [Note] Event Scheduler: Loaded 0 events 130401 21:04:47 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.30-1~dotdeb.0-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)

Je vais continuer à fouiller... Je suis toujours à 500 en max_connections. Par contre, au quotidien je trouve que Mysql bouffe vraiment rien en CPU (htop de gauche, à droit c'est mon apache/php)... C'est normal ? :

Aucunes. Je n'est rien dans les logs a part le démarrage du moteur de base de données et l'initialisation des buffers. Et dans le slow.log j'ai les mêmes log de requêtes qui n'utilisent pas d'index que dans mon post plus haut. Tout a tres bien fonctionné jusqu'à 2000/2500 visiteurs puis plantage. Mysql était complètement planté, même pas possible de l'arrêter. Et côté Apache php, les requêtes se sont empilées et le load average c'est envollé, sans pour autant s'effondrer.

En 20 minutes buffer explosé oui je pense, et empilement de Task coté Apache/Php, j'ai tout repassé en Myisam pour temporiser... Quand ça pète, impossible d'arreter proprement Mysql, ça part direct en "Failed". Rien dans error.log... Screen de mon "planton" coté Google Analytics, hécatombe difficile de faire des test en prod :

Et voilà, migration faite : Tout tourne en ce moment même avec ça (grand merci Kioob, et très intéressant ton article) : innodb_data_home_dir = /var/lib/mysql innodb_data_file_path = ibdata1:10M:autoextend innodb_log_group_home_dir = /var/lib/mysql innodb_buffer_pool_size = 20G innodb_additional_mem_pool_size = 32M innodb_file_per_table innodb_flush_method = O_DIRECT innodb_file_format = barracuda innodb_log_file_size = 256M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 innodb_lock_wait_timeout = 50 On fait des tests de monté de charge là... voir comment ça se comporte... Edit : Bon... ça ne tiens pas... à 3000 connexions Mysql s'éffondre, j'insiste bien, c'est Mysql qui pète

innodb_log_file_size ne doit pas faire au moins 20% de la valeur du pool_size ? Ensuite, si je comprends bien, c'est le logfile0 et logfile1 que je déplace une fois mysql arrêté proprement ? Par contre, si je passe toutes mes tables (wordpress et IPB donc) en innodb c'est pas contre-productif si je perds mes index fulltext ? innodb_file_per_table et innodb_file_format = barracuda seront pris en compte sur les bases existantes ou j'ai des manips à faire ? Je vais faire un autre essai ce soir... En prenant soins de faire un full backup avant :-D

J'ai déjà essayé de le faire, en le configurant comme ceci : innodb_data_home_dir = /var/lib/mysql innodb_data_file_path = ibdata1:50M:autoextend innodb_log_group_home_dir = /var/lib/mysql innodb_buffer_pool_size = 20G innodb_additional_mem_pool_size = 32M innodb_log_file_size = 5G innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 Avec cette config, Mysql ne démarrais plus du tout... (fameux ".....Failed") J'ai alors essayé de réduire : "innodb_log_file_size = 5G" à 3G et "innodb_log_buffer_size = 8M" à 1M Là ça à démarré, et curieusement, ça n'était pas stable du tout (fracassage toutes les 5 minutes)... Mais en effet je n'avais plus aucuns lock de table

Bon, je viens aux nouvelles Il se trouve que je n'ai aucunes requêtes qui prennent plus d'une seconde à s’exécuter Par contre, j'ai pas mal de requêtes qui n'utilisent pas (ou mal) les index, petit exemple : # Time: 130330 19:15:14 # User@Host: X[X] @ [xxx.xxx.xxx.xxx] # Query_time: 0.000218 Lock_time: 0.000016 Rows_sent: 0 Rows_examined: 1 SET timestamp=1364667314; DELETE FROM ipb_sessions WHERE ip_address='xxx.xxx.xxx.xxx' OR id='google=xx3xxcxxxxbb60xx8xx6xx2x6c82xxx_session'; # Time: 130330 19:15:39 # User@Host: X[X] @ [xxx.xxx.xxx.xxx] # Query_time: 0.000534 Lock_time: 0.000033 Rows_sent: 28 Rows_examined: 56 SET timestamp=1364667339; SELECT f.*,p.* FROM ipb_forums f LEFT JOIN ipb_permission_index p ON ( p.perm_type='forum' AND p.app='forums' AND p.per$ # User@Host: X[X] @ [xxx.xxx.xxx.xxx] # Query_time: 0.000185 Lock_time: 0.000033 Rows_sent: 19 Rows_examined: 63 SET timestamp=1364667339; SELECT s.id, s.member_id, s.member_name, s.seo_name, s.login_type, s.running_time, s.member_group, s.uagent_type,pp.cns_$ # Time: 130330 19:15:57 # User@Host: X[X] @ [xxx.xxx.xxx.xxx] # Query_time: 0.000172 Lock_time: 0.000017 Rows_sent: 0 Rows_examined: 1 SET timestamp=1364667357; DELETE FROM ipb_sessions WHERE ip_address='xxx.xxx.xxx.xxx' OR id='google=xx3xxcxxxxbb60xx8xx6xx2x6c82xxx_session'; Edit : ./tuning-primer.sh me dit que j'ai 8590 requête qui ont mis plus d'une seconde à s’exécuter, par contre je ne les voient pas dans mon "slow.log"... SLOW QUERIES The slow query log is enabled. Current long_query_time = 1.000000 sec. You have 8590 out of 7684513 that take longer than 1.000000 sec. to complete Your long_query_time seems to be fine

Merci beaucoup pour vos réponses, je vais essayer de faire ca a coup d'explain

Merci pour vos réponses :-) N'y connaissant que le strict minimum a la structure que peut avoir une base SQL, la méthode pour trouver ou se trouve les jointures me semble vachement nébuleuse... En fait c'est pas de faire qui me gêne, loin de là, en ce moment je passe des nuits complète à optimiser... C'est plutôt de ne pas connaitre comment est structuré réellement une base, ça m'handicape dans mon élan...