"Stephen Gutknecht (SAPDB)" schrieb: > > More analysis... > > I am slowly coming to the conclusion that SAPDB's network protocol concerns > aren't just with the ODBC driver. > > We have basically seen two things going on: > > 1. With three physical machines, two SAPDB servers and one client, the ODBC > driver tends to get "Hung up" if one of the servers is slow to respond - > resulting in the client getting stalled. > > 2. A slow client stall can hang the SAPDB vserver, resulting in a denial of > service against the entire SAPDB server. > > We ran for 18 months with SAPDB on the same server as the application. We > needed more memory for both, so went with two separate machines, one > dedicated to SAPDB and the other to the application. The third server is > also SAPDB and used for our largest table to ensure fast response. > > This configuration has turned out to perform horribly. At least with our > dotNet applications on Windows 2000. > > I had been blaming it all on the ODBC driver, and reported a crash after it > deadlocks (see previous list post). However, researching vserver on the > list, I'm now alerted that the problem may not just be with the ODBC driver, > but with the VSERVER's blocking behavior when there is a unresponsive > client. We sort of have a catch-22 here! > > Searching list archives, messages of interest: > > October 12, 2001 -- Christian Jung -- [tcpip problems] "Currently you have > to stop the whole vserver and all the instances running on it and restart > all. That's not good in a production-system! Is there another solution?" > > May 14, 2002 -- Thomas Markus -- [after running a loop of SQL activities] > "after some times I can't connect. The program tries to connect and no > message and no error comes up. I tried to connect with xsql and xload with > same effect. The only way to kill the client is a hard kill. The processes > under vserver are still exists. The only way to connect is via dbmcli with > user dbm. I can't drop that user devel. Restarting DB has no effect. The > only solution is to drop the DB and to recreate." and later follow-up > "autolog is on, i tried both > i can't connect with any client (problem is not limited to jdbc calls)" > > May 29, 2002 - Joerg Mensing @ SAP -- [in response to Thomas Markus > detailing that a lock seems to hang the entire SAPDB server if a client does > not release it] "The communication between SAPDB kernel and clients follows > a pure ping-pong principle. Each request must have an answer before the next > request can be send. Unfortunately the vserver process - while waiting for > SAPDB answer - was blocking itself on a semaphore. This did not allow him to > watch the status of the socket at the same time." > > Note that the problem being discussed here isn't just the TABLE being > locked, but all TCP/IP client requests being blocked! > > Our short term solution > ======================== > We have found the ODBC driver + xserver / vserver performance to be poor > enough that we ended up hacking an emergency solution. We put a dotNet > application directly on the SAPDB server and had it do a _local_ query > against the SAPDB system, then return the results to the other server over > HTTP. > > Almost like developing our own XML daemon for SAPDB. > > Then we moved the smaller database back onto the same machine. Things are > now running much better... but this configuration limits our growth due to > the shared RAM and I/O usage of both our application and the SAPDB. > > Our ultimate plan was to move our dedicated SAPDB servers from Windows 2000 > --> Linux. From what I understand, the xserver/vserver is forked instead of > multithreaded. Is it better?
I strongly recommend trying it. It's an easy way to find out whether your problem comes from a Windows specific implementation or it's a 'feature' of SAPDB in general. Simon > > Regards, > > Stephen Gutknecht > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
