问题标签 [disk-io]

在我们的项目工作期间，我们需要决定是使用“ElasticSearch”还是“MySQL”来记录系统的审计/跟踪日志。搜索速度在这里不是问题，我们需要查看两个平台的磁盘 I/O 性能。我没有磁盘 i/o 监控的经验，所以经过一些研究后，我决定通过一个简单的负载运行脚本监控 ElasticSearch 和 MySQL 的每秒写入量。

我应该考虑磁盘 i/o 性能的每秒写入次数吗？我是否朝着正确的方向前进？另外，我不确定是否更少。每秒写入数是更好还是最差？

考虑到磁盘 i/o 比率，在 Mongo DB 中使用 TTL 索引的最佳策略是什么。

前言：

我在集群 mongodb (v2.*) 基础架构上工作，其中每个节点都有大约 1TB 的硬盘。在那里，日志信息会保存 7 天。在那之后，它们不再需要并且应该被删除。有 6 个数据库，每个数据库有 10 个集合，每个集合超过 1000 万个文档。假设我们每天要存储 100GB 的临时数据。

因此，我在 createdAt 字段上创建了一个简单的索引。

这将在时间戳记 7 天后删除所有插入此集合的文档createdAt。这对我来说很清楚。但我不确定如何创建将保存到集合中的文档。

背景索引的 mongo 文档状态：

问题：

在考虑未来删除时，创建该 TTL 索引的最佳方法是什么。

例如，这里有 3 种方法可以创建要保存的对象。我使用的语法是 php 但没关系。

选项1：

在这里，今天创建的所有文档都将保存，例如“2015-04-09 00:00:00”的创建时间。这意味着所有文档都将在“2015-04-16 00:00:00”“过期”。

临：

• 每天午夜后不久，磁盘使用量应减少 100GB。
• 您可以轻松查看是否存在错误。如果磁盘使用量没有下降，就会出现问题。

缺点：

• 删除 100GB 的数据将导致巨大的磁盘 io 并可能减慢其他进程。
• 由于缺少小时和分钟，这些文件的保存时间不到 7 天。

选项 2：

在这里，所有创建的文档都有不同的创建时间，例如“2015-04-09 13:23:45”。这意味着此示例文档将在“2015-04-16 13:23:45”“过期”。

临：

• 文档将准确保存 7 天。
• 磁盘 io 将在一整天内几乎保持不变。干扰其他进程的可能性较小。

缺点：

• 查看是否有错误不像选项 1 那样容易，因为文档将在一天中被删除。磁盘使用量不会有很大的跳跃。

（选项 3）：

我认为这应该与选项 2 相同。不过我想在这里提一下。

我们还可以将索引更改为在特定时间后但在特定日期不过期。

然后以这种方式创建对象：

你认为最好的可能性是什么？有没有人遇到过这样的问题/基础设施？我很想从经验丰富的 mongodb 开发人员那里得到一些反馈。

我有 ac# 桌面应用程序。

它一次从 4 个数码相机“读取”1 个 JPEG 帧。

每个 JPEG 不超过 20K 字节。对于检测到的每一个运动，我都会将帧保存到我的硬盘驱动器中。

存储我的素材的另一种方法是在我的托管代码中创建 AVI 文件，并在建立一定大小后将其拆分。

我一次保存 1 个 JPEG 的原因是，如果窃贼在运行应用程序的情况下窃取了我的 PC 或/并且 PC 自行重新启动或/并且应用程序刚刚停止，那么我将始终能够保存最新的帧。

如果我采用 AVI 方法，我将失去我在代码中设置的任何截止值。

我知道如果窃贼偷走了我的电脑，他们也会拥有我所有的镜头，但我可以通过保存到存储在保险箱中的外部硬盘驱动器来规避这一点（例如）。

因此，请记住要保存的字节数很少（但可能很频繁），这是我希望在内存效率方面达到的最佳效果吗？

谢谢

