AgensGraph 推荐的内存参数和硬件大小
AgensGraph recommended memory parameters and hardware sizing
我一直在玩 AgensGraph 的测试版 (0.9)
最近几周。
现在，我正在我的 VM 机器（2 核和 2GB 内存）上测试产品，
并计划在真实服务器（x86_64 32 核和 96GB 内存）上安装产品。
虽然我正在计划安装，但我很难为产品找到合适的参数。
当然，由于产品是基于PostgreSQL的，所以产品使用的所有参数我都比较熟悉。但是，由于我们谈论的是图形数据（不是关系数据），我不确定我是否可以像以前在 PostgreSQL 服务器上那样分配服务器内存和调整硬件大小。
如果有人能回答我关于数据库参数配置和硬件大小调整的问题或提供指导，那将非常有帮助。
供参考，我的测试场景如下：
- os: CentOS 6.5
- cpu：2 X 英特尔至强 CPU E5-2640 v3 @ 2.60GHz
- 核心总数：32 个核心（带超线程）
- 内存：96GB
- 数据大小：约60gb
- 并发用户：100
AgensGraph的一大优点是PostgreSQL的大部分运维经验都适用。所以如果你已经熟悉PostgreSQL并且有一些在生产中操作PostgreSQL的经验，那么配置AgensGraph也会非常有帮助。
但正如您也指出的那样，AgensGraph 是一个图形数据库，其工作负载是广泛随机的 I/O 访问。因此，为了优化查询性能，您尽可能多地分配共享缓冲区，并使用图形对象预热数据库实例。当然，AgensGraph 也可以利用文件系统缓冲区，但如果您可以为图形数据显式分配足够的共享缓冲区，并且图形数据缓存在共享缓冲区中，则性能可能是最好的。
您可以使用 pg_prewarm 扩展来预热 AgensGraph 缓存。您可以参考此 link (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' 的堆空间和索引预热缓存。这是一个漫长而复杂的查询。但我认为 AgensGraph 会在不久的将来提供更简单的方法来做到这一点。
而当整个数据都可以缓存在内存中时，可以推荐设置random_page_cost = 1。该参数表示随机页面扫描的成本与顺序扫描相同。但是因为这会影响查询优化器选择最优计划，所以你要小心改变这个。
最后一点，如果你有很多并发用户，你也应该注意平衡 shared_buffers 和 work_mem 的大小。在分析您的工作量之前，我无法假设任何事情。但一般来说，更多的并发客户端意味着 work_mem 的更多使用。因此，如果 shared_buffers 和 work_mem 的总量超过了物理内存的大小，就会发生页面错误。你必须避免这种情况。
我一直在玩 AgensGraph 的测试版 (0.9) 最近几周。
现在，我正在我的 VM 机器（2 核和 2GB 内存）上测试产品， 并计划在真实服务器（x86_64 32 核和 96GB 内存）上安装产品。
虽然我正在计划安装，但我很难为产品找到合适的参数。
当然，由于产品是基于PostgreSQL的，所以产品使用的所有参数我都比较熟悉。但是，由于我们谈论的是图形数据（不是关系数据），我不确定我是否可以像以前在 PostgreSQL 服务器上那样分配服务器内存和调整硬件大小。
如果有人能回答我关于数据库参数配置和硬件大小调整的问题或提供指导，那将非常有帮助。
供参考，我的测试场景如下：
- os: CentOS 6.5
- cpu：2 X 英特尔至强 CPU E5-2640 v3 @ 2.60GHz
- 核心总数：32 个核心（带超线程）
- 内存：96GB
- 数据大小：约60gb
- 并发用户：100
AgensGraph的一大优点是PostgreSQL的大部分运维经验都适用。所以如果你已经熟悉PostgreSQL并且有一些在生产中操作PostgreSQL的经验，那么配置AgensGraph也会非常有帮助。
但正如您也指出的那样，AgensGraph 是一个图形数据库，其工作负载是广泛随机的 I/O 访问。因此，为了优化查询性能，您尽可能多地分配共享缓冲区，并使用图形对象预热数据库实例。当然，AgensGraph 也可以利用文件系统缓冲区，但如果您可以为图形数据显式分配足够的共享缓冲区，并且图形数据缓存在共享缓冲区中，则性能可能是最好的。
您可以使用 pg_prewarm 扩展来预热 AgensGraph 缓存。您可以参考此 link (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' 的堆空间和索引预热缓存。这是一个漫长而复杂的查询。但我认为 AgensGraph 会在不久的将来提供更简单的方法来做到这一点。
而当整个数据都可以缓存在内存中时，可以推荐设置random_page_cost = 1。该参数表示随机页面扫描的成本与顺序扫描相同。但是因为这会影响查询优化器选择最优计划，所以你要小心改变这个。
最后一点，如果你有很多并发用户，你也应该注意平衡 shared_buffers 和 work_mem 的大小。在分析您的工作量之前，我无法假设任何事情。但一般来说，更多的并发客户端意味着 work_mem 的更多使用。因此，如果 shared_buffers 和 work_mem 的总量超过了物理内存的大小，就会发生页面错误。你必须避免这种情况。