Процесс пула приложений IIS, использующий много памяти - PullRequest
1 голос
/ 29 июля 2011

У меня очень странная проблема с одним из процессов пула приложений IIS. В последнее время я получаю ошибку System.OutOfMemoryException и пытаюсь выяснить, что именно происходит. В основном у меня есть скрипт, который использует веб-сервис для получения файла из нашей DAM. Затем он проверяет, хранит ли файл байтовый массив, а затем использует Response для вывода файла. Единственная проблема, с которой у меня были проблемы - это файлы PDF, размер которых превышает 20 МБ, теперь кажется, что они иногда вызывают ошибку. Если я увеличу объем памяти в пуле приложений, это временно решит проблему. Я наблюдал за процессом w3wp.exe и видел, что иногда, когда я запускаю этот скрипт, он увеличивает память до 400 МБ, самый большой файл, который у нас есть, - 45 МБ, что может привести к такому типу поведения. Кажется, что проблема уходит каждую ночь, а утром она будет работать некоторое время, а затем снова начнет делать то же самое. Это приложение c # asp.net. Он работает внутри sharepoint.

После просмотра службы в течение некоторого времени я заметил, что поскольку эти PDF-файлы отображаются в окне браузера, то, пока файл не загрузится полностью, он не будет освобожден из памяти. это имеет смысл, но я вижу, что это в некоторой степени моя проблема. Если у меня есть несколько человек, загружающих файл со средним (без загрузки файла) использованием памяти в 385 000 КБ. Он может легко получить до 900 000-1 100 000 КБ, что является пределом пула приложений.

Я не столько ищу точный ответ, сколько похож на направление к голове, потому что у меня нет идей.

Ответы [ 2 ]

10 голосов
/ 29 июля 2011

Когда вы помещаете данные файла в память в виде массива байтов, вы оказываете большое давление на веб-сервер.

Вместо того, чтобы хранить все данные файла в массиве байтов, вы должныпопробуйте записать поток файлов в поток ответов в виде фрагментов.

Псевдо-пример:

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 (например, столбца 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
1 голос
/ 29 июля 2011

У Oppositional есть очень хороший совет по обработке самого файла. Я также хотел бы посмотреть на ссылки, которые вы, возможно, держите в своей веб-обработке. Храните ли что-нибудь в состоянии сеанса или состоянии приложения? Если это так, внимательно проследите, чтобы они не указывали на страницу или что-то еще, связанное с обработкой ваших файлов.

Я упоминаю об этом, потому что несколько лет назад у нас была неприятная «утечка», вызванная переводом объекта в состояние приложения. Оказывается, этот объект подписан на события страницы, и поскольку объект никогда не умирал, не делали и все страницы! упс

...