iis 7.5应用程序池问题失败

Question

I have been working on our website and every once in a while we get weird results. The IIS application pool seems to have problems and the db connection fails. I check the DB and all is fine & if I run the sql statement in the DB its lightning fast. Then every person after that first failure will fail to connect to the DB afterwards until I recycle the IIS application pool.

I am checking my code for memory leaks right now.

I did notice when I logged in and started working at 5 am this morning the memory usage was at 77% and no one is logged in right now, prior to me stress testing the system. Now I do know this box has sql server on it, so that will consume as much memory as possible. I am wondering if we should add more memory and limit sql to what it has now, and allow the new memory to be used for IIS.

Is anyone an IIS guru, specifically with the IIS Application Pool settings?

here is my code i am using to call the database:

dim strU_TmRecord5 as string
strU_TmRecord5 = "Some sql query..."
strSaveSuccessful = exExecuteNonQuery(strU_TmRecord5, "ConnectDBSettings", strUser)



Public Shared Function exExecuteNonQuery(ByVal sqlString As String, ByVal strConnName As String, Optional ByVal strUser As String = "") As Object

    Dim strConnString As String = ConfigurationManager.ConnectionStrings(strConnName).ConnectionString
    Dim sqlConnection1 As New SqlConnection(strConnString)
    Dim returnValue As String = "FAIL"
    Dim cmd As New SqlCommand

    '  NonQuery does not return any data
    Try
        cmd.CommandText = sqlString
        cmd.CommandType = Data.CommandType.Text
        cmd.Connection = sqlConnection1

        sqlConnection1.Open()
        cmd.ExecuteNonQuery()
        returnValue = "SUCCESS"
        sqlConnection1.Close()

    Catch ex As Exception
        returnValue = "FAIL"
        If sqlConnection1 IsNot Nothing Then
            sqlConnection1.Close()
        End If

    Finally
    End Try

    Return returnValue

End Function

here is code for DataReader:

    Dim drDataReader1 As SqlDataReader = Nothing
    Dim strGetMgrInfo as string = "sql stuff to get mgr info"

  Try
        Dim drDataReader As SqlDataReader
        ddlMgrName.Items.Clear()
        drDataReader = Utilities.exExecuteDataReader(strGetMgrInfo, "DBConnect", strUser)

        If drDataReader.HasRows = False Then
            lblError1.Visible = True
            lblError1.Text = "Invalid Employee Info"
        Else
            While drDataReader.Read()
                ddlMgrName.Items.Add(New ListItem(drDataReader(0).ToString.Trim, drDataReader(1).ToString.Trim))
            End While
            drDataReader.Close()
        End If
    Catch ex As Exception
    Finally
    End Try



Public Shared Function exExecuteDataReader(ByVal sqlString As String, ByVal strConnName As String, Optional ByVal strUser As String = "") As SqlDataReader

    Dim returnValue As SqlDataReader = Nothing

    '  Scalar gets 1st column of 1st row no matter how many records are returned.
    Dim strConnString As String = ConfigurationManager.ConnectionStrings(strConnName).ConnectionString
    Dim sqlConnection1 As New SqlConnection(strConnString)
    sqlConnection1.Open()

    Dim cmd As New SqlCommand
    exExecuteDataReader = Nothing

    cmd.CommandText = sqlString
    cmd.CommandType = Data.CommandType.Text
    cmd.Connection = sqlConnection1

    Try
        returnValue = cmd.ExecuteReader(Data.CommandBehavior.CloseConnection)
        Return returnValue
    Catch ex As Exception
        If sqlConnection1 IsNot Nothing Then
            sqlConnection1.Close()
        End If

    End Try

End Function

Answer 1

Running IIS and SQL on the same box for any production systems is a bad idea. SQL can be capped in its memory use. IIS not so much (you can give it a limit but it will just whack your application every time it goes over, which is probably not what you want).

A memory leak is the first thing to check, but you should also make sure you're not leaking database connections. You MUST close/dispose those, or you will experience exactly what you are seeing.

Also, the DataReader returned from the second query function requires the connection, so you can either return a disposable object that holds both the DataReader and the SqlConnection and rely on the caller to dispose of that I don't recommend this), or you can copy the data out from the DataReader into an array of custom objects (like an ORM system), a DataTable object, or some other kind of object. The second method is preferable, because it captures the data as quickly as possible and then releases the connection for other requests to use. The first method would only be used in situations where there is so much data being returned that it cannot be reasonably held in memory. Even in that case, though, passing in some kind of processing delegate and having that process each row within the function is probably a better design.