标签: solid-state-drive

在以下情况下顺序写入和随机写入之间有什么区别: - 1)基于磁盘的系统2)基于SSD [闪存设备]的系统

当应用程序写入某些东西并且需要在磁盘上修改信息/数据时,我们如何知道它是顺序写入还是随机写入.到此为止,写入不能被区分为"顺序"或"随机".写入只是缓冲,然后在我们刷新缓冲区时应用到磁盘.

如果我错了,请纠正我.

我准备发布一个只对常规硬盘有效的工具,而不是SSD(固态硬盘).实际上,它不应该与SSD一起使用,因为它会导致大量读/写而没有实际效果.

任何人都知道检测给定驱动器是否为固态的方法？

我想尝试加快我的C++项目的编译时间.他们有大约3M行代码.

当然,我不需要总是编译每个项目,但有时会有很多源文件被其他人修改,我需要重新编译它们(例如,当有人更新ASN.1源文件时).

我已经测量过编译一个中间项目(不涉及所有源文件)需要大约三分钟.我知道这不是太多,但有时候等待编译真的很无聊..

我试图将源代码移动到SSD(旧的OCZ Vertex 3 60 GB),基准测试,它比HDD快5到60倍(特别是在随机读/写中).无论如何,编译时间几乎相同(可能快2-3秒,但它应该是一个机会).

将Visual Studio bin移动到SSD可能会增加性能？

只是为了完成这个问题:我有一个W3520 Xeon @ 2.67 GHz和12 GB的DDR3 ECC.

固态硬盘现在司空见惯; Amazon EBS由SSD支持,因此大多数云数据库现在也运行在SSD(Heroku PostgreSQL等)上.传统上,数据库和相关体系结构的设计理念是随机访问不好 - SSD不再是这种情况.

SSD如何影响以下？

1. 数据库设计 - 数据库旨在最大限度地减少磁盘搜索(WAL,B树).SSD如何改变数据库设计的内部和调整？
2. 应用程序开发 - 工作假设一直是(a)您希望从内存而不是DB服务器用户请求,以及(2)对数据库的访问是IO绑定的.使用SSD,从数据库中检索数据可以足够快,并且数据库访问通常是网络绑定的.这是否减少了对内存数据库的需求？显然,您仍然希望预先计算昂贵的操作,但您可能只是将它们存储在数据库中
3. 专业数据库 - 有很多数据库可以处理关系数据库认为不好的事情(部分原因是随机数据访问).一个这样的例子是图形DB(Neo4j),它以紧凑的方式在磁盘上存储节点和邻接列表.如果我们可以在SSD上部署RDBMS而不担心随机访问,这些数据库是否有用？

我正在开发一个OS便携式程序,它可以从检测物理存储设备是SSD还是普通旧的旋转磁盘中受益.

在Linux上有:

/sys/block/sdX/queue/rotational

如果SSD返回0或1,但我不确定这是否是最好的方法.

在Windows和UNIX上,我还没有找到任何方法来检测它,也许我应该使用ioctl DEVICE_SEEK_PENALTY_DESCRIPTOR并检查搜索功能(在SSD存储设备上应该非常低),或者可能用于DeviceIoControl检查标称介质旋转速率(也应该在SSD存储设备上非常低).

有关如何在POSIX兼容操作系统上检测SSD磁盘的任何建议吗？

I would like to change the performance and behaviour of my C++ application, according to whether the system drive is an SSD or not. Example:

• With SSD, I want my gameserver application to load each map fully, with all objects in order to maximize performance.
• With HDD, I want my gameserver application to load only the essential objects and entities in each map, with no external objects loaded.

I've seen http://msdn.microsoft.com/en-gb/library/windows/desktop/aa364939(v=vs.85).aspx, which is a way of determining if a …

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

该场景大约有10亿条记录.每条记录的数据大小为1kb,并存储在SSD中.哪个kv商店可以提供最佳的随机读取性能？它需要将每次查询的磁盘访问次数减少一次,并且所有数据索引都将存储在内存中.

Redis速度很快,但在内存中存储1 TB数据太昂贵了.LevelDB每次查询多次读取磁盘.我找到的最接近的是fatcache,但它并不持久.这是一个SSD支持的memcached.

有什么建议？

鉴于固态硬盘(SSD)的价格正在下降并且很快将变得更加普遍,因为它们的访问速率明显高于旋转磁介质,那么标准算法将通过使用SSD来获得性能存储？例如,SSD的高随机读取速度使得类似于基于磁盘的散列表具有大型散列表的可行性; 容易获得4GB的磁盘空间,这使得散列到32位整数的整个范围都是可行的(更多的是查找而不是人口,但这仍然需要很长时间); 虽然由于访问速度的原因,这个哈希表的大小将无法与旋转媒体一起使用,但它不应该是SSD的问题.

是否有任何其他领域即将过渡到SSD将提供算法性能的潜在收益？我宁愿看到关于一件事情如何发挥而不是舆论的推理; 我不希望这变成有争议的.

我们正在开发具有以下属性的SSD支持的键值解决方案:

• 吞吐量:10000 TPS; 50/50看/得;
• 延迟:平均1ms,99.9百分位10ms
• 数据量:约10亿个值,每个约150个字节; 64位密钥; 随机访问,20%的数据适合RAM

我们在商用SSD上尝试了KyotoCabinet,LevelDB和RethinkDB,使用不同的Linux IO调度程序,ext3/xfs文件系统; 使用Rebench进行了多次测试; 并发现在所有情况下:

• 只读吞吐量/延迟非常好
• 整个写入/更新是适度的,但有许多高延迟异常值
• 即使在直接访问块设备(绕过文件系统)的情况下,混合读/写工作负载也会导致吞吐量/延迟出现灾难性的振荡

下图说明了KyotoCabinet的这种行为(横轴是时间,三个周期清晰可见 - 只读,混合,仅更新).

问题是:是否可以使用SSD实现所描述的SLA的低延迟以及建议使用哪些键值存储？