OVH Community, votre nouvel espace communautaire.

SP64 2016: load average jamais sous 1.0


zoupla
22/10/2015, 12h11
Felix : https://forum.ovh.com/showthread.php...-Linux-3-14-32

le mprobleme est chez supermicro

stormyboy
29/09/2015, 22h03
ah ben fallait le dire............... bon en tt cas faudrait qu'ils soient un peu + vigilants sur la compatibilité matérielle... Cette histoire m'a fait perdre 2 semaines

bbr18
29/09/2015, 15h29
Citation Envoyé par stormyboy
FelixK tu peux postuler chez ovh
ça fait bien longtemps que Felix fait partie d'ovh

stormyboy
29/09/2015, 15h15
tu as essayé de mettre @reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe01 dans la crontab?
Ou tu peux créer un script contenant:
Code:
#!/bin/sh
### BEGIN INIT INFO
# Provides:          disable_gpe
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Demarrage du script lors de la sequence de boot
# Description:       Faire tomber le load average a sa valeur normale a vide
### END INIT INFO

echo disable > /sys/firmware/acpi/interrupts/gpe01

# pour verifier processus en statut D:
# ps -e -o state,pid,cmd | grep ^D
# pour verifier gpe responsable du load average:
# grep -ve "\s\+0\s\+" /sys/firmware/acpi/interrupts/gpe[0-9]
tu le rends executable: chmod +x script

cp script /etc/init.d/
update-rc.d script defaults
reboot
et tu vois si le load a diminué

Pour moi le problème semble réglé, je vais faire part de tout ca au support...
FelixK tu peux postuler chez ovh

Pastranquille
28/09/2015, 20h16
Citation Envoyé par FelixK
Bonjour,

peux-tu me donner le résultat de la commande suivante?
Code:
 grep -ve "\s\+0\s\+" /sys/firmware/acpi/interrupts/gpe[0-9]*
idem (??????) pour moi......

/sys/firmware/acpi/interrupts/gpe01: 189645 enabled
/sys/firmware/acpi/interrupts/gpe24: 3 enabled

stormyboy
28/09/2015, 20h02
l'ajout de cette ligne dans crontab permet de faire tomber le load average à quasi 0 et il n'y a plus de processus en statut D, on avance...
@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe01

FelixK
28/09/2015, 18h39
OK, donc:
Code:
 echo disabled > /sys/firmware/acpi/interrupts/gpe01
Je suis encore a la recherche du bout de code dans le kernel qu'il faut fixer pour fixer ça de manière propre et durable - en attendant ce workaround (a éxécuter après chaque reboot) doit aider.

Félix

stormyboy
28/09/2015, 18h25
voici le résultat:
/sys/firmware/acpi/interrupts/gpe01: 49535 enabled
/sys/firmware/acpi/interrupts/gpe24: 3 enabled

FelixK
28/09/2015, 17h53
Bonjour,

peux-tu me donner le résultat de la commande suivante?
Code:
 grep -ve "\s\+0\s\+" /sys/firmware/acpi/interrupts/gpe[0-9]*

Kioob
27/09/2015, 22h37
Ce que je veux dire c'est que le load average est indiqueur mesurant le nombre de process à un certain état. Or, il arrive que certains processus restent à tort à l'état D, mais ça ne veut absolument pas dire qu'ils consomment des ressources.
J'ai par exemple souvent eu le cas avec le démon de synchronisation KeepAlived, qui restait (à l'époque ?) volontairement dans cet état.

Bref, ça fait moche sur le monitoring, et selon les cas ça peut être révélateur d'un autre problème, mais en soit ce n'est pas bien méchant.

Si tu veux vraiment essayer de régler ça, regarde du côté de l'outil perf : http://askubuntu.com/a/422151

stormyboy
27/09/2015, 22h24
Pour mon cas j'ai bien un processus qui reste en statut D (voir ci dessus), mais c'est un problème que je ne peux accepter. Sur mes serveurs, de gros calculs sont effectués et je ne peux pas me permettre d'avoir une partie des ressources bouffée par quelque chose qui n'a rien à faire là, surtout que sur les autres machines il n'y a rien d'anormal
Pour Pastranquille je te conseille de tester ton serveur suspect en mode rescue pro (voir manager) et si tu as tjrs du load anormal tu peux contacter le support.
Pour moi c'est le constat du load trop élevé en rescue qui les a fait se bouger, surtout que le serveur a été changé en intégralité avec toujours le même problème.

