Incohérence avec la charge du serveur

bibax
Messages : 3
Inscription : 10 octobre 2013, 09:59

Incohérence avec la charge du serveur

Message par bibax » 10 octobre 2013, 11:40

Bonjour à tous,

J'ai effectué une installation d'une centos 6.4 sur un serveur Dell R710.
Tout semble bien fonctionner mais il me reste 3 points de détail à résoudre ou au moins comprendre :

- Lorsque je fais un top, j'ai une charge de 24!! Pourtant aucun problème pour travailler dessus. Je pense qu'il doit y avoir une incohérence dans le calcul mais je ne sais pas du tout où chercher. Quand je tape sur 1 dans le top, je vois tous les processeurs (24) mais ils ne sont vraiment pas chargé...
top - 10:15:50 up 5 days, 19:51, 24 users, load average: 24.84, 24.61, 24.49
Tasks: 765 total, 1 running, 764 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 99.4%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32829392k total, 28089184k used, 4740208k free, 113220k buffers
Swap: 8388600k total, 36660k used, 8351940k free, 26608552k cached

- Un problème de trace dans les logs :
Oct 9 20:21:00 xx kernel: swapper: page allocation failure. order:5, mode:0x20
Oct 9 20:21:00 xx kernel: Pid: 0, comm: swapper Not tainted 2.6.32-358.18.1.el6.x86_64 #1
Oct 9 20:21:00 xx kernel: Call Trace:
Oct 9 20:21:00 xx kernel: <IRQ> [<ffffffff8112c257>] ? __alloc_pages_nodemask+0x757/0x8d0
Oct 9 20:21:00 xx kernel: [<ffffffff81166d92>] ? kmem_getpages+0x62/0x170
Oct 9 20:21:00 xx kernel: [<ffffffff811679aa>] ? fallback_alloc+0x1ba/0x270
Oct 9 20:21:00 xx kernel: [<ffffffff811673ff>] ? cache_grow+0x2cf/0x320
Oct 9 20:21:00 xx kernel: [<ffffffff81167729>] ? ____cache_alloc_node+0x99/0x160
Oct 9 20:21:00 xx kernel: [<ffffffff811688f0>] ? kmem_cache_alloc_node_trace+0x90/0x200
Oct 9 20:21:00 xx kernel: [<ffffffff81168b0d>] ? __kmalloc_node+0x4d/0x60
Oct 9 20:21:00 xx kernel: [<ffffffff8143ddad>] ? __alloc_skb+0x6d/0x190
Oct 9 20:21:00 xx kernel: [<ffffffff8143eed0>] ? skb_copy+0x40/0xb0
Oct 9 20:21:00 xx kernel: [<ffffffffa01d027c>] ? tg3_start_xmit+0xa8c/0xd50 [tg3]
Oct 9 20:21:00 xx kernel: [<ffffffff814493b8>] ? dev_hard_start_xmit+0x308/0x530
Oct 9 20:21:00 xx kernel: [<ffffffff8146773a>] ? sch_direct_xmit+0x15a/0x1c0
Oct 9 20:21:00 xx kernel: [<ffffffff8144d0c0>] ? dev_queue_xmit+0x3b0/0x550
Oct 9 20:21:00 xx kernel: [<ffffffff814857f8>] ? ip_finish_output+0x148/0x310
Oct 9 20:21:00 xx kernel: [<ffffffff81485a78>] ? ip_output+0xb8/0xc0
Oct 9 20:21:00 xx kernel: [<ffffffff81484d3f>] ? __ip_local_out+0x9f/0xb0
Oct 9 20:21:00 xx kernel: [<ffffffff81484d75>] ? ip_local_out+0x25/0x30
Oct 9 20:21:00 xx kernel: [<ffffffff81485250>] ? ip_queue_xmit+0x190/0x420
Oct 9 20:21:00 xx kernel: [<ffffffffa033448a>] ? xprt_complete_rqst+0x13a/0x1c0 [sunrpc]
Oct 9 20:21:00 xx kernel: [<ffffffff8149a04e>] ? tcp_transmit_skb+0x40e/0x7b0
Oct 9 20:21:00 xx kernel: [<ffffffff8149c45b>] ? tcp_write_xmit+0x1fb/0xa20
Oct 9 20:21:00 xx kernel: [<ffffffffa0198000>] ? ipt_do_table+0x1c0/0x678 [ip_tables]
Oct 9 20:21:00 xx kernel: [<ffffffff8149ce10>] ? __tcp_push_pending_frames+0x30/0xe0
Oct 9 20:21:00 xx kernel: [<ffffffff814948a3>] ? tcp_data_snd_check+0x33/0x100
Oct 9 20:21:00 xx kernel: [<ffffffff814984ed>] ? tcp_rcv_established+0x3ed/0x800
Oct 9 20:21:00 xx kernel: [<ffffffff814a04e3>] ? tcp_v4_do_rcv+0x2e3/0x430
Oct 9 20:21:00 xx kernel: [<ffffffffa032a557>] ? ipv4_confirm+0x87/0x1d0 [nf_conntrack_ipv4]
Oct 9 20:21:00 xx kernel: [<ffffffff814a1d6e>] ? tcp_v4_rcv+0x4fe/0x8d0
Oct 9 20:21:00 xx kernel: [<ffffffff8147f920>] ? ip_local_deliver_finish+0x0/0x2d0
Oct 9 20:21:00 xx kernel: [<ffffffff8147f9fd>] ? ip_local_deliver_finish+0xdd/0x2d0
Oct 9 20:21:00 xx kernel: [<ffffffff8147fc88>] ? ip_local_deliver+0x98/0xa0
Oct 9 20:21:00 xx kernel: [<ffffffff8147f14d>] ? ip_rcv_finish+0x12d/0x440
Oct 9 20:21:00 xx kernel: [<ffffffff8147f6d5>] ? ip_rcv+0x275/0x350
Oct 9 20:21:00 xx kernel: [<ffffffff814488ab>] ? __netif_receive_skb+0x4ab/0x750
Oct 9 20:21:00 xx kernel: [<ffffffff8149f08a>] ? tcp4_gro_receive+0x5a/0xd0
Oct 9 20:21:00 xx kernel: [<ffffffff8144ac88>] ? netif_receive_skb+0x58/0x60
Oct 9 20:21:00 xx kernel: [<ffffffff8144ad90>] ? napi_skb_finish+0x50/0x70
Oct 9 20:21:00 xx kernel: [<ffffffff8144d339>] ? napi_gro_receive+0x39/0x50
Oct 9 20:21:00 xx kernel: [<ffffffffa01ccc14>] ? tg3_poll_work+0x784/0xe50 [tg3]
Oct 9 20:21:00 xx kernel: [<ffffffffa01cd32c>] ? tg3_poll_msix+0x4c/0x150 [tg3]
Oct 9 20:21:00 xx kernel: [<ffffffff8109ae02>] ? enqueue_hrtimer+0x82/0xd0
Oct 9 20:21:00 xx kernel: [<ffffffff8144d453>] ? net_rx_action+0x103/0x2f0
Oct 9 20:21:00 xx kernel: [<ffffffff810770b1>] ? __do_softirq+0xc1/0x1e0
Oct 9 20:21:00 xx kernel: [<ffffffff810e1760>] ? handle_IRQ_event+0x60/0x170
Oct 9 20:21:00 xx kernel: [<ffffffff8100c1cc>] ? call_softirq+0x1c/0x30
Oct 9 20:21:00 xx kernel: [<ffffffff8100de05>] ? do_softirq+0x65/0xa0
Oct 9 20:21:00 xx kernel: [<ffffffff81076e95>] ? irq_exit+0x85/0x90
Oct 9 20:21:00 xx kernel: [<ffffffff815176e5>] ? do_IRQ+0x75/0xf0
Oct 9 20:21:00 xx kernel: [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11
Oct 9 20:21:00 xx kernel: <EOI> [<ffffffff812d3cae>] ? intel_idle+0xde/0x170
Oct 9 20:21:00 xx kernel: [<ffffffff812d3c91>] ? intel_idle+0xc1/0x170
Oct 9 20:21:00 xx kernel: [<ffffffff814155f7>] ? cpuidle_idle_call+0xa7/0x140
Oct 9 20:21:00 xx kernel: [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110
Oct 9 20:21:00 xx kernel: [<ffffffff8150756c>] ? start_secondary+0x2ac/0x2ef
Je pense que cela est dû à du transfert réseau mais comment le résoudre....
J'ai modifié ce paramètre dans sysctl.conf et je vais voir pour décommenter le deuxième...

vm.min_free_kbytes = 16384
#vm.zone_reclaim_mode = 1

- 3ème et dernier point.... :
J'ai un log qui n'est peut-être pas embêtant mais qui semble inquiétant :
Oct 9 17:59:35 xx kernel: CPU1: Core power limit notification (total events = 1193)
Oct 9 17:59:35 xx kernel: CPU5: Core power limit notification (total events = 1199)
Oct 9 17:59:35 xx kernel: CPU17: Core power limit notification (total events = 1199)
Oct 9 17:59:35 xx kernel: CPU15: Core power limit notification (total events = 1193)
Oct 9 17:59:35 xx kernel: CPU3: Core power limit notification (total events = 1193)
Oct 9 17:59:35 xx kernel: CPU19: Core power limit notification (total events = 1193)
Oct 9 17:59:35 xx kernel: CPU7: Core power limit notification (total events = 1193)
Oct 9 17:59:35 xx kernel: CPU9: Core power limit notification (total events = 1186)
Oct 9 17:59:35 xx kernel: CPU21: Core power limit notification (total events = 1186)
Oct 9 17:59:35 xx kernel: CPU11: Core power limit notification (total events = 1186)
Oct 9 17:59:35 xx kernel: CPU23: Core power limit notification (total events = 1186)
Oct 9 17:59:35 xx kernel: CPU13: Core power limit notification (total events = 1192)
Oct 9 17:59:35 xx kernel: CPU5: Package power limit notification (total events = 1188)
Oct 9 17:59:35 xx kernel: CPU17: Package power limit notification (total events = 1188)
Oct 9 17:59:35 xx kernel: CPU15: Package power limit notification (total events = 1183)
Oct 9 17:59:35 xx kernel: CPU3: Package power limit notification (total events = 1185)
Oct 9 17:59:35 xx kernel: CPU19: Package power limit notification (total events = 1187)
Oct 9 17:59:35 xx kernel: CPU7: Package power limit notification (total events = 1188)
Oct 9 17:59:35 xx kernel: CPU9: Package power limit notification (total events = 1176)
Oct 9 17:59:35 xx kernel: CPU21: Package power limit notification (total events = 1178)
Oct 9 17:59:35 xx kernel: CPU11: Package power limit notification (total events = 1179)
Oct 9 17:59:35 xx kernel: CPU23: Package power limit notification (total events = 1178)
Oct 9 17:59:35 xx kernel: CPU13: Package power limit notification (total events = 1182)
Oct 9 17:59:35 xx kernel: CPU1: Package power limit notification (total events = 1185)
Oct 9 17:59:35 xx kernel: CPU13: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU1: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU1: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU13: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU15: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU3: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU5: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU17: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU7: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU19: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU9: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU21: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU23: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU11: Core power limit normal
Oct 9 17:59:35 xx kernel: CPU3: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU5: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU17: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU7: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU19: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU9: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU21: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU23: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU11: Package power limit normal
Oct 9 17:59:35 xx kernel: CPU15: Package power limit normal
J'ai cherché mais je ne trouve rien de probant à ce sujet a part modifier un paramètre de boot clearcpuid mais je ne sais pas à quel endroit faire cela...


Bon après ce check, je tiens à préciser que tout semble fonctionner normalement mais ces petits messages sont un peu inquiétant... :?
Je ne savais pas s'il fallait déclarer un ou plusieurs topic alors je vais voir selon les réactions.

Je vous remercie d'avance pour vos connaissances et je vous souhaite une bonne journée!

Avatar de l’utilisateur
nouvo09
Messages : 2221
Inscription : 20 octobre 2009, 08:14
Localisation : Paris, France

Re: Incohérence avec la charge du serveur

Message par nouvo09 » 10 octobre 2013, 13:21

modifier un paramètre de boot clearcpuid mais je ne sais pas à quel endroit faire cela
Ca tu peux toujours regarder dans la doc kernel, les paramètres possibles.

Sinon pas d'idée. Déjà 24 processeurs, j'avais jamais vu :-D
C'est pas parce que c'est difficile qu'on ose pas,
c'est parce qu'on ose pas que c'est difficile !

bibax
Messages : 3
Inscription : 10 octobre 2013, 09:59

Re: Incohérence avec la charge du serveur

Message par bibax » 10 octobre 2013, 13:35

On est d'accord pour les 24 CPU! lol
Je me suis un peu emballé, on va retenir le nombre et seulement changer le terme en core!
Et sinon, pas d'idées sur comment rétablir les données pour la charge?

Pour le clearcpuid, j'ai bien trouvé les références dans la doc kernel mais je suis donc obligé de modifier le noyau pour cela ou bien peux-t-on modifier ce dernier dans un fichier (sysctl.conf? ....)

Cordialement,

Avatar de l’utilisateur
nouvo09
Messages : 2221
Inscription : 20 octobre 2009, 08:14
Localisation : Paris, France

Re: Incohérence avec la charge du serveur

Message par nouvo09 » 10 octobre 2013, 16:08

non, les paramètres noyau tu peux

1) les rajouter manuellement lors du boot en éditant à la volée le fichier grub.conf, sans l'enregistrer

2) modifier le fichier grub.conf

