Processus migration/0 ?

Support Debian
#1

Bonsoir à tous,

J’ai un processus inconnu sur mon serveur, il a l’air d’utiliser beaucoup de CPU et du coup, j’aurais aimé avec quelques informations et savoir si c’était normal…
Pour précision, je suis sous Debian Squeeze amd64 et j’utilise PuTTY comme SSH :wink:

# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... root 6 88.1 0.0 0 0 ? S Aug15 10290:00 [migration/0] root 7 68.7 0.0 0 0 ? S Aug15 8031:52 [migration/1] ... root 11 22.1 0.0 0 0 ? S Aug15 2590:38 [migration/2] ... root 14 99.3 0.0 0 0 ? S Aug15 11599:05 [migration/3] ...

(j’ai volontairement tronqué car il y a beaucoup de processus sinon)

Mais je me demande ce qu’est le processus “migration” ? Et en %CPU on croirait qu’il y a un bug… parce que sinon, il utilise plus de 250% du CPU…

En tout cas, je vous remercie d’avance de me renseigner car je débute et ce n’est pas toujours facile :slightly_smiling:
A bientôt !

#2

Ce qui apparaît entre crochets [] dans ps fait partie intégrante du kernel (autrement dit, ce n’est pas un programme habituel).
Une recherche rapide sur le web “linux migration process” indique qu’il s’agit de la partie du kernel qui s’occupe de déplacer les process d’un CPU (ou d’un cœur) à l’autre pour équilibrer la charge. Tu noteras qu’il y a un [migration] par cœur CPU.
C’est tout à fait normal qu’ils soient là.

Non, dans ps le %CPU correspond à la charge d’un seul cœur CPU. Vu que tu as un quadcore (4 process [migration]) tu peux aller jusqu’à 400%… :wink:

Par contre ce qui n’est pas normal c’est qu’ils utilisent autant de CPU. Une autre recherche rapide “linux migration process 100%” (décidément, les moteurs de recherche c’est utile des fois :mrgreen:) me mène à cette discussion sur les forums OpenVZ qui suggère que c’est un bug connu et donne même une solution de contournement :

echo 0 > /proc/sys/kernel/sched_cpulimit_nr_balance

De deux choses l’une :

  • soit tu utilises le bricolage ci-dessus (faudra bien penser à le faire à chaque redémarrage du système, le plus simple étant de mettre la commande dans /etc/rc.local) probablement au détriment de cette fonctionnalité d’équilibrage de charge (pour être honnête j’ai un peu la flemme de chercher plus avant)
  • soit tu peux essayer d’installer un kernel plus récent (j’imagine qu’avec ta Squeeze tu es toujours en 2.6.32 ?) à partir des backports voir si ça résout le souci, avec tous les inconvénients de sécurité que ça peut apporter sur un serveur (la procédure pour le faire a été expliquée mille fois sur ce forum, je te laisse chercher)

Franchement je sais pas quoi te conseiller : l’équilibrage de charge est une fonctionnalité plutôt importante question performances mais d’un autre côté les backports n’ont pas de vrai suivi de sécurité donc installer un kernel plus récent peut poser problème si une faille est découverte. Je te laisse te renseigner sur les implications exactes de chaque solution et prendre ta décision toi-même (même si je pense qu’au final ça dépendra beaucoup de ta priorité : performance ou sécurité)… Mais que ça ne t’empêche pas de venir nous rapporter tes trouvailles ! :wink:

#3

Bonjour Syam et merci pour la réponse.

Au moins, j’ai appris que le serveur pouvait monter a 400% (même si je ne préfère pas bien entendu :wink: )
Je viens de me pencher sur cela et voir quelles solutions y apporter, j’ai essayé :

Mais le fichier sched_cpulimit_nr_balance n’existe pas… Dans kernel je n’ai que :

