| 00:14.38 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.91.131) |
| 01:42.15 | *** join/#asterisk-dev n0tk (~n0tk@66-193-170-248.static.twtelecom.net) |
| 02:27.16 | *** join/#asterisk-dev moy (~moy@74.12.96.53) |
| 03:09.11 | *** join/#asterisk-dev guilhermebr (~Guilherme@187.113.37.229) |
| 03:12.30 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-75-87-99-1.kc.res.rr.com) |
| 03:21.10 | *** join/#asterisk-dev moy (~moy@74.12.96.53) |
| 03:56.04 | *** join/#asterisk-dev moy (~moy@74.12.96.53) |
| 04:21.49 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 04:32.13 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 04:50.13 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-115-128.ptld.qwest.net) |
| 07:03.07 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 08:17.41 | *** join/#asterisk-dev tiny_D (~tiny_D@mail.snom.com) |
| 08:20.26 | *** join/#asterisk-dev schmidts (d5ebd4c1@gateway/web/freenode/ip.213.235.212.193) |
| 08:20.31 | schmidts | hello all |
| 08:26.40 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:26.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:37.37 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 08:43.34 | *** join/#asterisk-dev drclue (~drclue@ip-65-49-164-42.wireless.dyn.beamspeed.net) |
| 08:43.54 | schmidts | after some testing in the subscribe handling i think there is lot more work to tune this thing |
| 08:44.37 | schmidts | the normal subscribe handling tooks up to 11 ms if there are 500 sip dialogs and raise up to 20ms if there are 1000 dialogs |
| 08:45.55 | drclue | I new there was a reason I do all my asterisk development in real time without reloads |
| 08:47.17 | schmidts | what you mean drclue? |
| 08:48.44 | drclue | Well, I realized some time ago that asterisk can indeed be run in a real time manner and that anything less was a cop out somewhere by someone. |
| 08:49.32 | drclue | Nothing in asterisk itself ever really requires a reload or a re read of a conf file |
| 08:51.33 | schmidts | do you mean reading all configs out of a database? |
| 08:53.46 | drclue | @schmidts No , I mean real time. A database could be used if desired , but asterisk itself really does not need that or a config file or much of anything else and can be run 1000% realtime |
| 08:55.02 | schmidts | i agree, if this asterisk just do call routings, but if it comes to peers you will need some conf files / databse to save this information |
| 08:56.57 | drclue | Just by mentioning the possibilities of a storing to a database means you by that claim require none at all. Asterisk can indeed be 100% real time |
| 08:58.59 | drclue | I already did the 100% realtime dialplan and have made HTML5 connections that convey events so fast that it is hard to tell the difference between an on screen web event and a hard phone's own LED's |
| 09:00.35 | drclue | I'm just intending to merge the two in such a fashion that you could edit and apply dial plan changes during a live call |
| 09:08.55 | drclue | I can do anything in Asterisk I like as it has the abilities to be totally live despite the fact that everone has ignored those abilities |
| 09:12.54 | drclue | Back to coding, as I have to finish the Droid and Iphone specs that let the AsterClick applications run on the web, desktops (linux , windows etc), an dsmartphones using the exact same and totally live code |
| 09:19.10 | schmidts | if you are talking about realtime, have you ever had a look for example at the sip handling how fast this is? |
| 09:21.03 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 11:11.17 | *** join/#asterisk-dev schmidts (d5ebd4c1@gateway/web/freenode/ip.213.235.212.193) |
| 11:11.20 | schmidts | re |
| 11:22.29 | oej | schmidts: I think we could separate so that the subscriptions has its own dialog list and not mix with the rest of the stuff |
| 11:23.17 | schmidts | i am know looking for another way of solving this |
| 11:23.27 | oej | How? I'm curious |
| 11:24.06 | schmidts | when the callback for the notify is set, the list of hints is traversed, maybe i can find a way to search for other callbacks for this peer/context/exten to just replace this |
| 11:25.01 | oej | I was thinking of having one callback per exten instead of one per sub at some point |
| 11:25.21 | oej | I looked into this years ago |
| 11:25.26 | schmidts | ;) |
| 11:25.27 | oej | I wanted to simplify the callbacks |
| 11:25.34 | oej | And then move the subs out of the dialog list |
| 11:25.52 | oej | If you have 1000 subs and 1000 regs and calls, it's stupid to traverse the same lists |
| 11:26.13 | oej | But now we have hash tables, so I imagine the list lookup is faster and maybe not a bottleneck any more |
| 11:26.14 | schmidts | i know this its the real slow thing on the subscribe handling |
| 11:26.49 | schmidts | looping through the dialogs in the ao2 container is the slow thing, maybe we are talking about different things? |
| 11:27.05 | oej | Is it not a hash table then? |
| 11:27.12 | oej | I haven't worked much with trunk code. |
| 11:27.28 | oej | It used to be a SLOW linked list |
| 11:27.57 | schmidts | http://www.asterisk.org/doxygen/asterisk1.6.2/chan__sip_8c-source.html#l21683 this is what i mean |
| 11:28.53 | oej | Oh, i was hoping that code was gone by now. That's awful. |
| 11:29.14 | schmidts | ;) |
| 11:29.42 | oej | What's the cost of creating a separate list of just the subs, indexed on username, exten and context |
| 11:30.28 | oej | I think the assumption on line 21678 is wrong |
| 11:30.36 | oej | It's better to just let it expire |
| 11:30.51 | schmidts | nope ;) i´ve tried this |
| 11:31.16 | oej | But this code is wrong. You can't delete a sub with another call-id just because it looks the same |
| 11:31.51 | oej | Could be another phone with the same account |
| 11:32.14 | schmidts | if there are several subscribes with other call-ids without this part which traverse the dialogs, a notify for every subscribe is send |
| 11:32.25 | schmidts | ok, i didnt know this |
| 11:33.38 | oej | We should propably just delete that part of the code. Or have an option to enable/disable it, because to me it seems pretty useless. |
| 11:34.05 | schmidts | ok |
| 11:34.08 | oej | A phone re-subscribes with the same call-id. If not, it's rebooted or we told it that the sub is cancelled from server side. |
| 11:34.44 | oej | Anyway, if that traversal is your issue, just disable it and see what else you find in your search for bad code :-) |
| 11:35.17 | schmidts | if done some time compares for this, and its real bad time waste there |
| 11:35.37 | oej | Oh, I understand that. |
| 11:35.45 | schmidts | 100 subscribes it tooks around 3 to 4 ms, 500 subscribes 11 to 13 ms, 2500 subscribes up to 40ms |
| 11:35.48 | oej | I think that it only handles corner cases |
| 11:36.03 | schmidts | on each subscribe i mean |
| 11:36.04 | oej | And if you have subscriptions hanging, they will time out |
| 11:36.19 | oej | 40 ms per subscription and 2500 subs, that's a lot of time. |
| 11:36.37 | schmidts | yes |
| 11:39.21 | schmidts | in this time, no incoming packages are read and no scheduled event is fired, so everything breaks down |
| 11:46.13 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 11:52.19 | *** join/#asterisk-dev fazendeiro (~chatzilla@200.249.86.178) |
| 11:53.15 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:53.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:59.27 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:59.27 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:04.55 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:04.55 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:11.34 | schmidts | without this traversing through the dialog list subs took from 300 usec at around 100 subs, up to 1500 usec with 2500 subs, so 10x times faster |
| 12:12.00 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 12:18.58 | oej | Wow. |
| 12:19.06 | *** join/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 12:19.51 | *** join/#asterisk-dev felipe_ (~felipe@my.nada.kth.se) |
| 12:20.58 | schmidts | i can subscribe 2500 subs with a call rate of 50 per second without any problem |
| 12:23.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:23.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:23.40 | snuff-home | mornin kp |
| 12:24.23 | kpfleming | morning indeed |
| 12:24.36 | kpfleming | kde 4.5 was a little unhappy this morning, so i hit it over the head |
| 12:24.56 | jsmith | kpfleming: "The beatings will continue until morale improves?" |
| 12:25.24 | kpfleming | exactly |
| 12:45.51 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 12:46.00 | schmidts | back |
| 12:46.25 | schmidts | olle do you know what RFC said to subscribes and call-ids? |
| 12:46.48 | schmidts | would it be an rfc violence to keep this subscribes? |
| 12:56.46 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 13:13.29 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.114.173) |
| 13:21.48 | *** join/#asterisk-dev otherwiseguy (~terry@75.87.99.1) |
| 13:22.19 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:35.19 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-75-87-99-1.kc.res.rr.com) |
| 13:39.35 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 13:43.00 | *** join/#asterisk-dev pabelanger (~pabelange@2607:f2c0:a000:166:218:f3ff:fe51:c71) |
| 13:55.35 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 14:18.40 | *** join/#asterisk-dev frawd (~francois@81.38.142.65) |
| 14:24.36 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.111) |
| 14:29.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:29.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:42.46 | schmidts | Wohoo |
| 14:43.09 | schmidts | 20015 sip peers [Monitored: 20000 online, 0 offline Unmonitored: 15 online, 0 offline] |
| 14:43.28 | schmidts | 6248 active SIP dialogs |
| 14:43.40 | *** join/#asterisk-dev Dovid (Dovid@213.8.118.62) |
| 14:43.46 | schmidts | rasterisk -x"core show channels count" |
| 14:43.51 | schmidts | 122 active channels |
| 14:44.01 | schmidts | and the very best of all |
| 14:44.05 | Dovid | can anyone help me look at the bt and figure out why asterisk took a dump ? http://pastebin.ca/1931153 |
| 14:44.12 | schmidts | load average: 0,26, 0,21, 0,12 |
| 14:44.17 | jsmith | schmidts: Nice! |
| 14:44.21 | schmidts | and i forget this: 4984 active SIP subscriptions |
| 14:44.44 | Dovid | (trying to learn here) I see that it was res_musiconhold and in the full log just before the crash a call was parked. |
| 14:47.27 | schmidts | ole i have asked klaus how kamilio handle this subscribes and if it doenst have a Totag i just would create a new subscribe and let the old one just expire |
| 14:51.00 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:51.00 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:56.50 | schmidts | if i use sipp a little bit slower, just 15 calls per second and wait for 25 seconds until i send the bye the load is around 0,30 with 375 concurrent calls |
| 14:58.00 | schmidts | received 2982 notifys in time, only 18 got lost |
| 15:04.42 | schmidts | this causes a max amount of traffic 5mbit incoming and 10 mbit outgoing with average 450 sip packets per second |
| 15:06.17 | schmidts | i will post this subscribe patch tomorow |
| 15:07.55 | schmidts | cya tomorrow |
| 15:12.42 | *** join/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 15:12.54 | *** join/#asterisk-dev drclue (~drclue@ip-65-49-164-42.wireless.dyn.beamspeed.net) |
| 15:40.50 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.12.183) |
| 15:43.37 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:43.41 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 15:58.04 | *** join/#asterisk-dev ebroad (~EB@72.11.213.195) |
| 16:19.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:19.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:33.31 | *** join/#asterisk-dev tiny_D (~tiny_D@e178233242.adsl.alicedsl.de) |
| 16:34.39 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:34.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:41.22 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:02.09 | Kobaz | pbx 10559 47.9 9.2 213508 190972 ? Rsl 08:03 142:33 /usr/sbin/asterisk -U pbx -g |
| 17:02.25 | Kobaz | i have an asterisk thread that sucking up a bunch of cpu |
| 17:02.31 | Kobaz | how do i find out what the actual thread is? |
| 17:02.47 | *** join/#asterisk-dev tiny_D (~tiny_D@e178233242.adsl.alicedsl.de) |
| 17:03.01 | Kobaz | it's chewing 47.9cpu and it's been going for 8ish hours |
| 17:04.57 | Kobaz | so i'm wondering how to map the thread id in core show threads, so some sort of thread info i can get from ps |
| 17:09.45 | tzafrir | Kobaz, strace -p PID_OF_THAT_THREAD |
| 17:09.54 | Kobaz | hmm |
| 17:10.02 | Kobaz | will that kill anything? |
| 17:10.20 | tzafrir | you can kill the whole process, not a specific thread |
| 17:10.49 | Kobaz | well |
| 17:10.52 | Kobaz | it's a production system |
| 17:11.00 | Kobaz | i dont want to kill anything or disrupt something |
| 17:11.14 | Kobaz | how do i know the process id of the thread |
| 17:11.34 | Kobaz | core show threads gives me ids like 0xb69f5b70 |
| 17:11.40 | Kobaz | i cant get anything like that out of ps |
| 17:12.59 | anonymouz666 | anyone care to explain what is "dahdi fax buffer transmit policy"? |
| 17:13.09 | Kobaz | is the thread pid the LWP column? |
| 17:17.29 | Kobaz | i guess it is |
| 17:17.45 | jpeeler | Kobaz: i've run into this problem before too and i think that i used top with threads on and matched it up to the LWP, which i could only manage to get by watching the thread creation output while running under gdb |
| 17:18.17 | jpeeler | i wish i did know a way to translate the core show threads output |
| 17:20.37 | Kobaz | you can't get the lwp when the thread spawns in asterisk? |
| 17:21.19 | tzafrir | Kobaz, in 'top' press 'H' (shift h) |
| 17:21.43 | Kobaz | yeah you can get the lwps |
| 17:21.49 | Kobaz | you can do that in ps too |
| 17:21.55 | Kobaz | but mapping lwp to thread it |
| 17:22.17 | Kobaz | is it a system call somewhere to get the lwp of the thread when it's spawned? so core show threads can show it |
| 17:26.10 | Kobaz | http://pastebin.ca/1931267 |
| 17:26.20 | Kobaz | thats the thread that's sucking up bunches of cpu |
| 17:27.15 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 17:27.23 | Kobaz | it doesnt seem to be doing much |
| 17:32.49 | Kobaz | ping is worthless |
| 17:32.50 | Kobaz | er |
| 17:33.05 | jpeeler | i'm about to submit a review to include lwp in core show threads output |
| 17:33.12 | Kobaz | very nice |
| 17:33.19 | jpeeler | of course this doesn't help you now |
| 17:33.21 | Kobaz | hehe |
| 17:34.50 | Kobaz | 18802 pbx 20 0 237m 215m 7164 R 93.9 10.7 153:24.44 /usr/sbin/asterisk -U pbx -g |
| 17:34.57 | Kobaz | i don't know what the heck it could be |
| 17:35.03 | Kobaz | there's just 4 channels barely doing anything |
| 17:35.07 | Kobaz | just bridged to other channels |
| 17:35.17 | Kobaz | no transcoding being done either |
| 17:36.01 | Kobaz | although strace only shows system calls... i might be stuck in some cpu hogging loop |
| 17:36.08 | Kobaz | s/i/it |
| 17:41.35 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 17:41.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:53.09 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 18:03.12 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 18:19.52 | *** join/#asterisk-dev drclue (~drclue@ip-65-49-164-42.wireless.dyn.beamspeed.net) |
| 18:20.37 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 18:37.50 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 18:37.50 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 18:52.40 | *** part/#asterisk-dev drclue (~drclue@ip-65-49-164-42.wireless.dyn.beamspeed.net) |
| 18:58.28 | *** part/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 19:05.21 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 19:05.21 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 19:13.42 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 19:40.41 | *** join/#asterisk-dev mpe_ (~mpe@65.161.206.209) |
| 19:42.34 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 19:42.34 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:43.35 | *** join/#asterisk-dev jdoe_ (jdoe@falseprophet.ca) |
| 19:52.35 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:52.35 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:17.33 | Kobaz | jpeeler: thanks... i put your patch in... i had to do a little twiddeling to port to 1.6 |
| 20:18.40 | jpeeler | cool, well hopefully soon it'll be put in officially |
| 20:22.34 | Kobaz | [Sep 2 16:22:12] ERROR[1862]: app_dial.c:1901 dial_exec_full: Could not stop autoservice on calling channel |
| 20:22.38 | Kobaz | is that bad? |
| 20:34.23 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@75-92-150-245.war.clearwire-wmx.net) |
| 20:35.15 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@75-92-150-245.war.clearwire-wmx.net) |
| 20:52.13 | *** join/#asterisk-dev ahowlader (howlader@180.234.37.227) |
| 21:39.24 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:39.24 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:04.51 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@75-92-150-245.war.clearwire-wmx.net) |
| 22:45.12 | *** join/#asterisk-dev Greek-Boy (~Greek-B0y@41.188.154.137) |
| 23:14.01 | Kobaz | boodu: analog vs digital |
| 23:14.04 | Kobaz | er |
| 23:17.22 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |