0

我正在开发 Silverlight 业务应用程序并希望实现“多部分”上传，它将单个文件拆分为大小为 4096KB 的部分。要将这些部分从客户端上传到服务器，我使用了 WebClient（客户端）和通用处理程序（*.ashx，服务器端）。

策略：第一部分创建了一个实体框架类的新实例。这个对象有一个字段/属性“二进制”（在 SQL 中它是一个 varbinary(MAX)，在实体框架中它是一个字节 []）。我将第一部分存储在属性“二进制”中并执行 SaveChanges()。然后，处理程序将这个新对象的 ID（主键）返回给客户端。

在我的文件的第二部分旁边，对服务器的第二个请求包含第一个请求后返回的 ID。在服务器上，我从数据库加载先前创建的对象并附加第二部分。

myobject.binary = myobject.binary.Concat(bytes).ToArray<byte>();

myobject是先前创建的对象，字节是我要附加到二进制属性的部分。

我重复这个“策略”，直到整个文件上传到服务器。这适用于最大大小约为 78MB 的文件。对于大小约为 83MB 的文件，它的工作是零星的。大小约为 140MB 的文件将在 SaveChanges() 处中止并出现OutOfMemory 异常。

堆栈跟踪

at System.Object.MemberwiseClone()
at System.Array.Clone()
at System.Data.Common.CommandTrees.DbConstantExpression..ctor(TypeUsage resultType, Object value)
at System.Data.Mapping.Update.Internal.UpdateCompiler.GenerateValueExpression(EdmProperty property, PropagatorResult value)
at System.Data.Mapping.Update.Internal.UpdateCompiler.BuildSetClauses(DbExpressionBinding target, PropagatorResult row, PropagatorResult originalRow, TableChangeProcessor processor, Boolean insertMode, Dictionary`2& outputIdentifiers, DbExpression& returning, Boolean& rowMustBeTouched)
at System.Data.Mapping.Update.Internal.UpdateCompiler.BuildUpdateCommand(PropagatorResult oldRow, PropagatorResult newRow, TableChangeProcessor processor)
at System.Data.Mapping.Update.Internal.TableChangeProcessor.CompileCommands(ChangeNode changeNode, UpdateCompiler compiler)
at System.Data.Mapping.Update.Internal.UpdateTranslator.<ProduceDynamicCommands>d__0.MoveNext()
at System.Linq.Enumerable.<ConcatIterator>d__71`1.MoveNext()
at System.Data.Mapping.Update.Internal.UpdateCommandOrderer..ctor(IEnumerable`1 commands, UpdateTranslator translator)
at System.Data.Mapping.Update.Internal.UpdateTranslator.ProduceCommands()
at System.Data.Mapping.Update.Internal.UpdateTranslator.Update(IEntityStateManager stateManager, IEntityAdapter adapter)
at System.Data.EntityClient.EntityAdapter.Update(IEntityStateManager entityCache)
at System.Data.Objects.ObjectContext.SaveChanges(SaveOptions options)
at MyObjectContext.SaveChanges(SaveOptions options) in PathToMyEntityModel.cs:Line 83.
at System.Data.Objects.ObjectContext.SaveChanges()
at MultipartUpload.ProcessRequest(HttpContext context) in PathToGenericHandler.ashx.cs:Line 73.

有谁知道，我的实现有什么问题？如果您需要更多信息或代码片段，请告诉我。

亲切的问候，克里斯

4

1 回答 1

5

想想看。上传（例如）130 MB 后，执行此行需要多少内存：

myobject.binary = myobject.binary.Concat(bytes).ToArray<byte>();

显然，前一个数组在内存中，即 130 MB。而且不知何故，新数组也必须在内存中，另外还有 130 MB，对吗？

它实际上要糟糕得多。Concat()正在生成一个序列，并且ToArray()不知道它会有多大。

那么它的作用是创建一个内部缓冲区并开始用迭代器.ToArray()的输出填充它。.Concat()显然，它不知道缓冲区应该有多大，所以每隔一段时间它就会发现传入的字节数超过了它的缓冲区可以容纳的字节数。然后它需要创建一个更大的缓冲区。它将做的是创建一个两倍于前一个缓冲区的缓冲区，复制所有内容并开始使用新缓冲区。但这意味着在某些时候，旧缓冲区和新缓冲区必须同时在内存中。

在某些时候，旧缓冲区将是 128 MB，而新缓冲区将是 256 MB。加上 130 MB 的旧文件，大约是 0.5 GB。现在让我们希望没有两个（或更多）用户同时这样做。

我建议你使用不同的机制。例如，将上传的块存储在磁盘上的临时文件中。当一个新的块进来时，只需附加到文件中。只有在上传完成后，才可以对文件执行任何操作，例如将其存储在数据库中。

此外，请注意 .NET 中数组的最大大小受 31 位索引的限制。因此，无论系统中有多少 RAM，字节数组的最大大小为 2 GB。

最后：如果您要处理这么大的内存块，请确保您在 64 位进程中运行，并且至少在 .NET 4.5 上运行，这样您就可以利用 .NET 4.5 中的大对象堆改进。但即使这样也不是魔法，因为“内存不足”并不指物理内存。

于 2013-10-16T13:12:27.800 回答