%O8s4SGAd8CDf+GTiW3Ids2OucmXViZT1RNSSyJx5Sjw=.sha256

@ev8 years ago %O8s4SGAd8CDf+GTiW3Ids2OucmXViZT1RNSSyJx5Sjw=.sha256

Created a git issue

Stability has been an issue for me with git-ssb-web of late.

git-ssb-web often is 'killed' by the OS without warning, and I have to go in and manually restart it.

I was running git-ssb-web on gitmx.com on a 256mb Ramnode instance with 1gb of swap. I figured this was the issue. So I fired up a new vps on DO (using vps2arch to archify it) and added 1gb of swap. There's nothing else running on this vps. I launched git-ssb-web and almost immediately it was 'killed' by the OS. I did this a few times during the night without success for more than a half an hour.

I'm guessing this is because git-ssb-web is consuming too much memory? 256 + 1gb/swap used to be plenty, but now 512 + 1gb/swap doesn't seem to be enough to run git-ssb-web on my vps.

@Dominic8 years ago %7YY9x6hWS1tEamKe2fhmG753w6AAF1NrDftpKX6gNTM=.sha256

there are now a lot more git-ssb repos. is that related?

@cel8 years ago %hzb81BT+Q+tqFDehxMKF+jdw7T17+kQzW0suT+hUGpw=.sha256

Does it crash just on starting to run it, or after browsing some pages?

There was a change I made in ssb-git-repo recently that might be contributing to this - I can try undoing that. It also could be because of there being more repos and more content on the network.

@ev8 years ago %dTHXGQlaHGOC1zt5Rbb6k59i0GgOHSpgVzpZNVuvwcc=.sha256

@cel I wish I could tell you when it is 'killed', but it's not consistent. It doesn't seem to relate to one particular thing that I'm doing. In fact it's more frequent that I've discovered that it's 'killed' upon checking gitmx after returning from grabbing a taco.

I realize that's not very helpful, but I'm up for reverting to a previous commit to see if that helps things.

@cel8 years ago %TbVfxBqi+OV936nQA0CLDsum0BhEsJclHBr5YBcq7KY=.sha256

@ev can you try reverting 6f1c8eb546ba380683c4a484ef66530c7d819591 in ssb-git-repo? Or find ssb-git-repo/lib/repo.js and apply this patch:

diff --git a/lib/repo.js b/lib/repo.js
index 35aabe4..c5744c1 100644
--- a/lib/repo.js
+++ b/lib/repo.js
@@ -447,11 +447,11 @@ Repo.prototype.getObject = function (hash, cb) {
 }

 Repo.prototype.getPackfile = function (id, cb) {
-  this._getBlobCached(id, cb)
+  this._getBlob(id, cb)
 }

 Repo.prototype.getPackIndex = function (id, cb) {
-  this._getBlobCached(id, cb)
+  this._getBlob(id, cb)
 }

 Repo.prototype.packs = function () {

@ev8 years ago %0J6QJzOFAYy9W1ZWSr1DK3J4KYC50SN4hxiJ1d4a4s8=.sha256

Ok, reverted to git-ssb-repo@1.8.3

Let's all try to crash gitmx.com

@ev8 years ago %KZEZEVsQcYKYP3hGl5Bar+p9ie8tKEdaaLkN16lEjYo=.sha256

@cel Seems a lot stable, and also faster to me already.

I'll be sure to report back in the morning if it crashes overnight.

@cel8 years ago %3WMk60Su0vK/7WkBNG5+rJwhiTW0EjNOv8vB7ooXTq8=.sha256

Ok, cool

@ev8 years ago %zd+V9AtwQGW2b1gNCUuXRTpRBZvViYMz6fjZtktbsR8=.sha256

It died, but it was not killed. The good news is I have an error

buffer.js:8
class FastBuffer extends Uint8Array {}
^

RangeError: Maximum call stack size exceeded
    at Buffer.Uint8Array (native)
    at FastBuffer (buffer.js:8:1)
    at Buffer.slice (buffer.js:817:10)
    at next (/home/ev/gitmx/node_modules/pull-buffered/index.js:61:23)
    at readData (/home/ev/gitmx/node_modules/pull-buffered/index.js:11:7)
    at readChunk (/home/ev/gitmx/node_modules/pull-buffered/index.js:79:7)
    at /home/ev/gitmx/node_modules/pull-git-repo/index.js:414:7
    at next (/home/ev/gitmx/node_modules/pull-buffered/index.js:33:9)
    at readData (/home/ev/gitmx/node_modules/pull-buffered/index.js:11:7)
    at readLine (/home/ev/gitmx/node_modules/pull-buffered/index.js:43:7)

@Dominic8 years ago %sBL+I3pTH8CM2wv97YXkvkA76j+XzdRc52PHZnH8CO4=.sha256

I think we have fixed this bug in other pull-streams,
for example
https://github.com/pull-stream/stream-to-pull-stream/commit/5b3ebd83cc540d163c232c02d56bb20593f3db35

since pull-buffer reads in a loop, if it happens to be sync (if a big queue has built up) then it can blow the stack. The simplest way to fix is to use nextTick, but the best way is to detect if it's sync and use iteration.

I made https://www.npmjs.com/package/looper to solve that problem.