[asterisk-users] HP DL360 G5 better than HP DL360 G7 ?

Tom Browning ttbrowning at gmail.com
Sun Jul 22 22:56:19 CDT 2012


I think I may have found the issue affecting our HP DL360 G7s (but I
don't begin to understand why this problem does not happen on our HP
DL360 G5 with a slower disk subsystem).

Recap:  Running tcpdump on SIP UDP along with Asterisk 1.8.* causes
Autodestruct ... owner in place ... BYE messages when running on our
new G7 servers (generally once the box has more than 100 B2BUA calls
up and running).

Items that had no effect:  updated firmware, later versions of
Asterisk 1.8.* (we are running 1.8.7.0, later versions crash after
half a million calls), enable/disable PAE kernel, tune/adjust AGI
script to make sure end-of-call processing is always fast (hi-res
timers confirm).

I was even able to reproduce the problem using SIPp to generate a high
call rate with no RTP (SIP signalling only).

Reading all the various threads on Autodestruct ... BYE messages, I
found the thread about using radius and having a non-responsive radius
server causing the CDR process to delay and generate this message.
I'm NOT using radius, and the only Asterisk CDR processing I have
enabled is the out-of-the-box CSV file.  On a hunch, I disabled CDR
processing completely in cdr.conf ([general] enable=no) and now the
Autodestruct messages are gone.  I've even pushed the load to twice
the normal peak and still no Autodestruct complaints.

It would appear for whatever reason, there was some delay/blocking
writing CDRs to the csv file?

I do still see channels that appear stuck in "Rx: BYE" state and that
must be related to other possibly resolved bugs in after 1.8.7.0?
(And I do see those as well on the DL360 G5 boxes that just seem to
run with no issue).

Next step will hopefully to get the latest 1.8.current up and running
(as long as it doesn't crash like 1.8.12.2 has with the same traffic).



More information about the asterisk-users mailing list