问题标签 [fragmentation]

我的问题类似于如何避免硬盘碎片？，但我每天将生成数百个文件，大小从 2 MB 到 100+ MB 不等（提问者暗示他的文件较小，因为他更担心磁盘混乱，我的问题是读取这些文件的性能）。这些文件一次写入一点点（记录数据），这是创建碎片的最佳方式。（数据库不是一个选项。）我有代码在它们完全编写后进行碎片整理，但是在同一天读回文件时性能会受到影响。

似乎如何在使用 .NET 时限制文件碎片？; 尽管他们缺乏细节（而且我在 C++ 中）。我会使用 SetFilePointerEx() 和 SetEndOfFile() 将文件大小设置为 2MB，然后当文件达到分配的大小时，我将根据观察到的增长率调整大小。然后在写入完成后，调整为实际数据大小。

我看到的一个陷阱（实际上是http://www.cplusplus.com/forum/windows/22114/指出的）是如果我的应用程序崩溃或计算机关闭会发生什么。现在我的文件中有未确定的数据，无法通过 Windows 检测到它。这建议我创建一个文件来跟踪每个文件或单个文件写入了多少数据。有更好的策略吗？也许在每次写入后写入足够的零以便以后检测（然后备份以准备下一次写入）？

你看到我错过的任何其他陷阱吗？

是否有任何 sql 子集专门处理水平分割表以进行分发？

我必须分割要在商店之间分发的库存表。我不是在寻找一个完整的解决方案，只是朝着正确的方向点头。

我找到了一个与我想要的类似的 IBM 示例（我认为）

但我需要一个 Oracle 示例（最高 11g2）。

我有一个非常简单的标准查询来显示数据库中索引的碎片，如下所示：

然而，当我运行它时，我看到完全相同的数据 - 相同的表名、索引名和索引类型 - 以不同百分比的碎片返回多次。下面是一个例子：

我不明白这些结果。当我在 SSMS 中打开表时，打开索引，然后转到 Fragmentation 页面，它告诉我最低的数字 1.71% 是碎片。所有这些其他碎片数字来自哪里？谁能帮助解释这些结果？非常感谢。

我的 Android 应用在 480x800 像素分辨率下看起来很棒，但它在 240x400 像素的 LDPI 屏幕上中断。我知道我可以在活动中获得屏幕的缩放因子，使用它会根据屏幕分辨率getResources().getDisplayMetrics().density给出确切的值。float

在我的应用程序中，我在其中使用了RelativeLayout和ImageViews，并使用 设置了图像的边距setMargins()，因为此方法使用像素int作为其顶部、左侧、底部和右侧的值，如何使用我得到的 DPI 因子设置这些值？（这是一个浮动）。我们有Math.floor()，但我使用像素将图像定位在非常特定的位置，并且方法返回的 DPI 因子在小数位处具有非常具体的值，无法忽略，因此转换为int对我不起作用。

更新

另外，我lp.setMargins(100,200,0,0);用来设置边距，我将对其进行哪些修改以使用从设备收到的 DPI 因子？

PS我知道它更像是一个数学问题而不是编程，但我的数学很差，对不起。

如果我在文件中间添加一些字母是该操作会使文件碎片化吗？

我只想将数据存储到文件中，有时会更新它们。所以......当我做了很多改变时，它可能对性能问题不利吗？

我对原始数据包分段时 TCP_ACK 的工作方式有疑问。

例如，原始数据包大小为 1,500*N 字节，MTU 为 1,500。然后，数据包将被分成（大约）N个数据包。在这种情况下，接收方如何向发送方发送 TCP_ACK？我检查了wireshark，似乎接收器为每两个碎片数据包发送TCP_ACK。这样对吗？

你能给我一些参考或解释吗？谢谢。

我每天使用以下代码将表从 Oracle DB 导入 SQL Server：

以上导致“mytable”上的非聚集索引出现大量碎片（90% 到 99%）。如果我运行下面的代码

我的非聚集索引的碎片率在 1% 到 3% 之间。这是什么原因造成的？这两个语句都在截断表并将新数据插入到空白表中。

我们的应用程序不断地为大量数据（比如数十到数百兆字节）分配数组，这些数据在被丢弃之前的生存时间很短。

天真地这样做可能会导致大对象堆碎片，最终导致应用程序崩溃并出现 OutOfMemoryException，尽管当前活动对象的大小并不过分。

过去我们成功管理此问题的一种方法是将数组分块以确保它们不会最终出现在 LOH 上，其想法是通过允许垃圾收集器压缩内存来避免碎片。

我们最新的应用程序处理的数据比以前更多，并且在托管在单独的 AppDomain 或单独的进程中的加载项之间非常频繁地传递这些序列化数据。我们采用了与以前相同的方法，确保我们的内存始终被分块，并非常小心地避免大型对象堆分配。

但是，我们有一个必须托管在外部 32 位进程中的加载项（因为我们的主应用程序是 64 位的，并且加载项必须使用 32 位库）。在特别重的负载下，当大量 SOH 内存块被快速分配并在不久之后被丢弃时，即使我们的分块方法也不足以保存我们的 32 位加载项，它会因 OutOfMemoryException 而崩溃。

在发生 OutOfMemoryException 时使用 WinDbg，!heapstat -inclUnrooted显示如下：

!dumpheap -stat显示这个：

这些告诉我，我们的内存使用并没有过多，而且我们的大对象堆像预期的那样非常小（所以我们绝对不会在这里处理大对象堆碎片）。

但是，!eeheap -gc显示了这一点：

这里让我印象深刻的是，我们最终的 SOH 堆段从 0x73b41000 开始，这正好是我们 32 位加载项中可用内存的限制。

所以如果我没看错的话，我们的问题似乎是我们的虚拟内存已经被托管堆段碎片化了。

我想我的问题是：

• 我的分析正确吗？
• 我们使用分块避免 LOH 碎片的方法是否合理？
• 有没有一个好的策略来避免我们现在看到的内存碎片？

我能想到的最明显的答案是池化和重用我们的内存块。这可能是可行的，但我宁愿避免这样做，因为它涉及我们自己有效地管理那部分记忆。

我正在使用 ChannelBuffers.dynamicBuffer() 来管理使用 Netty 在网络上的未知大小消息的碎片。我的问题是，当我从缓冲区中读取字节（...）时，读取的字节是否会自动从缓冲区中“修剪”，因此它不会随着时间的推移而增长到荒谬的大小？如果没有，我将如何自己做这件事？

谢谢。

我正在尝试构建一些我不确定是否可行的东西。我有 Fragment 选项卡（使用 FragmentActivity、TabHost 和 TabWidget 作为我的 Fragment 选项卡容器），并且在每个我想要的 Fragment 中，作为顶栏，还有另一个 Fragment。您可以将其视为 - 由项目类型构成的底部栏，以及将是过滤器的顶部栏。我想以常规手势在过滤器之间捕捉。

我的应用程序的行为如下：我可以看到第一个片段所在的主要活动，我可以看到顶部/底部栏，但我看不到第一个顶部栏类别的视图（片段）。当我试图捕捉到另一个类别时，什么也没有发生。

这是片段的代码：

这是外部片段的 xml：

这是我的第一个类别片段（第一个片段内的片段类别）的示例：

请帮我 ：（

这是我的片段适配器：