我已经阅读了很多关于尝试分配超过 1GB 内存的 SO 帖子和一般文章，所以在像其他人一样被击落之前，这里有一些上下文。

此应用程序将作为信息亭运行，专用机器不运行不必要的进程。

我的应用程序以 1920 x 1080 的分辨率和 24 位深度从具有滚动快门的高速相机获取图像，速度为每秒 120 帧。应用程序需要将每一帧写入磁盘以进行后期处理. 我目前面临的问题是磁盘 I/O 无法跟上捕获速率，即使它被限制为每秒 120 帧。所需的磁盘 I/O 带宽约为 750MBps！

原始记录的总长度至少需要 10 秒 (7.5GB)。执行任何即时转码或压缩都会将帧速率降至完全不可接受的水平。

为了解决这个问题，我尝试了以下方法：

• 通过将硬件级别的位深度降低到 16（仍约为 500MBps）来降低质量。
• 禁用所有图像编码并将原始相机数据写入磁盘。这节省了一些处理时间。
• 在磁盘上创建一个 10GB 的文件，并在帧进入时进行顺序写入。到目前为止，这很有帮助。所有开发和生产系统都有一个用于此应用程序的 100GB 专用驱动器。
• 使用 Sysinternals 的 Contig.exe 对文件进行碎片整理。这在非 SSD 驱动器上取得了惊人的收益。

这里没有可供探索的选择。我不熟悉内存映射文件，在尝试创建它们时，我得到一个 IOException 说Not enough storage is available to process this command.。

我目前使用的大文件需要顺序写入或顺序读取访问。任何指针将不胜感激。

如果有办法分配这么多 RAM，我什至可以将整体记录大小降低到 1.8GB。再一次，这将在具有 8GB 可用内存和 100GB 可用空间的专用设备上运行。但是，并非所有生产系统都将配备 SSD 驱动器。

我的盒子上有两个进程在运行 => A 和 B。

每当由于进程 A 将大文件写入磁盘而导致磁盘 I/O 活动繁重时，我看到进程 B 中的文件写入会间歇性地停止。我注意到我的 linux 内核上有以下虚拟内存设置。

文档指出，“dirty_background_ratio”是在内核后台刷新线程启动以将字节刷新到磁盘之前，脏页占用的内存百分比。鉴于我有 64 GB 的内存，当脏页缓存大小达到 ~ 3.2 GB 时，这个后台刷新应该开始，我看到进程 A 正在写入磁盘时确实是这种情况。

但是，一旦后台刷新开始，进程 B 中的文件写入就会开始间歇性地停止大约 10-20 秒的时间。1）鉴于此磁盘刷新是在后台发生的，鉴于所有写入首先进入页面缓存而不是直接写入磁盘，为什么进程 B 的写入会停止？2) 是否有任何系统级参数来防止这些缓冲写入停顿的发生？

背景：

我正在开发一个与数据库相关的程序，我需要按顺序将脏元数据从内存刷新到磁盘。/dev/sda1 是卷格式，因此 /dev/sda1 上的数据将被逐块访问，如果顺序访问，这些块在物理上是相邻的。而且我使用的是直接I/O，所以I/O会绕过文件系统的缓存机制，直接访问磁盘上的块。

问题：

打开 /dev/sda1 后，我将读取一个块，更新该块并将该块写回与 /dev/sda1 开头的相同偏移量，迭代。

代码如下 -

我发现如果我不做 pwrite，读取吞吐量是125 MB/s。

如果我执行 pwrite，读取吞吐量将为21 MB/s，写入吞吐量为169 MB/s。

如果我在 pwrite 之后进行预读，则写入吞吐量为115 MB/s，读取吞吐量为208 MB/s。

我也试过 read()/write() 和 aio_read()/aio_write()，但问题依旧。我不知道为什么在文件的同一位置读取后写入会使读取吞吐量如此之低。

如果一次访问更多块，像这样

