Roland,

What version and build of Witango are you using?

Chuck Lockwood
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LockData Technologies, Inc.                  
309 Main Avenue, Hawley, Pa 18428          
570-226-7340 ~ Fax: 570-226-7341    
[EMAIL PROTECTED] ~ www.lockdata.com                   
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-----Original Message-----
From: Roland Dumas [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 03, 2005 6: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

Reply via email to