Newbie questions about Pliant

Newbie questions about Pliant

Bug in trace?

Bug in trace?
Pliant 84 on Linux 2.4.20
Message posted by thomasb on 2003/05/12 11:27:36
When I trace some Pliant service pliant start to use 100% cpu as soon as 
the first trace message appears. This continues until I stop Pliant. Also,  
some defunct Pliant processes remains. Output of ps aux after a short
test looks like this:

root     22175  2.6  0.0     0    0 pts/12   Z    13:20   0:19 [pliant] <defunct>
root     22176  0.0  0.0     0    0 pts/12   Z    13:20   0:00 [pliant] <defunct>
root     22177  0.1  0.0     0    0 pts/12   Z    13:20   0:01 [pliant] <defunct>
root     22178 13.2  0.0     0    0 pts/12   Z    13:20   1:37 [pliant] <defunct>
root     22179  0.7  0.0     0    0 pts/12   Z    13:20   0:05 [pliant] <defunct>
root     22180  0.0  0.0     0    0 pts/12   Z    13:21   0:00 [pliant] <defunct>
root     22181  0.0  0.0     0    0 pts/12   Z    13:21   0:00 [pliant] <defunct>
Message posted by hubert.tonneau on 2003/05/12 11:46:11
I don't have so problems on my FullPliant servers where the CPU usage goes back
to close to 0.

Do you run on an SMP box (Pliant semaphores will compile very differently if it
detects UP or SMP hardware) ?

Do you run Pliant process has root (Pliant might use some features only available
to root user, also Pliant is running non root in FullPliant logical computers) ?

Please post the report of Pliant status page, and the 'details' one on CPU line
in the main status page.
Message posted by thomasb on 2003/05/12 11:54:13
CPU load report

CPU load report



   Documentation

In the status page, the number between brackets was the number provided by Linux kernel in /proc/loadavg, whereas other numbers are the result of consolidating this number over time.
See statistics.pli for extra details on how consolidating is implemented.

   List of the running threads in this process

Number of threads currently running in this process: 9
Maximum number of running threads was: 9
Number of allocated stacks: 9

Thread action stack ID Status
execute dynamic page /pliant/fullpliant/status.page 220 9
site 'localhost' user 'admin' command GET /pliant/fullpliant/status.html?button+0+0+%2Fpliant%2Ffullpliant%2Fstatus%2Epage%7C20030401114540%7C6+5kt2rA1W6Iya7C85J79h0w+BruDx2sU.5OK6EELOZwOYg HTTP/1.1
service HTTP request from 127.0.0.1
22276 running
recycling
22275 sleeping
database autostore daemon
22274 sleeping
shake random numbers generator
22273 sleeping
recycling
22272 sleeping
gather Linux kernel statistics
22271 sleeping
receive HTTP connections
22270 sleeping
recycling
22269 sleeping
receive HTTP connections
execute file:pliant/pliant/fullpliant/run.pli (internals) 128 1
parse file:pliant/pliant/fullpliant/run.pli (internals) 130 1
module file:pliant/pliant/fullpliant/run.pli
22268 sleeping


   List of all operating system threads

Total number of threads running in the server: 217

