0

我们正面临来自 Ceph MDS 守护进程的不断崩溃。我们已经安装了 Mimic (v13.2.1)。

mds: cephfs-1/1/1 up {0=node2=up:active(laggy or crashed)}

我们遵循了列出的 DR 步骤

http://docs.ceph.com/docs/mimic/cephfs/disaster-recovery/

请帮助解决以下错误。

mds 崩溃堆栈跟踪

 ceph version 13.2.1 (5533ecdc0fda920179d7ad84e0aa65a127b20d77) mimic (stable)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0xff) [0x7f984fc3ee1f]
 2: (()+0x284fe7) [0x7f984fc3efe7]
 3: (()+0x2087fe) [0x5563e88537fe]
 4: (Server::prepare_new_inode(boost::intrusive_ptr<MDRequestImpl>&, CDir*, inodeno_t, unsigned int, file_layout_t*)+0xf37) [0x5563e87ce777]
 5: (Server::handle_client_openc(boost::intrusive_ptr<MDRequestImpl>&)+0xdb0) [0x5563e87d0bd0]
 6: (Server::handle_client_request(MClientRequest*)+0x49e) [0x5563e87d3c0e]
 7: (Server::dispatch(Message*)+0x2db) [0x5563e87d789b]
 8: (MDSRank::handle_deferrable_message(Message*)+0x434) [0x5563e87514b4]
 9: (MDSRank::_dispatch(Message*, bool)+0x63b) [0x5563e875db5b]
 10: (MDSRank::retry_dispatch(Message*)+0x12) [0x5563e875e302]
 11: (MDSInternalContextBase::complete(int)+0x67) [0x5563e89afb57]
 12: (MDSRank::_advance_queues()+0xd1) [0x5563e875cd51]
 13: (MDSRank::ProgressThread::entry()+0x43) [0x5563e875d3e3]
 14: (()+0x7e25) [0x7f984d869e25]
 15: (clone()+0x6d) [0x7f984c949bad]
 NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

mds 日志：https://pastebin.com/AWGMLRm0

4

1 回答 1

0

Ceph 13.2.2发行说明说以下...

不再需要 bluestore_cache_* 选项。它们被 osd_memory_target 替换，默认为 4GB。BlueStore 将扩展和收缩其缓存以尝试保持在此限制内。升级的用户应该注意，这比之前的 bluestore_cache_size 1GB 更高，因此使用 BlueStore 的 OSD 默认会使用更多内存。有关更多详细信息，请参阅 BlueStore 文档。

这让我大吃一惊。我的 osds 对常驻内存的使用非常疯狂。内核正在 oom-killing osd 进程。

切换到新密钥并反弹 osd 进程给了我稳定的性能。因此，mds 似乎已经稳定下来。

我已经成功测试的东西......

  • 写的很稳定
  • 新数据的读取是稳定的（小于 1 年的文件）
  • 旧数据的读取是稳定的（大于 1 年的文件）
  • rm 的新文件是稳定的（小于 1 年的文件）

我还没有测试过 rm 的旧文件（超过 1 年的文件）。这是我看到 mds 不稳定性最严重的地方。

于 2019-01-15T02:59:45.077 回答