The joy :) Well seems you can get a 'thread ID' using procstat but that's as far as I've got thus far.
[root@mail4-db-4a ~]# !ps ps Hlauxc -p `pidof dbmail-pop3d` UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND USER %CPU %MEM STARTED 65534 75130 1 0 103 0 139116 49136 - R ?? 24:54.17 dbmail-pop3d nobody 100.0 0.2 1:59PM 65534 75130 1 0 20 0 139116 49136 uwait S ?? 0:00.00 dbmail-pop3d nobody 0.0 0.2 1:59PM [root@mail4-db-4a ~]# procstat -t 75130 PID TID COMM TDNAME CPU PRI STATE WCHAN 75130 101826 dbmail-pop3d - 10 203 run - 75130 102171 dbmail-pop3d - 7 120 sleep uwait Best regards, James Greig -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Reindl Harald Sent: 16 March 2014 14:36 To: [email protected] Subject: Re: [Dbmail] Iphone HTML emails Am 16.03.2014 15:21, schrieb Paul J Stevens: > On 16-03-14 15:02, James Greig wrote: >> Completely appreciate that by me just saying it "won't work" isn't >> helpful :) >> >> Ok. Top in freebsd doesn't have -n1 and -p so the next thing I did >> was move to just using ps >> >> [root@mail4-db-4a ~]# ps Hlauxc -p `pidof dbmail-pop3d` >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> USER %CPU %MEM STARTED >> 65534 74473 1 0 103 0 139116 57488 - R ?? 1:33.86 >> dbmail-pop3d nobody 100.0 0.2 1:17PM >> 65534 74473 1 0 20 0 139116 57488 uwait I ?? 0:00.00 >> dbmail-pop3d nobody 0.0 0.2 1:17PM >> >> As you can see that's the output and you can also see 100.0% CPU at the >> moment. >> >> Am I just awk'in out the normal PID there? > > The idea is to attach the gdb to the busy thread/pid, generate a bt > and get an idea of where in the code the thread is looping. > > On linux each thread/fork gets it's own PID, but apparently on FBSD > things are different. > > I just generalised the backtrace script to work for both imapd and > other processes. > > By default it will look for busy threads on imapd, but you can tweak > the > behavior: > > dumpbt.sh dbmail-pop3d 60 > > will look for pop3d processes eating up more than 60% cpu and generate > a bt for them > > Alas it only works for linux. > > http://git.dbmail.eu/paul/dbmail/tree/test-scripts/dumpbt.sh > > If Harald suffers from the same problem on linux, maybe he can run > this and get a handle on the problem hah i generalized mine last night too :-) i fear the timeouts i showed recently with pop3d growing over a longer run are a different problem, AFAIk i never seen dbmail-pop3d consume that much CPU, no idea what that is, why that grows over time and how top debug that :-( [root@mail:~]$ cat /Volumes/dune/debug/debug.sh #!/usr/bin/bash if [ "$1" != "" ]; then PROTOCOL="$1" else PROTOCOL="imap" fi DAEMON="dbmail-${PROTOCOL}d" cd /Volumes/dune/debug/ rm -f dbmail-debug-*.txt top -H -b -n1 -p `pidof $DAEMON` > dbmail-debug-top.txt MAXCPU=20 # get the PID PID=`pidof $DAEMON` # find busy threads BUSY=`top -H -b -n1 -p $PID|grep 'pool'|awk '{if ($9 > $MAXCPU) print $1}'|head -1` if [ -n "$BUSY" ]; then # generate a gdb commandfile tmpfile=`mktemp` echo 'bt' > $tmpfile # get a backtrace gdb --batch -x $tmpfile -p $BUSY > dbmail-debug-backtrace.$BUSY.txt rm -f $tmpfile fi cat dbmail-debug-top.txt /usr/bin/ls -l -h --color=tty -X --group-directories-first --time-style=long-iso _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
