Je vous serais reconnaissant si vous pouviez jeter un coup d'œil aux détails ici.
Lire tout le contenu de proc / [pid] Lire tout le contenu de proc / [pid] ~ d'attr à cpuset ~ Lire tout le contenu de proc / [pid] ~ de cwd à loginuid ~ Lire tout le contenu de proc / [pid] ~ de map_files à numa_maps ~ Faux, vous pouvez trouver plus d'informations ici, ce répertoire n'est plus utilisé, Je vous serais reconnaissant si vous pouviez commenter si vous avez des informations.
# sleep 365d > /dev/null &
[1] 3792
# ls /proc/3792
attr cwd map_files oom_adj schedstat task
autogroup environ maps oom_score sessionid timers
auxv exe mem oom_score_adj setgroups uid_map
cgroup fd mountinfo pagemap smaps wchan
clear_refs fdinfo mounts patch_state stack
cmdline gid_map mountstats personality stat
comm io net projid_map statm
coredump_filter limits ns root status
cpuset loginuid numa_maps sched syscall
# cd /proc/3792
oom_adj,oom_score,oom_score_adj
# cat oom_adj
0
[root@test-sv 3792]# cat oom_score
0
[root@test-sv 3792]# cat oom_score_adj
0
Le noyau Linux a un mécanisme appelé OOM (Out Of Memory) Killer, qui arrête de force les processus qui utilisent beaucoup de ressources mémoire lorsque la mémoire (RAM) est épuisée et que le système peut devenir inopérant. , Allouez de la mémoire. Si un processus est important pour le fonctionnement ou si vous ne souhaitez pas qu'il soit la cible d'OOM Killer, par exemple pendant les tests de charge, vous pouvez l'exclure de la cible d'OOM Killer en le définissant. https://users.atmark-techno.com/blog/1913/2767
Vous pouvez également ajuster le score oom_killer pour hiérarchiser les processus qui sont tués. Il existe deux outils dans / proc / PID / nommés oom_adj et oom_score. Les scores valides pour oom_adj vont de -16 à +15. Vérifiez le score oom_killer actuel dans le oom_score du processus. oom_killer tue le processus avec le score le plus élevé en premier. L'exemple suivant ajuste le oom_score d'un processus pour un processus avec un PID de 12465 pour réduire la priorité d'être tué par oom_killer. https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-pid
Il semble. Cela a été utile. pagemap
# cat pagemap
釞 ・
Le fichier pagemap est un fichier spécial qui contient à quelle page physique correspond chaque page virtuelle. http://mmi.hatenablog.com/entry/2017/05/01/215921
C'est vrai. Dès que «chat» a été fait facilement, «・» a commencé à cligner des yeux. J'étais effrayé
# ll | grep pagemap
-r--r--r--. 1 root root 0 Jan 12 05:09 pagemap
C'était également un fichier en lecture seule.
patch_state
# cat patch_state
-1
Il semble montrer l'état du correctif actuellement appliqué. -1 semble indiquer qu'il n'est pas attribué. ... de quoi parlez-vous de quand à quand? Je ne suis pas sûr.
personality
# cat personality
00000000
This read-only file exposes the process's execution domain, as set by personality(2). The value is displayed in hexadecimal notation.
Il existe un domaine d'exécution et il est décrit en octal. Il semble qu'il ne soit pas utilisé car il est tout à 0.
projid_map
# cat projid_map
0 0 4294967295
The /etc/projid file provides a mapping between numeric project identifiers and a simple human readable name (similar relationship to the one that exists between usernames and uids). http://man7.org/linux/man-pages/man5/projid.5.html
Cela ressemble à une carte entre project --id. Il semble que le mappage soit similaire à la connexion de l'ID utilisateur et du nom d'utilisateur. Vraiment?
root
# ll
(Abréviation)
lrwxrwxrwx. 1 root root 0 Jan 12 05:09 root -> /
Inutile de dire que c'est le chemin racine. Cela semble changer si c'est chroot
sched
cat sched
sleep (3792, #threads: 1)
-------------------------------------------------------------------
se.exec_start : 318459004.030016
se.vruntime : 15734302.289257
se.sum_exec_runtime : 1.437900
se.nr_migrations : 0
nr_switches : 1
nr_voluntary_switches : 1
nr_involuntary_switches : 0
se.load.weight : 1024
policy : 0
prio : 120
clock-delta : 51
mm->numa_scan_seq : 0
numa_migrations, 0
numa_faults_memory, 0, 0, 1, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1
Il semble que les informations de planification soient répertoriées. Il y avait un très bel article sur qiita avec des détails sur / proc / \ <pid > / sched, donc je vais le lire et étudier. Je ne sais pas si je peux mettre le lien, donc je ne le mettrai pas.
schedstat
# cat schedstat
1437900 472415 1
L'extrême gauche est comme se.sum_exec_runtime: 1.437900 of sched, mais je ne sais rien d'autre.
sessionid
# cat sessionid
89
Il semble que le processus ait un ID de processus (PID) et un ID de session (SID), qui sont écrits.
Il est difficile de lire l'anglais et de ne pas lire le code source.
http://www.usupi.org/sysad/238.html https://linuxjm.osdn.jp/html/LDP_man-pages/man5/proc.5.html http://man7.org/linux/man-pages/man5/proc.5.html https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-pid https://github.com/torvalds/linux/blob/master/Documentation/filesystems/proc.txt
Recommended Posts