Summary:ASTERISK-17294: [patch] high iowait due to ast_db_put of realtime peers
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2011-01-27 03:32:32.000-0600Date Closed:2011-02-10 13:28:49.000-0600
Versions:Frequency of
is related toASTERISK-18446 chan_sip rtcachefriends=no loads fullcontact, but doesn't store it, except in astdb
Environment:Attachments:( 0) issue18687_no_ast_db_put_for_rtpeers.patch

on an asterisk 1.6.2 server, I receive lots of REGISTERs (around 20 packets per second). For every (succesful) registration, it seems to be writing a new astdb. This causes an unnecessary disk load. (It writes a new blob of astdb data 10 times per second.)

As I understand it, there is no reason to store these realtime peers in the astdb as the needed info is already in the SQL db.

I've patched asterisk to not do that, and I haven't noticed any adverse effects after two weeks.

Walter Doekes


Related IRC log:

20:46 < wdoekes2> is there a reason why rtcachefriends must be set for the
fullcontact to be stored in the sipreg table?
20:49 <@Corydon76-home> wdoekes2: No, it's probably more of a question of
whether the realtime table exists or not
20:50 <@Corydon76-home> I'm trying to think of a scenario where you
wouldn't want it stored, and I'm coming up with nothing
20:51 < wdoekes2> the whole thing was added here
20:51 < wdoekes2> https://issues.asterisk.org/view.php?id=4832
20:52 < wdoekes2> I come up blank too. and I wonder if the lack of
fullcontact setting is why asterisk is still writing anything to astdb
20:53 <@Corydon76-home> No, Asterisk is writing stuff to astdb for restart
reasons when Asterisk has no realtime
20:54 < wdoekes2> but the bulk of the astdb is sip registrations, which
should be in the realtime db
20:55 <@Corydon76-home> You're ignoring that realtime is optional
20:56 < wdoekes2> not in my case.. I only have a handful static peers.
20:56 < wdoekes2> I'm wondering this because I have 10% iowait on my box
20:57 <@Corydon76-home> That's fine, but breaking Asterisk for people who
aren't using realtime is not an option
20:57 < wdoekes2> hehe, I wasn't intending on doing that. but is it
necessary to store realtime-loaded peers in the astdb?
20:58 <@Corydon76-home> Current Asterisk doesn't sync() after every store
to astdb, so it should be less of a problem now
20:58 -!- guilhermebr [~Guilherme@] has quit [Quit: Leaving]
20:58 <@Corydon76-home> Well, storing it in astdb will allow the peer to
continue to work when the external realtime DB is down
20:59 <@Corydon76-home> but I agree that that seems like an admin decision
21:01 < wdoekes2> I think I'll get rid of the ast_db_put if I enable
rtcachefriends.. but I don't believe I need the peers cached in memory
21:01 <@Corydon76-home> Actually, it would probably be better if you just
removed it if the peer realtime flag is set
21:02 <@Corydon76-home> Even when cachefriends is off, the value should be
reliable in the DB
21:02 <@Corydon76-home> but only if it's a RT peer
21:03 < wdoekes2> right. that sounds like a plan. thanks
21:09 <@Corydon76-home> wdoekes2: One of the items on the TODO list (but
it's a very involved patch) is to make SIP work correctly such that
rtcachefriends becomes
                       completely superfluous
21:10 <@Corydon76-home> Devicestate seems to be the only reason to keep a
peer in memory, but even that could be abstracted in a way to avoid the
21:11 <@kpfleming> devicestate is now handled via the event framework, so
there shouldn't be a reason to keep the peer around for that
21:11 <@Corydon76-home> Right, okay
21:11 <@Corydon76-home> Basically, the whole thing grew organically and
we've never actually gotten around to eliminating the unnecessary parts
21:12 <@kpfleming> indeed
21:12 <@kpfleming> that's how things happen when they aren't designed up
front :-)
21:13 <@Corydon76-home> kpfleming: Anybody designing SIP would have a
brain aneurysm in the process

(Actual patched version is, but this hasn't changed since.)
Comments:By: Leif Madsen (lmadsen) 2011-01-31 14:03:06.000-0600

Thanks for the patch!

By: Russell Bryant (russell) 2011-02-10 13:28:49.000-0600

In Asterisk 1.8 (I think, definitely trunk) the load of astdb has been significantly reduced.  It was previously doing an fsync() on every db modification.  It now rate limits them.