You might want to check how many licenses/concurrent sessions are allowed to...
It sounds like to me if you're getting deadlocks they're coming from writing to the table not reading though.
From: Warwick Burrows <[EMAIL PROTECTED]> Reply-To: "Slide Users Mailing List" <slide-user@jakarta.apache.org> To: 'Slide Users Mailing List' <slide-user@jakarta.apache.org> Subject: RE: Performance issues, Slow Downs Date: Mon, 3 Jan 2005 18:03:08 -0800
Jeff,
Excuse my ignorance but what are the clustered indexes you mention creating on certain tables? I'm hitting -911 database errors (deadlocks and or lock contention timeouts) with the Slide 2.1 release and am trying to find out how to improve Slide's DB2 table access performance.
Thanks, Warwick
> -----Original Message----- > From: J H [mailto:[EMAIL PROTECTED] > Sent: Monday, January 03, 2005 6:20 PM > To: slide-user@jakarta.apache.org > Subject: RE: Performance issues, Slow Downs > > > I just sent a different response on my performance > enhancements to date, but > I'm still stuck on > one thing.... > > Thanks in advance for any input! > > After we do PROPFINDS or SEARCHES for about 5 minutes with > around 16-20 > clients our system becomes very unresponsive for around 30 > seconds to a > minute. The responses normally come back in about 1 seconds > or less and the > response time does not DEGRADE until we see the first slow > down. Tomcat > seems to 'recover' from this slow down, but it's very > annoying to teach my > users that sometimes a query screen will show up in a second > and other times > they may have to wait until up to a minute!! After it > returns from a minute > response time, responses go back to normal. > > I have done about all the diagnostics I can think of.... > > MSSQL Server (2 CPU System) never goes above 50% > The Tomcat 4.1.27 Process (on a 4 cpu system) uses up to 100% of all > processors in slow periods and only about 75% maximum during > the normal > quick state. > We are using IIS to parse and send XMLHttp Requests, but this > doesn't seem > to be the problem (DLLHOST.exe isn't using much cpu power). > Using the java tags -Server -Xmx1380M -Xms1380M We have > created clustered indexes on the appropriate tables. I have > reviewed the Garbage collection and it says that the maximum time it > ever spends doing garbage collection is 1/2 second, with a > total of 14 > seconds over a 3 minute span. One thing odd is that it says > it's collecting > over 40GB!! of data. > > Any Advice or Hints would be GREATLY appreciated!! > > Jeff > > > >From: Pontus Strand <[EMAIL PROTECTED]> > >Reply-To: "Slide Users Mailing List" <slide-user@jakarta.apache.org> > >To: "Slide Users Mailing List (E-mail)" > <slide-user@jakarta.apache.org> > >Subject: Performance issues > >Date: Mon, 3 Jan 2005 12:03:46 +0100 > > > >Hello, > > > >There has been some talk about performance issues previously on this > >list and I would like to return to a couple of them as they are > >relevant to my current project. Let me begin by describing our setup. > > > >All files will be stored in a file system, most likely > UNIX-based, and > >all other data will be stored in a database, MySQL or > possibly Oracle. > >All access to Slide is done via a RMI-server that uses the > Slide WebDAV > >Client. So far we have used 2.1rc1 and before that 2.1b2. > > > >The system that we are developing should be able to handle tens of > >thousands > >of files, if not hundreds of thousands. At this point, after > having run > >various tests, we're quite concerned about Slide's performance. > > > >Let us begin with the famous OutOfMemoryException-problem. Disabling > >the cache only delays this issue, leaving us with the option to > >increase the memory size for the JVM. Has anyone looked into > it memory > >leaks related to inserting new documents? Has any changes > been done to > >that code since 2.1rc1? We would be willing to look into it, > but at the > >moment we are hard pressed by a looming deadline so we can't > allocate > >resources to that problem right now. We are going to "solve" the > >problem with an intermediate solution > >consisting of: > > > >1) Increase the JVM memory size > >2) Modify the cache settings > >3) Make sure that Slide is restarted frequently > > > >The second issue we are having right now is that we see a linear > >increase > >in > >the time it takes to add files to Slide. I saw an earlier post where > >someone > >who put 2000 files in a collection ran into to problems and > that he/she was > >discouraged from having such large collections. And I > believe that our > >problem is related to this. However, we have tried to remedy > the problem by > >creating a new collection every 500 files. This resulted in a small > >performance benefit but file 501 still took longer time to > add than the > >first file. We have the following questions: > > > >- Is there an optimal maximum size for a collection? > >- What is the best way to add large number of files? Does > SLIDE treat > >collections differently from files in terms of performance? > >- How would one go about adding large number of files to > Slide without > >having to wait unreasonably long for document inserts? > > > >Best regards > >Pontus Strand > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
