8G 云服务器上启了个 clickhouse，它总会因为某些 SQL 挂掉，现在想监控它，在它挂掉时能自己启动。我对 clickhouse🐔毛不懂，时间有限，想了 1 个简单方案和 1 个复杂，求帮忙看看。。。

[v2exblog]

如题。

简单方案： 写个后台脚本，定时监测 clickhouse 进程是否寄了，寄了就启动，治标不治本，实现起来快

复杂方案： 根据配置调优，或者扩大内存。收集最近导致服务挂掉的 SQL ，研究一下根本原因，这个方案可能花的时间会很多

另外请教，你们的 clickhouse 是怎么运维的...

谢谢各位大佬！打算用 docker 去弄了，还是 docker 省心

[foolvino]

改为 supervisor 启动

[zhenjiachen]

用 docker 才是最快的，用 docker compose 的 health check ，定时检测服务器接口是否健康，如果接口调用失败会自动重启。

[RangerWolf]

我的生产环境就是用的 docker~ 在启动的时候 docker --restart always 就好了。。。

[RangerWolf]

另外在 clickhouse 里面，systems.query_thread_log 等相关表，有很详细的记录，推荐去找找看，看看能不能找到蛛丝马迹。但是如果是生产环境，8G 确实太小了。实在没办法，你可以修改配置文件，把允许的最大内存使用量降低。
我记得默认就是 8G ，但是系统里面还有其他的地方用了内存，就可能导致你的 Clickhouse 被干掉了

[faceair]

有钱省事方案：买云厂商运维的 clickhouse

[podel]

+1 docker 启动 docker --restart always
或者 systemd 管理 挂掉后自动重启就行了。

[octobersnow]

可以现在 SQL 使用内存的

[alsas]

docker 或者 systemd

[Itoktsnhc]

docker --restart always , 然后通过 clickhouse 配置限制下使用的最大内存之类的配置

[pastor]

这配置，是在侮辱 clickhouse 还是在侮辱自家业务...

[v2exblog]

@pastor 哈哈哈老哥，这个 clickhouse 里面表不多，主要是为了报表展示的系统弄的，聚合起来能比 PG 快一些

[julyclyde]

systemd 是唯一方案
supervisord 它自己都不能保证重启，有什么资格去管别人
cron 里检测重启会导致程序所属的 cgroup 变成 user slice

[NikoXu]

systemd

[changdy]

@pastor 到也正常吧 比如有时候我只是想用到列式存储的优点 .不需要事务之类的情况 ,clickhouse 也是一个比较好的选择,

[changdy]

@v2exblog 会差多大?