【问题标题】:Broken pipe error on query from aerospike从 aerospike 查询时出现断管错误
【发布时间】:2018-04-11 10:34:48
【问题描述】:

我有命名空间“test”并设置“demo” 当我在 aql 终端中运行“select * from test.demo”时,出现此错误。究竟是什么原因导致管道破裂?

我在下面的服务器日志中收到一条警告消息。

我的 aerospike.conf 是:

service {
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1.
    proto-fd-max 15000
}

logging {
    file /var/log/aerospike/aerospike.log {
            context any info
    }
}

network {
    service {
            address any
            port 3000
    }

    heartbeat {
            mode multicast
            multicast-group 239.1.99.222
            port 9918

            # To use unicast-mesh heartbeats, remove the 3 lines above, and see
            # aerospike_mesh.conf for alternative.

            interval 150
            timeout 10
    }

    fabric {
            port 3001
    }

    info {
            port 3003
    }
}

namespace test {
    replication-factor 2
    memory-size 4G
    default-ttl 30d # 30 days, use 0 to never expire/evict.

    storage-engine memory
}
namespace bar {
    replication-factor 2
    memory-size 4G
    default-ttl 30d # 30 days, use 0 to never expire/evict.

    storage-engine memory

    # To use file storage backing, comment out the line above and use the
    # following lines instead.
    #       storage-engine device {
    #               file /opt/aerospike/data/bar.dat
    #               filesize 16G
    #               data-in-memory true # Store data in memory in addition to file.
    #       }
}

有人能找出原因吗?

【问题讨论】:

  • aql 在下面使用 C 客户端。 C 客户端中的错误 -10 是:AEROSPIKE_ERR_CONNECTION 同步连接错误。套接字读取错误 11:资源暂时不可用 - 想知道为什么会这样。
  • 服务器日志中有什么有趣的地方吗?
  • @Meher,嗨 Meher,我刚刚在服务器日志中收到如下警告。 2018 年 4 月 12 日 06:07:58 GMT: 警告 (proto): (proto.c:693) 发送错误 - fd 29 Broken pipe
  • 你在 aql 中设置的超时时间是多少?
  • @Darian.miao 是否有可能在您的命名空间中确实有很多没有与之关联的记录?这会减慢您发出的扫描,然后会导致客户端超时。但是,如果您真的只有这 2 组中的那 2 条记录,那么我不确定是什么原因造成的...您能显示命名空间中的记录总数吗?

标签: aerospike


【解决方案1】:

我认为您在尝试将扫描结果发送到客户端已经超时的套接字时遇到了套接字错误。

Error: (-10) Socket read error: 11, [::1]:3000, 36006

默认情况下,aql 超时设置为 1000 毫秒

使用 -T 命令行选项可以将其提高到 100000 毫秒。 (或在 aql 交互模式中使用设置超时)

aql -T 100000

-T, --timeout <ms> Set the timeout (ms) for commands. Default: 1000 此选项等效于在other clients 上设置 TotalTimeout。

将超时设置得更高应该会有所帮助,但不能回答为什么基本扫描需要这么长时间。

这是一个设置不同客户端超时的示例,这显示了客户端在收到扫描结果之前超时。在日志中,您会看到 TCP 发送扫描错误。

WARNING (proto): (proto.c:693) send error - fd 32 Broken pipe

来自 aql 控制台的详细信息:

aql> set timeout 10
TIMEOUT = 10
aql> select * from test.demo
Error: (-10) Socket read error: 11, 127.0.0.1:3000, 58496

aql> select * from test.demo
Error: (-10) Socket read error: 115, 127.0.0.1:3000, 58498


aql> set timeout 100
TIMEOUT = 100
aql> select * from test.demo
Error: (-10) Socket read error: 115, 127.0.0.1:3000, 58492

aql> set timeout 1000
TIMEOUT = 1000
aql> select * from test.demo
+-----+-------+
| foo | bar   |
+-----+-------+
| 123 | "abc" |
+-----+-------+
1 row in set (0.341 secs)

如果默认超时保持在 1000 毫秒,为什么您的 aql 客户端会超时返回 1 条记录,这仍然是个谜。你有没有机会修改超时。或者在带有空集的测试命名空间中有大量记录。

【讨论】:

  • AQL 是一个交互式 C 应用程序。如果您在庞大的数据集上执行“选择 * ...”,AQL 超时只是为了将输出限制为 AQL。我认为更改超时不会解决这个问题......但让我们看看。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-05-14
  • 2021-07-29
  • 2011-07-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多