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-0600 | Date Closed: | 2011-02-10 13:28:49.000-0600 | ||
Priority: | Minor | Regression? | No | ||
Status: | Closed/Complete | Components: | Channels/chan_sip/DatabaseSupport | ||
Versions: | Frequency of Occurrence | ||||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) issue18687_no_ast_db_put_for_rtpeers.patch | |||
Description: | Hi, 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. Regards, Walter Doekes OSSO B.V. ****** ADDITIONAL INFORMATION ****** 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@200.103.96.98] 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 necessity 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 1.6.2.14-rc1, 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. |