问题会缓解，请看图表。

我有一个在 CentOS Linux 6 x64 操作系统上运行的虚拟服务器。它使用 SSD 加速 RAID 存储，具有 2GB RAM，并在 Apache 上运行 Drupal 7。

我注意到服务器负载反复出现峰值。这些与 Cron、备份用户或任何计划的管理员操作无关。

峰值似乎都在世界标准时间晚上 8:00 左右，其中大多数似乎都达到了 0.75 大关，可能有明显的高点、低点和遗漏。

有什么我应该寻找或询问我的服务提供商的吗？

更新 这似乎是 cPanel 更新。现在我需要研究如何最大限度地减少这种情况或真正需要多久完成一次。

我有一个使用 Ubuntu 12.04 的亚马逊 ec2 实例（SAY S1）（4core-7GB 内存），它使用postgresql 9.1. 所有 postgres 数据都存储在 100 GB 的不同 ssd 卷（不是 root）上。（现在写它目前只有 26% 已满）。

突然从一两天开始，几个 postgres 操作开始花费大量时间。创建命令（52 秒）并恢复数据库（现在 9 分钟，以前最大 50 秒）。

通过在运行 postgres 命令的同时运行 iostat，我可以确认 ec2 卷的 IOPS 已达到其限制（3 IOPS/GB 等于 100GB 卷的 300 IOPS）。运行此命令后可以在下面看到它iostat -d 5 -x -p xvdf。

aws 上的IO 特性表明每个 IOPS 需要 256KiB 或更少的请求，那么 postgres 是否使用较小的数据块来写回导致更多数量的 IOPS 请求？

虽然我有另一个具有 100GB 卷（现在 95% 已满）的 ec2 实例（比如 S2），但 postgres 数据位于根卷上，并且性能很好。所以体积的大小是我确定在这里无关紧要的东西。

受影响的 S1 卷仅存储 postgres 数据，我仍然可以通过 iostat 看到以下统计信息。不知道为什么统计数据会这样，以及如何在不增加卷大小的情况下减少 postgres 命令时间。（虽然所有操作 3GB 内存始终是空闲的）

注意：受影响的 postgres 卷包含 100 个不同的 postgres db，平均大小为 110 MB/db（但老实说，我认为这无论如何都不是问题）

第三方库在内部将我的 SubClassOfOutputStream 转换为 FileOutputStream 以调用 getChannel() 操作，即使它们在其 API 中公开了 OutputStream 接口。这（显然）会导致 ClassCastException。

我需要写入 SubClassOfOutputStream 接口。我显然需要写入 FileOutputStream 容器，将该数据通过管道传输到 InputStream，然后将相关 InputStream 中的字节读取到我的 SubClassOfOutputStream 实例中。有没有办法在没有磁盘 i/o 的情况下做到这一点？

谢谢！

我在两台不同的机器上工作，它们都有不同的硬盘存储和不同的 cassandra 版本。

机器1个 SSD硬盘，Cassandra 2.1.13

机器2 HDD硬盘，Cassandra 2.1.3

现在我使用SSTableLoader实用程序将一个 CF 的数据从机器 2传输到机器 1 。直到这一步它工作正常，数据也成功传输。

但是我错误地截断了机器 2上相同 CF的数据。为了恢复数据，我使用了相同的概念。我试图将数据从machine 1传输到machine 2。

同时我发现了一些奇怪的日志

1. 16:22:53.956 [main] 调试 oacio.sstable.SSTableReader - 无法反序列化 SSTable 摘要文件 ./data/data/sstableloadertest/typestest-8e68e811f56511e59d60297061e28552/sstableloadertest-typestest-ka-57-Summary.db：无法反序列化 SSTable 摘要组件，因为DiskAccessMode 已更改！

它还删除了 sstable 的 *summary.db 组件。

首先我认为这是由于不同的 cassandra 版本而发生的，但我错了。

谁能告诉我为什么会这样？