问题标签 [solid-state-drive]

我正在测试与 MySql 一起使用的 SSD，但看不到任何性能优势。这让我觉得我一定做错了什么。

这是设置：

• 至强 5520 2.26 Ghz 四核
• 12GB 内存
• RAID 1 中 300GB 15k
• RAID 1 中的 64GB SSD

为了测试，我移动了 SSD 上的 mysql 目录。

我导入了一个包含 300 万行的表。然后导入同一个表，其中数据和索引目录符号链接到 15k 驱动器。

通过 mysqldump 的转储将数据加载到表中，15k 驱动器显示出比 SSD 更快的插入速率：

• 15k ~= 35,800 次插入/秒
• SSD != 27,000 次插入/秒

然后我通过执行'SELECT * FROM table INTO OUTFILE'/tmp/table.txt'来测试SELECT速度：

• 15kk ~= 3,000,000 行在 4.19 秒内
• SSD ~= 3,000,000 行在 4.21 秒内

SELECTS 几乎相同，SSD 上的写入速度实际上更慢，这看起来根本不对。关于我接下来应该研究什么有什么想法吗？

额外说明：我使用标准更改调整了 SSD：noatime 和 noob-scheduler

我知道在 SSD 的早期，这个话题已经被讨论到死，而且我知道当时的一些测试表明，升级 CPU 比升级 HDD 更好（主要是由于随机写入性能）。更新请参阅这个 1 岁的社区 wiki 问题。

但是现在，像 Corsair Force F40 这样的廉价驱动器提供了良好的全方位性能，有没有人从旧的 HDD 迈向新的 SSD 的一步？

我的直觉告诉我升级我的核心系统（主板 + CPU）会贵得多，而且收益不会是构建时间减半，但我在互联网上找不到任何关于新 SSD + Visual Studio 构建的证据稍旧的系统上的时间。

更新 我的系统规格供参考：Core 2 Duo 2.8Ghz，4GB Ram

更新 2 请参阅此博客文章，其中测试了较旧的 SSD 并且没有提高编译时间。

有没有人有使用 r/python 和存储在固态驱动器中的数据的经验。如果您主要进行读取，理论上这应该会显着改善大型数据集的加载时间。我想知道这是否属实，是否值得投资 SSD 以提高数据密集型应用程序的 IO 速率。

是否可以在 VMWare ESXI 4.1 中使用 sata ssd（例如 Intel X25-M）？

这将用于戴尔 poweredge r310（只有板载 sata，没有 raid 控制器）。此时，标准 7200 RPM SATA 驱动器可以正常工作。

我在硬件兼容性列表中找不到任何 ssd。ESXI 会识别一个吗？您如何执行 TRIM 功能，ESXI 会这样做吗？有什么问题吗？

提前致谢。

我有一个线程池将数据写入 SSD 磁盘。(windows XP, c#) 我想选择一个池大小来优化性能。从理论上讲，是否应该通过更多线程来提高性能？SSD 如何处理并发写入？还有并发读取，就此而言？

谢谢！

What I Want

I want to simulate the performance of a normal hard drive on my SSD based development machine.

Background

I'm developing a Mac application on a Macbook with an SSD. It's gloriously fast.

If someone has a standard platter hard drive, my app will be slower for them. My app is heavy on Core Data too, so the disk access speed will be a significant factor.

I worry that the performance measurements I take with Instruments look fine, but when a customer runs my app on their normal hard drive it will be achingly slow.

What I've Tried

Before I installed my SSD, I measured the performance of my app in Instruments. After the install, I measured it again and the two benchmarks were identical.

This doesn't make sense to me. I'm convinced I was doing something wrong here. Instruments probably measures clock speed, not wall time speed. But still, surely the speed of the hard drive should affect the benchmark I took? Or does Instruments somehow compensate for this?

亲爱的开发人员，出于某种原因，在 SSD 磁盘上更新 1720 条记录大约需要 15 秒（尤其是在启用修剪时）。

我使用以下文档调整了 sqlite 设置（效果很好） http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

我有以下 PRAGMA 设置来优化性能，并且我确实使用了围绕完整更新集的事务。

看起来 SSD 做的太多了（比如删除块等），这使得它阻塞了 15 秒，仅更新了 1720 条简单记录。

奇怪的是：插入 2500 条记录几乎是即时的。你能帮助我并给我一些指示如何解决这个问题吗？

我想知道即将到来的 SSD 技术如何影响（大多数系统）编程。出现了很多问题，但这里有一些最明显的问题：

• 磁盘访问速度是否可以考虑接近内存速度？
• 如果不是，它只是一种临时状态，还是有一些根本原因导致 SSD 永远不会像 RAM 一样快？
• B-Trees（及其表亲）仍然相关吗？
• 如果是这样，是否对 SSD 的 B-Trees（B+-Trees、R-Trees 等）进行了任何调整或修改？如果没有，是否还有其他为 SSD 设计的数据结构？

For instance, I want to find out how many times I built the solution in a day and how long the process took in total (per day).

I want to buy an ssd and I am not convinced it would save me a lot of time based on my current pattern of computer usage, so I want to go more scientifically about it. I spend most of my time typing, thinking as well, and compiling a C# solution with a few projects (on my current hdd it takes about 5-15s to compile the solution) and possibly in the future Java code. Everybody says they are very fast but the price holds me back.

Thanks

我想用企业级 SSD 升级现有的存储子系统。但是，我几乎没有发现关于是否应将机箱缓存设置为 WriteBack 或 WriteThrough 的证据。

我想某些子系统可能会比其他子系统更好地处理这个问题，在 SSD 上重新排序排队的 I/O 请求并不重要，因为没有任何寻道时间。

我相信 WriteBack 设置允许控制器在实际将数据写入磁盘之前将立即 I/O 完成消息发送回主机。但在 SSD 上，这种延迟是否显着？

我倾向于直写并放弃电池备份单元，但我很想听听任何关于这方面的子系统 SSD 经验。