Kioob
26/09/2015, 22h40
Hello,

Semblerait qu'un processus reste à l'État bloqué en permanence. C'est pas forcément un problème.
À tout hasard, que donne un :
Code:
ps auxw | grep D

Pastranquille
25/09/2015, 23h08
Salut,

On confirme que le problème existe sur d'autres machines:

1) serveur de secours ( il tourne sans clientèle - pas en prod ) - Serveur Enterprise SP-64 - 64G E5-1630v3 SoftRaid 2x2 To CENTOS 6.7 x86_64 standard – Carte Mère X10SRi-F - Load Averages: 1.10 1.04 1.05 la nuit GRA 1

2) serveur principal -infrastructure (en prod)- Serveur Infrastructure EG - 64G E5-1650v2 -2 x 480 Go SSD Load Averages: 0.08 0.06 0.05 la nuit RB5

Qu'est-ce que OVH prévoit de faire?

stormyboy
25/09/2015, 21h41
Bonjour,
Des nouvelles, après plusieurs contacts au telephone avec le support, le serveur a été remplacé totalement et le bug persiste. Il est quasi certain que le load average à 1.00 minimum soit lié à un problème entre le matériel et le software (divers noyaux testés), la cause précise reste inconnue.
Je suis à ce jour le 1er à leur faire remonter ce bug mais ils confirment qu'il pourrait être présent sur d'autres machines.
L'affaire a été transférée à un responsable et au service R&D pour voir s'il peuvent apporter un patch ou s'il faut changer un composant sur cette config.

stormyboy
24/09/2015, 11h41
Bonjour,
Je reposte, mon msg d'hier est passé à la trappe...
Alors après recherches c'est l'inconnue la plus totale: rien d'anormal dans les log si ce n'est un air flow T° qui est monté à 80°C...
J'ai réinstallé le serveur, mis à jour le kernel ovh, passé sur le kernel non ovh: dans tous les cas j'ai un load average toujours supérieur ou = à 1.00.
J'ai passé le serveur en rescue pro et fait les tests hardware: RAS. Et meme en rescue je me prends un load average de 1.00. J'ai fait un rescue sur une autre machine et le load average tombe à quasi 0.
La commande ps -e -o state,pid,cmd | grep ^D me retourne toujours ceci: D 4 [kworker/0:0]
Je soupçonne fortement que ce soit lié à mon problème mais je ne sais pas d'où ca vient, mes compétences s'arrêtent là.
J'ai trouvé un bug similaire ici http://ubuntuforums.org/showthread.php?t=2260699 c'était lié au matos semble t'il mais la cause est différente de mon cas.
J'ai contacté le support qui m'a répondu de faire les tests en rescue et qu'en gros je dois leur dire ce qui déconne sinon c'est pas un pb de matos, franchement c'est très moyen.......

stormyboy
23/09/2015, 14h44
Voici + d'infos. J'ai désactivé tout ce qui concerne le site qui tourne sur ce serveur. Le load descend à 1.00 et jamais en dessous

cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sda1[0] sdc1[2] sdb1[1]
5118912 blocks [3/3] [UUU]

md2 : active raid1 sda2[0] sdc2[2] sdb2[1]
2046912 blocks [3/3] [UUU]

md4 : active raid1 sda4[0] sdc4[2] sdb4[1]
285339584 blocks [3/3] [UUU]
unused devices:

