El 2020-10-20 23:17, Anthony D'Atri escribió:
On Oct 20, 2020, at 6:23 PM, Ing. Luis Felipe Domínguez Vega
<luis.dominguez@xxxxxxxxx> wrote:
El 2020-10-20 19:33, Anthony D'Atri escribió:
You have a *lot* of peering and recovery going on.
Write a script that monitors available memory on the system and
restarts the OSD process using the most when it crosses some
threshold. Run that on all OSD nodes. OSDs will come up, make some
progress, get restarted, but eventually they’ll sync up.
On Oct 20, 2020, at 2:57 PM, Ing. Luis Felipe Domínguez Vega
<luis.dominguez@xxxxxxxxx> wrote:
Hi, today mi Infra provider has a blackout, then the Ceph was try to
recover but are in an inconsistent state because many OSD can
recover itself because the kernel kill it by OOM. Even now one OSD
that was OK, go down by OOM killed.
Even in a server with 32GB RAM the OSD use ALL that and never
recover, i think that can be a memory leak, ceph version octopus
15.2.3
In: https://pastebin.pl/view/59089adc
You can see that buffer_anon get 32GB, but why?? all my cluster is
down because that.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
That's the only solution???
I didn’t say that. If you don’t like it, don’t do it. You can also
try eras’ idea. You’ve offered almost no detail about your cluster or
hardware.
there is nothing to limit the OSD resource usage on recover?
Sorry, what is the era's idea? And i can send my cluster info, what do
you need to try a solution (already i'm running your suggestion of a
script that restart the OSD on high memory)
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
