Memory leak on ASP.NET web site

Discussion in 'ASP .Net' started by Jon Davis, Jun 4, 2004.

  1. Jon Davis

    Jon Davis Guest

    OK I have a web app that I built that makes MANY calls to the DB in each
    request. The app wasn't tuned for scalability so this wasn't a problem, but
    time is too short to redesign how the database is accessed because the data
    that's being stored is time relevant and the web app will be thrown out in a
    few months. Since I try to separate the OleDb stuff from the business logic,
    I just create new database connections and trust that those connections will
    be closed and expunged when the response ends.

    But I'm finding that between SQL Server and IIS the machine is quickly
    running out of RAM, even when the session (where I'm caching data in a
    custom user object) terminates. After 20 or so page hits (containing several
    database hits per page hit) the server loses like 600MB or RAM. I wouldn't
    care since the access load is trivial, except that this RAM is NEVER
    re-gained. Resetting SQL Server returns about 200MB and then resetting IIS
    returns about 400MB. Again, this is long after the sessions have terminated.
    And I host nothing in the Application collection.

    Am I wrong in my understanding that database connections automatically close
    and are destroyed when the containing object destroys itself (when the web
    page's response ends)?

    I have tried forcing all new database connections to be kept in an ArrayList
    in Global and then go through the ArrayList and close and remove all of the
    connections when Global's EndRequest method executes, but this doesn't seem
    to do anything for me memory-wise.

    What is going on?!

    Jon
     
    Jon Davis, Jun 4, 2004
    #1
    1. Advertising

  2. Jon Davis

    Jon Davis Guest

    > I have tried forcing all new database connections to be kept in an
    ArrayList
    > in Global and then go through the ArrayList and close and remove all of

    the
    > connections when Global's EndRequest method executes, but this doesn't

    seem
    > to do anything for me memory-wise.


    ... Oh and it doesn't do anything because the Session object isn't exposed in
    this method.

    Jon

    "Jon Davis" <> wrote in message
    news:...
    > OK I have a web app that I built that makes MANY calls to the DB in each
    > request. The app wasn't tuned for scalability so this wasn't a problem,

    but
    > time is too short to redesign how the database is accessed because the

    data
    > that's being stored is time relevant and the web app will be thrown out in

    a
    > few months. Since I try to separate the OleDb stuff from the business

    logic,
    > I just create new database connections and trust that those connections

    will
    > be closed and expunged when the response ends.
    >
    > But I'm finding that between SQL Server and IIS the machine is quickly
    > running out of RAM, even when the session (where I'm caching data in a
    > custom user object) terminates. After 20 or so page hits (containing

    several
    > database hits per page hit) the server loses like 600MB or RAM. I wouldn't
    > care since the access load is trivial, except that this RAM is NEVER
    > re-gained. Resetting SQL Server returns about 200MB and then resetting IIS
    > returns about 400MB. Again, this is long after the sessions have

    terminated.
    > And I host nothing in the Application collection.
    >
    > Am I wrong in my understanding that database connections automatically

    close
    > and are destroyed when the containing object destroys itself (when the web
    > page's response ends)?
    >
    > I have tried forcing all new database connections to be kept in an

    ArrayList
    > in Global and then go through the ArrayList and close and remove all of

    the
    > connections when Global's EndRequest method executes, but this doesn't

    seem
    > to do anything for me memory-wise.
    >
    > What is going on?!
    >
    > Jon
    >
    >
     
    Jon Davis, Jun 5, 2004
    #2
    1. Advertising

  3. Jon Davis

    Jon Davis Guest

    > I have tried forcing all new database connections to be kept in an
    ArrayList
    > in Global


    Oh, and I meant to say I keep them in the Session object, with the intent to
    close them (and then remove them from the ArrayList) when the page ends.

    How can I do this? The Session object isn't exposed in the Request_End
    method in Global.

    Jon


    "Jon Davis" <> wrote in message
    news:...
    > OK I have a web app that I built that makes MANY calls to the DB in each
    > request. The app wasn't tuned for scalability so this wasn't a problem,

    but
    > time is too short to redesign how the database is accessed because the

    data
    > that's being stored is time relevant and the web app will be thrown out in

    a
    > few months. Since I try to separate the OleDb stuff from the business

    logic,
    > I just create new database connections and trust that those connections

    will
    > be closed and expunged when the response ends.
    >
    > But I'm finding that between SQL Server and IIS the machine is quickly
    > running out of RAM, even when the session (where I'm caching data in a
    > custom user object) terminates. After 20 or so page hits (containing

    several
    > database hits per page hit) the server loses like 600MB or RAM. I wouldn't
    > care since the access load is trivial, except that this RAM is NEVER
    > re-gained. Resetting SQL Server returns about 200MB and then resetting IIS
    > returns about 400MB. Again, this is long after the sessions have

    terminated.
    > And I host nothing in the Application collection.
    >
    > Am I wrong in my understanding that database connections automatically

    close
    > and are destroyed when the containing object destroys itself (when the web
    > page's response ends)?
    >
    > I have tried forcing all new database connections to be kept in an

    ArrayList
    > in Global and then go through the ArrayList and close and remove all of

    the
    > connections when Global's EndRequest method executes, but this doesn't

    seem
    > to do anything for me memory-wise.
    >
    > What is going on?!
    >
    > Jon
    >
    >
     
    Jon Davis, Jun 5, 2004
    #3
  4. Jon Davis

    Jon Davis Guest

    "Jon Davis" <> wrote in message
    news:...
    > > I have tried forcing all new database connections to be kept in an

    > ArrayList
    > > in Global

    >
    > Oh, and I meant to say I keep them in the Session object, with the intent

    to
    > close them (and then remove them from the ArrayList) when the page ends.
    >
    > How can I do this? The Session object isn't exposed in the Request_End
    > method in Global.


    Nevermind, I already have all pages' code-behind inheret from a base class,
    and I simply set up a deconstructor.

    Will report here whether this (closing all open connections) clears the
    memory leak.

    Jon


    > "Jon Davis" <> wrote in message
    > news:...
    > > OK I have a web app that I built that makes MANY calls to the DB in each
    > > request. The app wasn't tuned for scalability so this wasn't a problem,

    > but
    > > time is too short to redesign how the database is accessed because the

    > data
    > > that's being stored is time relevant and the web app will be thrown out

    in
    > a
    > > few months. Since I try to separate the OleDb stuff from the business

    > logic,
    > > I just create new database connections and trust that those connections

    > will
    > > be closed and expunged when the response ends.
    > >
    > > But I'm finding that between SQL Server and IIS the machine is quickly
    > > running out of RAM, even when the session (where I'm caching data in a
    > > custom user object) terminates. After 20 or so page hits (containing

    > several
    > > database hits per page hit) the server loses like 600MB or RAM. I

    wouldn't
    > > care since the access load is trivial, except that this RAM is NEVER
    > > re-gained. Resetting SQL Server returns about 200MB and then resetting

    IIS
    > > returns about 400MB. Again, this is long after the sessions have

    > terminated.
    > > And I host nothing in the Application collection.
    > >
    > > Am I wrong in my understanding that database connections automatically

    > close
    > > and are destroyed when the containing object destroys itself (when the

    web
    > > page's response ends)?
    > >
    > > I have tried forcing all new database connections to be kept in an

    > ArrayList
    > > in Global and then go through the ArrayList and close and remove all of

    > the
    > > connections when Global's EndRequest method executes, but this doesn't

    > seem
    > > to do anything for me memory-wise.
    > >
    > > What is going on?!
    > >
    > > Jon
    > >
    > >

    >
    >
     
    Jon Davis, Jun 5, 2004
    #4
  5. Jon Davis

    Jon Davis Guest

    > Will report here whether this (closing all open connections) clears the
    > memory leak.


    No it does not. Anyone know what would cause such a drastic memory leak?
    Again, lots of data is cached in the Session object, but even when the
    Session has expired, no change is made to the memory and IIS and SQL Server
    are taking up massive amounts of RAM.

    Jon


    "Jon Davis" <> wrote in message
    news:...
    >
    > "Jon Davis" <> wrote in message
    > news:...
    > > > I have tried forcing all new database connections to be kept in an

    > > ArrayList
    > > > in Global

    > >
    > > Oh, and I meant to say I keep them in the Session object, with the

    intent
    > to
    > > close them (and then remove them from the ArrayList) when the page ends.
    > >
    > > How can I do this? The Session object isn't exposed in the Request_End
    > > method in Global.

    >
    > Nevermind, I already have all pages' code-behind inheret from a base

    class,
    > and I simply set up a deconstructor.
    >
    > Will report here whether this (closing all open connections) clears the
    > memory leak.
    >
    > Jon
    >
    >
    > > "Jon Davis" <> wrote in message
    > > news:...
    > > > OK I have a web app that I built that makes MANY calls to the DB in

    each
    > > > request. The app wasn't tuned for scalability so this wasn't a

    problem,
    > > but
    > > > time is too short to redesign how the database is accessed because the

    > > data
    > > > that's being stored is time relevant and the web app will be thrown

    out
    > in
    > > a
    > > > few months. Since I try to separate the OleDb stuff from the business

    > > logic,
    > > > I just create new database connections and trust that those

    connections
    > > will
    > > > be closed and expunged when the response ends.
    > > >
    > > > But I'm finding that between SQL Server and IIS the machine is quickly
    > > > running out of RAM, even when the session (where I'm caching data in a
    > > > custom user object) terminates. After 20 or so page hits (containing

    > > several
    > > > database hits per page hit) the server loses like 600MB or RAM. I

    > wouldn't
    > > > care since the access load is trivial, except that this RAM is NEVER
    > > > re-gained. Resetting SQL Server returns about 200MB and then resetting

    > IIS
    > > > returns about 400MB. Again, this is long after the sessions have

    > > terminated.
    > > > And I host nothing in the Application collection.
    > > >
    > > > Am I wrong in my understanding that database connections automatically

    > > close
    > > > and are destroyed when the containing object destroys itself (when the

    > web
    > > > page's response ends)?
    > > >
    > > > I have tried forcing all new database connections to be kept in an

    > > ArrayList
    > > > in Global and then go through the ArrayList and close and remove all

    of
    > > the
    > > > connections when Global's EndRequest method executes, but this doesn't

    > > seem
    > > > to do anything for me memory-wise.
    > > >
    > > > What is going on?!
    > > >
    > > > Jon
    > > >
    > > >

    > >
    > >

    >
    >
     
    Jon Davis, Jun 5, 2004
    #5
  6. Jon Davis

    Jon Davis Guest

    Actually, eventually I do now get some of the RAM back. But I still lose
    about 25MB per session between SQL Server and IIS combined that is never
    regained after the Session times out.

    Jon


    "Jon Davis" <> wrote in message
    news:...
    > > Will report here whether this (closing all open connections) clears the
    > > memory leak.

    >
    > No it does not. Anyone know what would cause such a drastic memory leak?
    > Again, lots of data is cached in the Session object, but even when the
    > Session has expired, no change is made to the memory and IIS and SQL

    Server
    > are taking up massive amounts of RAM.
    >
    > Jon
    >
    >
    > "Jon Davis" <> wrote in message
    > news:...
    > >
    > > "Jon Davis" <> wrote in message
    > > news:...
    > > > > I have tried forcing all new database connections to be kept in an
    > > > ArrayList
    > > > > in Global
    > > >
    > > > Oh, and I meant to say I keep them in the Session object, with the

    > intent
    > > to
    > > > close them (and then remove them from the ArrayList) when the page

    ends.
    > > >
    > > > How can I do this? The Session object isn't exposed in the Request_End
    > > > method in Global.

    > >
    > > Nevermind, I already have all pages' code-behind inheret from a base

    > class,
    > > and I simply set up a deconstructor.
    > >
    > > Will report here whether this (closing all open connections) clears the
    > > memory leak.
    > >
    > > Jon
    > >
    > >
    > > > "Jon Davis" <> wrote in message
    > > > news:...
    > > > > OK I have a web app that I built that makes MANY calls to the DB in

    > each
    > > > > request. The app wasn't tuned for scalability so this wasn't a

    > problem,
    > > > but
    > > > > time is too short to redesign how the database is accessed because

    the
    > > > data
    > > > > that's being stored is time relevant and the web app will be thrown

    > out
    > > in
    > > > a
    > > > > few months. Since I try to separate the OleDb stuff from the

    business
    > > > logic,
    > > > > I just create new database connections and trust that those

    > connections
    > > > will
    > > > > be closed and expunged when the response ends.
    > > > >
    > > > > But I'm finding that between SQL Server and IIS the machine is

    quickly
    > > > > running out of RAM, even when the session (where I'm caching data in

    a
    > > > > custom user object) terminates. After 20 or so page hits (containing
    > > > several
    > > > > database hits per page hit) the server loses like 600MB or RAM. I

    > > wouldn't
    > > > > care since the access load is trivial, except that this RAM is NEVER
    > > > > re-gained. Resetting SQL Server returns about 200MB and then

    resetting
    > > IIS
    > > > > returns about 400MB. Again, this is long after the sessions have
    > > > terminated.
    > > > > And I host nothing in the Application collection.
    > > > >
    > > > > Am I wrong in my understanding that database connections

    automatically
    > > > close
    > > > > and are destroyed when the containing object destroys itself (when

    the
    > > web
    > > > > page's response ends)?
    > > > >
    > > > > I have tried forcing all new database connections to be kept in an
    > > > ArrayList
    > > > > in Global and then go through the ArrayList and close and remove all

    > of
    > > > the
    > > > > connections when Global's EndRequest method executes, but this

    doesn't
    > > > seem
    > > > > to do anything for me memory-wise.
    > > > >
    > > > > What is going on?!
    > > > >
    > > > > Jon
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Jon Davis, Jun 5, 2004
    #6
  7. Jon, you should automatically assume that anything connecting to a database
    is resource intensive. By that, I mean that it is going to take a fair
    amount of processing and memory to perform and *maintain* that connectivity.
    Therefore, it is common practice to only open any sort of database
    connection at the point that it is needed and then release that connection
    immediately after you are finished with it. Keeping the connection object
    open during the entire session is definitely going to adversely affect the
    memory usage of your application.

    Additionally, you need to make sure that you are closing all DataReaders and
    disposing of all DataSets, DataAdapters, Commands, etc.

    Finally, are there other resources that you are using that are not being
    closed or disposed?

    Unfortunately, your statement that "time is to short to redeisgn" may be
    irrelevant. If the site *has* to work, you may have to bite the bullet and
    redesign how you are handling the connection... One thing you could do is
    take a few pages a create a test site based on those few pages. First, make
    sure that those pages continue to exhibit the same resource problems. Then,
    alter just those few pages (and for goodness sake get that connection out of
    the session) and see if that makes a difference in the resource usage.

    Chris Darnell

    "Jon Davis" <> wrote in message
    news:...
    > OK I have a web app that I built that makes MANY calls to the DB in each
    > request. The app wasn't tuned for scalability so this wasn't a problem,

    but
    > time is too short to redesign how the database is accessed because the

    data
    > that's being stored is time relevant and the web app will be thrown out in

    a
    > few months. Since I try to separate the OleDb stuff from the business

    logic,
    > I just create new database connections and trust that those connections

    will
    > be closed and expunged when the response ends.
    >
    > But I'm finding that between SQL Server and IIS the machine is quickly
    > running out of RAM, even when the session (where I'm caching data in a
    > custom user object) terminates. After 20 or so page hits (containing

    several
    > database hits per page hit) the server loses like 600MB or RAM. I wouldn't
    > care since the access load is trivial, except that this RAM is NEVER
    > re-gained. Resetting SQL Server returns about 200MB and then resetting IIS
    > returns about 400MB. Again, this is long after the sessions have

    terminated.
    > And I host nothing in the Application collection.
    >
    > Am I wrong in my understanding that database connections automatically

    close
    > and are destroyed when the containing object destroys itself (when the web
    > page's response ends)?
    >
    > I have tried forcing all new database connections to be kept in an

    ArrayList
    > in Global and then go through the ArrayList and close and remove all of

    the
    > connections when Global's EndRequest method executes, but this doesn't

    seem
    > to do anything for me memory-wise.
    >
    > What is going on?!
    >
    > Jon
    >
    >
     
    Chris Darnell, Jun 5, 2004
    #7
  8. Jon Davis

    Jon Davis Guest

    I only put the connections in the section because that is the shortest term
    collection that I can keep around across all pages. I suppose I could put it
    as a static class somewhere. Same difference, though, I am, storing every
    connection in an arraylist, and at the termination of every page (through a
    parent class) I go through the list and close and delete everything,
    basically clearing out the arraylist.

    It doesn't seem to change much.

    Again I ask, don't Connections and DataReaders close automatically when
    destroyed?

    Jon


    "Chris Darnell" <> wrote in message
    news:...
    > Jon, you should automatically assume that anything connecting to a

    database
    > is resource intensive. By that, I mean that it is going to take a fair
    > amount of processing and memory to perform and *maintain* that

    connectivity.
    > Therefore, it is common practice to only open any sort of database
    > connection at the point that it is needed and then release that connection
    > immediately after you are finished with it. Keeping the connection object
    > open during the entire session is definitely going to adversely affect the
    > memory usage of your application.
    >
    > Additionally, you need to make sure that you are closing all DataReaders

    and
    > disposing of all DataSets, DataAdapters, Commands, etc.
    >
    > Finally, are there other resources that you are using that are not being
    > closed or disposed?
    >
    > Unfortunately, your statement that "time is to short to redeisgn" may be
    > irrelevant. If the site *has* to work, you may have to bite the bullet

    and
    > redesign how you are handling the connection... One thing you could do is
    > take a few pages a create a test site based on those few pages. First,

    make
    > sure that those pages continue to exhibit the same resource problems.

    Then,
    > alter just those few pages (and for goodness sake get that connection out

    of
    > the session) and see if that makes a difference in the resource usage.
    >
    > Chris Darnell
    >
    > "Jon Davis" <> wrote in message
    > news:...
    > > OK I have a web app that I built that makes MANY calls to the DB in each
    > > request. The app wasn't tuned for scalability so this wasn't a problem,

    > but
    > > time is too short to redesign how the database is accessed because the

    > data
    > > that's being stored is time relevant and the web app will be thrown out

    in
    > a
    > > few months. Since I try to separate the OleDb stuff from the business

    > logic,
    > > I just create new database connections and trust that those connections

    > will
    > > be closed and expunged when the response ends.
    > >
    > > But I'm finding that between SQL Server and IIS the machine is quickly
    > > running out of RAM, even when the session (where I'm caching data in a
    > > custom user object) terminates. After 20 or so page hits (containing

    > several
    > > database hits per page hit) the server loses like 600MB or RAM. I

    wouldn't
    > > care since the access load is trivial, except that this RAM is NEVER
    > > re-gained. Resetting SQL Server returns about 200MB and then resetting

    IIS
    > > returns about 400MB. Again, this is long after the sessions have

    > terminated.
    > > And I host nothing in the Application collection.
    > >
    > > Am I wrong in my understanding that database connections automatically

    > close
    > > and are destroyed when the containing object destroys itself (when the

    web
    > > page's response ends)?
    > >
    > > I have tried forcing all new database connections to be kept in an

    > ArrayList
    > > in Global and then go through the ArrayList and close and remove all of

    > the
    > > connections when Global's EndRequest method executes, but this doesn't

    > seem
    > > to do anything for me memory-wise.
    > >
    > > What is going on?!
    > >
    > > Jon
    > >
    > >

    >
    >
     
    Jon Davis, Jun 8, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon Davis

    Memory leak in ASP.NET web site

    Jon Davis, Jun 8, 2004, in forum: ASP .Net
    Replies:
    18
    Views:
    736
    ASP.Confused
    Jun 9, 2004
  2. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    707
    Eric Sosman
    Mar 22, 2005
  3. mark4asp
    Replies:
    1
    Views:
    1,157
    Steve C. Orr [MCSD, MVP, CSM, ASP Insider]
    Mar 24, 2007
  4. Peter K
    Replies:
    2
    Views:
    313
    Peter K
    May 29, 2008
  5. deepak
    Replies:
    3
    Views:
    1,451
    deepak
    Apr 22, 2010
Loading...

Share This Page