On Sat, Nov 9, 2013 at 7:53 AM, Mark Nelson wrote:
> One thing to try is run the mon and then attach to it with perf and see
> what it's doing. If CPU usage is high and leveldb is doing tons of
> compaction work that could indicate that this is the same or a similar
> problem to what we were see
One thing to try is run the mon and then attach to it with perf and see
what it's doing. If CPU usage is high and leveldb is doing tons of
compaction work that could indicate that this is the same or a similar
problem to what we were seeing back around cuttlefish.
Mark
On 11/08/2013 04:53 PM
Hrm, there's nothing too odd in those dumps. I asked around and it
sounds like the last time we saw this sort of strange memory use it
was a result of leveldb not being able to compact quickly enough. Joao
can probably help diagnose that faster than I can.
-Greg
Software Engineer #42 @ http://inkta
I try to dump perf counter via admin socket, but I don't know what does
these numbers actual mean or does these numbers have any thing to do with
the different memory usage between arm and amd processors, so I attach the
dump log as attachment(mon.a runs on AMD processor, mon.c runs on ARM
processo
I don't think this is anything we've observed before. Normally when a
Ceph node is using more memory than its peers it's a consequence of
something in that node getting backed up. You might try looking at the
perf counters via the admin socket and seeing if something about them
is different between
We recently discussed briefly the Seagate Ethernet drives, which were
basically dismissed as too limited. But what about moving an ARM SBC to
the drive tray, complete with an mSATA SSD slot?
A proper SBC could implement full Ubuntu single-drive failure domains
that also solve the journal is
Finally, my tiny ceph cluster get 3 monitors, newly added mon.b and mon.c
both running on cubieboard2, which is cheap but still with enough cpu
power(dual-core arm A7 cpu, 1.2G) and memory(1G).
But compare to mon.a which running on an amd64 cpu, both mon.b and mon.c
easily consume too much memory,
