我一直在玩AgensGraph的测试版（0.9） 过去几周。
现在，我正在我的VM机器上测试该产品（具有2个内核和2GB内存）， 并计划在真实服务器（具有32核和96GB内存的x86_64）上安装产品。
在我计划安装时，我很难找到适合该产品的参数。
当然，由于该产品基于PostgreSQL，我对产品使用的所有参数非常熟悉。但是，由于我们讨论的是图形数据（不是关系数据），我不确定是否可以像以前在PostgreSQL服务器上那样分配服务器内存并进行硬件调整。
如果有人可以回答或提供有关数据库参数配置和硬件大小调整的问题的指南，那将非常有用。
有关您的信息，我的测试方案编写如下：
答案 0 :(得分：2)
AgensGraph的一个好处是PostgreSQL的大多数操作体验都适用。因此，如果您已熟悉PostgreSQL并具有在生产中操作PostgreSQL的一些经验，那么配置AgensGraph也非常有用。
但正如您也指出的那样，AgensGraph是一个图形数据库，其工作负载是广泛随机的I / O访问。因此，为了优化查询性能，您可以尽可能多地分配共享缓冲区，并使用图形对象预先预处理数据库实例。当然，AgensGraph也可以利用文件系统缓冲区，但是如果你可以为图形数据显式分配足够的共享缓冲区并且图形数据缓存在共享缓冲区中，那么性能可能是最好的。
您可以使用pg_prewarm扩展来预热AgensGraph缓存。您可以参考此链接（https://www.postgresql.org/docs/9.6/static/pgprewarm.html）以了解如何使用此扩展程序。
如果您希望通过图表数据预热缓存，请说“test_graph＆＃39;”，您可以使用以下查询。
select pg_prewarm(c.oid)
from pg_class c
left join pg_namespace n on n.oid = c.relnamespace
where nspname = 'test_graph' and (relkind = 'i' OR relkind = 'r');
此查询使用堆空间和＆＃39; test_graph＆＃39;的索引来加热缓存。这是一个冗长而复杂的查询。但我认为AgensGraph将在不久的将来提供更简单的方法。
当整个数据可以缓存在内存中时，建议设置random_page_cost = 1。此参数表示随机页面扫描的成本与顺序扫描相同。但是因为这会影响查询优化器选择最佳计划，所以应该小心改变它。
最后，如果你有很多并发用户，你也应该小心平衡shared_buffers和work_mem的大小。在分析您的工作负载之前，我不能假设任何事情。但一般而言，更多并发客户端意味着更多work_mem的用法。因此，如果shared_buffers和work_mem的总量超过物理内存的大小，则可能发生页面错误。你必须避免这种情况。