其中一个(Ubuntu 16.04)谷歌云虚拟机的其中一个卷的磁盘利用率几乎一直是100% - 这是从系统中随机抽取的10秒样本:
iostat -x 10
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdd 0.60 17.20 5450.50 2468.00 148923.60 25490.00 44.05 11.81 1.49 1.13 2.29 0.13 99.60
这是目前的2.5T持久SSD.
我的理解是,通过添加虚拟"主轴"然后在它们之间分配工作负载,我无法获得更好的性能.
这是一个数据库卷,所以我也不能真正使用易失性SSD.
我目前在XFS上有这些挂载选项:
type xfs (rw,noatime,nodiratime,attr2,nobarrier,inode64,noquota)
有什么建议？
我的neo4j-2.3.2社区数据库用完了磁盘空间(80G).我做了一个干净的关闭它,然后添加了更多的磁盘,并试图启动它备份,只是为了得到神秘的错误消息,并让它拒绝启动.
今天早上,当我意识到磁盘已满并且不再接受任何插入时,我把它关闭了.直到今天晚上我都没有回来试图把它带回来.我为停机和重启之间的日志中的明显差距道歉.数据库仍处于原型/概念验证阶段.在过去一周左右的时间里,我一直在运行作业来加载数据.我真的,真的不想重新开始那个数据加载过程.这太慢了.
我希望有人会告诉我有一个"neo4j --force_repair"类型的命令行选项可以解决这个问题.我的数据加载器非常智能,可以在尝试加载新记录之前检查它在数据库中成功插入的最后记录,因此如果我们丢失了一些,那么它应该没问题.
这是我在console.log中看到的内容.
2016-01-31 16:25:56.648+0000 INFO Successfully shutdown Neo4j Server
2016-01-31 16:25:56.810+0000 INFO Successfully stopped database
2016-01-31 16:25:56.811+0000 INFO Successfully shutdown database
2016-02-01 01:16:10.591+0000 INFO Successfully shutdown Neo4j Server
2016-02-01 01:16:10.593+0000 ERROR Failed to start Neo4j: Starting Neo4j failed: Component 'org.neo4j.server.database.LifecycleManagingDatabase@2d9e9010' was successfully initialized, but failed to start. Please see attached cause exception. Starting Neo4j failed: Component 'org.neo4j.server.database.LifecycleManagingDatabase@2d9e9010' was successfully initialized, but failed to start. Please see attached cause exception.
org.neo4j.server.ServerStartupException: Starting Neo4j failed: Component 'org.neo4j.server.database.LifecycleManagingDatabase@2d9e9010' was successfully …由于Neo4j主要在内存中工作,我想知道在我的Linux内核中启用大页(https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt)是否有利,然后XX:+ UseLargePages或者-XX:+(OpenJDK 8)JVM中的UseHugeTLBFS？
如果是这样,我应该使用什么经验法则来决定要配置多少个大页？
Neo4j性能指南(http://neo4j.com/docs/stable/performance-guide.html)没有提到这一点,谷歌没有提出任何其他人讨论它(无论如何在前几个搜索页面),所以我想我会问.
我正在努力从我的新Neo4j实例(2.3.2社区)获得可接受的性能.任何一点都会有所帮助.我想知道在我关闭数据库以更改JVM标志之前是否值得尝试...我希望其他人已经在这些方面做了一些实验.
谢谢!
如果有一种简单的方法可以配置"网站处于维护状态"或"网站关闭"页面,那么仅仅查看Google Load Balancer文档对我来说并不明显.
一些云负载平衡器允许您上传一个简单的html页面,然后提供一个"复选框"来提供该页面,直到您取消选中它.
或者他们允许您上传自定义错误页面,当http运行状况检查失败时,它们会自动提供该错误页面.
或两者.
这可以通过Google云基础架构轻松完成吗？
我知道我们可以编辑我们的nginx配置来提供这样一个页面,但是我正在寻找一些更加白痴证明的东西,以及当nginx也失效时甚至可以工作的东西.
(并不是说我们想要那么多,但有时它会发生,并且能够发布故意的"是的,我们知道我们已经失败了 - 我们很快就会重新开始".)
我在让 python 函数web3.geth.txpool.inspect() 工作时遇到问题。
我已经尝试从命令行、ethereum/client-go容器和容器中使用 geth 服务器trufflesuite/ganache-cli:v6.7.0。
在每种情况下，我都会收到 txpool_inspect 方法丢失错误。我正在运行的代码非常简单，使用 Python 3.7.5 或 3.8：
from web3 import Web3
thing = Web3("http://localhost:42424")
thing.geth.txpool.inspect()
我正在使用 web3py==5.2.2 。
对于我尝试过的 Geth：--dev --mine --rpc --rpcaddr 0.0.0.0 --rpcport 42424 --verbosity 4 我也尝试了各种其他启动选项，似乎没有什么能让我克服 txpool_inspect 不存在或丢失的主题识别错误。
在真正的区块链上尝试之前，我想先让它在测试/开发环境中工作。
建议？
我们有一个 PostgreSQL 实例在 Google Cloud 的虚拟机中运行。我们运行的查询的性质涉及大量 PostgreSQL 临时表空间。（每天5 或 6 TB或更多TB的磁盘 I/O）
此 I/O 仍然是我们数据库中的主要瓶颈。目前，这一切都发生在 SSD 永久磁盘上——不是因为我们需要在重启时保存任何数据，而是因为 PostgreSQL 在磁盘上布置了一个文件结构，然后它用于临时表，如果数据库启动时文件结构丢失，不太好。
我想做的是在本地 SSD 上配置临时表空间，因为它们的 I/O 吞吐量要高得多。不幸的是，它们在每次重新启动时都会消失。我想要一种简单的方法，能够在重新启动后和 PostgreSQL 开始备份之前重新布局磁盘。
我可以解压缩空文件结构，然后编写一个脚本，在每次启动后解压缩它。那有意义吗？有没有更好的方法/最佳实践来做到这一点？
如果有一个 PostgreSQL 扩展可以神奇地做到这一点，那就太棒了。
想法？