On Thursday 25 October 2007 06:06:37 Tobias Engel wrote: > When there are about 100 parallel connections to asterisk (1.4.11, btw), > all leaving voicemails, the peformance becomes really abysmal: > Connections take over a minute before they are even accepted, etc. > > Since this does not happen when just using realtime for the voicemail > config, but storing the messages itself on the local harddisk, I assumed > some db (Oracle) or ODBC bottleneck (the CPU usage never goes over 20%). > But a few hundred added debug statements and some tcpdump sessions > later, to my surprise I found out that most of the time is spent waiting > for a lock on the "users" list in "find_user".
We could probably fix this by switching over to using rwlocks. > So far I couldn't find out why this only happens with ODBC message > storage, but since this users list is - as far as I can see from the > source - unused when using realtime, do I even need this lock? You do, to avoid a possible race condition with using the data versus the data being destroyed on a reload. > When the user data is fetched from the db, the operation should be > atomic - either it's there or it's not there, right? It is, but the data transfer is not atomic -- it takes time to process each column. > So do you think it is safe to remove the AST_LIST_LOCK call for realtime > usage? Definitely not. But as above, you could convert it to rwlocks. You'd just have to make sure that there are no recursive locks, because rwlocks do not support recursive locks. > And does anybody have any insights on these performance issues? (I also > found out that it takes sometimes up to 6 seconds from the SQLExecute > call in res_odbc until the call is really forwarded to the database - > but I assume this is an ODBC issue) It's probably another lock that is not exposed to the interface. You might post a note to the UnixODBC list, looking for an answer to that. -- Tilghman _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
