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? Regards, Stephen Gutknecht _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