Command ID Status
init 1 sleeping
keventd 2 sleeping
ksoftirqd_CPU0 3 sleeping
kswapd 4 sleeping
bdflush 5 sleeping
kupdated 6 sleeping
kjournald 7 sleeping
devfsd 40 sleeping
khubd 385 sleeping
ahc_dv_0 444 sleeping
scsi_eh_0 445 sleeping
dhcpcd 491 sleeping
kjournald 618 sleeping
kreiserfsd 620 sleeping
dhcpcd 1087 sleeping
cupsd 1340 sleeping
portmap 1341 sleeping
rpciod 1365 sleeping
lockd 1366 sleeping
rpc.statd 1441 sleeping
syslogd 1624 sleeping
klogd 1637 sleeping
ntpd 1642 sleeping
sshd 1682 sleeping
cron 1720 sleeping
agetty 2128 sleeping
agetty 2129 sleeping
agetty 2130 sleeping
agetty 2131 sleeping
agetty 2132 sleeping
agetty 2133 sleeping
kdm 2149 sleeping
vmnet-bridge 26862 sleeping
vmnet-natd 26880 sleeping
vmnet-netifup 27142 sleeping
vmnet-dhcpd 27159 sleeping
X 2415 running
kdm 2416 sleeping
kde-3.1.1 2511 sleeping
startkde 2566 sleeping
kdeinit 2592 sleeping
kdeinit 2595 sleeping
kdeinit 2598 sleeping
kdeinit 2600 sleeping
artsd 2608 sleeping
kdeinit 2623 sleeping
kwrapper 2624 sleeping
kdeinit 2626 sleeping
kdeinit 2627 sleeping
kdeinit 2629 sleeping
kdeinit 2631 sleeping
kdeinit 2632 sleeping
ksysguardd 2633 sleeping
kdeinit 2637 sleeping
kdeinit 2639 sleeping
kgpg 2640 sleeping
kget 2646 sleeping
kdeinit 2648 sleeping
kalarmd 2661 sleeping
gnome-name-serv 2844 sleeping
knode 18120 sleeping
knode 18121 sleeping
knode 18122 sleeping
knode 18123 sleeping
kdeinit 18158 sleeping
bash 18159 sleeping
su 18162 sleeping
bash 18165 sleeping
bash 22395 sleeping
kdeinit 22450 sleeping
bash 22451 sleeping
xmms 22524 sleeping
xmms 22525 sleeping
xmms 22526 sleeping
xmms 22529 sleeping
bash 23067 sleeping
bash 6784 sleeping
man 22252 sleeping
sh 22255 sleeping
sh 22256 sleeping
nroff 22260 sleeping
less 22261 sleeping
groff 22264 sleeping
grotty 22266 sleeping
vim 22329 sleeping
bash 22330 sleeping
less 32423 sleeping
bash 351 sleeping
bash 355 sleeping
man 1985 sleeping
sh 1988 sleeping
sh 1989 sleeping
less 1994 sleeping
vmware 19642 sleeping
vmware 19648 sleeping
bash 19661 sleeping
kdeinit 19772 sleeping
bash 19773 sleeping
oafd 19794 sleeping
wombat 19797 sleeping
bonobo-moniker- 19801 sleeping
evolution-alarm 19823 sleeping
gnome-spell-com 19852 sleeping
kmail 19929 sleeping
kdeinit 20083 sleeping
bash 20084 sleeping
opera 20115 sleeping
opera 20117 running
bash 20138 sleeping
su 20141 sleeping
bash 20144 sleeping
pliant 20150 zombie
pliant 20151 zombie
pliant 20152 zombie
pliant 20153 zombie
pliant 20154 zombie
pliant 20155 zombie
pliant 20156 zombie
pliant 20157 zombie
pliant 20158 zombie
pliant 20178 zombie
pliant 20179 zombie
pliant 20180 zombie
pliant 20181 zombie
pliant 20182 zombie
pliant 20183 zombie
pliant 20184 zombie
pliant 20185 zombie
bash 20186 sleeping
su 20191 sleeping
bash 20194 sleeping
pliant 20226 zombie
pliant 20227 zombie
pliant 20228 zombie
pliant 20239 zombie
pliant 20240 zombie
pliant 20245 zombie
pliant 20246 zombie
pliant 20247 zombie
pliant 20248 zombie
pliant 20249 zombie
pliant 20250 zombie
pliant 20251 zombie
pliant 20252 zombie
pliant 20253 zombie
pliant 20254 zombie
pliant 20256 zombie
pliant 20257 zombie
pliant 20262 zombie
pliant 20263 zombie
pliant 20264 zombie
pliant 20265 zombie
pliant 20266 zombie
pliant 20375 zombie
pliant 20376 zombie
pliant 20474 zombie
pliant 20475 zombie
pliant 20476 zombie
pliant 21047 zombie
pliant 21048 zombie
pliant 21049 zombie
pliant 21055 zombie
pliant 21153 zombie
pliant 21164 zombie
pliant 21262 zombie
bash 21370 sleeping
pliant 21383 zombie
pliant 21384 zombie
pliant 21385 zombie
pliant 21386 zombie
pliant 21387 zombie
pliant 21388 zombie
pliant 21401 zombie
pliant 21402 zombie
pliant 21414 zombie
pliant 21445 zombie
pliant 21446 zombie
pliant 21447 zombie
pliant 21448 zombie
pliant 21486 zombie
pliant 21497 zombie
pliant 21498 zombie
pliant 21499 zombie
pliant 21500 zombie
pliant 21501 zombie
kdeinit 21590 sleeping
kdeinit 21597 sleeping
kdeinit 21616 sleeping
ssh 21620 sleeping
pliant 21690 zombie
pliant 21691 zombie
pliant 21997 zombie
pliant 21998 zombie
pliant 22095 zombie
pliant 22096 zombie
pliant 22097 zombie
pliant 22175 zombie
pliant 22176 zombie
pliant 22177 zombie
pliant 22178 zombie
pliant 22179 zombie
pliant 22180 zombie
pliant 22181 zombie
clue.sh 22211 sleeping
wine 22213 sleeping
wine 22214 sleeping
wineserver 22216 sleeping
wine 22263 sleeping
pliant 22268 sleeping
pliant 22269 sleeping
pliant 22270 sleeping
pliant 22271 sleeping
pliant 22272 sleeping
pliant 22273 sleeping
pliant 22274 sleeping
pliant 22275 sleeping
pliant 22276 running