dans les deux cas il suffit de mettre le paramètre voulu à la suite du reste dans la ligne kernel....
C'est pas parce que c'est difficile qu'on ose pas,
c'est parce qu'on ose pas que c'est difficile !

MarbolanGos
Messages : 341
Inscription : 26 octobre 2009, 19:03

Re: Incohérence avec la charge du serveur

Message par MarbolanGos » 11 octobre 2013, 14:45

nouvo09 a écrit :Sinon pas d'idée. Déjà 24 processeurs, j'avais jamais vu :-D
Des machines à 64, 128 cœurs existent (voir les Bullx)
Là c'est des 12 cœurs avec HyperThreading.

Pour le problème j'ai eu un cas similaire récemment sur une machine et c'était sioux à trouver mais en fait c'était des processus morts qui montaient artificiellement la charge même si on ne ressentait pas la charge... Pour les détecter :

Code : Tout sélectionner

top -b -n 1 | awk '{if (NR <=7) print; else if ($8 == "D") {print; count++} } END {print "Total status D: "count}'
Dans mon cas c'est hald-addon-storage qui partait en vrille à cause du lecteur optique (qui d'ailleurs est inutile sur cette machine mais c'est une autre histoire).
http://rarebril.com/blog
http://www.smolts.org/client/show/pub_d44745d4-fc38-4d31-a94c-499e6e1838ea

