2 Replies Latest reply: Aug 11, 2010 2:29 AM by Mats Ulvedal RSS

    CPU usage

    Mats Ulvedal
      Hi all,
      It seems that SALT uses a lot of CPU, we have done some test and then we could see that, and if heavily loaded we get some stuff in ULOG.

      We test with one VB client who makes a request to the same service 1000 time, the server (with the service called) then used 7% of CPU and GWWS used 55% CPU.

      If we used 3 VB client as above then the server used 15% of CPU and response time are a bit higher and GWWS use 80-95% of CPU.
      And ULOG had the following error messages.

      More than 10 threads
      120522.u30907!GWWS.3369.1.0: LIBTUX_CAT:582: ERROR: Unable to register, registry table full

      DESCRIPTION
      The TUXEDO System was attempting to find a registry table slot for a process, but the registry table was full.
      ACTION
      Increase the MAXACCESSERS parameter in the UBBCONFIG file, rebuild the TUXCONFIG file, then reboot the application and try again.


      More than 5 threads
      120541.u30907!gwks001.3375.1.0: LIBTUX_CAT:1285: WARN: tpreturn message send blocked, will try file transfer

      DESCRIPTION
      A server process encountered a message queue blocking condition when returning a message to the client via tpreturn ().
      ACTION
      The system will automatically attempt to return the message using a temporary file. Performance may be degraded if this occurs frequently. Check the kernel parameters related to message queue size, and increase them if necessary.


      When reply buffer bigger than 300 kb:

      111402.u30907!GWWS.9803.26.0: GWWS_CAT:109: ERROR: HTTPS error: Connection sending fails. Errcode = SSLIOErr.

      DESCRIPTION
      GWWS's HTTPS connection error occurs.
      Action
      If it is an occasional receiving error, it may be caused by heavy load. If it is another error type or the error happens continuously, check configuration, certificate files and network status.

      Now I try to form a question about the CPU usage,

      Is this normal or known behavior in current version?

      And can some help us with the error in the ULOG, what can we change in configuration, code and kernel?

      Regards
      Mats
        • 1. Re: CPU usage
          Todd Little-Oracle
          Hi Mats,

          The answer to your question about CPU usage is a little difficult. It is largely going to depend upon the complexity/size of the SOAP request and to a lesser extent the complexity/size of the SOAP response. XML processing is EXPENSIVE! This is why we see so few Tuxedo applications using XML because the parsing time for the XML is often greater than the processing time of the service.

          The solution for LIBTUX_CAT:582 is as the documentation says, increase the MAXACCESSERS value in the UBBCONFIG.

          The solution for LIBTUX_CAT:1285 is to increase the size of the IPC queues on the underlying OS, if possible. Basically what happened was a server called by the GWWS tried to place a reply message on the GWWS reply queue and found that it would have made the queue more than 75% full. So to ensure that message can still be returned to the GWWS, Tuxedo spools the message to disk and then places a much smaller message in the reply queue indicating where the message can be read on disk. Obviously this can cause a huge performance hit and should be avoided if at all possible.

          For the GWWS_CAT:109 error, I would open a support case as that sounds like either a problem with the GWWS SSL code or an undocumented limitation, although these are just guesses. Oracle Customer Support should be able to give you better answers.

          Regards,
          Todd Little
          Oracle Tuxedo Chief Architect

          PS If you are dealing with 300kb messages, the SOAP/XML processing is going to be significant.
          • 2. Re: CPU usage
            Mats Ulvedal
            Hi Todd,

            thanks, we did increase the MAXACCESSERS value with no difference, obviously not enough or the problem is somewhere else.
            We will test more, and yes I will create a case of the last one.

            See you in SF.

            Regards