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
