我一直在使用 AgensGraph 的测试版 (0.9) 过去几周。
现在，我正在我的 VM 机器上测试产品（具有 2 个内核和 2gb 内存）， 并计划将产品安装在真实服务器上（x86_64，32核，96gb内存）。
在我计划安装时，我很难为产品找到合适的参数。
当然，由于产品是基于 PostgreSQL 的，我对产品使用的所有参数都非常熟悉。但是，由于我们讨论的是图形数据（而不是关系数据），我不确定我是否可以像以前在 PostgreSQL 服务器上那样分配服务器内存并进行硬件调整。
如果有人可以回答我关于数据库参数配置和硬件大小的问题或提供指导，那将非常有帮助。
供您参考，我的测试场景如下：
【问题讨论】：
标签： graph-databases agens-graph
AgensGraph 的优点之一是 PostgreSQL 的大部分操作经验都适用。因此，如果您已经熟悉 PostgreSQL，并且有一些在生产中操作 PostgreSQL 的经验，那么配置 AgnsGraph 也将非常有帮助。
但正如您也指出的，AgensGraph 是一个图形数据库，其工作负载是广泛的随机 I/O 访问。因此，为了优化查询性能，您可以尽可能多地分配共享缓冲区，并使用图形对象预热数据库实例。当然，AgensGraph 也可以利用文件系统缓冲区，但是如果您可以为图形数据显式分配足够的共享缓冲区，并且图形数据缓存在共享缓冲区中，则性能可能是最好的。
您可以使用 pg_prewarm 扩展来预热 AgensGraph 缓存。您可以参考此链接 (https://www.postgresql.org/docs/9.6/static/pgprewarm.html) 了解如何使用此扩展程序。
如果您想通过图形数据预热缓存，例如“test_graph”，您可以使用以下查询。
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');
此查询使用“test_graph”的堆空间和索引来预热缓存。这是一个相当长而复杂的查询。但我认为 AgnsGraph 在不久的将来会提供更简单的方法来做到这一点。
并且当整个数据都可以缓存在内存中时，可以推荐设置random_page_cost = 1。该参数意味着随机页面扫描的成本与顺序扫描相同。但是因为这会影响查询优化器选择最优计划，所以你应该小心改变它。
最后一件事，如果你有很多并发用户，你还应该注意平衡shared_buffers 和work_mem 的大小。在分析您的工作负载之前，我不能假设任何事情。但一般来说，更多并发客户端意味着更多work_mem 的使用。因此，如果shared_buffers 和work_mem 的总量超过物理内存的大小，就会发生页面错误。你必须避免这种情况。
【讨论】：