Roland, Wouldn't it be nice to have a cron job (or even included in Witango itself) that would:
Inspect datasources for their minutes idle. Compare it to the system datasourcelife. If it is greater, kill the datasource. It appears that some ODBC drivers have connection release problems. Wouldn't this solve this particular problem? I have had similar problems. Steve Fogelson internet Commerce Solutions -----Original Message----- From: Roland Dumas [mailto:[EMAIL PROTECTED] Sent: Thursday, March 03, 2005 5:45 PM To: [email protected] Subject: Re: Witango-Talk: Baling wire and duct tape to prevent crashing Unfortunately, even with datasource connections being immortal, the CPU usage for witangod is climbing to 60% and upward. There's something else that's going on in witango that's unhappy. On 3/3/05 11:20 AM, "Roland Dumas" <[EMAIL PROTECTED]> wrote: > Ok, not yet figured out why one machine clone crashes while the other > doesn't, but am trying to patch each part of ODBC without taking production > machine out of service. (It's a very productive ecommerce site) > > What we've figured out: > > When witango gets a hit that requires a connection to mysql, it looks for an > available connection using that DSN. If it's available, it uses it. > > If there are current connections, but they're busy, it spawns another > > A pile of hits at the same moment creates a small stack of data connections. > Up to 8. > > Subsequently, when traffic is slower, witango picks one of the data > connections and lets the others age. Don't know how it picks one vs another, > but that's what it does. That leaves the others aging out and should expire > when they hit the datasourcelife setting. > > That's where the trouble comes. Rather than die, the connections get hung > up, cause CPU usage to jack up, eventually cause new hits to get hung and > the witango server crashes. When they're tied up, they aren't available to > be used, but are technically alive, I guess, because if witango has selected > one of those, visitors get hung up. > > So, after updating this piece and that piece of ODBC, it still does the same > thing and JDBC has its own profile of random crashes. > > So, while we sift though the finger-pointing and terse instructions, we've > jury rigged a way to prevent crashes. > > On another witango server, we've created a cron to hit the sick server every > hour with 8 <@URL>s that each hit a database. That makes sure that the 8 > connection requests are simultaneous and generate 8 connections. The > connections are alive, but aging, these 8 refresh them all. The counter goes > back to 1. > > Then, we set the datasource life to 24 hours. That gives the cron 24 > opportunities to restart the timer on every datasource. > > Seems to be working. > > Net net: if datasource expiry is causing crashes, don't ever let one expire. > > > > > > > ----------------------------------------- > Roland Dumas > Roberts Information Services > 310 W. Bellevue Avenue > San Mateo CA 94402 > 650-347-1373 > 415-412-9300 (cell) > [EMAIL PROTECTED] > SMS: http://new.servqual.com/html/sms.tml > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
