部署到數字海洋的流星應用程序停留在100％的CPU和OOM

我有一個流星（0.8.0）應用程序部署使用流星到數字海洋一直被卡在100％的CPU，只有在內存不足時崩潰，以及以100％的CPU再次啓動。它在過去的24小時內一直如此卡住。奇怪的部分是沒有人使用服務器和meteor.log沒有顯示出很多線索。我有MongoHQ oplog的數據庫。部署到數字海洋的流星應用程序停留在100％的CPU和OOM

數字海洋規格：

1GB內存30GB SSD磁盤紐約2的Ubuntu 12.04.3 64

屏幕截圖顯示的問題：

enter image description here

注意截圖昨天捕獲並它一直保持與100％cpu掛鉤，直到它崩潰，內存不足。日誌顯示：

FATAL ERROR: Evacuation Allocation failed - process out of memory error: Forever detected script was killed by signal: SIGABRT error: Forever restarting script for 5 time

Top顯示：

26308 meteorus 20 01573米644米4200轉98.1 64.7 32：45.36節點

它是如何開始：我有一個應用程序，需要在通過csv或mailchimp oauth發送電子郵件列表，通過批處理過程調用http://www.fullcontact.com/developer/docs/batch/將它們發送到fullcontact，然後根據響應狀態相應地更新Meteor集合。從200響應

if (result.statusCode === 200) { 
      var data = JSON.parse(result.content); 
      var rate_limit = result.headers['x-rate-limit-limit']; 
      var rate_limit_remaining = result.headers['x-rate-limit-remaining']; 
      var rate_limit_reset = result.headers['x-rate-limit-reset']; 
      console.log(rate_limit); 
      console.log(rate_limit_remaining); 
      console.log(rate_limit_reset); 
      _.each(data.responses, function(resp, key) { 
       var email = key.split('=')[1]; 
       if (resp.status === 200) { 
        var sel = { 
         email: email, 
         listId: listId 
        }; 
        Profiles.upsert({ 
         email: email, 
         listId: listId 
        }, { 
         $set: sel 
        }, function(err, result) { 
         if (!err) { 
          console.log("Upsert ", result); 
          fullContactSave(resp, email, listId, Meteor.userId());        
         } 
        }); 
        RawCsv.update({ 
         email: email, 
         listId: listId 
        }, { 
         $set: { 
          processed: true, 
          status: 200, 
          updated_at: new Date().getTime() 
         } 
        }, { 
         multi: true 
        }); 
       } 
       }); 
       }

本地在我的懦弱的Windows筆記本電腦上運行放浪一個片段，我有任何一次處理成千上萬的電子郵件沒有性能問題。但在數字海洋上，它甚至無法處理15,000個看起來（我已經看到CPU峯值達到100％，然後與OOM崩潰，但在它出現後，它通常會暫停......而不是現在）。令我擔心的是，儘管應用程序沒有/很少活動，但服務器仍然沒有恢復。我通過查看分析來驗證這一點--GA在整個24小時內顯示了9個會話，並不僅僅是點擊/彈跳，MixPanel在同一時間段內只顯示1個登錄用戶（我）。而且，由於最初的失敗，我做的唯一的事情就是檢查facts包，其中顯示：

mongo-livedata observe-multiplexers 13 observe-drivers-oplog 13

oplog-watchers 16 observe-handles 15 time-spent-in-QUERYING-phase

87828 time-spent-in-FETCHING-phase 82 livedata

invalidation-crossbar-listeners 16 subscriptions 11 sessions 1

流星APM還沒有顯示出任何不尋常的，該meteor.log不顯示任何除OOM外的流星活動和重新啓動信息。 MongoHQ不報告任何運行緩慢的查詢或很多活動 - 通過查看，更新，插入或刪除平均監視儀表板上的平均值。據我所知，24小時沒有太多活動，當然沒有任何密集的活動。我已經嘗試安裝newrelic和nodetime，但都不工作 - newrelic不顯示數據，meteor.log有nodetime調試消息

加載失敗的nodetime本機擴展。

因此，當我嘗試使用nodetime的CPU分析器時，它變成空白，並且堆快照返回錯誤：未加載V8工具。

我基本上沒有想法在這一點上，因爲Node對我來說很新，所以感覺就像我在黑暗中的野生刺傷。請幫忙。

更新：服務器仍然在四天後100％掛鉤。即使是init 6也不會做任何事情 - 服務器重新啓動，節點進程啓動並跳回到100％cpu。我嘗試了其他工具，如memwatch和webkit-devtools-agent，但無法讓它們與Meteor合作。

以下是strace的輸出

strace -c -p 6840

Process 6840 attached - interrupt to quit

^CProcess 6840 detached

% time seconds usecs/call calls errors syscall

77.17 0.073108 1 113701 epoll_wait

11.15 0.010559 0 80106 39908 mmap

6.66 0.006309 0 116907 read

2.09 0.001982 0 84445 futex

1.49 0.001416 0 45176 write

0.68 0.000646 0 119975 munmap

0.58 0.000549 0 227402 clock_gettime

0.10 0.000095 0 117617 rt_sigprocmask

0.04 0.000040 0 30471 epoll_ctl

0.03 0.000031 0 71428 gettimeofday

0.00 0.000000 0 36 mprotect

0.00 0.000000 0 4 brk

100.00 0.094735 1007268 39908 total

所以它看起來像節點過程花費大量的時間在epoll_wait。

來源

2014-04-18 landland

我對Meteor並不熟悉，但是您正在使用_.each遍歷結果，並對潛在的巨大集合項執行異步I/O。這意味着如果你有15,000個項目，所有的15,000個upserts等將被嘗試同時寫入。你應該嘗試使用async.eachLimit或類似的。 – eshortie

我有一個類似的問題。我不需要Oplog，並且我建議添加流星包「disable-oplog」。所以我做了，並且CPU使用率減少了很多。如果你沒有真正利用Oplog，最好禁用它，所以meteor add disable-oplog，看看會發生什麼。

我希望這會有所幫助。

來源

2014-05-11 17:05:39 afuggini

部署到數字海洋的流星應用程序停留在100％的CPU和OOM

回答

相關問題