Fork you NodeBB


  • ♿ (Parody)

    I tried to fork some stuff out of the Status thread this morning and it didn't work. Our anti-cooties watchdog process would kill the instance before the forking could complete. So I fired up my dev instance and added some poor man's profiling (logging at points through the process).

    First test was on a relatively small topic in the Staff category (that's where my homepage is, so it's what shows up first...what you expect me to not do the easiest possible thing?). That worked fine:

    3/10 06:52 [3168] - info: sorting
    3/10 06:52 [3168] - info: getCidByPid
    3/10 06:52 [3168] - info: calling async.parallel to get post data / is admin or mod
    3/10 06:52 [3168] - info: creating new topic...
    3/10 06:52 [3168] - info: updating bookmarks
    3/10 06:52 [3168] - info: checking for post edit capability...
    3/10 06:52 [3168] - info: moving post 959509 to topic 20973
    3/10 06:52 [3168] - info: checking for post edit capability...
    3/10 06:52 [3168] - info: moving post 959519 to topic 20973
    3/10 06:52 [3168] - info: checking for post edit capability...
    3/10 06:52 [3168] - info: moving post 983993 to topic 20973
    3/10 06:52 [3168] - info: checking for post edit capability...
    3/10 06:52 [3168] - info: moving post 984002 to topic 20973
    3/10 06:52 [3168] - info: updating timestamp
    3/10 06:52 [3168] - info: get topic data
    

    OK, next up: try the Status thread! That's where the problem was happening, after all:

    3/10 06:52 [3168] - info: sorting
    3/10 06:52 [3168] - info: getCidByPid
    3/10 06:52 [3168] - info: calling async.parallel to get post data / is admin or mod
    3/10 06:52 [3168] - info: creating new topic...
    3/10 06:52 [3168] - info: updating bookmarks
    
    <--- Last few GCs --->
    
      176754 ms: Scavenge 1397.0 (1457.3) -> 1397.0 (1457.3) MB, 0.8 / 0 ms (+ 2.3 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
      177337 ms: Mark-sweep 1397.0 (1457.3) -> 1396.8 (1457.3) MB, 582.6 / 0 ms (+ 3.1 ms in 2 steps since start of marking, biggest step 2.3 ms) [last resort gc].
      177929 ms: Mark-sweep 1396.8 (1457.3) -> 1395.2 (1457.3) MB, 591.9 / 0 ms [last resort gc].
    
    
    <--- JS stacktrace --->
    
    ==== JS stack trace =========================================
    
    Security context: 0x36d7062b4629 <JS Object>
        1: toString [buffer.js:~440] [pc=0x2bc3203fde03] (this=0x368bd8af6d91 <an Uint8Array with map 0x3f1aefe8aeb9>)
        2: arguments adaptor frame: 3->0
        3: /* anonymous */(aka /* anonymous */) [/home/boomzilla/nodebb/node_modules/mongodb/node_modules/mongodb-core/node_modules/bson/lib/bson/parser/deserializer.js:~37] [pc=0x2bc3206d96c4] (this=0x36d7062041b9 <undefined>,buffer=0x368bd8af6d91 ...
    
    FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
    

    D'oh! Of course, the code to update topic bookmarks was mine. 😞



  • @boomzilla It couldn't remember what it was doing...


  • ♿ (Parody)

    @xaade Because it's remembering too much.

    Gotta get my head back into node async world and figure out how to break it up better.


  • ♿ (Parody)



  • @boomzilla
    Those of us who do not remember DiscoCoding are doomed to repeat its shortcomings 🚎


  • ♿ (Parody)

    Looks like it has been fixed.


Log in to reply