bibax
Messages : 3
Inscription : 10 octobre 2013, 09:59

Re: Incohérence avec la charge du serveur

Message par bibax » 11 octobre 2013, 16:41

Merci pour l'information!

En effet, voici la liste des processus Dead :
top -b -n 1 | awk '{if (NR <=7) print; else if ($8 == "D") {print; count++} } END {print "Total status D: "count}'
top - 16:26:59 up 7 days, 2:02, 30 users, load average: 24.31, 24.60, 24.71
Tasks: 766 total, 1 running, 765 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 0.4%sy, 0.1%ni, 98.5%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32829392k total, 31793184k used, 1036208k free, 138652k buffers
Swap: 8388600k total, 48688k used, 8339912k free, 28352300k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
179 root 20 0 0 0 0 D 0.0 0.0 0:00.00 kacpi_notify
22136 root 20 0 4156 604 532 D 0.0 0.0 0:00.00 modprobe
29362 root -2 0 0 0 0 D 0.0 0.0 0:01.19 power_saving/0
29363 root -2 0 0 0 0 D 0.0 0.0 0:00.05 power_saving/1
29364 root -2 0 0 0 0 D 0.0 0.0 0:09.98 power_saving/2
29365 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/3
29366 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/4
29367 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/5
29368 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/6
29369 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/7
29370 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/8
29371 root -2 0 0 0 0 D 0.0 0.0 0:09.20 power_saving/9
29372 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/10
29373 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/11
29374 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/12
29375 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/13
29376 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/14
29377 root -2 0 0 0 0 D 0.0 0.0 0:09.22 power_saving/15
29378 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/16
29379 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/17
29380 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/18
29381 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/19
29382 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/20
29383 root -2 0 0 0 0 D 0.0 0.0 0:09.50 power_saving/21
Total status D: 24
A lire les noms de processus, je pense que cela est en relation avec mon log d'erreur sur les CPU.....
De plus, 24 comme les cpu.... hummm!

