OMI server configuration and problems

2002-05-07
2002-05-08
  • James A Self

    James A Self - 2002-05-07

    We have started using GTM and OMI to serve DTM multi-user clients as a major step in making a smooth transition to GTM for our hospital information system running on a distributed DTM network. We had hoped simply to gain a better position for developing functionality in GTM that could gradually replace our DTM based applications, but it appears that we have achieved better overall performance as well.

    However, we have found that OMI server processes grow in memory size over time and some variations in the specification and location of global directories and data files will result in rapid process growth and loss of performance.

    In particular, we ran into serious problems when referring to the global directory with a symbolic link or a simple filename relative to the default directory instead of a complete path. This resulted in noticieable performance degradation within minutes and 200KB/sec growth of the server process.

    We have seen the server process exceed 100MB within a day even when we used a complete path to specify the global directory and did not experience significant performance loss. We have tried running one OMI server process for all clients and one server process per client. Running one server per client seems to consume memory more quickly

    Have you seen this memory leak? Can you give us any guidelines or tips for configuring OMI?

     
    • Steven Estes

      Steven Estes - 2002-05-07

      Hi Jim. To be honest with you, we are OMI-challenged. We have an old testcase written in antiquity that we use to test basic function but nothing along the lines of performance testing or tuning is done. What you describe sounds like a memory leak of some kind that our test program would not be able to detect. If you can send us a test case (simpler the better) that demonstrates the problem we have some tools we can use to hopefully track down the leak and at least get a fix to you that you can do a build with. It may be awhile before it appears in a regular release as we are right near the end of one cycle and starting a new one. Hope this helps..

      Steve

       
    • Steven Estes

      Steven Estes - 2002-05-08

      Hi Jim. Your description of problems using symbolic paths rang a bell with some folks here. There was a problem introduced in V4.3-000 where extended references that contained environment vars (symbolic refs) caused a memory leak that when heavily used would cause the process to eventually run out of memory. The fix is a new dpgbldir.c module which I will send you under another cover. The OMI server sends stuff through the same path extended references in M code go through so it seems likely to be the source of (the bulk of) your troubles. If you redo a build with this fix and there are still problems, please let us know..

      Steve

       
      • James A Self

        James A Self - 2002-05-08

        Steve,
        Thanks for the fix and for being so responsive. We are eagerly awaiting V43001.

        I do want to emphasize that OMI is working great for us. This fix should make it better. Ed Clubb noticed that the path to the global directory specified on the OMI client is included in every global reference  transmitted so minimizing that could have a significant effect on the volume of OMI network traffic.

         
    • Steven Estes

      Steven Estes - 2002-05-08

      As a shortcut and more general audience, here is the delta between the V43000 version and the (soon to be released) V43001 version:

      *** /usr/library/V43000/src/dpgbldir.c  Mon Nov 19 19:16:12 2001
      --- /usr/library/V43001/src/dpgbldir.c  Fri Apr 19 21:01:05 2002
      ***************
      *** 11,16 ****
      --- 11,18 ----
       
        #include "mdef.h"
       
      + #include "gtm_string.h"
      +
        #include "gdsroot.h"
        #include "gtm_facility.h"
        #include "fileinfo.h"
      ***************
      *** 82,95 ****
                      tran_name = get_name(&v->str);
              gd_ptr = gd_load(tran_name);
              name = (gdr_name *)malloc(sizeof(gdr_name));
      !       if (name->name.len = v->str.len)
      !               name->name = *tran_name;
      !       else
      !       {       /* free up memory allocated for mstr and its addr field in get_name */
      !               assert(tran_name->len);
      !               free(tran_name->addr);
      !               free(tran_name);
              }
              if (gdr_name_head)
                      name->link = (struct gdr_name *)gdr_name_head;
              else
      --- 84,99 ----
                      tran_name = get_name(&v->str);
              gd_ptr = gd_load(tran_name);
              name = (gdr_name *)malloc(sizeof(gdr_name));
      !       if (name->name.len = v->str.len)        /* Note embedded assignment */
      !       {
      !               name->name.addr = (char *)malloc(v->str.len);
      !               memcpy(name->name.addr, v->str.addr, v->str.len);
              }
      +       /* free up memory allocated for mstr and its addr field in get_name */
      +       assert(tran_name->len);
      +       free(tran_name->addr);
      +       free(tran_name);
      +
              if (gdr_name_head)
                      name->link = (struct gdr_name *)gdr_name_head;
              else

       

Log in to post a comment.