1

我的一个 IIS 应用程序池进程有一个非常奇怪的问题。我最近收到了 System.OutOfMemoryException 错误,我一直在试图弄清楚到底发生了什么。基本上我有一个脚本,它使用 Web 服务从我们的 DAM 获取文件。然后它检查文件将其存储为字节数组,然后使用响应输出文件。我唯一遇到的问题是 PDF,当它们超过 20MB 时,现在似乎它们有时会导致错误。如果我增加应用程序池中的内存,它会暂时解决问题。我观察了 w3wp.exe 进程,发现有时当我运行这个脚本时,它会将内存增加到 400MB,我们拥有的最大文件是 45MB,这会导致这种行为发生。这个问题似乎每晚都会消失,早上它会工作一段时间,然后再次开始做同样的事情。此应用程序是 c# asp.net 应用程序。它在共享点内部运行。

在观看了该服务一段时间后,我确实注意到,由于这些 PDF 是在浏览器窗口中呈现的,因此在文件完全下载之前它不会从内存中释放。这是有道理的,但我可以看出这是我的问题。如果我有几个人加载文件,平均(无文件下载)内存使用量为 385,000 kb。它可以轻松达到 900,000-1,100,000 KB,这是应用程序池的限制。

我不是在寻找一个确切的答案,而是更像是一个前进的方向,因为我完全没有想法。

4

2 回答 2

10

当您将文件数据作为字节数组放入内存时,您对 Web 服务器施加了很大的压力。

与其将整个文件数据存储在字节数组中,不如尝试将文件流以块的形式写入响应流。

伪示例:

context.Response.Buffer = false;

byte[] buffer   = new byte[4096];
int bytesRead   = 0;

using(var stream = new FileStream(path, FileMode.Open, FileAccess.Read))
{
    while ((bytesRead = stream.Read(buffer, 0 , buffer.Length)) > 0)
    {
        context.Response.OutputStream.Write(buffer, 0, buffer.Length);
        context.Response.OutputStream.Flush();
    }
}

这里的想法是,您只需在每次读取文件流时将一大块文件数据放入内存,然后将其写入响应。请注意,响应缓冲已被禁用,您可以使用文件流替换另一个 Stream 数据源(我在从 SQL 数据库读取二进制数据时使用了这种方法)。

编辑:(对如何将数据从 SQL 流式传输到 HTTP 响应的响应)

为了从 SQL Server 数据库表(例如 varbinary(max) 列)流式传输数据,您在 SqlCommand 上使用顺序访问:

#region WriteResponse(HttpContext context, Guid id)
/// <summary>
/// Writes the content for a media resource with the specified <paramref name="id"/> 
/// to the response stream using the appropriate content type and length.
/// </summary>
/// <param name="context">The <see cref="HttpContext"/> to write content to.</param>
/// <param name="id">The unique identifier assigned to the media resource.</param>
private static void WriteResponse(HttpContext context, Guid id)
{
    using(var connection = ConnectionFactory.Create())
    {
        using (var command = new SqlCommand("[dbo].[GetResponse]", connection))
        {
            command.CommandType = CommandType.StoredProcedure;

            command.Parameters.Add("@Id", SqlDbType.UniqueIdentifier);
            command.Parameters.AddReturnValue();

            command.Parameters["@Id"].Value = id;

            command.Open();

            using(var reader = command.ExecuteReader(CommandBehavior.SequentialAccess))
            {
                if(reader.Read())
                {
                    WriteResponse(context, reader);
                }
            }
        }
    }
}
#endregion

#region WriteResponse(HttpContext context, SqlDataReader reader)
/// <summary>
/// Writes the content for a media resource to the response stream using the supplied <paramref name="reader"/>.
/// </summary>
/// <param name="context">The <see cref="HttpContext"/> to write content to.</param>
/// <param name="reader">The <see cref="SqlDataReader"/> to extract information from.</param>
private static void WriteResponse(HttpContext context, SqlDataReader reader)
{
    if (context == null || reader == null)
    {
        return;
    }

    DateTime expiresOn      = DateTime.UtcNow;
    string contentType      = String.Empty;
    long contentLength      = 0;
    string fileName         = String.Empty;
    string fileExtension    = String.Empty;

    expiresOn               = reader.GetDateTime(0);
    fileName                = reader.GetString(1);
    fileExtension           = reader.GetString(2);
    contentType             = reader.GetString(3);
    contentLength           = reader.GetInt64(4);

    context.Response.AddHeader("Content-Disposition", String.Format(null, "attachment; filename={0}", fileName));

    WriteResponse(context, reader, contentType, contentLength);

    ApplyCachePolicy(context, expiresOn - DateTime.UtcNow);
}
#endregion

#region WriteResponse(HttpContext context, SqlDataReader reader, string contentType, long contentLength)
/// <summary>
/// Writes the content for a media resource to the response stream using the 
/// specified reader, content type and content length.
/// </summary>
/// <param name="context">The <see cref="HttpContext"/> to write content to.</param>
/// <param name="reader">The <see cref="SqlDataReader"/> to extract information from.</param>
/// <param name="contentType">The content type of the media.</param>
/// <param name="contentLength">The content length of the media.</param>
private static void WriteResponse(HttpContext context, SqlDataReader reader, string contentType, long contentLength)
{
    if (context == null || reader == null)
    {
        return;
    }

    int ordinal     = 5;
    int bufferSize  = 4096 * 1024; // 4MB
    byte[] buffer   = new byte[bufferSize];
    long value;
    long dataIndex;

    context.Response.Buffer         = false;
    context.Response.ContentType    = contentType;
    context.Response.AppendHeader("content-length", contentLength.ToString());

    using (var writer = new BinaryWriter(context.Response.OutputStream))
    {
        dataIndex   = 0;
        value       = reader.GetBytes(ordinal, dataIndex, buffer, 0, bufferSize);

        while(value == bufferSize)
        {
            writer.Write(buffer);
            writer.Flush();

            dataIndex   += bufferSize;
            value       = reader.GetBytes(ordinal, dataIndex, buffer, 0, bufferSize);
        }

        writer.Write(buffer, 0, (int)value);
        writer.Flush();
    }
}
#endregion
于 2011-07-29T15:04:46.343 回答
1

反对派对处理文件本身有很好的建议。我还会查看您在 Web 处理中可能保留的参考资料。是否在会话状态或应用程序状态中存储任何内容?如果是这样,请仔细跟踪它们,以确保它们不会反过来指向与处理您的文件有关的页面或其他东西。

我之所以提到这一点,是因为几年前我们有一个令人讨厌的“泄漏”,这是由于将对象置于应用程序状态而引起的。结果证明该对象订阅了页面事件,并且由于该对象从未死亡,因此所有页面也没有!哎呀

于 2011-07-29T15:08:40.640 回答