Le 06/11/2017 à 18:19, Warren Young a écrit :
The remaining PIDs are all certainly a single parent with multiple
children. You’d have to run top in “tree” mode or show the PPID
column to find out which one is the parent. You can tell without
doing that by the fact that all of the VIRT column values are
identical, meaning that within the limits of top’s reporting
resolution, the children are allocating no dynamic virtual memory of
their own, which is what we’d expect from a forking HTTP
child-per-conn model.
Given all of that, I’d just pick one of the PIDs and attach to it:
$ gdb -p 26819
If that works, say “bt” when attached, then “quit” to detach again.
Post the backtrace output here, Oliver.
If it doesn’t work, it’s probably due to lack of debugging permission
on the target system, in which case you’ve got some sysadminning
ahead of you, not on topic here.
But, this does not look like a madly-spinning system. The CPU is
idle and the PIDs are pretty far apart.
Basically, it’s looking like each one is the result of an HTTP
transaction and the child just isn’t dying at transaction end as it
should. This should only be a serious problem when the children
collectively hold so many resources that the system can’t run
properly.
Bottom line, I don’t think the top output explains the problem.
Thank you for the explanation.
The server on which Fossil is running is dedicated to this task, I don’t
do anything else with it.
When I reported the problem I had killed all processes and had
relaunched Fossil. I now run the version I compiled, and will do as you
said as soon as I noticed the problem occurs again. I still have no clue
of what can produce this behavior.
We’ll have to wait.
Olivier
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
