>具有以下组合的服务器的旧群集 –
将数据存储在磁盘i2.2xlarge实例中Aerospike build vesion 3.8.2.3
>具有以下组合的服务器的较新群集 –
将数据存储在内存r3.4xlarge实例中Aerospike使用partition-tree-sprigs构建版本3.14.1.1
我想比较它们的服务器端延迟和超时.
我通过以下命令启用了使用Aerospike内置的asgraphite守护程序 –
python /opt/aerospike/bin/asgraphite --start --prefix aerospike.stats -g <URL> -p <port>
我无法在石墨控制台中看到针对旧群集的延迟统计信息(请参见屏幕截图中的突出显示) –
另外,我很困惑,我应该考虑哪种延迟属性.
针对较旧的群集提供以下统计信息 –
Metric Value observed on one node batch_index_timeout 0 batch_timeout 0 err_tsvc_requests_timeout ~80K stat_rw_timeout ~500K
正如预期的那样,批次统计信息显示为0,因为我们没有进行任何批量查询.高于3.9的新群集没有err_tsvc_requests_timeout和stat_rw_timeout指标.
The relevant manual page of aerospike提到了已弃用的指标 –
As of version 3.9, refer to the more specific stats at the namespace
level.
不确定是哪些.
开放赏金
metrics reference manual提到了metricstat_rw_timeout –
As of version 3.9, refer to the more specific stats at the namespace
level.
我希望石墨Web控制台中的命名空间值能够反映出来,但我能看到的只有以下内容 – ops_per_sec,over_1ms,over_64ms等.
所以,基本上我现在正在寻找两件事 –
>某些统计/指标移动到命名空间级别的确切含义.如何在石墨网络控制台中查看,它可以看到它.
>更多关于为两个版本选择适当的延迟和超时指标的指针.我正在研究通过PHP客户端API函数读取和编写aerospike缓存键的常见用例 –
Aerospike->得到()
Aerospike->放()
更新2
超时 – 最后,我能够在新的构建版本中找到重组的超时相关参数,如答案https://stackoverflow.com/a/45244090/351903中所述.
但是,client_write_timeout等值是累积的,很难在集群之间进行比较,因为日志可能已在其中一个集群中更早开始.最好有超时的瞬时指标.
更新3
延迟 – 由于我没有在石墨Web控制台中获得低于3.9的构建版本的延迟统计数据,我计划使用asloglatency并将这些统计信息转储到石墨服务器以获取这两个构建版本.
为了以图形方式统一比较延迟,我计划 –
>设置一个每5分钟运行一次的cron.
>运行asloglatency命令以收集以下延迟统计信息,持续2分钟,从两个构建版本的最后5分钟开始 –
> avg of – %大于1 ms,8和64 ms以及每秒操作数.
>最大值 – %大于1 ms,8和64 ms以及每秒操作数.
版本的Asloglatency命令> 3.9
asloglatency -N FC -h write -f -0:05:00 -d 0:60:00 asloglatency -N FC -h read -f -0:05:00 -d 0:60:00
版本命令< 3.9
asloglatency -h writes_master -f -0:05:00 -d 2:00 asloglatency -h reads -f -0:05:00 -d 2:00
注意 – 我通过运行asgraphite命令获得了新构建的延迟统计信息 –
python /opt/aerospike/bin/asgraphite --start -g <domain> -p <port>
但是我不确定在石墨控制台中{HOSTNAME} .latency下的新构建 – avg或max值时,会记录上述哪些统计信息.我没有在指标参考手册中找到任何相同的文档.
此外,上述命令未在旧版本的石墨控制台中显示延迟统计信息.
希望使用asloglatency派生的统计信息在两个构建版本中是统一的.
通过开放赏金 – 寻找确认,这将是工作/将是我想要找到的最佳方式/指向更容易的方式做同样的事情.
更新4
1.超时
我可以通过在通过记录stat_rw_timeout获得的图形上应用derivative()来获得旧构建的瞬时超时 –
http://<domain>/render?width=1700&from=-6h&until=now&height=900&target=derivative(aerospike.old_statsip-10-146-210-31.service.stat_rw_timeout)&title=old_latency_cumulative_derivative&hideLegend=false&_salt=1367201670.479&yMax=&_uniq=0.985620767407021
但是,即使client_read_success显示值,新构建的超时也会始终显示0 –
2.延迟
看起来以下asgraphite命令记录了两个构建版本中的延迟,所以我不需要像我在Update 3中提到的那样使用asloglatency完成所有这些工作 –
python /opt/aerospike/bin/asgraphite -l 'latency:' --start --prefix aerospike.temp.old_trial1 -g <graphite server domain> -p <port>
我监控的价值是 –
新建 –
aerospike.temp.new_trial2ip-10-13-215-20.latency.FC.read.over_1ms aerospike.temp.new_trial2ip-10-13-215-20.latency.FC.write.over_1ms
旧建筑 –
aerospike.temp.old_trial1ip-10-182-71-216.latency.reads.over_1ms aerospike.temp.old_trial1ip-10-182-71-216.latency.writes_master.over_1ms
以下是从图表中观察到的结果 –
>在新版本上读取延迟 – 始终为0.
>在新版本上写入延迟 – 只有一个峰值,否则始终为0.
>对旧构建的读写延迟 – 一致数据.
更新5
我只想让我在构建版本中比较正确的延迟和超时比较指标.有人能指出一些与此相关的文档吗?
延迟 – 我已经提到了我在上面的更新4中比较的值.以下是他们在石墨网络控制台中的层次结构 –
超时 – 在指标参考手册中没有直接提及stat_rw_timeout在版本3.9中拆分为client_read_timeout和client_write_timeout.有人可以确认吗?
由于我的观察得出以下结论,我有上述问题/疑问 –
如您所述,最佳资源是Aerospike文档部署部分中的 metrics reference manual.找到旧的,已弃用的统计信息,说明将告诉您调用等效的 release 3.9指标的内容.Stats and Benchmark Migration Guide for the 3.9 Release详细介绍了不同的统计数据.
特别是对于延迟,Histograms from Aerospike Logs具有3.9之后的延迟直方图的细分,pre-3.9 latency histograms在单独的文章中.