Project

General

Profile

Actions

Bug #19343

open

OOM kills ceph-fuse: objectcacher doesn't seem to respect its max objects limits (jewel 10.2.6)

Added by Arne Wiebalck about 7 years ago. Updated about 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Creating a 100G file on CephFS reproducibly triggers OOM to kill the
ceph-fuse process.

With objectcacher debug enabled (debug objectcacher = 10) and looking
at the output (from the "trim" lines) it seems that the reason is that
the objectcacher does not manage to trim its number objects down to the
limit (max = 100 in the example below):

-->
2017-03-20 10:38:53.171177 7fea5f51b700 10 objectcacher trim start: bytes: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171178 7fea5f51b700 10 objectcacher trim finish: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171231 7fea6071f700 10 objectcacher trim start: bytes: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171232 7fea6071f700 10 objectcacher trim finish: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171300 7fea5f51b700 10 objectcacher trim start: bytes: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171301 7fea5f51b700 10 objectcacher trim finish: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171372 7fea6071f700 10 objectcacher trim start: bytes: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171374 7fea6071f700 10 objectcacher trim finish: max 209715200 clean 588, objects: max 100 current 473
2017-03-20 10:38:53.171451 7fea5f51b700 10 objectcacher trim start: bytes: max 209715200 clean 588, objects: max 100 current 474
2017-03-20 10:38:53.171452 7fea5f51b700 10 objectcacher trim finish: max 209715200 clean 588, objects: max 100 current 474
<--

Note that there is no line saying "trim trimming" (from void ObjectCacher::trim()).

This is with ceph-fuse-10.2.6-0.el7.x86_64.

Actions #1

Updated by John Spray about 7 years ago

Hmm, could be that we just have no limit on the number of dirty objects (trim is only dropping clean things), so if we're not writing out to rados quickly enough then the client buffer is just growing and growing.

Actions #2

Updated by Arne Wiebalck about 7 years ago

I see ... so the fix would be to have a dirty_limit (like vm.dirty_ratio) above which all new request would not be cacheable anymore? I guess this doesn't exist yet, does it? Any other way to limit the client-side cache? Or give back-pressure to the client?

Actions #3

Updated by John Spray about 7 years ago

Hmm, I've looked at the code now and it turns out we do already have a client_oc_max_dirty setting that is supposed to block writes and wait for writeback, so something else is going on here.

Actions #4

Updated by Arne Wiebalck about 7 years ago

Just in case it wasn't clear from the log snippet above: the current counter is continously growing until the process gets killed. The original (default) value was 1000, I set it to 100 to see if setting it explicitly would make a difference. How can I confirm that the client uses the 100MB default for client_oc_max_dirty and how can I see how much the current amount of dirty bytes?

Actions #5

Updated by John Spray about 7 years ago

  • Assignee set to John Spray
Actions #6

Updated by John Spray about 7 years ago

Hmm.

I've tried setting some comically low limits:

        client oc size = 10485760                                               
        client oc max dirty = 5242880                                           
        client oc max objects = 1   

and found that it is indeed keeping the cache small when I write a large file. The object count does go up to 3/4 rather than 1, so it's clearly not completely strict, but the client_oc_max_dirty setting blocking writes is kicking in.

What are the settings you've got?

Actions #7

Updated by Arne Wiebalck about 7 years ago

I don't think I have changed the defaults. How can I see the values I use?

Actions #8

Updated by John Spray about 7 years ago

The log says "objects: max 100" but the default of client_oc_max_objects is 1000, so I assumed there was some manual configuration going on.

If you find the .asok file for the fuse client in /var/lib/ceph, then do a "ceph daemon <asok> config show" you can dump the current configuration. There may or may not be an asok file though depending on permissions and configuration (sometimes I set "admin_socket = /tmp/$cluster-$name.asok" for debugging a client).

Actions #9

Updated by Patrick Donnelly about 5 years ago

  • Assignee deleted (John Spray)
Actions

Also available in: Atom PDF