[Résolu] Munin : décryptage des graphes présentés

kAzz · Le 21/02/2010, à 23:02

Tu peux faire un copier/coller de ce que ça te sort ?

Mornagest · Le 21/02/2010, à 23:02

Idem,
sh tuning-primer.sh | more

tuning-primer.sh: line 845: bc: command not found
tuning-primer.sh: line 846: bc: command not found
tuning-primer.sh: line 847: [: -gt: unary operator expected
tuning-primer.sh: line 854: [: -le: unary operator expected
tuning-primer.sh: line 858: [: -ge: unary operator expected
tuning-primer.sh: line 440: bc: command not found
etc....

O_O

kAzz · Le 21/02/2010, à 23:10

Very strange... le script doit être altéré, pas normal ces messages. Dans un terminal, peux-tu aller dans le répertoire ou tu as installé le script, et taper ces commandes :

rm tuning-primer.sh
wget http://www.day32.com/MySQL/tuning-primer.sh
chmod +x tuning-primer.sh
sh tuning-primer.sh | more

et coller le résultat ?

Mornagest · Le 21/02/2010, à 23:23

Un pote (ArkSeth pour ne pas le nommer) m'a suggéré d'installer xterm et de le lancer avec la scrollbar (xterm -sb) et je peux ainsi remonter très haut, suffisamment pour voir tout le résultat je copie le tout (sauf les détails visitez tel site sur mysql)

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 5 out of 5410791 that take longer than 10 sec. to complete
tuning-primer.sh: line 403: bc: command not found
tuning-primer.sh: line 606: [: -gt: unary operator expected
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
Binlog sync is not enabled, you could loose binlog records during a server crash

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 6
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 2
Historic max_used_connections = 26
The number of used connections is 26% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
tuning-primer.sh: line 440: bc: command not found
Current InnoDB index space =  M
tuning-primer.sh: line 440: bc: command not found
Current InnoDB data space =  M
Current InnoDB buffer pool free = 0 %
tuning-primer.sh: line 440: bc: command not found
Current innodb_buffer_pool_size =  M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
tuning-primer.sh: line 1321: bc: command not found
tuning-primer.sh: line 1322: bc: command not found
tuning-primer.sh: line 1346: bc: command not found
tuning-primer.sh: line 1349: bc: command not found
tuning-primer.sh: line 1350: bc: command not found
tuning-primer.sh: line 1352: bc: command not found
tuning-primer.sh: line 1354: [: -gt: unary operator expected
tuning-primer.sh: line 459: [: max_memoryHR: integer expression expected
tuning-primer.sh: line 465: [: max_memoryHR: integer expression expected
tuning-primer.sh: line 471: [: max_memoryHR: integer expression expected
tuning-primer.sh: line 478: export: `=max_memoryHR': not a valid identifier
Max Memory Ever Allocated :  bytes
tuning-primer.sh: line 459: [: per_thread_buffersHR: integer expression expected
tuning-primer.sh: line 465: [: per_thread_buffersHR: integer expression expected
tuning-primer.sh: line 471: [: per_thread_buffersHR: integer expression expected
tuning-primer.sh: line 478: export: `=per_thread_buffersHR': not a valid identifier
Configured Max Per-thread Buffers :  bytes
tuning-primer.sh: line 459: [: total_memoryHR: integer expression expected
tuning-primer.sh: line 465: [: total_memoryHR: integer expression expected
tuning-primer.sh: line 471: [: total_memoryHR: integer expression expected
tuning-primer.sh: line 478: export: `=total_memoryHR': not a valid identifier
Configured Max Memory Limit :  bytes
tuning-primer.sh: line 440: bc: command not found
Physical Memory :  G
Max memory limit seem to be within acceptable norms

KEY BUFFER
tuning-primer.sh: line 754: bc: command not found
tuning-primer.sh: line 755: bc: command not found
tuning-primer.sh: line 440: bc: command not found
Current MyISAM index space =  M
tuning-primer.sh: line 440: bc: command not found
Current key_buffer_size =  M
Key cache miss rate is 1 : 566
Key buffer free ratio =  %
tuning-primer.sh: line 792: [: -le: unary operator expected
tuning-primer.sh: line 796: [: -le: unary operator expected
Your key_buffer_size seems to be fine

QUERY CACHE
tuning-primer.sh: line 827: bc: command not found
tuning-primer.sh: line 828: bc: command not found
Query cache is enabled
tuning-primer.sh: line 440: bc: command not found
Current query_cache_size =  M
tuning-primer.sh: line 440: bc: command not found
Current query_cache_used =  M
tuning-primer.sh: line 440: bc: command not found
Current query_cache_limit =  M
Current Query cache Memory fill ratio =  %
tuning-primer.sh: line 440: bc: command not found
Current query_cache_min_res_unit =  K
tuning-primer.sh: line 845: bc: command not found
tuning-primer.sh: line 846: bc: command not found
tuning-primer.sh: line 847: [: -gt: unary operator expected
tuning-primer.sh: line 854: [: -le: unary operator expected
tuning-primer.sh: line 858: [: -ge: unary operator expected
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
tuning-primer.sh: line 440: bc: command not found
Current sort_buffer_size =  K
tuning-primer.sh: line 440: bc: command not found
Current read_rnd_buffer_size =  K
Sort buffer seems to be fine

JOINS
tuning-primer.sh: line 440: bc: command not found
Current join_buffer_size =  K
You have had 217 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

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 = 128 tables
You have a total of 595 tables
You have 128 open tables.
Current table_cache hit rate is 0%
, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
tuning-primer.sh: line 440: bc: command not found
Current max_heap_table_size =  M
tuning-primer.sh: line 440: bc: command not found
Current tmp_table_size =  M
Of 39185 temp tables, 27% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your 
ratio of on disk temp tables.

TABLE SCANS
tuning-primer.sh: line 440: bc: command not found
Current read_buffer_size =  K
Current table scan ratio = 2274 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 127
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'.

Toujours ce problème de commande bc non installée... bizarre.

kAzz · Le 21/02/2010, à 23:28

Tu l'as rechargé avec wget le script ? bc non installé ça parait énorme... ça donne quoi si tu tapes which bc ?

Mornagest · Le 21/02/2010, à 23:34

Eh beeen... rien bc n'est pas installé. C'est juste dingue. Et con de ma part, j'aurais dû commencer par là... je l'installe et je relance le bousin (mais les résultats seront les mêmes ).

Mornagest · Le 21/02/2010, à 23:38

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

MySQL Version 5.0.32-Debian_7etch4-log i486

Uptime = 3 days 10 hrs 17 min 23 sec
Avg. qps = 18
Total Questions = 5443632
Threads Connected = 2

Server has been running for over 48hrs.
It should be safe to follow 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 NOT enabled.
Current long_query_time = 10 sec.
You have 5 out of 5443662 that take longer than 10 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
Binlog sync is not enabled, you could loose binlog records during a server crash

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 6
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 2
Historic max_used_connections = 26
The number of used connections is 26% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 3 M
Current InnoDB data space = 19 M
Current InnoDB buffer pool free = 0 %
Current innodb_buffer_pool_size = 8 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 81 M
Configured Max Per-thread Buffers : 152 M
Configured Max Global Buffers : 42 M
Configured Max Memory Limit : 194 M
Physical Memory : 1.00 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 209 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 560
Key buffer free ratio = 88 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 16 M
Current query_cache_used = 15 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 94.74 %
Current query_cache_min_res_unit = 4 K
However, 198148 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size

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

JOINS
Current join_buffer_size = 132.00 K
You have had 217 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

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 = 128 tables
You have a total of 595 tables
You have 128 open tables.
Current table_cache hit rate is 0%
, 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 39586 temp tables, 27% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your 
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 508 K
Current table scan ratio = 2279 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 127
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'.

kAzz · Le 21/02/2010, à 23:50

Good

Bon rien qui choque, tu peux améliorer quelques trucs mais rien de bloquant. Juste cette ligne qui parait suspecte : You have 5 out of 5443662 that take longer than 10 sec. to complete, + de 10s c'est énorme pour une requête sql.

Tu peux localiser la ou les coupable(s) dans /var/log/mysql/mysql-slow.log, après avoir ajouté (ou décommenté) dans my.cnf :

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 4

Redémarrer ensuite mysql par /etc/init.d/mysql restart, et relever le log après un plantage, des fois que...

Yann · Le 21/02/2010, à 23:55

Mornagest, tu pourrais me montrer un cat /proc/cpuinfo ?

Mornagest · Le 22/02/2010, à 00:01

@ kAzz : uniquement en cas de plantage ? parce qu'un redémarrage de mysql ça va faire planter le forum

Je ne sais pas quand il interviendra, cela dit...

/proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 4
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 5
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 6
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1600.059
cache size      : 4096 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 tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 x$
bogomips        : 3061.35

kAzz · Le 22/02/2010, à 00:14

@ kAzz : uniquement en cas de plantage ? parce qu'un redémarrage de mysql ça va faire planter le forum

Linux n'est pas <biiiiiiip>, ils ne s'en apercevront même pas les gens du forum et tu pourras consulter les logs quand tu voudras of course, mais ça pourra être particulièrement révélateur après un plantage.

Dernière modification par kAzz (Le 22/02/2010, à 00:14)

Mornagest · Le 22/02/2010, à 00:18

OK.

Bon, il est temps d'aller au lit, boulot demain... je vous tiens au courant en cas de nouveau plantage... ou d'une réponse de l'hébergeur

Merci pour votre patience !

kAzz · Le 22/02/2010, à 00:20

Bonne nuit @++, pareil pour moi

Yann · Le 22/02/2010, à 00:24

Ptet un pb de la carte reseau, du driver de la carte reseau, ou du reseau lui meme. Je demanderais a un gars de tenter de se connecter par serial (ou ptet que t as une connexion serial via ton panel admin) la prochaine fois que ca plante, pour voir si ca peut venir de la. Rien dans les logs et rien dans les graphs, ptet que le serveur etait pas planté

Mornagest · Le 22/02/2010, à 10:43

C'est possible que ce soit un problème matériel, en effet, et là on est obligé d'attendre qu'ils fassent une analyse plus poussée de leur côté...

En tout cas, merci pour votre coup de main, je vais essayer de les recontacter pour voir ce qu'ils peuvent faire ^^

Mornagest · Le 22/02/2010, à 14:11

Réponse :

Les graphs munin montrent très très clairement une augmentation juste avant le crash, en simultanée, du nombre de connexions actives, du nombre de processus
mysql, et de la consommation mémoire / utilisation du swap.
Il semble donc que dans certains condition, le serveur n'ai pas assez de mémoire, saturant son swap, ce qui le fait planter.
Il reste a determiner pourquoi cette augmentation subite, qui est probablement
lié a forte activité sur le site (il faudrait voir les logs apache pour cela).
Je vous invite donc a enquete en ce sens.

J'ai bien vu un ou deux pics mais c'était le 16 ou le 17 or le crash a eu lieu le 18 à midi vous en pensez quoi ?

Yann · Le 22/02/2010, à 14:22

Mornagest: T'es sur qu'on regarde les memes graphs? J'ai bcp de respect pour sivit, mais la je pense qu'ils regardent pas aux memes graphs que moi

Ils ont ptet les graphs du apache sous les yeux. Oui il y a un souci le 16, mais ca explique pas le crash du 18

Bon sinon oue, 1gbit de ram pour un serveur sql, c est assez ridicule, surtout avec un octocore qui sert a rien... Je savais pas que ca se faisait encore des servs avec juste 1go de ram... mais bon, plus de ram, ca t aideras un peu, mais il crashera qd meme si il est pas configuré proprement.

Tu devrais jouer sur le max_clients afin de limiter le nombre de clients simultanés. Un gros jump dans le nombre de connexion peut souvent venir d une requete SQL qui locke les tables trop longtemps, du coup les connexions sql s amassent et attendent que la grosse requete ait fini, souvent en bouffant toute la ram.

Active le log pour les slow_queries (je te laisse googler), ca te donnera une indication sur les grosses requetes..

Yann · Le 22/02/2010, à 14:23

PS: note que si c etait vraiment un probleme de swap, t'aurais tout plein de messages de oom_kill dans tes logs. (un demon qui butte les process gourmands quand l espace ram dispo devient critique)

Mornagest · Le 22/02/2010, à 15:12

Dans /var/log/apache/error.log

[Sun Feb 21 07:27:36 2010] [notice] child pid 11382 exit signal Segmentation fault (11)

décliné toutes les minutes voire plus parfois.

Dans /var/log/syslog, des erreurs de connexions UDP à tout-va mais j'ignore si c'est inquiétant ou pas.

Je regarde pour les slow_queries et je vais demander s'ils ont d'autres graphes (mais j'en doute, ceux-là on y arrive via l'interface admin SIVIT...).

Edit : kAzz avait donné l'astuce un peu plus haut pour les slow_queries c'est fait et MySQL redémarré.

Dernière modification par Mornagest (Le 22/02/2010, à 15:16)

kAzz · Le 22/02/2010, à 21:24

Re !

Pour avoir les graphes Apache dans munin, faut installer les plugins, et redémarrer munin-node :

ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins
/etc/init.d/munin-node restart

Ca risque d'être intéressant

Mornagest · Le 22/02/2010, à 21:32

Merci ! J'ai redémarré Munin mais pour l'instant les graphes sont vides... faudra attendre le prochain plantage

Mornagest · Le 25/02/2010, à 23:23

Nouveau plantage le 25/02/2010 à 21h30, mise à jour des graphes Munin... malheureusement ceux d'Apache ne s'affichent pas http://www.baldursgateworld.fr/images/Munin.html

Et les logs : *retirés pour sécurité*
Merci d'avance ! S'il manque quelque chose...

Dernière modification par Mornagest (Le 26/02/2010, à 14:01)

Yann · Le 25/02/2010, à 23:34

RAS au niveau des graphs, si ce n est que tes graphs mysql deconnent
Tu peux faire un mysqldumpslow ? ca aide lire le slow log.

PS: Attention, mysqlslow log et syslog peuvent (et contiennent) des donnes sensibles, tels que de sidentifiants de session et des adresses IP.

Yann · Le 25/02/2010, à 23:39

Euh a part ca, j'avais raison

C'est pas un serveur dédié: Linux version 2.6.16.33-xenU (root@vds-master27.sivit.org) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #11 SMP Wed Oct 17 12:49:02 CEST 2007

VDS ca veut dire "Virtual dedicated server" - c'est une VM, du XEN. Ca se voyait un peu aux logs. Je penche fortement pour un probleme avec le reseau au niveau de XEN.

PS: On dirait que ta VM a rebooté plusieurs fois. Ils ont très bonne réputation sivit pourtant.

Dernière modification par Yann (Le 25/02/2010, à 23:43)

Mornagest · Le 26/02/2010, à 14:03

J'ai dû rebooter trois fois avant que le serveur ne se relance correctement ; les deux premiers essais ont échoué.

Je retire les liens dès maintenant... j'ai remarqué qu'il y avait des données, mais vu le nombre d'infos je n'ai pas eu le temps de les crypter...

Je suis désolé pour la confusion, j'ai toujours pensé qu'on avait un serveur mutualisé... il faut dire que ce n'était pas moi qui m'étais occupé de la location concrètement, qu'est-ce que je peux faire ?

Aussi, on m'avait expliqué qu'on ne pouvait pas mettre à jour la Lenny installée ; est-ce vrai ?

Encore merci !

Edit : le mysqlslowdump

Dernière modification par Mornagest (Le 26/02/2010, à 14:15)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 21/02/2010, à 23:02

Re : [Résolu] Munin : décryptage des graphes présentés

#27 Le 21/02/2010, à 23:02

Re : [Résolu] Munin : décryptage des graphes présentés

#28 Le 21/02/2010, à 23:10

Re : [Résolu] Munin : décryptage des graphes présentés

#29 Le 21/02/2010, à 23:23

Re : [Résolu] Munin : décryptage des graphes présentés

#30 Le 21/02/2010, à 23:28

Re : [Résolu] Munin : décryptage des graphes présentés

#31 Le 21/02/2010, à 23:34

Re : [Résolu] Munin : décryptage des graphes présentés

#32 Le 21/02/2010, à 23:38

Re : [Résolu] Munin : décryptage des graphes présentés

#33 Le 21/02/2010, à 23:50

Re : [Résolu] Munin : décryptage des graphes présentés

#34 Le 21/02/2010, à 23:55

Re : [Résolu] Munin : décryptage des graphes présentés

#35 Le 22/02/2010, à 00:01

Re : [Résolu] Munin : décryptage des graphes présentés

#36 Le 22/02/2010, à 00:14

Re : [Résolu] Munin : décryptage des graphes présentés

#37 Le 22/02/2010, à 00:18

Re : [Résolu] Munin : décryptage des graphes présentés

#38 Le 22/02/2010, à 00:20

Re : [Résolu] Munin : décryptage des graphes présentés

#39 Le 22/02/2010, à 00:24

Re : [Résolu] Munin : décryptage des graphes présentés

#40 Le 22/02/2010, à 10:43

Re : [Résolu] Munin : décryptage des graphes présentés

#41 Le 22/02/2010, à 14:11

Re : [Résolu] Munin : décryptage des graphes présentés

#42 Le 22/02/2010, à 14:22

Re : [Résolu] Munin : décryptage des graphes présentés

#43 Le 22/02/2010, à 14:23

Re : [Résolu] Munin : décryptage des graphes présentés

#44 Le 22/02/2010, à 15:12

Re : [Résolu] Munin : décryptage des graphes présentés

#45 Le 22/02/2010, à 21:24

Re : [Résolu] Munin : décryptage des graphes présentés

#46 Le 22/02/2010, à 21:32

Re : [Résolu] Munin : décryptage des graphes présentés

#47 Le 25/02/2010, à 23:23

Re : [Résolu] Munin : décryptage des graphes présentés

#48 Le 25/02/2010, à 23:34

Re : [Résolu] Munin : décryptage des graphes présentés

#49 Le 25/02/2010, à 23:39

Re : [Résolu] Munin : décryptage des graphes présentés

#50 Le 26/02/2010, à 14:03

Re : [Résolu] Munin : décryptage des graphes présentés

Pied de page des forums