Message posted by hubert.tonneau on 2003/05/12 11:57:29
Pliant has a single running thread (yellow) which is your HTTP request.
Everything looks fine to me.

The large number of Zombies you have is probably related to the way you are
launching Pliant, not to Pliant itself.
Message posted by thomasb on 2003/05/12 12:05:54
The computer has a single Atlon CPU. No SMP.

Pliant is running as root. I will try with a normal user.

Some corretions:
100% start some about 10 seconds after the trace is started, not the first message.
Loads goes back to 0 some minutes after trace is stopped. 
The defunct Pliant processes still remains when Pliant is stopped.


Message posted by hubert.tonneau on 2003/05/12 12:28:28
Ok, I can reproduce that.

This is related to the communication between the Pliant thread handling the
HTTP request for the user that requested the trace, and the Pliant trace
machinery.

It is implemented under the 'Start tracing' button in
/pliant/protocol/http/trace.page
and the thread handling the HTTP request is busy looping on a Pliant
fast semaphore.

So, the CPU usage raises to 100%, but in facts the machine is not that much
loaded. If you compare the execution time for another task, you will notice
that it is not much impacted. What you are mesuring is rather the limits of
the reliability of the Linux kernel statistics.
Message posted by thomasb on 2003/05/12 12:30:35
When I run Pliant as a normal user the load problem remains, but no defunct
appears.

I run Pliant as:
pliant pliant/pliant/fullpliant/run.pli

A also tried:
pliant module "/pliant/protocol/http/server.pli" command 'http_server'

When I quit the shell all defunct processes dissapered. Nice. This was a
bash shell was started using "su -" from another bash shell. Logging in
as root an a text console does not change anything.

I will post a new report that looks a bit different.
Message posted by hubert.tonneau on 2003/05/12 12:33:08
PS: A good way to discover what's going on, is to send a kill signal to the
    Linux process (ie Pliant thread) which is running all the time, so that
    you will get a stack trace of the right thread, and through reading the
    code at the positions specified in the stack trace, you should be abble
    to conclude what the Pliant process is truely spending all it's time on.