ps -faux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 0.0 0.0 0 0 ? S sept.18 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S sept.18 0:27 \_ [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/0:0H]
root 7 0.0 0.0 0 0 ? S sept.18 3:32 \_ [rcu_sched]
root 8 0.0 0.0 0 0 ? S sept.18 0:00 \_ [rcu_bh]
root 9 0.0 0.0 0 0 ? S sept.18 0:00 \_ [migration/0]
root 10 0.0 0.0 0 0 ? S sept.18 0:00 \_ [migration/1]
root 11 0.0 0.0 0 0 ? S sept.18 0:27 \_ [ksoftirqd/1]
root 13 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/1:0H]
root 14 0.0 0.0 0 0 ? S sept.18 0:00 \_ [migration/2]
root 15 0.0 0.0 0 0 ? S sept.18 0:29 \_ [ksoftirqd/2]
root 17 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/2:0H]
root 18 0.0 0.0 0 0 ? S sept.18 0:00 \_ [migration/3]
root 19 0.0 0.0 0 0 ? S sept.18 0:29 \_ [ksoftirqd/3]
root 21 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/3:0H]
root 22 0.0 0.0 0 0 ? S sept.18 0:01 \_ [migration/4]
root 23 0.0 0.0 0 0 ? S sept.18 0:15 \_ [ksoftirqd/4]
root 25 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/4:0H]
root 26 0.0 0.0 0 0 ? S sept.18 0:01 \_ [migration/5]
root 27 0.0 0.0 0 0 ? S sept.18 0:13 \_ [ksoftirqd/5]
root 29 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/5:0H]
root 30 0.0 0.0 0 0 ? S sept.18 0:01 \_ [migration/6]
root 31 0.0 0.0 0 0 ? S sept.18 0:10 \_ [ksoftirqd/6]
root 33 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/6:0H]
root 34 0.0 0.0 0 0 ? S sept.18 0:01 \_ [migration/7]
root 35 0.0 0.0 0 0 ? S sept.18 0:10 \_ [ksoftirqd/7]
root 37 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/7:0H]
root 38 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [khelper]
root 39 0.0 0.0 0 0 ? S sept.18 0:00 \_ [kdevtmpfs]
root 40 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [netns]
root 41 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [writeback]
root 42 0.0 0.0 0 0 ? SN sept.18 0:00 \_ [ksmd]
root 43 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kintegrityd]
root 44 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 45 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [crypto]
root 46 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kblockd]
root 48 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ata_sff]
root 49 0.0 0.0 0 0 ? S sept.18 0:00 \_ [khubd]
root 50 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [md]
root 51 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [edac-poller]
root 52 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [rpciod]
root 54 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kvm-irqfd-clean]
root 130 0.0 0.0 0 0 ? S sept.18 0:23 \_ [kswapd0]
root 131 0.0 0.0 0 0 ? S sept.18 0:00 \_ [fsnotify_mark]
root 132 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [nfsiod]
root 133 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [cifsiod]
root 134 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsIO]
root 135 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 136 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 137 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 138 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 139 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 140 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 141 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 142 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsCommit]
root 143 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jfsSync]
root 144 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [xfsalloc]
root 145 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [xfs_mru_cache]
root 146 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [xfslogd]
root 147 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ocfs2_wq]
root 148 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [user_dlm]
root 149 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [glock_workqueue]
root 150 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [delete_workqueu]
root 151 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [gfs_recovery]
root 182 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kthrotld]
root 187 0.0 0.0 0 0 ? S sept.18 0:05 \_ [nvme]
root 188 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [nvme]
root 189 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 190 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [drbd-reissue]
root 193 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [iscsi_eh]
root 195 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_0]
root 196 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_0]
root 197 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_1]
root 198 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_1]
root 199 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_2]
root 200 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_2]
root 201 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_3]
root 202 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_3]
root 207 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_4]
root 208 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_4]
root 209 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_5]
root 210 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_5]
root 211 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_6]
root 212 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_6]
root 213 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_7]
root 214 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_7]
root 215 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_8]
root 216 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_8]
root 217 0.0 0.0 0 0 ? S sept.18 0:00 \_ [scsi_eh_9]
root 218 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [scsi_tmf_9]
root 225 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bond0]
root 226 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bnx2x]
root 228 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ixgbe]
root 229 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [mlx4]
root 230 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [vfio-irqfd-clea]
root 235 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kpsmoused]
root 236 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [raid5wq]
root 237 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bcache]
root 238 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bch_btree_io]
root 239 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [dm_bufio_cache]
root 240 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kmpathd]
root 241 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kmpath_handlerd]
root 242 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ipv6_addrconf]
root 243 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ceph-msgr]
root 244 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 245 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [deferwq]
root 246 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 247 0.0 0.0 0 0 ? S sept.18 0:53 \_ [md4_raid1]
root 248 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 249 0.0 0.0 0 0 ? S sept.18 0:00 \_ [md2_raid1]
root 250 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [bioset]
root 251 0.0 0.0 0 0 ? S sept.18 0:08 \_ [md1_raid1]
root 252 0.0 0.0 0 0 ? S sept.18 0:05 \_ [jbd2/md1-8]
root 253 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ext4-rsv-conver]
root 279 0.0 0.0 0 0 ? S< sept.18 0:08 \_ [kworker/2:1H]
root 324 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/6:1H]
root 325 0.0 0.0 0 0 ? S< sept.18 0:07 \_ [kworker/5:1H]
root 326 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/0:1H]
root 451 0.0 0.0 0 0 ? S< sept.18 0:13 \_ [kworker/4:1H]
root 465 0.0 0.0 0 0 ? S sept.18 0:00 \_ [jbd2/md2-8]
root 466 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ext4-rsv-conver]
root 467 0.0 0.0 0 0 ? S sept.18 0:42 \_ [jbd2/md4-8]
root 468 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [ext4-rsv-conver]
root 870 0.0 0.0 0 0 ? S< sept.18 0:19 \_ [kworker/3:1H]
root 1000 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/7:1H]
root 1001 0.0 0.0 0 0 ? S< sept.18 0:00 \_ [kworker/1:1H]
root 9914 0.0 0.0 0 0 ? S sept.21 0:03 \_ [kworker/5:0]
root 24621 0.0 0.0 0 0 ? S sept.22 0:02 \_ [kworker/1:2]
root 21205 0.0 0.0 0 0 ? S sept.22 0:02 \_ [kworker/6:1]
root 13293 0.0 0.0 0 0 ? S sept.22 0:01 \_ [kworker/7:2]
root 30362 0.0 0.0 0 0 ? S sept.22 0:01 \_ [kworker/4:0]
root 3629 0.0 0.0 0 0 ? S sept.22 0:01 \_ [kworker/3:2]
root 2685 0.0 0.0 0 0 ? D sept.22 0:36 \_ [kworker/0:3]
root 19965 0.0 0.0 0 0 ? S 12:39 0:00 \_ [kworker/5:1]
root 21515 0.0 0.0 0 0 ? S 12:40 0:00 \_ [kworker/2:2]
root 22719 0.0 0.0 0 0 ? S 12:40 0:00 \_ [kworker/4:2]
root 27926 0.0 0.0 0 0 ? S 12:52 0:00 \_ [kworker/6:2]
root 28492 0.0 0.0 0 0 ? S 12:54 0:00 \_ [kworker/7:1]
root 32154 0.0 0.0 0 0 ? S 12:58 0:00 \_ [kworker/2:0]
root 2175 0.0 0.0 0 0 ? S 13:03 0:00 \_ [kworker/0:2]
root 18589 0.0 0.0 0 0 ? S 13:31 0:00 \_ [kworker/u16:2]
root 3688 0.0 0.0 0 0 ? S 14:02 0:00 \_ [kworker/1:1]
root 3695 0.0 0.0 0 0 ? S 14:02 0:00 \_ [kworker/3:0]
root 11871 0.0 0.0 0 0 ? S 14:13 0:00 \_ [kworker/u16:1]
root 20916 0.0 0.0 0 0 ? S 14:30 0:00 \_ [kworker/0:1]
root 21065 0.0 0.0 0 0 ? S 14:31 0:00 \_ [kworker/1:0]
root 21220 0.0 0.0 0 0 ? S 14:32 0:00 \_ [kworker/2:1]
root 21443 0.0 0.0 0 0 ? S 14:32 0:00 \_ [kworker/3:1]
root 22411 0.0 0.0 0 0 ? S 14:35 0:00 \_ [kworker/0:0]
root 1 0.0 0.0 29728 4312 ? Ss sept.18 0:15 /lib/systemd/systemd --system --deserialize 16
root 289 0.0 0.1 164280 103648 ? Ss sept.18 0:25 /lib/systemd/systemd-journald
root 441 0.0 0.0 13440 1320 ? Ss sept.18 0:00 /sbin/mdadm --monitor --scan
root 802 0.0 0.0 24344 2140 ? Ss sept.18 0:00 /usr/sbin/smartd -n
root 812 0.0 0.0 4232 844 ? Ss sept.18 0:00 /usr/sbin/acpid
root 847 0.0 0.0 14396 880 tty6 Ss+ sept.18 0:00 /sbin/agetty --noclear tty6 linux
root 848 0.0 0.0 19332 828 ? Ss sept.18 0:36 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
root 849 0.0 0.0 14396 876 tty5 Ss+ sept.18 0:00 /sbin/agetty --noclear tty5 linux
root 850 0.0 0.0 14396 880 tty4 Ss+ sept.18 0:00 /sbin/agetty --noclear tty4 linux
root 851 0.0 0.0 14396 872 tty3 Ss+ sept.18 0:00 /sbin/agetty --noclear tty3 linux
root 852 0.0 0.0 14400 876 tty2 Ss+ sept.18 0:00 /sbin/agetty --noclear tty2 linux
root 853 0.0 0.0 14396 880 tty1 Ss+ sept.18 0:00 /sbin/agetty --noclear tty1 linux
root 3220 0.0 0.0 32536 1484 ? Ss sept.18 0:00 /lib/systemd/systemd-udevd
root 7468 0.0 0.0 27968 1384 ? Ss sept.18 0:02 /usr/sbin/cron -f
root 7589 0.0 0.0 258648 2416 ? Ssl sept.18 0:05 /usr/sbin/rsyslogd -n
message+ 21686 0.0 0.0 42104 1548 ? Ss sept.18 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root 21089 0.0 0.0 55148 3000 ? Ss sept.19 0:01 /usr/sbin/sshd -D
root 16446 0.0 0.0 82556 3724 ? Ss 14:23 0:00 \_ sshd: xxxx [priv]
xxxx 16448 0.0 0.0 82692 1716 ? S 14:23 0:00 \_ sshd: xxxx@pts/0
xxxx 16449 0.0 0.0 22340 2048 pts/0 Ss 14:23 0:00 \_ -bash
root 16454 0.0 0.0 46836 1648 pts/0 S 14:23 0:00 \_ su
root 16455 0.0 0.0 22424 2216 pts/0 S 14:23 0:00 \_ bash
root 22471 0.0 0.0 19728 1552 pts/0 R+ 14:36 0:00 \_ ps -faux
root 9347 0.0 0.0 93412 25552 ? Ss sept.20 0:03 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 21772 0.0 0.0 10676 340 ? Ss sept.21 0:00 /usr/bin/ssh-agent
top
top - 14:43:13 up 4 days, 16:27, 1 user, load average: 1,00, 1,09, 1,35
Tasks: 171 total, 1 running, 170 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,2 us, 0,0 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 65926100 total, 3202540 used, 62723560 free, 88376 buffers
KiB Swap: 1569780 total, 0 used, 1569780 free. 2302388 cached Mem

Niloo
22/09/2015, 11h30
Bonjour,
Avec si peu d'information, difficile de savoir si c'est "normal" ou pas.
Vu que tu as du raid soft, est-il en train de se reconstruire ? (cat /proc/mdadm)
Quelles sont les applications lancées ? (top / htop / ps -ef / iotop)

stormyboy
22/09/2015, 11h16
Bonjour,
J'ai pris un SP64 ssd 3x300 soft de la nouvelle gamme et à ma grande surprise le load average n'est jamais sous 1 et ce depuis l'installation du serveur donc avec rien d'autre de plus que l'install made in ovh
http://hpics.li/e72ddcd

Sur l'ancien (Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz 64Gb RAM et 2x160 SSD soft) je pouvais le voir descendre sous 0.5 notamment la nuit:
http://hpics.li/b30b876

Bug ou problème quelque part?!