Par contre, je bug sur comment les enlever de cette liste car du fait qu'ils sont dead,... je ne peux plus les tuer! Comme un zombie! ;-)
A moins de rebooter mais tant que je n'aurais pas de solution sur les logs du cpu, je pense que ces processus reviendront.
J'ai testé la solution du # modprobe- r acpi_pad mais la commande ne se finalise... même au bout de quelques minutes...

Je suis toujours preneur de bonnes idées!
Et en tout cas merci, car je là je commence à comprendre un peu plus!

MarbolanGos
Messages : 341
Inscription : 26 octobre 2009, 19:03

Re: Incohérence avec la charge du serveur

Message par MarbolanGos » 14 octobre 2013, 13:30

Comme tu l'as compris ces processus ne peuvent bien sûr pas être tués sauf en redémarrant la machine...

J'ai un peu cherché sur ce problème et il semblerait que le support de Dell propose une solution : http://en.community.dell.com/support-fo ... x#20168890
C'est aussi documenté chez RH : https://access.redhat.com/site/solutions/366273
Resolution :

•Disable C states/Speed Step in system BIOS

•To immediately reduce load on the system without a reboot modprobe -r acpi_pad
http://rarebril.com/blog
http://www.smolts.org/client/show/pub_d44745d4-fc38-4d31-a94c-499e6e1838ea

Répondre