acpi_video_flags msgmax printk_ratelimit_burst auto_msgmni msgmnb pty blk_iopoll msgmni random bootloader_type ngroups_max randomize_va_space bootloader_version osrelease real-root-dev cad_pid ostype sched_child_runs_first cap_last_cap overflowgid sched_rt_period_us compat-log overflowuid sched_rt_runtime_us core_pattern panic sem core_pipe_limit panic_on_io_nmi sg-big-buff core_uses_pid panic_on_oops shmall ctrl-alt-del panic_on_unrecovered_nmi shmmax dmesg_restrict perf_event_max_sample_rate shmmni domainname perf_event_mlock_kb shm_rmid_forced hostname perf_event_paranoid tainted hotplug pid_max threads-max io_delay_type poweroff_cmd unknown_nmi_panic keys print-fatal-signals usermodehelper kptr_restrict printk version kstack_depth_to_print printk_delay max_lock_depth printk_ratelimit

Encore merci !

#4

Ah c’est plutôt embêtant ça !
Quel est ton kernel exact ? (uname -a)

Après vérification (il était un peu tard pour ça hier soir :blush:) je ne l’ai pas non plus sur aucune machine (2.6.32, 3.2, 3.5). :075
Par contre j’ai beaucoup plus de choses que toi dans /proc/sys/kernel/ dont sched_nr_migrate qui y ressemble fortement. Sûrement une question d’options de compilation du kernel (les miens sont des kernels Debian directement en provenance des dépôts).

Si tu n’es pas trop trop paranoïaque sur la sécurité tu peux toujours essayer avec un kernel plus récent, de toutes façons ça va pas durer bien longtemps puisque Wheezy arrive en début d’année normalement (6-7 mois). :eusa-whistle: :wink:
À part ça je sais pas trop quoi te dire, cette histoire de sched_cpulimit_nr_balance était la seule info pertinente que j’ai trouvé concernant ton problème. :frowning:

#5

S’il n’existe pas créé le !

Au mieux ça résoud ton problème, au pire il n’est pas pris en compte :mrgreen:

Donc ca ne coute rien d’essayer :041

#6

Euh on parle d’un pseudo-fichier dans /proc là… Seul le kernel peut créer des fichiers là-dedans, même root ne peut pas.
La preuve :

# echo 0 > /proc/sys/kernel/sched_cpulimit_nr_balance bash: /proc/sys/kernel/sched_cpulimit_nr_balance: Aucun fichier ou dossier de ce type
:wink:

#7

C’est pas faux :blush:
et par la même occase je viens de vérifier dsur mon système et je n’ai pas ce fichier non plus :whistle:

#8

Bonjour a tous :slightly_smiling:

J’ai installé depuis peu la distribution linux Mageia 2 (Mageia est un Fork de Mandriva) sur mon pc portable ( cpu : P7550, gpu ati HD 4650, 4Go de ram, je travail avec KDE 4.8.2, kernel 3.3.8).

Ce forum est consacré à débian mais je rencontre le même problème avec le processus Migration:

Il me surcharge le CPU ce qui entraine des lenteurs, une surconsommation, chauffe beaucoup donc fait pas mal de bruit avec le ventilateur.

Cela me rassure beaucoup de voir que d’autre gens ont le même problème, je commençais à desespérer.

Voici un aperçu de la charge du processus Migration

[code]#ps ax -o pid,comm,pcpu | grep “migration”
6 migration/0 79.7
7 migration/1 97.6

Parfois seul un processus est actif :

ps ax -o pid,comm,pcpu | grep “migration”

6 migration/0 86.4
7 migration/1 0.0
[/code]

En lisant ce topic j’ai apperçu une commande qui focntionne chez certaines personnes, mais chez moi j’ai le message d’erreur que syam :

echo 0 > /proc/sys/kernel/sched_cpulimit_nr_balance

bash: /proc/sys/kernel/sched_cpulimit_nr_balance: Aucun fichier ou dossier de ce type

J’ai créé un topic sur le forum de mageia :
http://www.mageialinux-online.org/forum/topic-12635+lags-et-2-processus-inconnu-erreur-dbus.php
Si cela permet d’aider un petit peu

Cordialement